-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
DRAFT: Update themes to use new Automatic History Management #1951
base: master
Are you sure you want to change the base?
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
...so the plugin is friendly to variables already marked read-only.
...and hide errors relating to setting already-readonly variables. `plugin/history-eternal` does not need to force loading after `plugin/history` because both plugins will play nicely with read-only variables, and since we're overwritting and marking read-only then the intended result survives no matter which loads first. plugin/history-eternal: require Bash v4.3+ Unlimited history is only possible in _Bash_ version 4.3 and up
There's no need for these plugins to load after `plugin/history`. None of the history plugins depend upon each other loading before, after, or at all.
Two new functions `_bash-it-history-auto-save()` and `_bash-it-history-auto-load()`, which append new history to disk and load new history from disk, respectively. See Bash-it#1595 for discussion.
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. |
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
.