Suggest abbreviations from zsh history

[kinland]

Just found out about zsh-abbr. it's a cool idea, but I doubt I would ever generate abbreviations manually, which makes zsh-abbr have limited value for me. I've been on projects where dozens of incomprehensible aliases are used, so I can see a use case there, for sure, but I'm far more likely to rely on zsh completion plugins than I am on manually configured aliases.

With that in mind... it would be really cool if you could type a few arbitrary letters, then hit a keyboard shortcut, and have it provide a list of suggestions based on your zsh history.

Back in the day, I used to play a lot of MUDs. They had some pretty good interpretation of arbitrary abbreviations. For example, while mm is obvious for magic missile, you could also type things like mami/mmi/etc and it would generally figure out what you meant. And that was decades ago!

I'm sure there's a better algorithm than the following, but one way you could do this is generate a regex that inserts *s between what the user typed, then use that w/ grep over zsh history. A slight reliability improvement might be to only match the start of words, e.g. if you type ga and hit the shortcut, it'd look for g.* a.*|ga.*

Again, I'm sure there's a better way (and regexes are not my specialty; I'm sure there's a better regex for this), but the above seems like a reasonably low-effort way to do this.

You could also try to trim parameters that are only used once. For example, zsh history could be full of things like git checkout -b somebranchname. somebranchname might only exist once in the history, but git checkout -b could be a frequent history substring.

This could be a really flexible way of shortening parameters. gcm (or maybe require explicit hyphens to reduce ambiguity, e.g. gc-m) + shift+space or something might expand to git commit -m , whereas gcnv/gc-nv might find git commit --no-verify, etc.

I was surprised there didn't appear to already be a suggestion along these lines... there were some red herrings that were actually about integrating with zsh-autosuggestions plugin.

[olets]

Thanks for the idea! Going to experiment with multiple response threads…

 

I've played a bit with the idea of a tool that would help me identify good abbreviation candidates.

Low priority because my abbreviations stabilized long ago. The more I was taking advantage of abbreviations, the more obvious it was which commands I was still repeatedly typing in full.

Still, a tool like that could be fun. Don't know that it will end up built into zsh-abbr itself. I'll follow up here if make something.

Note

If anyone has a good solution for this, let us know!

[olets]

suggestions based on your zsh history

This space is partly covered by history search plugins. The UX isn't exactly the abbreviation effect you're describing, but it's close.

Check out https://github.com/zsh-users/zsh-history-substring-search, in particular with the fuzzy search option. I rely heavily on it, bound to the up and down arrows.

Or you might like https://github.com/marlonrichert/zsh-autocomplete. It's said to have history fuzzy search.

[kinland]

Yeah, I use zsh-autocomplete and a variety of other similar completion plugins (and I previously used the history substring search). That's the main reason I don't see myself using zsh-abbr.

Incidentally, zsh-autocomplete behavior model / UI design is pretty similar to what I had in mind when I started this discussion, but while it does have some really useful stuff, AFAIK it doesn't really handle extreme arbitrary abbreviations.

[olets]

gcm might expand to git commit -m, whereas gcnv/gc-nv might find git commit --no-verify

I know you're proposing this in the context of history searching, and if you don't want to create abbreviations that's cool. For me, this is where abbreviations shine. git any-command --any-flag is a lot to type. You can probably name some of the Git patterns you use all the time. Say they include commit -m and commit --no-verify. Run

abbr git cm="commit -m"
abbr git cnv="commit --no-verify

once and you'll be able to type

git cm[space] # expands to git commit -m
x y git cm[space] # expands to x y git commit -m
gcm[space] # expands to git commit -m
git cnv[space] # expands to git commit --no-verify
x y git cnv[space] # expands to x y git commit --no-verify
gcnv[space] # expands to git commit --no-verify

without losing time stepping through any other fuzzy history matches.

[kinland]

The reason I don't do stuff like this, and have hated work projects with large amounts of aliases, mostly boils down to never being able to remember 2-3 letter abbreviations, and when you have like a dozen similar abbreviations that are only 1 letter different, it gets worse.

I have a terrible memory to begin with. So when I see aliases like that, I copy the full version the first time, and try to rely on completion plugins after that. With the way my brain works, things like "git commit --no-verify" are far easier for me to remember than "cnv."

Your examples above only work if you can memorize that sort of thing. I'm incapable of that. So it has to be dynamic to be useful to me. Otherwise, I might unintentionally use "cm" sometimes, or "gc" others, etc., despite having the same intent. It'd be one thing if collisions were unlikely, but take a look at your aliases - sometimes the 'g' for git is omitted, sometimes not. And almost every single one has a c in it... sometimes at the front, sometimes at the end.

It's possible one of the completion plugins I have already can actually more or less accomplish what I was wanting (the history subsearch plugin you mentioned is pretty close, and I used it until relatively recently, when I switched to something else whose name is escaping me right now, and I'm not at my desktop to check, but again, bad memory)

[olets]

Finally got around to doing this with my own history. I made a copy of my HISTFILE, sorted by unique lines (I used https://open-vsx.org/extension/Tyriar/sort-lines), and went through it manually.

I've had

# .zshrc
setopt hist_expire_dups_first
setopt hist_ignore_dups

for a long time, so the commands I run most often don't necessarily appear most often in my history.