minor annoyance with zsh and git flow

minor annoyance with zsh and git flow

[Rick DeNatale]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

I'm using zsh, on a rails project using cucumber and git flow.

git flow adds a subcommand to git.

The git flow subcommand has lower level subcommands itself, one of which is
called feature, and cucumber conventionally uses a directory in the project
root called features

I've got git completion and git flow completion installed
https://github.com/bobthecow/git-flow-completion which is probably
irrelevant.

When I type in a git flow command with or without using completions

say

->git flow feature checkout make_it_niftier

and hit enter, zsh helpfully? asks

zsh: correct 'feature' to 'features'

I can't figure out how to stop zsh from doing this.  I see the FAQ about
turning off correction for a single command, but that doesn't seem directly
relevant, I don't want to turn off correction for the git command in
general.

Ideas

*Rick DeNatale*
*Blog:*http://talklikeaduck.denhaven2.com/
*GitHub:*http://github.com/rubyredrick
*Twitter:* @RickDeNatale
*WWR:*http://www.workingwithrails.com/person/9021-rick-denatale
*LinkedIn:*http://www.linkedin.com/in/rickdenatale

Re: minor annoyance with zsh and git flow

[Bart Schaefer]

On May 25, 11:25am, Rick DeNatale wrote:
} 
} git flow adds a subcommand to git.

Of course the root of all this is that "subcommands" are not a concept
that unix-derived shells were ever designed to deal with.  This ...
 
} The git flow subcommand has lower level subcommands itself

... is just adding injury to insult.

(Sorry, my curmudgeon is showing.)

} ->git flow feature checkout make_it_niftier
} 
} and hit enter, zsh helpfully? asks
} 
} zsh: correct 'feature' to 'features'
} 
} I can't figure out how to stop zsh from doing this.

You can't unless you're willing to unsetopt correctall.  Zsh assumes
that anything after the command word that doesn't start with a hyphen
is an ordinary argument, and the most common kind of ordinary argument
is a file name, and there you are.

} Ideas

Well ... you can hack something ... like so:

    zle-line-init() {
      # Reset correctall in case finish unset it
      setopt no_localoptions correctall
    }
    zle-line-finish() {
      if [[ $BUFFER = (${~CORRECTALL_IGNORE})* ]]
      then setopt no_localoptions no_correctall
      fi
    }
    zle -N zle-line-init
    zle -N zle-line-finish

    CORRECTALL_IGNORE="git flow feature "

Here CORRECTALL_IGNORE is a pattern, so you can add alternatives with
"|" between, etc.

Re: minor annoyance with zsh and git flow

[Richard Hartmann]

On Thu, May 26, 2011 at 02:22, Bart Schaefer <schaefer@brasslantern.com> wrote:

> Of course the root of all this is that "subcommands" are not a concept
> that unix-derived shells were ever designed to deal with.  This ...

You are raising an interesting point. Realistically speaking, love it
or hate it, this kind of syntax will only become more common over time
which means a way to deal with this generically would be helpful.

Of course, this more or less requires zsh to actually know what
commands a program can understand and with what syntax. Part of this
information could be gleaned from completions, I guess.

A different approach would be to define syntax files for commands
(EBNF?) which could be distributed with the programs themselves or at
least shared between shells. Dreaming some more, this could then even
be helpful for zsh's long-long-term possibility of syntax highlighting
capabilities..


I'll stop babbling now, but the more I think about it, the more I
think it's an interesting idea...


Richard

PS: If zsh, Bash, fish, you name it could generate their own
completion definitions from EBNF or similar, this could be a huge
boost to having current completions everywhere.

PPS: And it could even solve the old "keep zsh's git completion in
git's git or zsh's" debate.