Make possible to customize themes "history" behavior consistently

[3v1n0]

Bash-it base theme provides _save-and-reload-history() function that does history actions depending on user settings.

While this is defined as [[ $autosave -eq 1 ]] && history -a && history -c && history -r , the input parameter isn't a global bash-it variable, and so each theme may use its own (the only one supporting it, powerline, seems to use $HISTORY_AUTOSAVE.

In the other side, I see various themes doing:

prompt_setter() {
  local exit_status=$?

  # Save history
  history -a
  history -c
  history -r

  PS1="foooo"
}

Now, I've a big history file, so while I do want to use history -a all the times, I don't want to reload it once saved, but do it on-demand.

At the same time, some themes don't do this, so there's no consistency.

So, things to do are:

• Provide HISTORY_AUTOSAVE_* variables to define what actions to do with history
• Use _save-and-reload-history() in all the themes

[nwinkler]

Good idea! Do you want to get started with this work, e.g. defining the variable, and then adjusting the first couple of themes? Maybe start with the one you're using...

[davidpfarrell]

Greetings, Below is a bit of Stream of consciousness, so apologies in advance.

So this was introduced in #1379 and was only implemented in powerline-plain.

It is not clear to me what the best practices are for using these history features, i.e is "-a -c -r" the most commonly-used feature combo?

Its also not clear to me how to conveniently expose ALL history features via environment variables. i.e do we want to offer a plethora of variables like:

# -c  clear the history list by deleting all of the entries
HISTORY_CLEAR=true

# -a  append history lines from this session to the history file
HISTORY_APPEND=false

# -n  read all history lines not already read from the history file
#     and append them to the history list
HISTORY_READ_NEW=false

# -r  read the history file and append the contents to the history
#     list
HISTORY_READ_ALL=true

-n and -r seem mutually-exclusive and feels like it would weird to enable both at the same time? Should the implementation be smart enough to prevent that, maybe defaulting to -r if both are enable?

Do the -d, -w, -p, -s options make sense to have as part of a built-in feature? I'm thinking not.

How portable are the options? Minimum bash versions, etc?

Would it ever make sense to the user to execute the arguments in a different order, or is -a -c -[rn] pretty much the only useful order to use them?

If the user opted out of some features (say did not enable -c) would you still expect to execute -a -n in that specific order. i.e. Could the optimum order change based on which feature(s) are enabled?

Should the user be able to control the order?

If there are a finite set of useful combinations of features, I might be inclined to support a single HISTORY_MODE variable with named-features as the value, ie.

export HISTORY_MODE="save_reload"

Or maybe let the user express the arguments:

export HISTORY_MODE="-a -c -n"

We could still parse the value and execute them individually (assuming history requires it?)

Ok thats all for now. Thanks for reading and lemme know your thoughts.

-DF

[nwinkler]

Thanks for the thoughts! Let's try to keep it simple...

To start off, we should implement a reasonable feature set. While the individual variables are probably easiest, they cause the issues you mentioned (precedence, mutually exclusive options, priority).

Maybe we should let the user provide their preference and then call the required commands. I would probably use an array instead of a string, since the array is easier to iterate over:

export HISTORY_MODE=( -a -c -n )

Thoughts?

[gaelicWizard]

Mixing these flags arbitrarily will basically destroy the user's history.

The combo -a -c -r specifically emulates "share history between running shells" (which is an actually expressly supported feature of some other shells). This basically flushes to disk, blanks in-memory cache, then loads fresh from disk.

Using -n reads history added by some other process, but it gets super super weird if the current shell is alsö appending history. I found I get duplicates appearing /and disappearing/ during usage. No idea how this interacts with $HISTCONTROL.

Reasonable modes would be:

1. Share history among running shells automatically (-a -c -r), HISTORY_MODE="autoshare" or maybe just auto;
2. Save history automatically but don't load anything (-a), HISTORY_MODE="autosave";
3. Load history automatically but don't save anything until exit, HISTORY_MODE="autoload";
4. Don't do anything special (by default, history is overwritten on exit using what was loaded at start plus current session), HISTORY_MODE="".

NOTE: Bash expressly documents that unknown keywords in $HISTCONTROL are ignored, so it may make more sense from a UI/UX point of view to use that instead of $HISTORY_MODE.

Aside: Apple does some shenanigans with history that I will go off on if you ask me. 🤬

---

Alsö, I don't think history management should be a feature of the theme. Bash It should handle this separately from the theme.

---

One possible improvement I can think of is to use some preexec/precmd to separate the write from the read. (Currently, history is updated on next prompt.)

[gaelicWizard]

@3v1n0, does #1940 address your need? I think you would use mode autosave (don't re-read from disk, but do append). That said, I alsö have a monstrous history and I just let it re-read from disk all the time b/c the other parts of my prompt are just so much heavier that it doesn't matter! 😃