-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-word / prefixed abbreviations #32
Comments
I started conversation in the PR before seeing this ticket. Relocating conversation to here.
Here's what I'm thinking: Really cool idea. Rather than tie it to Git, I'd like to support spaces in abbreviations generally. It would meet the Git need Data handling should be pretty straightfoward — The hard part is expansion, because there can be overlap. abbr "a b a b"=d
abbr -g a=e
abbr -g b=f
abbr -g "a b"=g
abbr -g "b a"=h
abbr -g "a b a"=i
abbr -g "b a b"=j I think longest (the one with the most spaces) should probably win — given abbr "a b"=c
abbr -g b=d
I think hardest —and possibly even a deal breaker— is a performant implementation of the upgraded functions. But maybe it'll shake out as a pretty recursion. // Would you be interested in working on this? Do you have an intuition about what the user expectation is for overlapping abbreviations? |
This is actually something I've started working on myself as a separate utility. The idea of "scoped aliases" is so useful to me in contexts like Git and ssh, I want that behaviour everywhere! So I agree: we should try to support this for any arbitrary command. A simple but effective solution occurs to me w.r.t. overlapping abbreviations: we simply don't allow spaces in global abbreviations, and we always prefer a spaced abbreviation over a global one. That makes conflicts straightforward to resolve, and it makes it easy for the user to understand what to avoid (i.e. don't make global abbreviations that match subwords of spaced abbreviations). |
Perfect 👍 -- zsh associative array keys can have spaces as long as the entire key is quoted. So conceptually implementation won't be bad:
Won't have much spare time for a couple months. If you want to take a stab at it that'd be awesome! I'm happy to support. |
It occurs to me now that one issue with handling it this way is that we can't really have abbreviations that are substrings of other abbreviations. For example:
What should happen if the user types I suppose this only affects inline expansion with Space; expand-and-accept with Enter would still work as intended (since pressing Enter serves to disambiguate). |
I think immediately expand on Can think of it as two scopes: yarn abbreviations, and yarn lerna abbreviations:
Then —provided |
@henrebotha I've pushed up a wip branch, prefixes (diff). The idea is to treat abbreviations and expansions the same — so where I've also added placeholders for some tests we'll need, and added a new test harness (in Todo:
Don't know when I'll get back to this — probably not soon. If you're inspired to pick it up that'd be awesome! |
@henrebotha 🎁 I've built this out If you're up for it I'd appreciate your trying it out! Branch is For you original request % git fp<space> # expands inline to `git fetch --prune` do % abbr "git fp"="git fetch --prune"
% git fp<space> # expands inline to `git fetch --prune` Taking that further, in theory you could % abbr g=git
% abbr "git fp"="git fetch --prune"
% g<space>fp<space> # expands inline to `git fetch --prune` |
Legend! Going to try it now. |
Works beautifully! I'll report back if I come across any issues. |
I've been using this very happily over the last few months and have had no trouble with it at all. This is a game-changer! Thank you so much for making the effort of implementing this. I'd like to make a token donation to an org of your choice by way of thanks; perhaps a Hawaiian organisation championing indigenous rights? Let me know. |
Great to hear, and encourages me to get it released. Amazing!! Let me think and get back to you with a couple groups to choose from. |
Time flies! I've listed a couple organizations in the Thanks again. The sentiment is inspiring. |
@all-contributors please add @henrebotha for code, ideas, and financial. (#31, #32) |
I've put up a pull request to add @henrebotha! 🎉 |
I don't really like using
import-git-aliases
as it produces too many conflicts with other commands. What I think would be really fantastic is if zsh-abbr could be clever enough to expand regular Git aliases contextually, i.e. when prefixed with the commandgit
.What would it take to implement this? I see this in
_abbr_widget_expand
:zsh-abbr/zsh-abbr.zsh
Lines 1236 to 1242 in ccac4d0
I suppose we'd need another layer here, something like
_abbr_git_expansion
, which takes place only if$words[0] == 'git'
.I tried this, but even thoughZsh arrays are 1-indexed, haha._abbr_git_expansion fp
printsfetch --prune
, typinggit fp<space>
doesn't expand. What am I missing?The text was updated successfully, but these errors were encountered: