Pressing up prior to prompt being ready does not properly engage plugin behavior

[unphased]

I originally posted this on ohmyzsh/ohmyzsh#3857, but I realized that it belongs here, so I moved it.

Observe, if you run a long running process and type something that uses the shell's behavior, e.g. tab completion, as long as the process is not consuming stdin the shell will intelligently buffer your input for use when the prompt eventually arrives in the future.

For instance, zsh will tab complete globs when you hit tab. So if I type sleep 5 <ENTER> ls * <TAB>, what I will see is the shell waits for sleep to finish and then helpfully queues up my keystrokes, and ~3 seconds later I am automatically greeted by my prompt where i already have the contents of the current directory entered for me.

But the history-substring-search plugin does not apply this behavior properly. My aim here is to determine whether there is a systemic limitation that causes this unexpected behavior. When the shell prompt is being used normally, the plugin has perfect behavior. If the prompt is empty and I have not entered anything, then pressing up and down triggers the default behavior of fetching commands from history. Once I make an edit, though, the up and down keys trigger the plugin's search behavior using the contents of the command buffer to search.

The issue arises when I type commands during a long running process that does not consume input.

Suppose my command history at this point is this:

command A foo
command A bar
command B
command C
command D

(where command D is the long-running process not consuming input)

I type bar<Up> while D runs: zsh leaves my prompt on "command D". What I expect is the behavior I get if I type the same after D completes: "command A bar".

The behavior is that the part of the key queue that I typed prior to the movement key is discarded. I find that the best way to explain this is that the plugin behavior does not properly engage based on these queued up keystrokes.

If I disable the plugin and repeated the test, in both ways, I would get the same behavior because bar is essentially thrown away the moment that <Up> is pressed, in the absence of the plugin... this is standard default behavior.

So my Occam's Razor explanation of the problem is that the plugin's "edited buffer detection" feature is failing to produce a true value in the case of queued up keystrokes.

However, I tested some more and I discovered that if I bind pgup/pgdown keys to the plugin actions,

bindkey '^[[5~' history-substring-search-up
bindkey '^[[6~' history-substring-search-down

This actually works properly! This is confusing me because pgup/pgdown are by default also performing the same task in vanilla zsh, so the key conflict should still exist in this situation. The custom only-substring-search-if-buffer-is-edited behavior is still in effect as I use pgup/pgdn now, but any queued keystrokes prior to pressing pgup are now properly handled. This was definitely not expected and I cannot guess as to why this happens.

I was also hoping for a way to disable the only-substring-search-if-buffer-is-edited feature since I have demultiplexed the Up/Down keys at this point. But that is a separate topic.

[unphased]

I tried using zsh setopt XTRACE VERBOSE to debug, but it does not seem to emit any tracing when running zsh things triggered by key events (maybe zsh line editor (zle) related stuff? sorry I am not familiar with the zsh lingo or the subsystems...) so I am sort of stuck. I think there might be something related to zle -T that may help me since the docs say "debugging" associated with it a lot, but I don't know how to use this yet.

Actually, scratch that, I just found this. Neat trick!

[josefson]

I would like a solution for this problem as well. I tried fish and i loved that feature.

[unphased]

I can at least report that applying the "neat trick" I linked to above reveals that the zle widget for search up does NOT run in this situation. Do note that everything DOES FUNCTION PROPERLY if the action is bound to Page Up. The mission now is to find out why.

I was hoping I could hack it somehow (and there still may be a way!) but there is simply no way that I can re-wire my brain to use pgup/pgdn instead of arrow up down for navigating shell history.

So my next step was to delve into zsh source code, so that will have to wait a week or so, for me, at least.

Best case scenario is that zsh implements "cleverness" where if it sees "up" it abandons generating delayed fake keypresses. I hope that isnt what it's actually doing, but I also sort of hope it is, so I can take it out to fix the issue.

[josefson]

I dunno what i did. Mine is working. Although i binder to ^p and ^n, which i prefer, but it was also working with up and down. Sorry for the previous comment i guess.

[unphased]

Hmmm interesting. Yeah, i mean it could really be anything, and I have to do minimal-configuration testing to start out anyway and is very likely a configuration problem on my end.

[sunaku]

To rule out differences in configuration, start with zsh -f and then manually source this plugin and configure it as shown in the README. 🎉

[sunaku]

Closing due to no response after 6 months. 👮 Please reopen/comment if you have new information.
Note that I wasn't able to reproduce the issue here (I use a plain old zshrc and this plugin; no OMZ). 😱