show-ambiguity style

show-ambiguity style

[Yuri D'Elia]

Hi everyone. A colleague today was particularly intrigued by the
'show-ambiguity' style that was introduced last year.

I realized it is basically unknown, google yields zero hits, and the
description in zshcompsys doesn't really give it justice. I love it too
much to let it rot. I've updated a page I wrote already last year with
some animations in order to show it off.

I'm posting it here, for random observers to see:

http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/

Re: show-ambiguity style

[lilydjwg]

On Fri, Apr 10, 2015 at 11:36:04PM +0200, Yuri D'Elia wrote:
> Hi everyone. A colleague today was particularly intrigued by the
> 'show-ambiguity' style that was introduced last year.
> 
> I realized it is basically unknown, google yields zero hits, and the
> description in zshcompsys doesn't really give it justice. I love it too
> much to let it rot. I've updated a page I wrote already last year with
> some animations in order to show it off.
> 
> I'm posting it here, for random observers to see:
> 
> http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/

Thanks! It's a nice feature I never knew :-)

-- 
Best regards,
lilydjwg

Re: show-ambiguity style

[Vadim Zeitlin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 907 bytes --]

On Fri, 10 Apr 2015 23:36:04 +0200 Yuri D'Elia <wavexx@thregr.org> wrote:

YDE> I realized it is basically unknown, google yields zero hits, and the
YDE> description in zshcompsys doesn't really give it justice. I love it too
YDE> much to let it rot. I've updated a page I wrote already last year with
YDE> some animations in order to show it off.
YDE> 
YDE> I'm posting it here, for random observers to see:
YDE> 
YDE> http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/

 Thanks for the post, this definitely was unknown to me. One question
though: is it possible to change the highlighting to use something other
than underlining? I often deal with the files with underscores in their
names and the ambiguous character is usually right after an underscore and
underscore following by an underlined character is not really readable. So
do you know if there is a style to change this?

 TIA,
VZ

[-- Attachment #2: Type: APPLICATION/PGP-SIGNATURE, Size: 196 bytes --]

Re: show-ambiguity style

[Bart Schaefer]

On Apr 11,  6:33pm, Vadim Zeitlin wrote:
} 
} YDE> http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/
} 
}  Thanks for the post, this definitely was unknown to me. One question
} though: is it possible to change the highlighting to use something other
} than underlining?

Zsh manual:

 show-ambiguity
     If the zsh/complist module is loaded, this style can be used to
     highlight the first ambiguous character in completion lists. The
     value is either a color indication such as those supported by the
     list-colors style or, with a value of true, a default of
     underlining is selected. The highlighting is only applied if the
     completion display strings correspond to the actual matches.

So for example:

  autoload colors
  colors
  zstyle ':completion:*' show-ambiguity $color[bg-red]

Completion gets screwed up if show-ambiguity is not an ANSI term color
attribute or one of the "true" strings (which by the way means you can't
use boldface because "1" means "true" and is therefore replaced with "4"
for underlining, but you can use e.g. "1;7" for "bold reverse video").

Anyway, the point is there could be more internal sanity checking that
the string that is output is going to make sense, but there currently is
not, so use caution.

Re: show-ambiguity style

[Yuri D'Elia]

On 04/11/2015 10:02 PM, Bart Schaefer wrote:
> Completion gets screwed up if show-ambiguity is not an ANSI term color
> attribute or one of the "true" strings (which by the way means you can't
> use boldface because "1" means "true" and is therefore replaced with "4"
> for underlining, but you can use e.g. "1;7" for "bold reverse video").

I mentioned it in the page (and now that I look again, you actually
responded to my first implementation ;)).

show_ambiguity is bolted on list-colors. I started approaching it just
as completer widget.

Since it just accepts a pattern to be fed to list colors, my setting is
actually more interesting(tm):

zstyle ':completion:*' show-ambiguity "1;4:=*=0"

I use bold-underline (not shown in the video), and the extra =*=0
pattern is used as a fallback match to clear any coloring. That is, if
there is no match, I don't want any color.

> Anyway, the point is there could be more internal sanity checking that
> the string that is output is going to make sense, but there currently is
> not, so use caution.

The way the match is constructed (a nested glob expression - a great
idea of Oliver Kiddle) is the neatest and weakest part IMHO. It makes
the highlight work even with complete_in_word, but surely is not as
efficient as post-processing the result *after* list coloring.

It would make sense to decouple show-ambiguity from file coloring. This
would enable to have both on, and avoid keeping extra state.

But again, show_ambiguity is not very well known. After seeing it in
emacs, I *had* to have it on zsh.

Re: show-ambiguity style

[Bart Schaefer]

On Apr 12,  2:40pm, Yuri D'Elia wrote:
} Subject: Re: show-ambiguity style
}
} On 04/11/2015 10:02 PM, Bart Schaefer wrote:
} > Completion gets screwed up if show-ambiguity is not an ANSI term color
} 
} I mentioned it in the page (and now that I look again, you actually
} responded to my first implementation ;)).

I'm not sure what this means ... the 20141010-zsh_show_ambiguity page has
not changed since I first looked at it.  Oh, you mean that I responded
on the users/18440 thread.  In any case there's nothing in either your
page or the docs to indicate that bad syntax in list-colors will garble
the completion display.

} The way the match is constructed (a nested glob expression - a great
} idea of Oliver Kiddle) is the neatest and weakest part IMHO. It makes
} the highlight work even with complete_in_word, but surely is not as
} efficient as post-processing the result *after* list coloring.

I don't know that it makes any difference to efficiency, but to have
the ambiguity disply overlaid on top of the other coloring would require
changes to the complist internals.

The main thing this is telling me is that we need more examples of how
to set list-colors.

Re: show-ambiguity style

[Yuri D'Elia]

On 04/12/2015 08:58 PM, Bart Schaefer wrote:
> I don't know that it makes any difference to efficiency, but to have
> the ambiguity disply overlaid on top of the other coloring would require
> changes to the complist internals.

My guess would be that it would probably end up being simpler and more
robust compared to the current approach.

Although I won't have time to look at this anytime soon.
Any takers?

> The main thing this is telling me is that we need more examples of how
> to set list-colors.

I'll put up some examples later next week.

Re: show-ambiguity style

[Jesper Nygårds]

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

This is interesting. I had also missed it.

I ran into something that perhaps is impossible to solve. If I use the
following:

zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
zstyle ':completion:*' show-ambiguity $color[bg-red]

I only get EITHER the file type coloring or the ambiguity indication,
depending on the order of those two lines.

In an ideal world, I would like to have the file type coloring, AND then
something that indicates where the ambiguity starts, but this is perhaps
not possible to achieve?



On Sun, Apr 12, 2015 at 11:03 PM, Yuri D'Elia <wavexx@thregr.org> wrote:

> On 04/12/2015 08:58 PM, Bart Schaefer wrote:
> > I don't know that it makes any difference to efficiency, but to have
> > the ambiguity disply overlaid on top of the other coloring would require
> > changes to the complist internals.
>
> My guess would be that it would probably end up being simpler and more
> robust compared to the current approach.
>
> Although I won't have time to look at this anytime soon.
> Any takers?
>
> > The main thing this is telling me is that we need more examples of how
> > to set list-colors.
>
> I'll put up some examples later next week.
>
>
>

Re: show-ambiguity style

[Bart Schaefer]

On Apr 13,  1:00pm, Jesper Nygards wrote:
}
} zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
} zstyle ':completion:*' show-ambiguity $color[bg-red]
} 
} I only get EITHER the file type coloring or the ambiguity indication,
} depending on the order of those two lines.

It shouldn't depend on the order of the lines.  I think if you look more
closely, you'll find that you get show-ambiguity any time there *is* an
ambiguity, and list-colors the rest of the time.

} In an ideal world, I would like to have the file type coloring, AND then
} something that indicates where the ambiguity starts, but this is perhaps
} not possible to achieve?

It's not currently possible because show-ambiguity is a trick done in
shell script code that sits on top of list-colors which is done in the
underlying C code.

There's a bit of side discussion on zsh-workers about this right now, but
nobody immediately available to make changes to the zsh/complist module.

Re: show-ambiguity style

[Jesper Nygårds]

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

On Mon, Apr 13, 2015 at 5:25 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Apr 13,  1:00pm, Jesper Nygards wrote:
> }
> } zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
> } zstyle ':completion:*' show-ambiguity $color[bg-red]
> }
> } I only get EITHER the file type coloring or the ambiguity indication,
> } depending on the order of those two lines.
>
> It shouldn't depend on the order of the lines.  I think if you look more
> closely, you'll find that you get show-ambiguity any time there *is* an
> ambiguity, and list-colors the rest of the time.
>
> I see. Bad testing on my part.


> } In an ideal world, I would like to have the file type coloring, AND then
> } something that indicates where the ambiguity starts, but this is perhaps
> } not possible to achieve?
>
> It's not currently possible because show-ambiguity is a trick done in
> shell script code that sits on top of list-colors which is done in the
> underlying C code.
>
> There's a bit of side discussion on zsh-workers about this right now, but
> nobody immediately available to make changes to the zsh/complist module.
>

OK. Too bad. Both are really nice, but I guess I'll have to choose then.

Re: show-ambiguity style

[Yuri D'Elia]

On 04/11/2015 10:02 PM, Bart Schaefer wrote:
> Completion gets screwed up if show-ambiguity is not an ANSI term color
> attribute or one of the "true" strings (which by the way means you can't
> use boldface because "1" means "true" and is therefore replaced with "4"
> for underlining, but you can use e.g. "1;7" for "bold reverse video").

I mentioned it in the page (and now that I look again, you actually
responded to my first implementation ;)).

show_ambiguity is bolted on list-colors. I started approaching it just
as completer widget.

Since it just accepts a pattern to be fed to list colors, my setting is
actually more interesting(tm):

zstyle ':completion:*' show-ambiguity "1;4:=*=0"

I use bold-underline (not shown in the video), and the extra =*=0
pattern is used as a fallback match to clear any coloring. That is, if
there is no match, I don't want any color.

> Anyway, the point is there could be more internal sanity checking that
> the string that is output is going to make sense, but there currently is
> not, so use caution.

The way the match is constructed (a nested glob expression - a great
idea of Oliver Kiddle) is the neatest and weakest part IMHO. It makes
the highlight work even with complete_in_word, but surely is not as
efficient as post-processing the result *after* list coloring.

It would make sense to decouple show-ambiguity from file coloring. This
would enable to have both on, and avoid keeping extra state.

But again, show_ambiguity is not very well known. After seeing it in
emacs, I *had* to have it on zsh.

Re: show-ambiguity style

[Daniel Shahaf]

Bart Schaefer wrote on Sat, Apr 11, 2015 at 13:02:49 -0700:
> Completion gets screwed up if show-ambiguity is not an ANSI term color
> attribute or one of the "true" strings (which by the way means you can't
> use boldface because "1" means "true" and is therefore replaced with "4"
> for underlining, but you can use e.g. "1;7" for "bold reverse video").

IIRC, both "1" and "01" work for bold.

The style was missing from the completion function:

diff --git a/Completion/Zsh/Command/_zstyle b/Completion/Zsh/Command/_zstyle
index 8f6c412..2f8981d 100644
--- a/Completion/Zsh/Command/_zstyle
+++ b/Completion/Zsh/Command/_zstyle
@@ -125,6 +125,7 @@ styles=(
   select-prompt          c:
   select-scroll          c:
   separate-sections      c:bool
+  show-ambiguity	 c:
   show-completer	 c:bool
   single-ignored         c:single-ignored
   sort			 c:bool

I haven't checked whether other styles are also missing.

Re: show-ambiguity style

[zzapper]

Yuri D'Elia <wavexx@thregr.org> wrote in news:mg9fo4$d3$1@ger.gmane.org:
h
> some animations in order to show it off.
> 

> 
> http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/
> 


any chance you could slow down the animation?



-- 
zzapper
https://twitter.com/dailyzshtip

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: show-ambiguity style

[Yuri D'Elia]

On 04/13/2015 10:21 PM, zzapper wrote:
> Yuri D'Elia <wavexx@thregr.org> wrote in news:mg9fo4$d3$1@ger.gmane.org:
>> some animations in order to show it off.
>>
>> http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/
> 
> any chance you could slow down the animation?

I updated it with some examples and more visible colors.

Re: show-ambiguity style

[zzapper]

Yuri D'Elia <wavexx@thregr.org> wrote in news:mgmfpj$88a$1@ger.gmane.org:

> On 04/13/2015 10:21 PM, zzapper wrote:
>> Yuri D'Elia <wavexx@thregr.org> wrote in news:mg9fo4$d3$1@ger.gmane.org:
>>> some animations in order to show it off.
>>>
>>> http://www.thregr.org/~wavexx/rnd/20141010-zsh_show_ambiguity/
>> 
>> any chance you could slow down the animation?
> 
> I updated it with some examples and more visible colors.
> 
> 
> 
> 
thanks Yuri!


-- 
zzapper
https://twitter.com/dailyzshtip

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com