Completion lists

Completion lists

[Yuri DElia]

Hi everyone,

I would like to customize how the completion list is shown in zsh, I a way
similar to how current emacs does it. I've looking around, but found nothing.

Whenever I complete a file prefix which is ambiguous, I get a list of the form:

$ cd prog<TAB>
program1
progman
progwhatever

I would like to highlight (in bold) the trailing/ambiguous part (typed in caps
here):

$ cd prog<TAB>
progRAM
progMAN
progWHATEVER

This would be a *huge* time saver for me. Often I find myself completing over a
long set of files with a very similar name, and I really don't know *where* to
look at. Bonus points if this works with complete_in_word.

Having the unambiguous part with ellipses would also be fine (if any simpler to
implement):

$ cd prog<TAB>
...ram
...man
...whatever

Though I would prefer highlighting.

Thanks for any info.

Re: Completion lists

[Bart Schaefer]

On Sep 13, 12:54pm, Yuri DElia wrote:
}
} I would like to highlight (in bold) the trailing/ambiguous part (typed in caps
} here):
} 
} $ cd prog<TAB>
} progRAM
} progMAN
} progWHATEVER

You should be able to do this with something like:

zstyle -e ':completion:*:default' list-colors \
    'reply=("=(#b)${words[CURRENT]:t}(*)=0=7")'

The -e option evaluates the style so you can use $words[CURRENT] to put
the string from the line into the style.  The highlight is controlled
by the =0=3 part, where =0 means no highlight on the parts that are
not matched by a pattern in parens and the =7 means use reverse video
on the part matched by the first sub-pattern in parens (here "(*)").
See the doc for the complist module ZLS_COLORS variable.

It won't work all the time because completion is a really complex beast.
You probably need to do the above a few times replacing "default" with
different tags.

For example, above I've use the tail (:t) of the current word so that
it'll do something useful when completing files in subdirectories, but
that isn't really necessary when completing variable names or options.
You might want to use one pattern for file completion and another for
other contexts.

If you've got matcher-list styles that do fancy completion in the middle
of words, $words[CURRENT] is going to be inadequate to the task (and it
is likely that nothing you can expand at the time the list-colors style
is evaluated would be sufficient).  You might specify case-insensitive
globbing on to help with mixed-case matcher-lists:

zstyle -e ':completion:*:default' list-colors \
    'reply=("=(#bi)${words[CURRENT]:t}(*)=0=7")'

If someone builds up a useful set of these based on this example, please
post back to the list.

Re: Completion lists

[Yuri DElia]

Bart Schaefer <schaefer <at> brasslantern.com> writes:

> zstyle -e ':completion:*:default' list-colors \
>     'reply=("=(#b)${words[CURRENT]:t}(*)=0=7")'
> 
> The -e option evaluates the style so you can use $words[CURRENT] to put
> the string from the line into the style.  The highlight is controlled
> by the =0=3 part, where =0 means no highlight on the parts that are
> not matched by a pattern in parens and the =7 means use reverse video
> on the part matched by the first sub-pattern in parens (here "(*)").
> See the doc for the complist module ZLS_COLORS variable.

Your code seem to fail badly with directories.
For instance, completing anything with "./" will incorrectly skip the first two
characters of the files themselves.

> If you've got matcher-list styles that do fancy completion in the middle
> of words, $words[CURRENT] is going to be inadequate to the task (and it
> is likely that nothing you can expand at the time the list-colors style
> is evaluated would be sufficient).  You might specify case-insensitive
> globbing on to help with mixed-case matcher-lists:
> 
> zstyle -e ':completion:*:default' list-colors \
>     'reply=("=(#bi)${words[CURRENT]:t}(*)=0=7")'

While I was waiting I kept trying and came up with this:

c='${PREFIX:+=(#b)($PREFIX:t)(?)*===$color[bold]}':'=(#b)(?)*==$color[bold]'
zstyle -e ':completion:*' list-colors "reply=(\"$c\")"

The first part of the reply matches the first character after the prefix.
The second matches the first character in a list (when completing directories). 
Seems to work fine for both files and parameters.

Doesn't work for anything beyond prefix matching:

$ ls ///list<TAB> (ambiguous)
etc/
lib/
usr/

will simply put the cursor after the first / and highlight the third characters 
of the list (and I don't understand why).

I'm wondering what variables could in the reply. I found $PREFIX in other 
examples, and now also $words[CURRENT]. Is there a list for these? Maybe I 
could make it work if I had SUFFIX/somethingelse.

> If someone builds up a useful set of these based on this example, please
> post back to the list.

I would also be glad.

Re: Completion lists

[Yuri DElia]

Yuri DElia <wavexx <at> users.sf.net> writes:

> c='${PREFIX:+=(#b)($PREFIX:t)(?)*===$color[bold]}':'=(#b)(?)*==$color[bold]'
> zstyle -e ':completion:*' list-colors "reply=(\"$c\")"

I think I've hit a zsh bug here :/.

c='${PREFIX:+=(#b)${PREFIX:t}(?)*==1}':'=(#b)(?)*==1'
zstyle -e ':completion:*' list-colors "reply=(\"$c\")"

Try to complete a directory such as "./" first. The second expression will 
match, and the first character becomes bold.

Now try:

$ touch fileaa
$ touch filebb
$ ls file<TAB>

(this will correctly highlight "a" and "b")

suddenly:

$ ls ./<TAB>

will still match the second expression '=(#b)(?)*==1' but here (?) will capture
the first 4 characters, not just the first one. The length is dependent on
previous PREFIX ("file" here).

Bug?

Re: Completion lists

[Bart Schaefer]

On Sep 13,  3:16pm, Yuri DElia wrote:
}
} Bart Schaefer <schaefer <at> brasslantern.com> writes:
} 
} > zstyle -e ':completion:*:default' list-colors \
} >     'reply=("=(#b)${words[CURRENT]:t}(*)=0=7")'
} 
} Your code seem to fail badly with directories.
} For instance, completing anything with "./" will incorrectly skip the
} first two characters of the files themselves.

It works just fine from

zsh -f
autoload -Uz compinit
compinit -D
zstyle ...

and it also works with my own usual completion styles, so there's
something else in your configuration that's clashing with it.

[...]

} While I was waiting I kept trying

Always a good plan.

} and came up with this:
} 
} c='${PREFIX:+=(#b)($PREFIX:t)(?)*===$color[bold]}':'=(#b)(?)*==$color[bold]'
} zstyle -e ':completion:*' list-colors "reply=(\"$c\")"

Strictly speaking I think you should use =0=0=$color[bold]}, that may be
why strange things are getting highlighted in some of your attempts.  I
get different results with =0=0= vs ===.

} I'm wondering what variables could in the reply. I found $PREFIX in
} other examples, and now also $words[CURRENT]. Is there a list for
} these? Maybe I could make it work if I had SUFFIX/somethingelse.

All the completion special variables are listed in the "Completion
Special Parameters" section of the manual (info section 19.2 with the
latest CVS checkout).

The list-colors style is looked up several times during the course of
a typical completion, so it may get evaluated late enough for the
values of words / PREFIX / SUFFIX etc. to be accurate.  I still think
it's going to be difficult to get a single global list-colors style
that covers all the cases.

Re: Completion lists

[Yuri DElia]

Bart Schaefer <schaefer <at> brasslantern.com> writes:

> Strictly speaking I think you should use =0=0=$color[bold]}, that may be
> why strange things are getting highlighted in some of your attempts.  I
> get different results with =0=0= vs ===.

Doesn't do anything for me.

Could you please try the following?

highlights='${PREFIX:+=(#b)${PREFIX:q:t}(?)*=0=1}':'=(#b)(?)*=0=1'
zstyle -e ':completion:*' list-colors "reply=(\"$highlights\")"
unset highlights

and try

touch filea
touch fileb

ls ./<TAB>

ls ./file<TAB>

ls ./<TAB>

and report what happens?

In the first ls, the first character is highlighted. In the second, [ab] should
be highlighted. In the third, the '=(#b)(?)*=0=1' expression fails, and matches
[ab] instead of [f].

You can also try this afterwards:

highlights='=(#b)(?)*=0=1'
zstyle -e ':completion:*' list-colors "reply=(\"$highlights\")"
unset highlights

and it will still match [ab].

Can you replicate this issue?

Re: Completion lists

[Bart Schaefer]

On Sep 13,  4:07pm, Yuri DElia wrote:
}
} $ touch fileaa
} $ touch filebb
} $ ls file<TAB>
} 
} (this will correctly highlight "a" and "b")
} 
} suddenly:
} 
} $ ls ./<TAB>
} 
} will still match the second expression '=(#b)(?)*==1' but here (?)
} will capture the first 4 characters, not just the first one.

The behvior I see is that it *skips* the first 4 characters and 
highlights the fifth one, i.e., it continues to highlight "a" and
"b" in those two files but highlights nothing in file names with
fewer than 5 characters.  Still wrong, but not in the way you said.

} The length is dependent on previous PREFIX ("file" here).
} 
} Bug?

It would appear so.  compstate[insert_positions]=5 at the end of the
"ls ./<TAB>" although compstate[unambiguous_positions]=2.  So the
pattern is matched correctly, but incorrectly is compared to the
string beginning at the 5th position.  Some part of the internal
state that should be getting cleared when the completion restarts,
is not.  This perists across ZLE restarts but not across different
words in command position, e.g. if you complete for "ls" twice in a
row it's broken, but if you complete for "ls" and then for "setopt"
and then back to "ls" again it works correctly all three times (or
at least did for me in a couple of quick trials).

Unfortunately I'm not going to have an opportunity to run that down
anytime soon.  Peter?

Re: Completion lists

[Yuri DElia]

Bart Schaefer <schaefer <at> brasslantern.com> writes:

> } will still match the second expression '=(#b)(?)*==1' but here (?)
> } will capture the first 4 characters, not just the first one.
> 
> The behvior I see is that it *skips* the first 4 characters and 
> highlights the fifth one, i.e., it continues to highlight "a" and
> "b" in those two files but highlights nothing in file names with
> fewer than 5 characters.  Still wrong, but not in the way you said.

On a related note, can I set a different list-colors when completing files, and
a default for everything else?

zstyle -e ':completion:complete-files:*' list-colors ...

don't seem to work.

Re: Completion lists

[Peter Stephenson]

How about this?

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.127
diff -p -u -r1.127 complist.c
--- Src/Zle/complist.c	19 Jun 2011 16:26:11 -0000	1.127
+++ Src/Zle/complist.c	16 Sep 2011 21:03:32 -0000
@@ -880,9 +880,9 @@ putfilecol(char *group, char *filename, 
     Patcol pc;
     int len;
 
-    nrefs = MAX_POS - 1;
+    for (pc = mcolors.pats; pc; pc = pc->next) {
+	nrefs = MAX_POS - 1;
 
-    for (pc = mcolors.pats; pc; pc = pc->next)
 	if ((!pc->prog || !group || pattry(pc->prog, group)) &&
 	    pattryrefs(pc->pat, filename, -1, -1, 0, &nrefs, begpos, endpos)) {
 	    if (pc->cols[1]) {
@@ -894,6 +894,7 @@ putfilecol(char *group, char *filename, 
 
 	    return 0;
 	}
+    }
 
     if (special != -1) {
 	colour = special;

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

Re: Completion lists

[Peter Stephenson]

Or even this?

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.127
diff -p -u -r1.127 complist.c
--- Src/Zle/complist.c	19 Jun 2011 16:26:11 -0000	1.127
+++ Src/Zle/complist.c	16 Sep 2011 21:06:08 -0000
@@ -849,9 +849,9 @@ putmatchcol(char *group, char *n)
 {
     Patcol pc;
 
-    nrefs = MAX_POS - 1;
+    for (pc = mcolors.pats; pc; pc = pc->next) {
+	nrefs = MAX_POS - 1;
 
-    for (pc = mcolors.pats; pc; pc = pc->next)
 	if ((!pc->prog || !group || pattry(pc->prog, group)) &&
 	    pattryrefs(pc->pat, n, -1, -1, 0, &nrefs, begpos, endpos)) {
 	    if (pc->cols[1]) {
@@ -863,6 +863,7 @@ putmatchcol(char *group, char *n)
 
 	    return 0;
 	}
+    }
 
     zcputs(group, COL_NO);
 
@@ -880,9 +881,9 @@ putfilecol(char *group, char *filename, 
     Patcol pc;
     int len;
 
-    nrefs = MAX_POS - 1;
+    for (pc = mcolors.pats; pc; pc = pc->next) {
+	nrefs = MAX_POS - 1;
 
-    for (pc = mcolors.pats; pc; pc = pc->next)
 	if ((!pc->prog || !group || pattry(pc->prog, group)) &&
 	    pattryrefs(pc->pat, filename, -1, -1, 0, &nrefs, begpos, endpos)) {
 	    if (pc->cols[1]) {
@@ -894,6 +895,7 @@ putfilecol(char *group, char *filename, 
 
 	    return 0;
 	}
+    }
 
     if (special != -1) {
 	colour = special;

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

Re: Completion lists

[Tomasz Pala]

On Tue, Sep 13, 2011 at 12:54:01 +0000, Yuri DElia wrote:

> I would like to customize how the completion list is shown in zsh, I a way
> similar to how current emacs does it. I've looking around, but found nothing.

I think I've already posted this (in polish, but with screenshots):
http://jakilinux.org/aplikacje/konsola/zsh-automatyzacja-czynnosci/
In this case try:

setopt extended_glob
highlights='${PREFIX:+=(#bi)($PREFIX:t)(?)*==31=1;32}':${(s.:.)LS_COLORS}}
highlights2='=(#bi) #([0-9]#) #([^ ]#) #([^ ]#) ##*($PREFIX)*==1;31=1;35=1;33=1;32=}'
zstyle -e ':completion:*' list-colors 'if [[ $words[1] != kill && $words[1] != strace ]]; then reply=( "'$highlights'" ); else reply=( "'$highlights2'" ); fi'
unset highlights

-- 
Tomasz Pala <gotar@pld-linux.org>

Re: Completion lists

[Yuri DElia]

Bart Schaefer <schaefer <at> brasslantern.com> writes:

> If someone builds up a useful set of these based on this example, please
> post back to the list.

Just for posterity, this is what I've using since a couple of days:

##################
# completition list colorization (emacs style)
highlight-comp()
{
  reply=()
  [ -n "$PREFIX" -a ! -d "$PREFIX" ] && reply+=( "=(#b)${PREFIX:q:t}(?)*==1" )
  reply+=( "=(#b)(?)*==1" )
}

zstyle -e ':completion:*' list-colors highlight-comp
##################

It seems to work fine for most cases. This particular code also seems to avoid
the reset bug as mentioned before (although this wasn't intended).

Is also works for in-word completions, like this:

% ls ///list<TAB>
etc/  lib/  usr/

but it's also pure chance, since PREFIX in this case seems to be "///list" which
doesn't pass the "! -d" test (which is done for simple directories). I tried to
write better code to handle this case, but "$compstate" doesn't seem to put
anything meaningful (I was expecting insert_positions to be set to something!).

Also, I could avoid the test entirely if I could set a different function when
completing arguments instead of files. How can I do this?

Thanks.

Re: Completion lists

[Mikael Magnusson]

On 18 September 2011 15:41, Yuri DElia <wavexx@users.sf.net> wrote:
> Bart Schaefer <schaefer <at> brasslantern.com> writes:
>
>> If someone builds up a useful set of these based on this example, please
>> post back to the list.
>
> Just for posterity, this is what I've using since a couple of days:
>
> ##################
> # completition list colorization (emacs style)
> highlight-comp()
> {
>  reply=()
>  [ -n "$PREFIX" -a ! -d "$PREFIX" ] && reply+=( "=(#b)${PREFIX:q:t}(?)*==1" )
>  reply+=( "=(#b)(?)*==1" )
> }
>
> zstyle -e ':completion:*' list-colors highlight-comp
> ##################
>
> It seems to work fine for most cases. This particular code also seems to avoid
> the reset bug as mentioned before (although this wasn't intended).
>
> Is also works for in-word completions, like this:
>
> % ls ///list<TAB>
> etc/  lib/  usr/
>
> but it's also pure chance, since PREFIX in this case seems to be "///list" which
> doesn't pass the "! -d" test (which is done for simple directories). I tried to
> write better code to handle this case, but "$compstate" doesn't seem to put
> anything meaningful (I was expecting insert_positions to be set to something!).
>
> Also, I could avoid the test entirely if I could set a different function when
> completing arguments instead of files. How can I do this?
[...]
> zstyle -e ':completion:*' list-colors highlight-comp

Here you can use something like ":completion:*:files:" instead, i
don't know off hand what the exact value you want is, bindkey some key
to _complete_help and check. Or maybe you want to make it match
against _files rather than the specific tag.

-- 
Mikael Magnusson

Re: Completion lists

[Mikael Magnusson]

[you forgot to reply to all]

On 18 September 2011 16:03, Yuri D'Elia <wavexx@users.sourceforge.net> wrote:
> On Sun, 18 Sep 2011 15:48:39 +0200, Mikael Magnusson wrote:
>>>
>>> % ls ///list<TAB>
>>> etc/  lib/  usr/
>>>
>>> but it's also pure chance, since PREFIX in this case seems to be
>>> "///list" which
>>> doesn't pass the "! -d" test (which is done for simple directories). I
>>> tried to
>>> write better code to handle this case, but "$compstate" doesn't seem to
>>> put
>>> anything meaningful (I was expecting insert_positions to be set to
>>> something!).
>>>
>>> Also, I could avoid the test entirely if I could set a different function
>>> when
>>> completing arguments instead of files. How can I do this?
>>
>> [...]
>>>
>>> zstyle -e ':completion:*' list-colors highlight-comp
>>
>> Here you can use something like ":completion:*:files:" instead, i
>> don't know off hand what the exact value you want is, bindkey some key
>> to _complete_help and check. Or maybe you want to make it match
>> against _files rather than the specific tag.
>
> I guess I want to match set a different functions depending whether I'm
> completing on _files or _arguments, but I'm unsure how to do that.
>
> $ vi ./d^xh
> tags in context :completion::complete:vi::
>    all-files  (_files _default (eval))
>
> Doing
>
> zstyle -e ':completion:*:files:' list-colors ..
>
> doesn't do what I mean.

As you can see, the tag here is "all-files", not "files". You also
need another * after the last :, I see that I missed that, sorry. I
think you can put either all-files or _files and it might work. Note
that if you set the list-dirs-first style, you'll get other-files and
directories instead of all-files.

-- 
Mikael Magnusson

Re: Completion lists

[Yuri D'Elia]

 On Sun, 18 Sep 2011 16:08:29 +0200, Mikael Magnusson wrote:
>> zstyle -e ':completion:*:files:' list-colors ..
>>
>> doesn't do what I mean.
>
> As you can see, the tag here is "all-files", not "files". You also
> need another * after the last :, I see that I missed that, sorry. I
> think you can put either all-files or _files and it might work. Note
> that if you set the list-dirs-first style, you'll get other-files and
> directories instead of all-files.

 Ah, thanks! This:

 ######
 # completition list colorization (emacs style)
 highlight-comp()
 {
   reply=( "=(#b)${PREFIX:q}(?)*==1" )
 }

 highlight-comp-files()
 {
   reply=()
   [ -n "$PREFIX" -a ! -d "$PREFIX" ] && reply+=( 
 "=(#b)${PREFIX:q:t}(?)*==1" )
   reply+=( "=(#b)(?)*==1" )
 }

 zstyle -e ':completion:*' list-colors highlight-comp
 zstyle -e ':completion:*:all-files' list-colors highlight-comp-files
 ######

 ...now covers a couple more edge cases where an argument might match 
 some existing files (git completion being one of the main offenders ;)).

 One more thing I'd like to cover when completing files.

 Is there a way to get the prefix up to the insert position when 
 completing something like:

 ls ///list<TAB>
 (where the cursor is placed just after the first /)

 Looking at the documentation, $compstate should help, but inside the 
 callback function PREFIX is still set to "///list" and 
 $compstate[insert_positions] is empty.