Completing a unique prefix of "script" completes "script"

Completing a unique prefix of "script" completes "script"

[Nikolai Weibull]

Yes, it's true, that's precisely what you'd expect.

However, when working with ruby-on-rails, you often run scripts in the
"script" subdirectory.  This is made somewhat harder by the fact that
util-linux installs a program called "script" in your bindir.  Thus,
whenever you're in a ruby-on-rails root-directory you wind up
completing a unique prefix of "script" as "script ", i.e., with the
added space and completion is finished.  But I never want to complete
that script command.  What I want is the completion of the directory
name.

Is there a way to make sure that both options, i.e., "script/" and
"script ", are completed?

Also, is there a way to ignore the command "script" found in $path?
Using the ignored-patterns style doesn't work, of course.  And that's
basically the only thing I
was able to think of.

Up until a non-unique prefix both "script" as a command and "script/"
as an executable or directory are listed.

  nikolai

Re: Completing a unique prefix of "script" completes "script"

[Peter Stephenson]

"Nikolai Weibull" wrote:
> Is there a way to make sure that both options, i.e., "script/" and
> "script ", are completed?

This is all rather frustrating, yet again...

Looks like you can get this with the combination of "setopt autocd" to
have local directories completed and "zstyle ':completion:*' group-name
''" to separate groups, so that it knows that it's ok to have both
matches for "script" separately.  I'm not sure why you would need
autocd---that looks like a bug, since you can execute commands by relative
paths anyway.

That's still not it, however, since you only get both if the completion
is otherwise ambiguous (i.e. script and script/ aren't sufficiently
different to show up separately).  Bizarrely, playing around suggests my
matcher-list is enough to make them appear "different":

zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|=**'

> Also, is there a way to ignore the command "script" found in $path?
> Using the ignored-patterns style doesn't work, of course.  And that's
> basically the only thing I
> was able to think of.

You should be able to do it with the tag-order style so that it prefers
the directory if it's found.  However, there's something a bit screwy
here, too.

zstyle :completion::complete:-command-:: tag-order local-directories

should prefer local directory completion to everything else, only
offering other stuff if there's no local directory (or if you explicitly
use _next_tags).  But that doesn't work; you get all possibilities
together.

Explicitly listing other possibilities in a second argument doesn't
work, either.

However, it's not completely broken since

zstyle :completion::complete:-command-:: tag-order local-directories -

does work; that gives you only local directories and nothing else.  So
for some reason as soon as you try to specify an order it's assuming you
don't want an order.

You can cheat and unhash the command if you never use it.  "unhash
script" did seem to do the trick.  Note, however, that a "rehash" will
bring it back.

That's about five things I don't understand.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Completing a unique prefix of "script" completes "script"

[Nikolai Weibull]

On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> "Nikolai Weibull" wrote:
> > Is there a way to make sure that both options, i.e., "script/" and
> > "script ", are completed?

> You can cheat and unhash the command if you never use it.  "unhash
> script" did seem to do the trick.  Note, however, that a "rehash" will
> bring it back.

It seems that the hash table is initialized after .zshrc is read.  Is
there a way to run some scripts after everything is initiaziled?

I just stuck

[[ -n $(whence script) ]] && unhash script

in my .zshrc and figured that it'd work ($path being set in my
.zprofile).  That failing, I put a "rehash" before that line.  I still
get

/home/now/.local/etc/zsh/.zshrc:unhash:36: no such hash table element: script

What am I missing?

And thanks for the very complete answer.  Too bad none of the
solutions seem to work very well.

  nikolai

Re: Completing a unique prefix of "script" completes "script"

[Nikolai Weibull]

On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:

> zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|=**'

What exactly are the 'r's doing here?

  nikolai

Re: Completing a unique prefix of "script" completes "script"

[Peter Stephenson]

"Nikolai Weibull" wrote:
> On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> 
> > zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|=
> **'
> 
> What exactly are the 'r's doing here?

That's become a bit garbled: the bit we're referring to should look like

'r:|[.,_-]=** r:|=**'

There's a fairly full description of this in MATCHING CONTROL in the
zshcompwid manual page---in something of the sense of "I couldn't walk
across the English Channel because the sea was fairly full", so I'll
summarise here.  The general form is

r:LPAT|RANCHOR=TPAT

where LPAT has to occur on the left of the string already on the command
line, RANCHOR indicates something at the right hand end of the string on
the line, and TPAT says what sort of pattern to use to try to match the
stuff in the middle when looking for possible completions.  The LPAT
isn't commonly used and if it's empty it has no particularly special
meaning.  The [.,_-] says look for any part of the code on the command
line which has any of the those characters to the right.  The ** then
says match anything there; a single * wouldn't allow the anchor,
i.e. the character out of that set in square brackets, to be matched
itself, so you'd have to have typed any anchor characters yourself.

The result is that something like u-l-o-h is matched as u*-l*-o*-h.
(If we'd used r:|[.,_-]=* those *'s wouldn't have matched further -'s,
as we've doubled the * they can.)

The r:|=** matches at the end of the string:  that's only necessary if
you're completing in the middle and want to act as if there was a *
there.  In other words, without it, u-l-o<CURSOR>-h would have been
treated as u*-l*-o*-h, with it it's treated as u*-l*-o*-h*.  (This
supposedly depends on COMPLETE_IN_WORD being set; if it isn't completion
always takes place at the end.)

Quite why this forces a distinction between script as an executablle and
script as a directory is one of the great mysteries of the modern world.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Completing a unique prefix of "script" completes "script"

[Nikolai Weibull]

On 8/13/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> "Nikolai Weibull" wrote:
> > On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> >
> > > zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|=
> > **'
> >
> > What exactly are the 'r's doing here?
>
> That's become a bit garbled: the bit we're referring to should look like
>
> 'r:|[.,_-]=** r:|=**'

That's what I figured.

[excellent description of 'r' matcher-list operator]

Thanks!

> Quite why this forces a distinction between script as an executablle and
> script as a directory is one of the great mysteries of the modern world.

Hehe, it's bad when this comes from a lead developer...

  nikolai

Re: Completing a unique prefix of "script" completes "script"

[Peter Stephenson]

"Nikolai Weibull" <now@bitwi.se> wrote:
> It seems that the hash table is initialized after .zshrc is read.  Is
> there a way to run some scripts after everything is initiaziled?

Hmm... I haven't looked at the source but in my case it seems to
be being hashed straight away...

zsh -f -c 'zmodload -i zsh/parameter
print $commands[script]
unhash script
print $commands[script]'

prints /usr/bin/script the first time and nothing the second time.
/etc/zshenv is empty.  Aha---it looks like zsh/parameter is filling the
hash table itself (based on the HASHLISTALL option which is on by default).
So maybe putting

zmodload -i zsh/parameter

early in your initialization file (it'll probably be loaded by the completion
system later anyway) is good enough.
-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

Re: Completing a unique prefix of "script" completes "script"

[Nikolai Weibull]

On 8/14/06, Peter Stephenson <pws@csr.com> wrote:
> "Nikolai Weibull" <now@bitwi.se> wrote:
> > It seems that the hash table is initialized after .zshrc is read.  Is
> > there a way to run some scripts after everything is initiaziled?
>
> Hmm... I haven't looked at the source but in my case it seems to
> be being hashed straight away...
>
> zsh -f -c 'zmodload -i zsh/parameter
> print $commands[script]
> unhash script
> print $commands[script]'
>
> prints /usr/bin/script the first time and nothing the second time.
> /etc/zshenv is empty.  Aha---it looks like zsh/parameter is filling the
> hash table itself (based on the HASHLISTALL option which is on by default).
> So maybe putting
>
> zmodload -i zsh/parameter
>
> early in your initialization file (it'll probably be loaded by the completion
> system later anyway) is good enough.

Nope.  It seems zmodload returns before the hash table is fully
initialized.  If I put a "sleep 1" in there it works, but without it
it'll still complain about the command not being hashed.

Actually, a "sleep 0" seems to work as well...

That's /one/ thing /I/ don't understand...

  nikolai

Problem with _arguments

[Nikolai Weibull]

Say that I have

#compdef craptastic

_arguments \
  '-s[omething]:with an argument' \
  '*:directory:_directories'

Then, at least with my setup, if I have the following command line and
press <Tab> I get:

% craptastic -s <Tab>
::: with an argument :::

but if I have the following and press <Tab> I get:

% craptastic src -s <Tab>
::: with an argument :::
::: directory :::

Why is directory all of a sudden a viable option here?

It makes no sense.  No banging my fists against my head has made me
any wiser (and, believe you me, I've tried...repeatedly).

  a really f:ing pissed off nikolai

Re: Problem with _arguments

[Peter Stephenson]

"Nikolai Weibull" wrote:
> Say that I have
> 
> #compdef craptastic
> 
> _arguments \
>   '-s[omething]:with an argument' \
>   '*:directory:_directories'
> 
> Then, at least with my setup, if I have the following command line and
> press <Tab> I get:
> 
> % craptastic -s <Tab>
> ::: with an argument :::
> 
> but if I have the following and press <Tab> I get:
> 
> % craptastic src -s <Tab>
> ::: with an argument :::
> ::: directory :::
> 
> Why is directory all of a sudden a viable option here?

   _arguments [ -nswWACRS ] [ -O name ] [ -M matchspec ] [ : ] spec ...
          This function can be used to give a complete  specification  for
          completion  for  a  command whose arguments follow standard UNIX
          option and argument conventions.

"Standard UNIX option and argument conventions" are that all options
come before all non-option arguments.  The GNU extension that they can
occur in any order is not supported.  So -s is an argument following the
argument src.  _arguments thinks src, -s and the argument you're now
completing are normal arguments and hence completes directories.

Offers to add the option for the GNU extension as an option to
_arguments to be applied if POSIXLY_CORRECT isn't set will be gladly
accepted.  Volunteer must like murky code with limited comments.  The
ability to spend hours puzzling over why individual lines are written
the way they are would be an advantage.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Problem with _arguments

[Nikolai Weibull]

On 11/22/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> "Nikolai Weibull" wrote:
> > Say that I have
> >
> > #compdef craptastic
> >
> > _arguments \
> >   '-s[omething]:with an argument' \
> >   '*:directory:_directories'
> >
> > Then, at least with my setup, if I have the following command line and
> > press <Tab> I get:
> >
> > % craptastic -s <Tab>
> > ::: with an argument :::
> >
> > but if I have the following and press <Tab> I get:
> >
> > % craptastic src -s <Tab>
> > ::: with an argument :::
> > ::: directory :::
> >
> > Why is directory all of a sudden a viable option here?
>
>    _arguments [ -nswWACRS ] [ -O name ] [ -M matchspec ] [ : ] spec ...
>           This function can be used to give a complete  specification  for
>           completion  for  a  command whose arguments follow standard UNIX
>           option and argument conventions.
>
> "Standard UNIX option and argument conventions" are that all options
> come before all non-option arguments.  The GNU extension that they can
> occur in any order is not supported.  So -s is an argument following the
> argument src.  _arguments thinks src, -s and the argument you're now
> completing are normal arguments and hence completes directories.

But it still offers the completion for -s, so it must have /some/ sort
of understanding of what's going on already.

Oh well, I guess I'll have to give up on this for the time being.

Actually, would there be a good way of tricking _arguments into only
seeing what you want it to see?  In this case, it would work fine if
one could trick it into only seeing the stuff after src, so that it
would continue completing options.

Thanks.

  nikolai

Re: Problem with _arguments

[Peter Stephenson]

"Nikolai Weibull" wrote:
> > > _arguments \
> > >   '-s[omething]:with an argument' \
> > >   '*:directory:_directories'
> > >
> > > % craptastic src -s <Tab>
> > > ::: with an argument :::
> > > ::: directory :::
> 
> But it still offers the completion for -s, so it must have /some/ sort
> of understanding of what's going on already.

Right, my answer was a bit dozy... it looks like it's hedging, i.e. it's
completing as if the strict POSIX and GNU forms are both allowed and
it can't tell which applies.

> Actually, would there be a good way of tricking _arguments into only
> seeing what you want it to see?  In this case, it would work fine if
> one could trick it into only seeing the stuff after src, so that it
> would continue completing options.

There are certainly ways of updating the line, but the trouble is to
find out what you need to do either you're going to be doing some
parsing yourself or running _arguments twice.  You can edit words (the
command line) and CURRENT (the index into it), plus it's also possible
in some contexts to tell _arguments to limit the words visible in the
completion that it's calling by the use of enough colons.  I find
directly manipulating words and CURRENT less infuriating.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

Re: Problem with _arguments

[Bart Schaefer]

On Nov 22, 10:39am, Peter Stephenson wrote:
}
} parsing yourself or running _arguments twice.  You can edit words (the
} command line) and CURRENT (the index into it), plus it's also possible
} in some contexts to tell _arguments to limit the words visible in the
} completion that it's calling by the use of enough colons.  I find
} directly manipulating words and CURRENT less infuriating.

Don't forget about compset:

    -n BEGIN [ END ]
          If the current word position as specified by the parameter
          CURRENT is greater than or equal to BEGIN, anything up to the
          BEGIN'th word is removed from the words array and the value
          of the parameter CURRENT is decremented by BEGIN.

          If the optional END is given, the modification is done only if
          the current word position is also less than or equal to END.
          In this case, the words from position END onwards are also
          removed from the words array.

          Both BEGIN and END may be negative to count backwards from
          the last element of the words array.

    -N BEG-PAT [ END-PAT ]
          If one of the elements of the words array before the one at
          the index given by the value of the parameter CURRENT matches
          the pattern BEG-PAT, all elements up to and including the
          matching one are removed from the words array and the value
          of CURRENT is changed to point to the same word in the
          changed array.

          If the optional pattern END-PAT is also given, and there is an
          element in the words array matching this pattern, the
          parameters are modified only if the index of this word is
          higher than the one given by the CURRENT parameter (so that
          the matching word has to be after the cursor). In this case,
          the words starting with the one matching end-pat are also
          removed from the words array. If words contains no word
          matching END-PAT, the testing and modification is performed
          as if it were not given.

So it should work to do something like

	compset -N '[^-]*'

before calling _arguments.

Re: Problem with _arguments

[Nikolai Weibull]

On 11/22/06, Peter Stephenson <pws@csr.com> wrote:

> > Actually, would there be a good way of tricking _arguments into only
> > seeing what you want it to see?  In this case, it would work fine if
> > one could trick it into only seeing the stuff after src, so that it
> > would continue completing options.
>
> There are certainly ways of updating the line, but the trouble is to
> find out what you need to do either you're going to be doing some
> parsing yourself or running _arguments twice.  You can edit words (the
> command line) and CURRENT (the index into it), plus it's also possible
> in some contexts to tell _arguments to limit the words visible in the
> completion that it's calling by the use of enough colons.  I find
> directly manipulating words and CURRENT less infuriating.

This worked out quite well actually.  Find is actually incredibly
complicated and has a rather horrible interface.  Anyway, here's my
solution:

    integer i
    (( i = index_of_find + 1 ))
    while [[ $words[i] == -([HLP]|-(help|version)) ]]; do
      (( i++ ))
    done
    while [[ -d $words[i] ]]; do
      (( i++ ))
    done
    words=($words[1,index_of_find] $words[i,-1])
    (( CURRENT -= i - index_of_find - 1 ))
    integer old_words_length
    (( old_words_length = $#words ))
    words=(${words:#\\[()\!]})
    (( CURRENT -= old_words_length - $#words ))

Index_of_find keeps track of the index of -find in the words array.
Here's the algorithm:

1.  The option -find can be followed by the options -H, -L, or -P to
specify how symbolic links are to be dealt with, along with -help or
-version, so skip those. [1]

2.  After that, any number of directories may follow. [2]

3.  Now we know what slice to remove from the words array and we do so.

4.  Next we need to remove any \!, any \(, and any \) that may appear
in the $words array, as these are used to negate and group expressions
and also mess up the command-line processing of _arguments. [3]

/Now/ we can call _arguments.

This can actually be used in _find as well, and I might submit a patch
once I'm done with this completion definition (for mkisofs if that was
unclear).

Super-happy-fun-thank-yous to Peter and Bart for your suggestions on
how to solve this.  Your answers are always helpful, insightful, and
to the point.  Seriously, you guys rock.  But it's also a bit sad that
you seem to be the only two that posses the necessary knowledge of Zsh
to answer these questions (and are active on these two mailing lists).
 I hope my shell-skills will reach your level some day.

  super-happy-fun-time-nikolai

[1]  Of course, if -help or -version is in the command line,
completion has ended already (they're defined as '(- *)-help...' and
'(- *)-version...'), so this is superfluous, but at least it's
complete.

[2]  Checking that they're directories is also a bit stupid, and
should perhaps only check that they don't match an option, for
example, [^-]*, but I figured this was a bit more expressive.

[3]  This could technically be limited to only the slice [i,-1], but I
wanted to keep things simple.

Re: Problem with _arguments

[Nikolai Weibull]

On 11/22/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 22, 10:39am, Peter Stephenson wrote:
> }
> } parsing yourself or running _arguments twice.  You can edit words (the
> } command line) and CURRENT (the index into it), plus it's also possible
> } in some contexts to tell _arguments to limit the words visible in the
> } completion that it's calling by the use of enough colons.  I find
> } directly manipulating words and CURRENT less infuriating.
>
> Don't forget about compset:
>
>     -n BEGIN [ END ]
>           If the current word position as specified by the parameter
>           CURRENT is greater than or equal to BEGIN, anything up to the
>           BEGIN'th word is removed from the words array and the value
>           of the parameter CURRENT is decremented by BEGIN.
>
>           If the optional END is given, the modification is done only if
>           the current word position is also less than or equal to END.
>           In this case, the words from position END onwards are also
>           removed from the words array.
>
>           Both BEGIN and END may be negative to count backwards from
>           the last element of the words array.
>
>     -N BEG-PAT [ END-PAT ]
>           If one of the elements of the words array before the one at
>           the index given by the value of the parameter CURRENT matches
>           the pattern BEG-PAT, all elements up to and including the
>           matching one are removed from the words array and the value
>           of CURRENT is changed to point to the same word in the
>           changed array.
>
>           If the optional pattern END-PAT is also given, and there is an
>           element in the words array matching this pattern, the
>           parameters are modified only if the index of this word is
>           higher than the one given by the CURRENT parameter (so that
>           the matching word has to be after the cursor). In this case,
>           the words starting with the one matching end-pat are also
>           removed from the words array. If words contains no word
>           matching END-PAT, the testing and modification is performed
>           as if it were not given.
>
> So it should work to do something like
>
>         compset -N '[^-]*'

The problem with this is that it removes arguments to options, that
is, it'll remove, as I understand it, the 1 to -maxdepth "find src
-maxdepth 1" causing all sorts of confusion for the _arguments
function and it won't complete anything after it any more.

  nikolai

Re: Problem with _arguments

[Bart Schaefer]

On Nov 22,  2:22pm, Nikolai Weibull wrote:
}
} > Don't forget about compset:
} >
} >     -N BEG-PAT [ END-PAT ]
} >           If one of the elements of the words array before the one at
} >           the index given by the value of the parameter CURRENT matches
} >           the pattern BEG-PAT, all elements up to and including the
} >           matching one are removed from the words array ...
} >
} >           If the optional pattern END-PAT is also given, and there is an
} >           element in the words array matching this pattern, the
} >           parameters are modified only if the index of this word is
} >           higher than the one given by the CURRENT parameter ...
} >
} > So it should work to do something like
} >
} >         compset -N '[^-]*'
} 
} The problem with this is that it removes arguments to options, that
} is, it'll remove, as I understand it, the 1 to -maxdepth "find src
} -maxdepth 1" causing all sorts of confusion for the _arguments
} function and it won't complete anything after it any more.

Actually in that case it should remove everything up to and including
the "1" so the completion should behave as if there is nothing on the
command line except the command word and the leading part of the word
containing the cursor (assuming it is to the right of the "1") -- plus
anything to the right of the cursor, of course.

As your real usage is considerably more complex than the example you
gave, that's probaby not what you want, but it's also not what you
understood.