The question of whether fish can synchronize history between running shells came up twice on IRC today, and has been asked before as well.
With fishd I imagine we have some of the infrastructure for this in place already, so perhaps implementing it wouldn't be too hard. However, I also think this is something not everyone wants to have all the time, and we also want to avoid adding configuration options. So the question then is, can we accommodate most needs without configuration?
One idea is to have something like say, history --synchronize, and then provide events like "executed a commandline" or perhaps it's enough to do a function -v history, and then people who want this can script it.
I don't think that idea is optimal: it's not discoverable (you have to script it) and you can only have either behavior at any given time.
I instead propose making the history wrap around to a synchronized history; that is, if you step or search forward in the history when you are at the bottom (such as is the normal state when on the commandline and you haven't used history-search-backward yet), you're acting on a reversed history of commands entered in any shell. This way, the current behavior of history-search-backward is retained and can be used just like we've always use it, but we can also initiate a history search forwards to navigate the universally synchronized history.
Remaining questions:
- Should the synchronized history also include items from the local history? I think it should, because some people will prefer to always use the synchronized history, and because I think it'll be easier to remember to use the synchronized history when you need it than the opposite.
- What should happen if you do something like
C-p C-n C-n? I think this should work just like only doing C-n, which is to say "get the latest command used in any shell", and which is in line with the view of these two histories "wrapping around" above and below the commandline.
(BTW, this idea comes from zsh, which I hear can be made to do something like it, although I haven't actually studied exactly how it behaves.)
The question of whether fish can synchronize history between running shells came up twice on IRC today, and has been asked before as well.
With
fishdI imagine we have some of the infrastructure for this in place already, so perhaps implementing it wouldn't be too hard. However, I also think this is something not everyone wants to have all the time, and we also want to avoid adding configuration options. So the question then is, can we accommodate most needs without configuration?One idea is to have something like say,
history --synchronize, and then provide events like "executed a commandline" or perhaps it's enough to do afunction -v history, and then people who want this can script it.I don't think that idea is optimal: it's not discoverable (you have to script it) and you can only have either behavior at any given time.
I instead propose making the history wrap around to a synchronized history; that is, if you step or search forward in the history when you are at the bottom (such as is the normal state when on the commandline and you haven't used
history-search-backwardyet), you're acting on a reversed history of commands entered in any shell. This way, the current behavior ofhistory-search-backwardis retained and can be used just like we've always use it, but we can also initiate a history search forwards to navigate the universally synchronized history.Remaining questions:
C-p C-n C-n? I think this should work just like only doingC-n, which is to say "get the latest command used in any shell", and which is in line with the view of these two histories "wrapping around" above and below the commandline.(BTW, this idea comes from zsh, which I hear can be made to do something like it, although I haven't actually studied exactly how it behaves.)