bindkey '^r' _histdb-isearch

[Beastie71]

I'm not exactly sure how to describe the behavior, but I have ^r bound to _histdb-isearch, but not sure if its a display issue, a fill-in issue, or something else... Let me describe the behavior...

I ^r at the start of the prompt and start typing the command I want to search. The first match it comes up with displays fine. If I hit enter, it puts in the command as far as I had typed, but then duplicates the arguments. For example:

^r
type: vi
finds my last vi command vi dir_colors
If I hit enter, my result is: vi dir_colors dir_colors with the cursor right after vi.

I could just go to the end of the first dir_colors and be happy, but its not what I would expect.

Now if I do the following:
^r
type: vi
^r
It brings up the previous command to the last vi command, displaying it fine.
If I hit enter, my result is: vi cluster.yaml dir_colors with the prompt right after vi.

Again I could go to the end of cluster.yaml and be happy, but its not what I would expect.

This is zsh version 5.7.1 on OS X 10.15.5

I am attaching an output of functions and bindkey, let me know if you need other items please.

functions.txt
bindkey.txt

[larkery]

I don't fully understand your question; to make clear, are you saying:

1. At some point in the past, you ran vi dir_colors
2. Then you press ^r and enter vi
3. This shows something like this:

$ vi dir_colors
→ in /home/you                              
→ on 2020-07-22 10:39:15
histdb 0 h: vi 

in which the word vi after the $ is underlined.
4. You press return
5. You see something like this

$ vi dir_colors dir_colors

6. If you press return, the shell invokes vi dir_colors dir_colors (presumably you can ask vi what its arguments were somehow; I am not a vi user so dunno).

To make clear the expected behaviour:

1. You press ^r
2. The isearch starts, initialized with whatever you have already in the buffer (the input you are typing)
3. Before the buffer and after the prompt is displayed the match; most recent matching history entry will be shown, and the matching region underlined
4. Press return
5. The match information goes away; the buffer content is replaced with the match from history; the cursor moves to the end of where the underline was.

If this is what's happening, it's not a bug. If at point 5 the buffer doesn't contain the match, something has gone wrong somewhere. In histdb-interactive.zsh on L160 you will see where I set the buffer after doing the history search. If your buffer ends up containing something other than the history text, I think something else in your zsh config is modifying BUFFER after _histdb-isearch has completed. You could check this by doing something like echo "HELLO BUFFER IS ${BUFFER}" after that line to see what's happening.

Or you can do functions -t _histdb-isearch to get a trace of what happens when you press ^r. That will show you what it is setting BUFFER to when it finishes (and also fill your screen with junk).

I'm afraid I am not going to debug this further for you, but if you can work out what is happening and find that it's something I need to fix I will be happy to fix it.

[Beastie71]

I've got a very short screen recording to show what I mean.

I actually start before typing anything with ^r, and then vi to find all vi commands. And then cycle back by continuously hitting ^r.

I'll try out what you suggest, but wanted to show you what I meant, hopefully more clearly.

Screen Recording 2020-07-22 at 8.23.17 AM.mov.gz

[larkery]

I think what's happening here might just be some redraw crud caused by your fancy prompt or terminal or other feature.

In your video, I notice that after you exit vi (which triggers a screen redraw) the prompt contents for the last command you ran are displayed as I would expect, without json on the end. One thing this could be is if something in your zsh is setting the value of POSTDISPLAY, as that variable is dumped after BUFFER but is just presentation rather than input.

You could check this by amending _histdb-isearch definition to do something like POSTDISPLAY="" before the zle recursive-edit call.

[Beastie71]

Thank you, I started digging in yesterday after my video trying to figure out where that was coming from. I appreciate the assistance!

[Beastie71]

Bingo! Its POSTDISPLAY holding that, now just to figure out why, I could just clear it out I guess, but like to know why. Thank you very much for your insight!