Using ⌥← from history menu

[amomchilov]

macOS has some nifty text editing shortcuts:

• ⌘← move to the start of the line (like Home)
• ⌘→ move to the end of the line (like End)
• ⌥← move left by 1 word
• ⌥→ move right by 1 word

iTerm has a "Natural Text Editing" Key Mapping preset that configures these:

In ZSH's hotkey syntax, ⌥← and ⌥→ are represented as ^[b and ^[f. The default ZSH config has keybinds for these:

$ bindkey -M main | grep "\^\[[bf]"
"^[b" backward-word
"^[f" forward-word

(I don't understand how the hex codes 1 and 5 work for home/end/⌘←/⌘→, so I'll ignore them for now)

Often times when I'm in the history menu, I want to press the left arrow key to go in and edit a history item. As of #370, this is possible, and it's wonderful!

In addition using the left arrow key to jump a single character left, I want to also be able to use ⌥← and ⌘← to jump left by a large amount.

I tried to implement this myself. I thought the trick would be to augment _autocomplete.history_lines.suffix() to make it detect these character sequences. However, it looks like the "signal" never even makes it to there. Something earlier in the chain capture these key events, and they end up behaving the same as ⌥↑/⌥↓ (which just goes to the first and last items of the history menu).

Do you have any idea what might be catching this key event, or how I might be able to figure that out?

Monosnap.screencast.2022-07-07.18-54-00.mp4

In this clip I first show what ⌥←/⌥→ do, then just ↑/↓. Then you'll see once I press ← just once (to remove the ;, exist the history menu, and start editing the line), I can then follow up with more ⌥← and have them skip words correctly.

[amomchilov]

Another solution approach I've been considering is to add a zstyle config which just removes the ; suffix entirely.

I tried to love it and the way that you used it, but it only ever gets in the way for me. In the off chance that I want to compose one history item with another, I would rather opt into that behaviour with an explicit ; or →.

In my local copy, I just ripped out the -s "$suf" flag:

zsh-autocomplete/functions/completion/_autocomplete.history_lines

Lines 119 to 120 in f52f45a

	builtin compadd "$expl[@]" -S "$suf" -R _autocomplete.history_lines.suffix \
	-QU -ld displays -a matches

-  builtin compadd "$expl[@]" -S "$suf" -R _autocomplete.history_lines.suffix \
+  builtin compadd "$expl[@]" -R _autocomplete.history_lines.suffix \
      -QU -ld displays -a matches

If I were to polish that off (add zstyle config, docs, etc.), would you be interested in having it contributed?

[marlonrichert]

If I were to polish that off (add zstyle config, docs, etc.), would you be interested in having it contributed?

I would suggest you instead try out my Zsh Edit plugin and see if that solves the problem for you.

[amomchilov]

@marlonrichert This works great! I still find the ; to be a bit of a visual cruft, but I can live with it.

Is this behaviour (how zsh-edit modifies the history menu behaviour) documented somewhere?

[marlonrichert]

Hm, no, it’s not. I made an issue for it: marlonrichert/zsh-edit#12

[marlonrichert]

You’re approaching it the wrong way. Instead of handling possible keystrokes, you should define which keybinding widgets should cause the user to exit the menu, here:

zsh-autocomplete/functions/widget/.autocomplete.history-search.zle-widget

Line 21 in f52f45a

'\e[D' .backward-char \

Alternatively, install my Zsh Edit plugin and see if that solves the problem for you.

I don't understand how the hex codes 1 and 5 work

They correspond to ^A and ^E, respectively.

[amomchilov]

Instead of handling possible keystrokes, you should define which keybinding widgets should cause the user to exit the menu, here:

Ahhh that makes sense, and it looks like that's exactly what zsh-edit does:

https://github.com/marlonrichert/zsh-edit/blob/4a8fa599792b6d52eadbb3921880a40872013d28/zsh-edit.plugin.zsh#L37-L61

Is there a reason for these behaviours to not be stock in zsh-autocomplete? I guess because the menuselect keymap general to zsh, and editing might alter the behaviour of other, non auto-complete related things?

They correspond to ^A and ^E, respectively.

That makes sense, they're equivalent to pressing control+A and control+E.

Now I'm curious: What exactly is ^ in this context? I know it signifies the "control key", but mechanically, what exactly is the interaction between iTerm (that's a "terminal emulator", if I understood the terminology correctly) and zsh? Is ^ a stand-in for a special, non-printable character? Does it have a specific ASCII/unicode code?

Do you know where I can learn more about this?

[marlonrichert]

Is there a reason for these behaviours to not be stock in zsh-autocomplete? I guess because the menuselect keymap general to zsh, and editing might alter the behaviour of other, non auto-complete related things?

Moreso to reduce bloat and because Zsh Autocomplete cannot account for all the possible widget names that could be in use.

Now I'm curious: What exactly is ^ in this context? I know it signifies the "control key", but mechanically, what exactly is the interaction between iTerm (that's a "terminal emulator", if I understood the terminology correctly) and zsh? Is ^ a stand-in for a special, non-printable character? Does it have a specific ASCII/unicode code?

Do you know where I can learn more about this?

It’s a common convention of notating control characters and, in particular, the one that bindkey uses for its ouput.