Preview expansion before actual expansion

[cohml]

Proposal

I'd love some mechanism by which you can "preview" what an abbreviation would expand to on <SPACE>, <ENTER>, etc. Like I type an abbreviation, and before expanding it, some indication of what it will become is shown.

This would be not only be a flashy and oh-so-zsh feature, but it would also reduce cognitive load by helping to disambiguate multiple similar aliases.

Worked example

Imagine I have the following aliases:

abbr -g "git c"="git commit -m \"%\""
abbr -g "git co"="git checkout"

If I type git c<SPACE> it expands to git commit and gets stored in my shell history as such. If I later type git co (intending to run git checkout), something like zsh-autosuggestions will suggest git commit (b/c the git co prefix matches).

This always makes me pause and think first, slowing me down. So some indication/hint that git co would expand to git checkout would be very helpful.

Possible implementation

A nice way to do this might be to leverage zle's zle-line-pre-redraw widget, which will show text on the line below the prompt.

Here's a minimal example of how this might work:

function preview_expansion {
  if [[ <$LBUFFER ends with an abbreviation> ]]; then
    local expanded_command=$(<fetch expansion from abbreviations file>)
  zle -M "${expanded_command}"
}

Then just register this hook as a zsh widget on startup:

zle -N zle-line-pre-redraw preview_expansion

[olets]

Previewing is an interesting idea, thanks for sharing! This might be a better fit for a standalone zsh-abbr extension. Currently, zsh-abbr doesn't run anything until triggered by one of the bound keys (spacebar, for example). Checking for previews would have to be done on every keystroke. Even before wondering whether zsh-abbr should get into TUI, I'm not sure it should get into running on every input. If anyone's inspired to try to author a zsh-abbr previews plugin, I could be up for answering questions or reviewing code.

For your specific zsh-autosuggestions pain point, there are two quick solutions.

• Rename your abbreviations to something that doesn't overlap with commands in your history. Not trying to victim-blame, and zsh-abbr shouldn't push you away from using the abbreviations you want! And, having seen some configs, I think people sometimes forget that the abbreviation can be anything. For example, git o (cOmmit) and git h (cHeckout).

• Keep your abbreviations, and use my plugin zsh-autosuggestions zsh-abbr integration plugin https://zsh-abbr.olets.dev/integrations.html#suggestions. With that in place, zsh-autosuggestions will recognize git c and git co as "commands" and won't suggest anything after them.

  abbr git c="git commit -m \"%\""
  abbr git co=checkout
  git # zsh-autosuggestions will suggest something
  git c # no suggestion
  git co # no suggestion
  git com # some suggestion

[cohml]

If you feel this functionality would be better bolted on via an extension rather than implemented as a core feature, I could perhaps give it a go. But some pointers would be helpful to get started. At this moment it's a total black box to me.

In fact, more generally, a "getting started" guide for creating extensions with some minimal examples/starter snippets might be a nice thing to have. I don't see anything like that e.g., here. It might also facilitate others contributing to the zsh-abbr ecosystem.

[olets]

Cool if you're feeling it go for it!

Authoring the plugin I'm imagining doesn't require deep understanding of zsh-abbr's source.

For anyone who wants to understand how zsh-abbr works

I recommend reading the source. If you go back to v5.x, the "save to history", prefixes, and reminders code didn't clutter things up. If you go back to 2.x there are a bunch of bugs but it's much more stripped down. (An easy way to jump to a release's coffee even in the GitHub mobile app is to click the links in the CHANGELOG.)

It would customize zle's self-insert ¹ to do some extra work that uses abbr expand ² (probably something with abbr expand $LBUFFER).

I've thought about writing a "how I architect zsh plugins" blog post to go with the other zsh posts on my dev blog. For now, if you're new to zsh plugin authoring, zsh-transient-prompt's CHANGELOG, CODE_OF_CONDUCT, CONTRIBUTING, LICENSE, .plugin.zsh, and .zsh-theme (which for a non-theme plugin would have the extension .zsh not .zsh-theme) are representative of how I set things up.

Footnotes

1. random example https://superuser.com/questions/604812/how-to-execute-a-function-in-bash-or-zsh-on-every-letter-being-typed-into-prompt ↩

2. https://zsh-abbr.olets.dev/commands.html#expand ↩

[cohml]

If anyone's inspired to try to author a zsh-abbr previews plugin, I could be up for answering questions or reviewing code.

I have just created this simple extension which is working well for me currently:

• https://github.com/cohml/zsh-abbr-preview

@olets Please let me know if you feel it could be improved or more tightly integrated.

Otherwise, if you think this extension would be of wider interest, please consider mentioning it in the README.

Thanks!

[cohml]

Thanks for the info @olets.

My zsh-abbr-preview extension is currently working perfectly for my purposes. But simplification is always welcome.

To that end, I will probably wait until you merge whatever is currently subject to change, then investigate whether/how the extension can be simplified.

If not too much trouble, please chime back in here once main has the requisite updates, and I'll get to work.

[olets]

Done! The updates shipped with v6.5.0. The changes are in PR #204, and I've added documentation at https://zsh-abbr.olets.dev/extending.html.

As part of the development, I made myself a proof-of-concept widget which previews expansions and line cursor placement. Ifffff you want to look at my (non-configurable) solution, it's at https://gist.github.com/olets/05192d42308500b690d9a671612220bd

Thanks for the proposal! Would you like to be listed in the readme and the website's Community page as an "ideas" contributor?

[cohml]

Awesome, congrats on the release!

I'm pleased to see related functionality being added to the core of your plugin rather than relegated to just a bolt-on feature. I'll have a think as to how this might cannibalize my own zsh-abbr-preview extension, which is fine by me.

Would you like to be listed in the readme and the website's Community page as an "ideas" contributor?

I would be honored :) Thanks!

I love this plugin by the way. Such a good idea and nice, simple implementation - cheers!

[olets]

@all-contributors please add @cohml for ideas

[olets]

Apparently that doesn't work in Dissusions… got it working in #206. @cohml please review pr #207 to make sure it's the info you want