Hooks have always been a mess. There was no organization when they were
added, as when the project first started there was no need for them.

To make things consistent, break out disabling hooks into
__lp_disable_hooks(), and make prompt_on() be the enabler of hooks. Then
have lp_activate() disable hooks at the start, and enable hooks at the
end.

Some small changes around how state is detected, but no functional
difference here.

Based on the work done in ecdde384, the
prompt_bang and prompt_subst options, which handle '!' and '$'/'`'
characters respectively, can be left untouched. When running
__lp_escape(), those options are checked, and if set, their characters
are escaped.

prompt_percent however, must still be enabled always. The shell sequence
escapes, '%{' and '%}' only work when the option is enabled. Maybe
someday we can detect when the option is off and disable all terminal
formatting, but it doesn't seem worth the effort.

Backslashes must be escaped even on Zsh to prevent confusion with a
backslash directly preceding a character that would give is special
meaning.

For some reason, Bash ignores a '\$' sequence when the promptvars option
is off, printing it as '$'. It does not do the same for a backtick
escaped: '\`' is printed as '\`'. To prevent this issue, detect if the
option is on, and if so, escape both '$' and '`'.

Running 'shopt' is actually faster than either a [[ ]] or (( ))
expression.

Extension to #496 to add [AWS Vault](https://github.com/99designs/aws-vault)
support. AWS Vault does not set the AWS_PROFILE/AWS_DEFAULT_PROFILE
variables, but does add AWS_VAULT. Since this is philosophically the
same as showing an AWS profile on the prompt, I simply added AWS_VAULT
to the detection chain.

Also remove some trailing space.

Closes: nojhan/liquidprompt#675

This was missed in the PR for the Ruby Virtualenv section.
The order in the docs for Terraform and Kubecontext was backwards from
the order in the code.
Moved parts of the PS1 building to different lines to make it easier to
read and add new sections.

Resolves #676

LP_KUBECONTEXT_DELIMITER_SUFFIX removes a suffix (dev-cluster and - becomes ->
dev). But sometimes the boilerplate part is a prefix, as when using AWS
EKS (Elastic Kubernetes Service).

`aws eks update-kubeconfig --name $CLUSTER_NAME` sets the cluster's ARN
as the context name, most of which is boilerplate:
`arn:aws:eks:$REGION:$ACCOUNT_ID:cluster/$CLUSTER_NAME`.

This breaks several VCS functions (mercurial, fossil, svn).

Rarely, sensors or acpi can return no temperature data. In this case,
the data function would return false and 0, but the detect function
would error if set -u was enabled.

Harden all of the four temperature functions against this, and greatly
increase the test coverage to cover these four functions, as well as
adding a specific case for the tools returning no data.

This also allows for the temperature functions to return values less
than 0, if somehow a device has all temp sensors returning less than
that.

Mention in the function documentation that it is possible for the
function to return a not set string.

Fixes 670

Fixes https://github.com/nojhan/liquidprompt/issues/600.

Zsh 5.0 continues to be a huge pain. As noted in the shell wiki, all
variables assigned to another variable as part of a 'local' or 'typeset'
line must be quoted, or things will break. The reason I caught these
many instances was a failing test on Zsh-5.0.8 because of the bad line
in __lp_pwd_tilde().

Parameter substitution is (like most standards) weakly defined, and here
is a case where it was not tested on Zsh. Simple fix of wrapping the
whole string (the '(' was the bad character) in quotes.

Also add a test case to catch a regression.

Fixes #667

When the LP_COLORMAP config option contained a first element that was
the empty string, lp_activate() would think it was empty, and set
LP_COLORMAP back to the default value.

This was identified by @milouse in a comment here:
https://github.com/nojhan/liquidprompt/pull/628#discussion_r611182040

The issue is not severe, as any value set in the config will always be
taken (as it is set last). But a value set in the environment, either
manually or in a shell RC file would be overridden (as long as the first
element was the empty string).

Commit e121179d has a good explaination
of why the ${array[@]+"${array[@]}"} form is used. This unfortunately
must be used _anywhere_ an array could be empty or have any empty
strings as values.

Fixes: https://github.com/nojhan/liquidprompt/issues/249

The problem is simple enough: the extra backslashes or percents that
__lp_escape() adds show up in the title, as the title is changed in the
previous commit to no longer be printed as part of PS1. The fix is not
so simple.

This patch adds "raw" copy of the data strings for username, hostname,
and current path with no color or shell character escaping. This is
designed for putting into the terminal title, but it could also be used
for comparisons. lp_path_format() already had a no formatting return var
in lp_path, but now it is not shell escaped.

The title is changed from duplicating the prompt to instead showing just
the core bits in the central brackets: username, hostname, current path,
followed by the prompt mark. As well as the user prefix, postfix, and
MARK_PREFIX. This is a change from the long standing default, but it is
customizable both by themes and users, and I have long seen complaints
of the current title layout being less than helpful.

There is one small issue though: to prevent LP_PS1_PREFIX,
LP_PS1_POSTFIX, and LP_MARK_PREFIX that have color from messing up the
title, the whole title string is still passed into lp_formatted_title()
to strip color out. This is less than ideal, but faster than treating
those 3 variables by themselves.

Rationale:

* In general, it is not proper for liquidprompt to change shell
  options that it does not absolutely have to change.

* LP_PS1_{PREFIX,POSTFIX} are a thing, and are in fact an effective
  means to combine liquidprompt with other prompt-touching logics
  (such as emacs-vterm).  So it is not good to prevent those other
  logics from actually working.

This commit restores the bash version of __lp_escape to what it did
prior to 62f02708 (escaping dollar signs in addition to backslashes)
and removes all interference with the promptvars shell option.

NOTE: I don't know much about shells other than bash, so left the
parallel logic for zsh as is.

This feature depends on the removal of the prompt escape sequences that
came before. Part of that is the removal of adding the title to $PS1:
now it is just print to the screen. This could improve speed slightly,
as the shell doesn't need to parse that text. But it does prevent usage
of prompt escape codes in the title.

Which causes a rare issue where __lp_escape() adds duplicate backslashes
or percents to escape a string for the prompt, but now are not needed in
the title. It will just print double in the title, so it isn't a huge
issue, but is something that should be fixed. I'm not sure how to handle
it though, since the current architecture requires escaping the strings
before formatting is added to them.

I also needed to rework how the runtime feature was handled, since it
monopolized the DEBUG trap in Bash. Now it can handle multiple features
that need to run after the user has submitted the command, but before it
runs.

The feature itself is simple: lookup the latest command in the history,
and print the normal title postpended by that command to the screen,
formatted as a terminal title. Note that Bash's $BASH_COMMAND is not
great, as it only contains the current _command_, not the whole command
line.

Resolves #609

This was forgotten before.

This was added in commit 74e14fe0. I
don't understand why, except that maybe a single backslash display would
look like an escape code for a control character, like \n. But that is
not the case for Bash, so why the difference?

Zsh only uses percents (%) to escape things in the prompt, where Bash
only uses bashslashes. This changes makes the same input string print
the same way in the prompt for both shells.

Again further work on #651. This time it is simple: both Bash and Zsh
set the exact same hostname that they use for their prompt escape
sequences into HOSTNAME and HOST, respectively.

Then it is a simple matter to replicate their "short" version by
truncating the string to the first period.

Another replacement for #651, this one was mostly simple. Unfortunately,
not all shells set an environment variable for user. Zsh always sets
USERNAME, but neither Bash nor Zsh set USER. login(1) does however, so
it _should_ always be set. See https://unix.stackexchange.com/a/76356/421569
for some good info.

Fall back to id -nu just in case the variables don't work. I don't know
how portable that command is, but since it is a backup, it should be
fine.

By calling date(1), another shell prompt escape sequence is removed.
This also allows for custom formatting strings.
Add and update docs for time functions.

Resolves #281

Part of #651, this removes a shell prompt escape string, making it
easier to work with terminal titles, as well as making it possible to
customize the prompt mark for the root user. This patch does not do
that, as the functionality has remained the same, but it would now be
possible to add a LP_MARK_ROOT.

This patch should have no functional difference, as the checks that Bash
and Zsh did in the prompt escape are exactly the same that Liquidprompt
is doing: comparing EUID to 0.

This will add `[profile_name]` to the prompt should it find either
`AWS_PROFILE` or `AWS_DEFAULT_PROFILE` set in the environment.

This is useful when switching between different AWS profiles and
working with multiple accounts.

Add a data source to get the current Kubernetes context. Includes a
mechanism for truncating the context to the first matching character,
configurable.

The data source is disabled by default. The truncation is also disabled
by default (disabled by setting the config option to the empty string).

Add a default theme function to format the context like the other
development environments.

Git worktrees (see git worktree --help) are registered as .git _files_
instead of directories. This meant Liquidprompt would fail to detect
them. Since other VCSs do not have similar files, add a special case for
Git files like this.

Fixes #658

On terminals with the default background color as white, the colors used
by default for the path sections would stand out strongly. By removing a
specific background color, and making most of the sections have no
specific foreground color, the colors will work on both dark and light
backgrounds. The "lowlight" colors, used for shortened paths and path
separators, are now middle of the spectrum grey, which works for both
light and dark as well.

Update the documentation to match these slightly changed defaults.

This will be a patch version bump, as the defaults should be no
different for users with dark backgrounds, but should very much improve
for those with light backgrounds.

Fixes #657

Windows Bash does not set USER, at least inside Github actions.

While liquidprompt has a unset safe TERM check at the top of the file
that will bail out of liquidprompt if it is not set, that check can be
skipped with the --no-activate flag, which is used in the tests. Zsh
seems to not set the TERM var when run with no terminal, so these need
to be safe.

Bash 3.2 scans a whole line for unset problems, unlike later versions,
which will exit the line if the boolean expression returns False
already. So we need to have a safe exit when unsafe for
_LP_RUNTIME_SECONDS on Bash 3.2.

This SO post is super helpful: https://stackoverflow.com/a/61551944/8338372
This is why the ${array[@]+"${array[@]}"} form is used, anywhere either
the arary could be empty, or the array could have empty strings as
values. Most of our array usages we know for sure there are good values
in, but user config ones we have no way to know for sure.

Change source path for liquidprompt file in theme-preview. Zsh expects a
sourced filed with no path to be on the Bin path, which liquidprompt
won't be. By changing to a relative path, that is fixed. While that
script is designed to be run under Bash, it works just fine under Zsh,
so why not run it under Zsh to test Liquidprompt as a whole.

Also add an exit condition in the theme-preview where the passed in
theme does not exist.

Add tests for the two tools scripts, just to check that they don't exit
with errors.

Fixes #656

This config variable is a great case of "no perfect default for anyone".
Every machine is different, and each user wants to see different things.
That is why I added it as a config option.

But there are two good arguments for making this change to the default:

* Often users report that they reach the top of the color range too
  quickly.
* Only four of the LP_COLORMAP colors would be displayed with the old
  default. With this change, seven will be. This means there are more
  colors shown for a longer gradient, and when the value is starting to
  be displayed it doesn't start right away at "danger" colors.

The load average display has been notoriously not helpful. It is scaled
by the CPU count, and then multiplied by 100 to make it apear like a
percentage. But load average and CPU utilization have almost nothing to
do with each other.

This change displays the actual load average, while keeping the
threshold and color calculations the same. This means the functionality
is no different, just that the display has changed formats.

To make the configuration options LP_LOAD_THRESHOLD less confusing, it
too has been changed to be an actual load value, no longer "centiload".
Old values are still supported, which is done by checking for a period
('.') in the string. So for this historical reason, all new values must
have a period in them. Which should not be a problem, any useful value
would be a float.

Change the greater-than comparison to a greater-than-or-equal-to, since
it is a little more intuitive to what would be expected from the config
option.

Since I was at it, I added a new config option LP_LOAD_CAP, to configure
the range for color values output by _lp_color_map() for load averages.
It too takes a load average float value. As it does not have the
historical reason above, it does not accept "centiload" values.

The implementation details are long. Floating point math does not exist
in shells (which I suspect is the reason that "centiload" was used in
the first place). To make it possible to compare, the values are scaled
up by 100 just like before. They are not shown to the user. 100 scaling
should be plenty for the precision we need.

To do the scaling, __lp_floating_scale() is added, which as a standalone
function, can be unit tested.

And for good measure, the lp_load return value is passed through
__lp_escape(), just in case.

Special thanks to Tore Anderson (@toreanderson) for helping dig through
the issues here.

I have yet to come accross any instance of Zsh less than version 5.0.0,
but the check is cheap, and I would rather be explicit. As far as my
testing and interpritation of the Zsh release docs
(http://zsh.sourceforge.net/releases.html) goes, we should have no
problem supporting versions of Zsh back to 5.0.8 or so. I have not seen
any version less than 5.0.8, but I would assume that they should work.

Before zsh-5.1, assignments after a local/typeset were treated like any
other argument, not assignments, and so they were expanded as such. To
fix this, simply quote them like arguments, or move them to their own
line to make them parse like arguments.

I went for a mixed use, where single variable declarations I kept on one
line and quoted, but multi-variable declarations I moved the assignments
to following lines.

This is why code coverage is amazing. I missed writting tests for this
specific case, which allowed a bug to slip through.

Zsh did not know how to handle a ${var//[!"string"]} syntax, so remove
the quotes and replace it with a backslash.

Add tests to cover that case to prevent a regression.

Some of the execution paths of _lp_path_format() would return a correct
lp_path value, but most would not. This variable should contain the same
shortened path as lp_path_format, but without any of the formatting or
special separators.

Add tests to test lp_path for each shortening method.

These are tame defaults, no colors, just shades of white for the
different path elements.

Both LP_PATH_DEFAULT and PROMPT_DIRTRIM needed shell escape sequences to
work, which is impossible to add our formatting to.

There is no way to support LP_PATH_DEFAULT and add our formatting, so
don't add the formatting in the shim.

We can get a pretty close approximation of PROMPT_DIRTRIM + our
calculating function by using the default shorten method.

LP_PATH_KEEP=-1 has not changed in function, only that now that we have
a LP_PATH_METHOD selection, that is the prefered way to do it.

It works exactly like how LP_PATH_KEEP=-1 does. Simply display the
current directory. It will be formatted with the last dir format, unless
LP_PATH_VCS_ROOT=1 and the current directory is the root, in which case
it will be the vcs formatting instead.

In Liquidprompt v1, this path truncation was simple; just cut out the
correct number of characters. But now that we can have a "special"
directory in the middle of the path (the VCS root) and also each
separator and directory needs its own formatting, this is much harder.

The extra tricky part is that a check is needed to see if we are
currently shortening already, and if so, not to fail out of the shorten
if it looks like we would "break even".