Skip to content
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

Abbreviations #731

Closed
dag opened this issue May 11, 2013 · 92 comments
Closed

Abbreviations #731

dag opened this issue May 11, 2013 · 92 comments
Labels
Milestone

Comments

@dag
Copy link
Contributor

@dag dag commented May 11, 2013

Introduce abbreviations as an alternative to aliases, possibly replacing them.

Abbreviations are exactly like aliases, except they're expanded into their full form live as you type them on the commandline. Say you have gc as an abbreviation for git commit; now if you type gc -am "did stuff" the commandline changes when you type the space after "gc" and finally ends up as git commit -am "did stuff". This should only happen in command position, and when you type a space or hit enter.

Original text follows:

Replace aliasing with self-expanding short forms

I don't know what to call these but anyway. The idea is that if you type "g" as a command it expands to "git" when you type a space or enter.

Arguments for:

  • It solves many of the issues with completions. Since the alias expands "live", the git completions work as normal and commandline doesn't have to lie or do any other hacks like that.
  • It's easy to implement. I can kinda do it with bind and commandline although I didn't try to write a complete implementation. We don't need any changes to function or complete etc, as in other proposed solutions.
  • It's arguably "fishy": the user can see the expanded form, it's not hidden in an alias; it's instant and live, similar to completions, prompt repainting with prevd-or-backward-word etc.
  • When copy-pasting a command-line for instructions to others, it won't be full of your custom aliases that they have no knowledge of.
  • You can edit the expanded form if it's only almost-right.

Arguments against:

  • Doesn't solve the problem with alias git=hub, a problem that doesn't currently exist but is introduced with some alias completion proposals such as this one. However you can simply write a normal function function git; hub $argv; end instead to side-step this proposed alias system.
  • Some might find it surprising to have the command-line change as you type, without pressing anything like Tab or such.
  • The reason you can edit the expanded form is also the reason you can't delete what you typed with simply two backspaces. Even CTRL-W might not be enough as you might have gc expand to git commit for example. CTRL-U will do if it's the only command but it will delete too much if you're using the alias for a pipe for example. Perhaps we could introduce a new binding for "kill current command but not whole buffer".

Prior art:

  • :abbreviate in Vim
  • I think maybe search engines in Chrome?

Discuss.

@dag
Copy link
Contributor Author

@dag dag commented May 11, 2013

Another idea is to name this "abbreviations" like in Vim, and then decide what to do with aliases in another issue [I tend to think they should be removed].

Thought of another argument against:

  • Can't use these "aliases" in scripts. Not sure it's a good idea to use aliases in scripts anyway, but we could have a function for expanding "abbreviations" and/or we could hook fish's abbreviations into editors to have them expand on input there as well.
@terlar
Copy link
Contributor

@terlar terlar commented May 11, 2013

I like your proposal, sounds cool and fishy 👍

@gustafj
Copy link
Contributor

@gustafj gustafj commented May 12, 2013

I also like this.
It's a very clean solution to the "completions for aliases" #393 problem which is quite annoying.
This combined with a ll (Alias) printout when doing a ll<tab> would be perfect.

As alias is just a script wrapper around function today, I would want that changed as well so that there is a distinct difference between functions and aliases since they differs in so many ways after this, ex:

  • Syntax
  • Expressibility
  • Usage
@dag
Copy link
Contributor Author

@dag dag commented May 12, 2013

@gustafj I think it's probably better to call this idea "abbreviations" and replace alias with something that shows a helpful error message pointing at function and abbreviate. Thoughts?

@dag
Copy link
Contributor Author

@dag dag commented May 14, 2013

Another note:

I meant for this to only affect the command in a commandline, because it would be really annoying if g kept expanding to git in argument position. However, we might want some expansion in argument positions as well, for example with sudo (which would mean you could use sudo with abbreviations - something you can't do with aliases!) and certain cases of unambiguous completions such as for git's own aliases or if you type part of a long option. Getting this right might be tricky though, and would only get in the way if the completions are out of date, and if you actually wanted to sudo g not sudo git you now have to do something like sudo (echo git). Perhaps we could say that quoted arguments never expand, so you could then say sudo "g". Not sure whether that would be too magical and surprising or in fact exactly what one would expect and intuit. Thoughts? :-)

@gustafj
Copy link
Contributor

@gustafj gustafj commented May 14, 2013

Abbreviations sounds good to me (but I'm a regular vim user, so I might be biased ...).
When I think about it there are quite many "interesting" things that can be done with this, but (as you already point out) there are traps hidden in this minefield as well :/

I think it might be problematic/annoying if it is completely automatic and in any place in the commandline, mostly since undoing the abbreviation could be tedious if it expands to something you don't want and particularly if it expands to a long string.

A few thoughts of my own:
Should it be automatic by using space or should it be triggered by an option via tab, or something else?
Should it only be for simple strings ex g for git?
Should it only be applicable for the first item on the commandline, or anywhere?
Should it be possible to do string -> value conversions ex d for current date Tue May 14 20:23:03 CEST 2013?
Should it be possible to expand subshells ex vim (find . -iname '*cfg')<tab> gives

foo.cfg bar/poo.cfg foo/bar/more/beer.cfg
> vim
@dag
Copy link
Contributor Author

@dag dag commented May 14, 2013

Thoughts on your thoughts!

Should it be automatic by using space or should it be triggered by an option via tab, or something else?

I don't think this works with anything but space (and enter) because the whole point is to get the seamless experience you get with aliases where you don't have to think about something being an alias or not, and tab doesn't work either because g<Tab> should complete commands that begin with a g. If we add a new binding say CTRL-X we now have three types of completions: normal ones, autosuggestions and abbreviations. I really think this needs to be done with space or not at all.

Should it only be for simple strings ex g for git?

In command position it should be possible to include arguments in an abbreviation. For example gc expanding to git commit --all or what have you. Basically I think of abbreviations as being exactly like aliases, except they expand live on the command line.

Should it only be applicable for the first item on the commandline, or anywhere?

Only in command position is probably a good start. Then we can maybe experiment with the argument position use cases I suggested before.

Should it be possible to do string -> value conversions ex d for current date Tue May 14 20:23:03 CEST 2013?

You mean in argument position? echo d expanding to echo the date? I really think if we do argument position abbreviations at all, it needs to be used very conservatively and only when either the argument is a command (as in the case of sudo) or when the command has its own alias system (as in the case of git) and expanding would have the exact same effect as not expanding (so we only expand for usability).

Should it be possible to expand subshells ex vim (find . -iname '*cfg')<tab>

I think that's a question for completions and not abbreviations, as I don't think of abbreviations as involving tab and expanding subshells on space is probably a bad idea. However not sure it can work for completions either because you can already complete variable names without expanding them.

It could be useful though. Like I imagine doing rm *.png, expanding the wildcard and removing some of the files from the list.

How about this: we have a generic "expansion" or "abbreviation" system similar to the completions system; we bind CTRL-X or something for expanding tokens; and in command position we also expand abbreviations automatically. That could also make the sudo and git use cases work less obtrusively by making those expansions explicit.

It's a much bigger proposal than my original idea, though. 😉

@gustafj
Copy link
Contributor

@gustafj gustafj commented May 15, 2013

Space as trigger sounds good to me, probably gives the best user experience.
Expanding *.png sounds interesting ;)
I myself don't like a lot of different bindings for different things, perhaps "double tab" could be used instead of a new binding.
Ex ....*.png<tab> gives press <tab> again to expand *.png (the same for subshells).

But it might be better to limit this proposal to: abbreviations for the command position, expanding using space.
And have "expand subshells/wildcards" & sudo support as a separate one?

@dag
Copy link
Contributor Author

@dag dag commented May 15, 2013

Not sure double tab would work as that currently cycles between completions. Vim seems to have CTRL+] for expanding abbreviations without typing a space...

I think if we do live expansions at all, then abbreviations should be implemented with that somehow, so the ideas are related. But if we don't do live expansions, abbreviations should still be considered on their own. So not sure what to do here. :-)

@gustafj
Copy link
Contributor

@gustafj gustafj commented May 16, 2013

Yeah your right about <tab>, was only thinking for subshells (where it currently does nothing).
It could be possible to change the current behavior of <anything><space><tab> which currently cycles through all available files in the current dir (first printing them all).
Ex

> ls <tab>
a.cfg  b.cfg  c.cfg  d.cfg
> ls <tab>
> ls a.cfg<tab>
> ls b.cfg<tab>

But i would rather have "live expansions" using a new key-combo than living without it ;)
Expanding *.cfg to a.cfg b.cfg c.cfg d.cfg feels really useful.
But then all forms of possible expansions should be expandable, not just wildcards, ex brace completion (which i would rather see removed ... but that is a different issue #354)

@dag
Copy link
Contributor Author

@dag dag commented May 16, 2013

But then all forms of possible expansions should be expandable, not just wildcards, ex brace completion (which i would rather see removed ... but that is a different issue #354)

Agreed on both accounts. I wonder if double quotes should be expandable too... echo "hello $USER" -> echo "hello dag".

@dag
Copy link
Contributor Author

@dag dag commented May 16, 2013

I think what we're talking about here is actually "evaluation" more than "expanding" while on the other hand abbreviations are not about evaluation, so these ideas are probably separate and I'll make a new issue for the other one and edit this one a bit.

@dag
Copy link
Contributor Author

@dag dag commented May 19, 2013

Here's a basic working prototype:

function __fish_expand_abbreviation
    if test (count (commandline -poc)) -eq 0
        switch (commandline -t)
            case g
                commandline -t git
            case gc
                commandline -t 'git commit'
        end
    end
end

bind \  '__fish_expand_abbreviation; commandline -i " "'
bind \n '__fish_expand_abbreviation; commandline -f execute'

One problem I noticed is that if you hit enter to execute an abbreviated commandline, the expanded form is highlighted as an error (unknown command), even including the arguments.

@terlar
Copy link
Contributor

@terlar terlar commented May 19, 2013

I liked this so much, so I implemented a way to manage these abbreviations.

In the end I think these should be handled the same way completions and functions are handled. With it's own abbreviations folder where it can be saved.

This is the current implementation:

function __fish_expand_abbreviation
  if test (count (commandline -poc)) -eq 0
    set -l token (commandline -t)

    if abbreviations -q $token
      commandline -t (abbreviations $token)
    end
  end
end
function abbreviations --description 'List, show and query abbreviations'
  if test (count $argv) = 0
    printf '%s\n' $fish_abbreviations
    return
  end

  set -l abbreviation_index 0
  set -l expanded_abbreviation

  for i in $fish_abbreviations
    set abbreviation_index (math $abbreviation_index + 1)
    echo $i | read -l abbreviation command

    if test $abbreviation = $argv[-1]
      set expanded_abbreviation $command
      break
    end
  end

  if test -n "$expanded_abbreviation"
    switch $argv[1]
      case -q --query
        return 0
      case -e --erase
        set -e fish_abbreviations[$abbreviation_index]
      case '*'
        echo $expanded_abbreviation
      end
  else
    return 1
  end
end
function abbreviate --description 'Define a new abbreviation'
  if test (count $argv) -lt 2
    echo 'abbreviate: Takes two arguments. First abbreviation and then expanded command'
    return 1
  end

  echo $argv | read -l abbreviation command

  eval "function $abbreviation; $command \$argv; end"
  abbreviations -e $abbreviation

  set -U fish_abbreviations $fish_abbreviations "$argv"
  return 0
end

Then you do something like this:

abbreviate !    'sudo'
abbreviate tf   'tail -f'
abbreviate l    'ls -la'
abbreviate l.   'ls -d .*'
abbreviate g    'git'
abbreviate gs   'git status'

Update 1: Add ability to remove abbreviations and store them in a universal variable.
Update 2: Create functions for abbreviations also

@terlar
Copy link
Contributor

@terlar terlar commented May 19, 2013

Looking at how functions work, we could introduce:

  • abbred
  • abbrsave

Which would basically be to clone those functions.

@dag
Copy link
Contributor Author

@dag dag commented May 20, 2013

Nice! I'm not quite convinced we need a ~/.config/fish/abbreviations directory and the accompanying abbr{ed,save}, though. Unlike functions and completions, they're not really slow to load individually and they only need a single line to be defined. I think they're more like bind, perhaps we could have a fish_[user_]abbreviations function like the fish_user_key_bindings function, that loads the first time fish tries to expand an abbreviation? ([user_] for consistency but I'm not sure we should ship any default abbreviations?)

Only reason I can think of for having multiple files for abbreviations is if you have say an abbreviation for every git command in existence and some with arguments, so you want those separate from any others. But that's not how lazy-loading functions and completions work: they're loaded based on the command name, so if we did that for abbreviations we'd end up with one file for each abbreviation, each file containing only a single line of code!

Another idea is to do something like the universal variables, perhaps even by actually using universals (like set -U fish_abbreviations). Perhaps there is a use case for host-local abbreviations? Not sure.

@terlar
Copy link
Contributor

@terlar terlar commented May 20, 2013

You have some good points and I'm leaning towards the fish_user_abbreviations way.

The other approach would be to have like completions where you put all related abbreviations into a file, but that might be harder to map.

I was planning to use set -U fish_abbreviations at first, but I like to have the config maintained by git, so prefer setting them somewhere, like a config. But the nice thing with a universal variable would be that you can add completions on the fly without any hazle, like (abbred, abbrsave). Just do a abbreviate.

One solution would be to let the command make sure abbreviations are uniquely added and overwrites existing ones. Then it would be bootstrapped with the fish_user_abbreviations and users can add custom ones to the universal variable if they want.

I have this right now:
set -q fish_abbreviations ; or fish_user_abbreviations

But that won't work if I keep maintaining the file.

@terlar
Copy link
Contributor

@terlar terlar commented May 20, 2013

Updated my previous functions to use universal variable and added possibility to erase them and also check before adding new ones if they exist.

I was thinking about making it more interactive, like asking if it should replace the current abbreviation. But since it might also be scripted, I didn't want to do that. I will look into the determination of interactive mode.

@dag
Copy link
Contributor Author

@dag dag commented May 20, 2013

Well see thing with completions is that even they're loaded for a single command. If the current command line process is git then completions/git.fish is loaded. When you have separate command names, you have to make separate files, see for example the completions for [ef]grep which are actually in a function that's called from each of those three completion files.

With abbreviations I don't see any way to know from the abbreviation which file to load, unless the file name is the abbreviation. And then you can't have multiple abbreviations in one file. I guess we could load all abbreviation files on start, or on first attempt to expand abbreviations, but that's different from how functions and completions are loaded, and could potentially be slow if you have many abbreviation files.

New idea: abbreviate -U to make a universal abbreviation, and abbreviate -g or just abbreviate to make a global one? If we do that, perhaps we should consider doing it for bind too...

@dag
Copy link
Contributor Author

@dag dag commented May 20, 2013

Also I think abbreviate should just overwrite any existing abbreviation, same as bind and function and set...

@terlar
Copy link
Contributor

@terlar terlar commented May 20, 2013

All are valid points. I think it makes sense to just overwrite like all other functions do.

I also like the suggestion with universal and global, which gives flexibility to choose how to handle your abbreviations/bindings. I'm not entirely sure how to implement that though, and I'm thinking maybe this should be a builtin to enhance the performance?

@dag
Copy link
Contributor Author

@dag dag commented May 20, 2013

Yeah, I was only prototyping it in fish scripting for trying it out. Probably don't want slow scripting to fire every time you type a space. 😉

@terlar
Copy link
Contributor

@terlar terlar commented May 20, 2013

Yeah, still working great. I have been using it for about 1 day now and cannot imagine myself live without it anymore, haha 😁

@dag
Copy link
Contributor Author

@dag dag commented May 20, 2013

😊

Another problem I've noticed though is that if you do C-a on a non-empty commandline and type an abbreviation, it's not expanded on space since you're in the middle of a word. So say you do make install oops need root C-a ! now you have ![cursor]make install and typing the space doesn't expand the ! abbreviation. I'm gonna try to work around this with commandline -C.

A third problem, which might be a feature, is that it's only expanded when you type a space or enter after an abbreviation. So not for example if you type a space then C-a ! C-e. This could be a feature because it makes it possible to avoid abbreviation expansion, but I think it's a bit unfishy and we should instead have like a command to run a command line literally, bit like the command command but also accounting for shell functions and builtins. Or some special syntax, like \g in command position is interpreted as g and not expanded. Special syntax isn't really fishy either, but we already have space before the command special cased to mean "don't log in history", so shrug.

Fourth, and this one is an obscure one, if you do like in the previous paragraph so you have an unexpanded abbreviation followed by a space, then do C-a and space, the abbreviation is expanded and an extra space is inserted after it! Again, may need to check cursor position with commandline -C.

Oh and, the first problem I mentioned in a previous comment, it only happens if the unexpanded abbreviation is an unknown command. So a gc abbreviation expands to git commit and the whole thing highlights as an error, on hitting enter (without a space), but a gs abbreviation expands to git status and highlights correctly, because apparently I have ghostscript installed:

> which gs
/usr/bin/gs

I'm also wondering if maybe abbreviations should highlight as known "commands" even before you hit space... Currently if I type g it's red until type a space, but if I type git it highlights as known even before a space.

All these problems could probably be dealt with better if we do this in the C++ parts.

@dag
Copy link
Contributor Author

@dag dag commented May 20, 2013

Silly workaround for syntax highlighting problems: make an alias/function for every abbreviation. 😆

Actually, maybe that's a good idea to do anyway, hm... Means abbreviations will work in scripts, in eval, with type... Not sure.

@terlar
Copy link
Contributor

@terlar terlar commented May 27, 2013

Your workaround is what I am using currently, but I'm not sure if that is what it should do in the end, or if they should be intended to be used inside eval or type. For me they should be an input thing only. But I guess it might not hurt to also let them be run to get easy support for say sudo.

So I have been using the current implementation for a while now and these are the problems discovered with this solution so far (they are not related to the approach 👍):

  1. When pasting text, the last space gets inserted at the beginning of the line, e.g. echo this is a test becomes _echo this is atest when pasted, where _ is a space.
  2. When using read builtin the bindings on enter and space applies there also. So for example if I want to input some non command to read it will expand. I guess in the final implementation this should be off by default and enabled by read -s
  3. It is a little bit slow (~0.25-0.5 seconds)
@dag
Copy link
Contributor Author

@dag dag commented May 27, 2013

You can work around 1. by pasting with C-y.

@terlar
Copy link
Contributor

@terlar terlar commented May 27, 2013

For me C-y only pastes within fish (from what is cut inside fish) and not from my system clipboard. Copying between terminals or other apps.

@ridiculousfish
Copy link
Member

@ridiculousfish ridiculousfish commented May 28, 2013

I think abbreviations are a really cool idea.

@zanchey zanchey modified the milestones: next-minor, next-major Dec 1, 2014
@binaryphile
Copy link

@binaryphile binaryphile commented Jan 6, 2015

Hey folks,

I wanted to make a note after having used abbreviations for quite some time now.

I'm a big fan, and they make my life much easier. I especially like the fact that other people can see what commands I'm issuing, in a familiar form.

My only dislike is that there is no history for abbreviations. Since I use abbreviations for almost every command, this has ended up with me losing history functionality for the most part. While you may think that abbreviations should be short enough to not need history functionality, I find myself missing it quite a bit. I have over 200 abbreviations defined, and some of them differ only slightly. Having history show me the one I issued yesterday, for example, would be immensely useful for the more involved and less-frequently used abbreviations. As I practically live with abbreviations, I've had to resort to using functions instead where I need history support since I really don't have history otherwise.

Thanks again for the feature.

@ridiculousfish
Copy link
Member

@ridiculousfish ridiculousfish commented Jan 6, 2015

@binaryphile Very interesting. It sounds like you have an idea in mind of what this should look like (i.e. the UI). Would you like to describe it in more detail?

@binaryphile
Copy link

@binaryphile binaryphile commented Jan 7, 2015

Good question. I guess I'd just like it that if any expansion were triggered then for the abbreviation to go into the history list. So if I my abbreviation were "gclon" for "git clone", then when i hit space (or semicolon), "gclon" would be added to my history. I wouldn't alter the normal behavior of storing the expanded command in history, so both would be available.

After that, when I began typing a prefix of the abbrev (such as "gcl"), I'd expect "gclon" to be the first option for autocompletion to pop up.

Ideally, at that point I'd be able to hit alt-f and have it both complete automatically to the expanded version, plus further offer a new autocompletion of that expanded command from history. I'd want that because I may have entered further arguments after expansion, and would want to have that available in as few keystrokes as possible via the same route I entered it in the first place (abbrev then arguments). Since the abbreviation in the history wouldn't have the arguments, alt-f would be the most natural method for me to move further along the completion argument by argument.

I think ctrl-f wouldn't change and would just move forward to the end of the abbreviation, not the expanded version, since there would be no visual cue as to what you'd be expanding to.

@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented Mar 2, 2015

I just got a nightly build up and running to finally test this! I really like this feature and love the fact is has the abbr command that ships with it.

My feedback is that we need a good way to export for dotfile backup. I am thinking these should all go into one file in the format abbr --show outputs. abbr --show is good enough for me for now, I am just going to pipe them into a dotfile for now. But I do want an easy way to import them again when that time comes. So if Fish could import that format now that would be a good next step.

@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented Mar 2, 2015

Following the command in the help to add a new abbreviation fails with this error.

selection_235

@zanchey
Copy link
Member

@zanchey zanchey commented Mar 6, 2015

Currently you need to enter abbr -a "gco git checkout" but I think it would make more sense to support the case described in the manual.

@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented Mar 6, 2015

Ahh, thanks!

@zanchey
Copy link
Member

@zanchey zanchey commented Mar 13, 2015

48d3536 makes that change.

@zanchey
Copy link
Member

@zanchey zanchey commented Mar 13, 2015

I think we should either leave the '=' separator support in the next minor release and disable it after that, or (silently?) upgrade people's fish_user_abbreviations.

@zanchey
Copy link
Member

@zanchey zanchey commented May 4, 2015

I'm going to close this as fixed; I filed #2051 to track the migration. Many thanks to @dag for the concept and all those who tested it - looking forward to seeing this released soon!

@zanchey zanchey closed this May 4, 2015
@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented May 4, 2015

W00t, thanks everyone, I really LOVE this feature!!

@dideler
Copy link
Contributor

@dideler dideler commented Jul 24, 2016

I'm loving abbreviations, it's a much friendlier experience than aliases. Thanks so much!

I came across this thread while looking up how to store abbreviations in dotfiles1, 2.
If anyone stumbles here for the same reason, you can use abbr -s/--show. For example

abbr --show >> ~/.config/fish/config.fish
@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented Jul 25, 2016

@dideler I am using something similar to that for automated backup, I also recommend piping to sort.

abbr --show | sort > fish_abbreviation_backup;

I put everything into a fish_abbreviation_backup file and then add that to Homeshick for backup. It is all automated though and runs on cron. After I backup I source fish_abbreviation_backup so that fish shows alphabetical order when doing an abbr --show.

Would be nice if fish kept abbreviations in a file, similar to how it does things with functions.

update: Issue to sort abbreviations when storing them -> #2156

@krader1961
Copy link
Contributor

@krader1961 krader1961 commented Jul 25, 2016

Would be nice if fish kept abbreviations in a file...

From the man page: "Abbreviations are stored using universal variables." Which means you'll find them in the ~/.config/fish/fishd.macaddr file under var name fish_user_abbreviations. The abbr command simply manipulates that universal var.

@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented Sep 2, 2016

Thanks, would it be okay to consider the idea of keeping them in ~/.config/fish/abbreviations.fish so we can add them easily to our dotfiles?

@faho
Copy link
Member

@faho faho commented Sep 2, 2016

@ElijahLynn: What I do is I have a file called "abbrs.fish" in ~/.config/fish/conf.d/, with the following contents:

if not set -q fish_initialized
    abbr -a alsamixer alsamixer -c0
    abbr -a e emacs -nw
    abbr -a \$PAGER less
    abbr -a mu4e emacs --eval "\(mu4e\)"
    abbr -a pm pulsemixer
    abbr -a rm rm -I
    abbr -a sc systemctl
    abbr -a upo upower -i /org/freedesktop/UPower/devices/battery_BAT0
    abbr -a usc systemctl --user
    # Double-escaping needed
    abbr -a d2 env WINEPREFIX=/home/alfa/.wine32/ wine ~/.wine/drive_c/Program\\ Files\\ \\(x86\\)/Diablo\\ II/Diablo\\ II.exe
    abbr -a c curl -LO -C -
    set -U  fish_user_paths ~alfa/.local/bin $GOPATH/bin
    set -U fish_initialized
end

I have this in my dotfiles, and I can just drop it into any machine I haven't yet used it on, and if I want to reset the abbrs, I can erase them all (I do set -e fish_user_abbreviations; set -e fish_initialized) and restart fish.

@ElijahLynn
Copy link

@ElijahLynn ElijahLynn commented Sep 2, 2016

Thanks, I may be missing this but that looks like you need maintain that manually and don't get to add manage them easily with the abbr command.

@faho
Copy link
Member

@faho faho commented Sep 2, 2016

You add the abbr command there. This can even be the output of an abbr --show call.

@AlexWayfer
Copy link

@AlexWayfer AlexWayfer commented Mar 27, 2020

Only in command position is probably a good start. Then we can maybe experiment with the argument position use cases I suggested before.

I think not only a position in the start would be handful, example: s for sudo and n for nano which can expands from s n to sudo nano, but not in the current implementation.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.