-
Notifications
You must be signed in to change notification settings - Fork 2.3k
DRAFT: Update themes to use new Automatic History Management #1951
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
0ae7dcb
to
8220aa2
Compare
@davidpfarrell, this is "stacked" on my automatic history management PR, which has been approved, but I'd love to start getting feedback on this one pending that one getting merged. Do you think I should just remove all history management from themes rather than just adopting the new functions? I think that might require an update to the documentation too. |
edba5dd
to
4ae213a
Compare
34c9d79
to
95148bf
Compare
1c5a6d3
to
ec96c60
Compare
8ee61fd
to
455bbe2
Compare
455bbe2
to
52bac07
Compare
d698955
to
0e88fd0
Compare
0e88fd0
to
7825eb9
Compare
First pass to use _Bash It_'s automatic history management.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
Use `preexec` and `$HISTCONTROL` to configure _Bash It_'s automatic history management feature.
7825eb9
to
ee65fd8
Compare
@cornfeedhobo, would you suggest just yanking all history-related tomfoolery from themes or to update them to interact with the new automatic history management? Long term, I vote for themes-don't-touch-history, but I'm conflicted about short-term. |
I'm all for a hook mechanism, of course, where themes don't touch any other function like history. |
@akinomyoga looks legit? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description of thsi PR seems to imply that this PR is intended to preserve the existing behavior of themes while using the new mechanism of the history syncing. However, the changes in this PR seem to drop the support for HISTORY_AUTOSAVE
, which the old mechanism used but lib/history.bash
doesn't reference.
The following values of HISTCONTROL
do not seem to be documented at all. Also, it should be clarified that auto-save
is called before running the command, and auto-load
is called after running the command. These should be documented somewhere.
From the PR cover of #1940 (comment)
autoshare
: append to$HISTFILE
when_bash_it_history_auto_save()
called, and read from$HISTFILE
when_bash_it_history_auto_load()
called.autosave
: append to$HISTFILE
when_bash_it_history_auto_save()
called, but do not do anything when_bash_it_history_auto_load()
called.autoload
: do not do anything when_bash_it_history_auto_save()
called, but do read from$HISTFILE
when_bash_it_history_auto_load()
called.noauto
(default): don't do anything.
# Append new history lines to history file | ||
HISTCONTROL="${HISTCONTROL:-}${HISTCONTROL:+:}autosave" | ||
;; | ||
esac |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hooks into preexec and prompt_command are missing.
All the themes touched in this PR seems to have called _save-and-reload-history
in prompt_command
, but auto-load/save are registered to preexec/prompt_command for some themes and not for other themes. What are the differences? Are they just oversights? Or is it intentional?
edit: Anyway, I suggest removing all these additional hooks as discussed in #1951 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question is do I keep fixing this or just close and bury it? Maybe it's just the wrong approach altogether.
safe_append_preexec '_bash-it-history-auto-load' | ||
safe_append_prompt_command '_bash-it-history-auto-save' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compared to _bash-it-history-init
(in lib/history.bash
), the commands for preexec
and prompt_command
are reversed.
Lines 5 to 8 in dc25be3
function _bash-it-history-init() { | |
safe_append_preexec '_bash-it-history-auto-save' | |
safe_append_prompt_command '_bash-it-history-auto-load' | |
} |
Thinking of the functions that auto-load
and auto-save
perform, I think the "save" should be performed before running the command, and the "load" should be performed before the prompt command.
In addition, why don't they simply call _bash-it-history-init
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it seems _bash-it-history-init
is anyway forcibly loaded at the end of bash_it.sh
through _bash_it_library_finalize_hook
.
Line 49 in dc25be3
_bash_it_library_finalize_hook+=('_bash-it-history-init') |
One possibility is that the above "reversed hooks" are intended to complement load/save that haven't been registered by _bash-it-history-init
to perform both load/save in both preexec and prompt_command. However, I don't see the reason for running both twice before running the command and after running the command. The default hooks set up by _bash-it-history-init
seem sufficient to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My suggestion is to remove all safe_append_preexec '_bash-it-history-auto-load'
and safe_append_prompt_command '_bash-it-history-auto-save'
from this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in other words, it really needs to be redone. I'll dump it.
case $HISTCONTROL in | ||
*'auto'*) | ||
: # Do nothing, already configured. | ||
;; | ||
*) | ||
# Append new history lines to history file | ||
HISTCONTROL="${HISTCONTROL:-}${HISTCONTROL:+:}autosave" | ||
;; | ||
esac | ||
safe_append_preexec '_bash-it-history-auto-load' | ||
safe_append_prompt_command '_bash-it-history-auto-save' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, there are too many repetitions of this code section. These lines should be factorized into an independent function (defined in e.g. lib/history.bash
), and I think each theme should contain a single line of the call to the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed.
This is not about this PR itself, but this is about the implementation detail of "the new automatic history management" that this PR relies on: Lines 27 to 32 in dc25be3
I think the above case-statement should test the exact fields split by case :$HISTCONTROL: in
*:'noauto':*)
: # Do nothing, as configured.
;;
*:'autosave':*)
# Append new history from this session to the $HISTFILE
[...] |
Description
This follows up on my
history
(#1940) branch to adopt the two new functions in all themes which had already included history management.Closes #1595.
Motivation and Context
This PR adopts the new functions from #1940 and removes all use of the old function
_save-and-reload-history()
, but does not remove the function yet (in case anyone is using it somewhere out of tree...for the time being).A future PR should remove all history-related activities from all the themes. I didn't do that here as I want to be as minimally-invasive as possible in this PR. At that time, it will need to be determined how to account for users who have not enabled
plugin/history
but who use a theme which triggershistory -a
...their history would after that future PR suddenly stop saving the way they're used to.How Has This Been Tested?
All tests pass.
Types of changes
Checklist:
clean_files.txt
and formatted it usinglint_clean_files.sh
.