zsh-workers
 help / color / mirror / code / Atom feed
* Funky list-colors
@ 2019-11-29 12:21 zsugabubus
  2019-11-29 16:06 ` Bart Schaefer
  0 siblings, 1 reply; 12+ messages in thread
From: zsugabubus @ 2019-11-29 12:21 UTC (permalink / raw)
  To: zsh-workers

zstyle ':completion::complete:*' list-colors 'fi=mXXX \e['

Zsh doesn't seem to correctly handle cases when “color” causes something
to being printed on the screen:
- because completion menu computes widths without colors, it completely
  loses its grid structure;
- because highlighted items in the menu (tab, tab, tab...) no longer get
  prefixed with colors from `list-colors`, they are becoming shorter,
  causing additional visual glitches.

I'm not completely sure if it's a bug or I am trying to do something
illegal with `list-colors`/`LS_COLORS`.

--
zsugabubus

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-11-29 12:21 Funky list-colors zsugabubus
@ 2019-11-29 16:06 ` Bart Schaefer
  2019-11-29 17:23   ` zsugabubus
  0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 2019-11-29 16:06 UTC (permalink / raw)
  To: zsugabubus; +Cc: Zsh hackers list

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

On Fri, Nov 29, 2019, 4:22 AM zsugabubus <
zsugabubus@national.shitposting.agency> wrote:

> zstyle ':completion::complete:*' list-colors 'fi=mXXX \e['
>
> Zsh doesn't seem to correctly handle cases when “color” causes something
> to being printed on the screen
>

Color sequences are assumed to be zero-width.  They aren't supposed to
insert printable text, the shell has no way to know how much space that
will use.


I'm not completely sure if it's a bug or I am trying to do something
> illegal with `list-colors`/`LS_COLORS`.
>

The latter :-)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-11-29 16:06 ` Bart Schaefer
@ 2019-11-29 17:23   ` zsugabubus
  2019-11-29 19:22     ` Bart Schaefer
  0 siblings, 1 reply; 12+ messages in thread
From: zsugabubus @ 2019-11-29 17:23 UTC (permalink / raw)
  To: zsh-workers

> > I'm not completely sure if it's a bug or I am trying to do something
> > illegal with `list-colors`/`LS_COLORS`.
> >
> 
> The latter :-)

Though the name clearly states that these are “colors”, but why this
artificial limitation? Width measuring happens at the prompts too, so
as a layman, couldn't the same logic be used here? (Or a simplified
one, assuming that only graphical escape codes are used.)

I really would like it to work and I'm gladly implement this if you say
yes (and help me a bit pointing out things).

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-11-29 17:23   ` zsugabubus
@ 2019-11-29 19:22     ` Bart Schaefer
  2019-11-29 20:37       ` zsugabubus
  0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 2019-11-29 19:22 UTC (permalink / raw)
  To: zsugabubus; +Cc: zsh-workers

On Fri, Nov 29, 2019 at 9:23 AM zsugabubus
<zsugabubus@national.shitposting.agency> wrote:
>
> Though the name clearly states that these are “colors”, but why this
> artificial limitation? Width measuring happens at the prompts too

Prompts have the reverse assumption, that everything is nonzero width
(needs counting) unless special syntax indicates otherwise.  The
overhead of designating the width of every color element and checking
whether it is greater than zero doesn't seem worth it, given that
we're sharing color definitions with other standard apps like "ls" and
none of THOSE support nonzero-width colors.

> I really would like it to work

Chances are there's a different way to do what you are trying to do.
What's the end goal here?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-11-29 19:22     ` Bart Schaefer
@ 2019-11-29 20:37       ` zsugabubus
  2019-12-04 23:27         ` Bart Schaefer
  0 siblings, 1 reply; 12+ messages in thread
From: zsugabubus @ 2019-11-29 20:37 UTC (permalink / raw)
  To: zsh-workers

On Fri, Nov 29, 2019 at 11:22:52AM -0800, Bart Schaefer wrote:
> On Fri, Nov 29, 2019 at 9:23 AM zsugabubus
> <zsugabubus@xxxxxxxx> wrote:
> >
> > Though the name clearly states that these are “colors”, but why this
> > artificial limitation? Width measuring happens at the prompts too
> 
> Prompts have the reverse assumption, that everything is nonzero width
> (needs counting) unless special syntax indicates otherwise.  The
> overhead of designating the width of every color element and checking
> whether it is greater than zero doesn't seem worth it, given that
> we're sharing color definitions with other standard apps like "ls" and
> none of THOSE support nonzero-width colors.
> 
> > I really would like it to work
> 
> Chances are there's a different way to do what you are trying to do.
> What's the end goal here?

Recently I completely get rid of terminal file managers because I
realized that they are much-much less powerful than the "plain" shell
could be. I can easily write small functions that do exactly what and
how I need. To keep my message short, I wanted to receive a quick visual
feedback what kind of files I work with. That's where `LS_COLORS` came
into the view. However, if I'm only using 3-4 colors it looks like a
rainbow (more colors can be hardly distinguished and remembered). I even
had no luck with fuzzy finders, because:
- fzf: I can't see the search highlights because of this rainbow
  (everything customize just the one I'd need not... hehh);
- fzy: Doesn't customizable too much;
- skim (fzf in rust): Can set background for search highlights (hurray)
  but fails to correctly display other colors.
So after my success story with colors, I started modifying `LS_COLORS`
to put prefixes before files. It's a way better solution from every
point of view. Programs handle it as much as I need[1], but zsh's
completion fails. .<- Here I'm now.

Personally, I don't care about that few additional microseconds that zsh
takes to parse that hundred 10 chars long string to compute how much
space will it take up on the screen. Maybe, hiding it behind an shell
option?

1: Expect `ls` grid view, but I can live without it.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-11-29 20:37       ` zsugabubus
@ 2019-12-04 23:27         ` Bart Schaefer
  2019-12-05  7:44           ` Oliver Kiddle
                             ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Bart Schaefer @ 2019-12-04 23:27 UTC (permalink / raw)
  To: zsugabubus; +Cc: zsh-workers

On Fri, Nov 29, 2019 at 12:37 PM zsugabubus
<zsugabubus@national.shitposting.agency> wrote:
>
> On Fri, Nov 29, 2019 at 11:22:52AM -0800, Bart Schaefer wrote:
> > What's the end goal here?
>
> To keep my message short, I wanted to receive a quick visual
> feedback what kind of files I work with. That's where `LS_COLORS` came
> into the view. However, if I'm only using 3-4 colors it looks like a
> rainbow (more colors can be hardly distinguished and remembered).
> [...]
> So after my success story with colors, I started modifying `LS_COLORS`
> to put prefixes before files.

OK, so what you want here is not to fiddle with the way completion
applies colors to the grid, but the way it populates the grid with
file names.

The first and most straightforward thing you might do is set the
LIST_TYPES option (it should be set by default, but maybe it's become
turned off).  This puts an identifiying character at the end of the
file name, e.g., character devices get a "%", block devices get  a
"#", directories a "/", symlinks an "@", etc.  (Oddly I can't find a
complete description of the identifying characters in the manual.)  If
you have this set and are not seeing these marks, it may be because
your completion function is not using "compadd -f" to tell the
internals to treat the names as files.

If that's not sufficient (e.g., you want to differentiate among files
that list_types treats as "plain") then I would presume you are doing
this with a pattern match in the LS_COLORS setting.  In that case you
should look at the file-patterns zstyle, which in combination with the
group-name and descriptions zstyles allows you to split the completion
listing into sections.  This can be a little tricky to get right, so
feel free to post samples of your attempts here if you want help.

If that's still not enough, then you'll want to create your own
completion function to manage these files.  "compadd -P prefix ..."
will attach a prefix to each string added by that call to compadd,
where that prefix is NOT treated as part of the file name, so if you
can make separate calls to compadd for each variety of file you want
to label, you can get exactly what you're looking for.

For even more detail you can use something similar to:
  compadd -o -d labels_array -a filenames_array
where there is one entry in $labels_array for each entry in
$filenames_array.  The completion system will arrange to build a grid
of the labels and names so that each name is paired with the
corresponding element from the labels.  However, it does place the
labels to the right of the names rather than to the left.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-12-04 23:27         ` Bart Schaefer
@ 2019-12-05  7:44           ` Oliver Kiddle
  2019-12-05 11:07           ` Sebastian Gniazdowski
  2019-12-07 20:58           ` zsugabubus
  2 siblings, 0 replies; 12+ messages in thread
From: Oliver Kiddle @ 2019-12-05  7:44 UTC (permalink / raw)
  To: zsugabubus, zsh-workers

Bart wrote:
> For even more detail you can use something similar to:
>   compadd -o -d labels_array -a filenames_array
> where there is one entry in $labels_array for each entry in
> $filenames_array.  The completion system will arrange to build a grid
> of the labels and names so that each name is paired with the
> corresponding element from the labels.  However, it does place the
> labels to the right of the names rather than to the left.

Actually the array specified with -d is not just for the labels but for
the whole string - match and label. So you can make any change you
like to how the match appears in the completion listing for your
own custom version of the LIST_TYPES option.

The common rendering of the match followed by a separator (-- by
default) and a label is not part of compadd. (in terms of man
pages/documentation sections, it is part of zshcompsys rather than
zshcompwid). In most, but by no means all, cases this is done from
_describe.

This also means that for things like the list-colors style, patterns
match the whole display string. It can thus be used to change
attributes for either or both match and label. For an example, try:
'=(#b)(--) (*)==32=3'

Oliver

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-12-04 23:27         ` Bart Schaefer
  2019-12-05  7:44           ` Oliver Kiddle
@ 2019-12-05 11:07           ` Sebastian Gniazdowski
  2019-12-05 11:19             ` Roman Perepelitsa
  2019-12-05 17:40             ` Oliver Kiddle
  2019-12-07 20:58           ` zsugabubus
  2 siblings, 2 replies; 12+ messages in thread
From: Sebastian Gniazdowski @ 2019-12-05 11:07 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsugabubus, zsh-workers

On Thu, 5 Dec 2019 at 00:28, Bart Schaefer <schaefer@brasslantern.com> wrote:
> OK, so what you want here is not to fiddle with the way completion
> applies colors to the grid, but the way it populates the grid with
> file names.
>
> The first and most straightforward thing you might do is set the
> LIST_TYPES option (it should be set by default, but maybe it's become
> turned off).  This puts an identifiying character at the end of the
> file name, e.g., character devices get a "%", block devices get  a
> "#", directories a "/", symlinks an "@", etc.  (Oddly I can't find a
> complete description of the identifying characters in the manual.)  If
> you have this set and are not seeing these marks, it may be because
> your completion function is not using "compadd -f" to tell the
> internals to treat the names as files.

This seems a less powerful than the hacky printable-LS_COLORS idea,
which I overall like. From experience, such things often result in
unpredictable and highly surprising + valuable solutions. Maybe it's
worth opening this door? In a most optimistic scenario, the code would
have to do a few isprints…

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-12-05 11:07           ` Sebastian Gniazdowski
@ 2019-12-05 11:19             ` Roman Perepelitsa
  2019-12-05 17:40             ` Oliver Kiddle
  1 sibling, 0 replies; 12+ messages in thread
From: Roman Perepelitsa @ 2019-12-05 11:19 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Bart Schaefer, zsugabubus, zsh-workers

On Thu, Dec 5, 2019 at 12:08 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> This seems a less powerful than the hacky printable-LS_COLORS idea,
> which I overall like. From experience, such things often result in
> unpredictable and highly surprising + valuable solutions. Maybe it's
> worth opening this door? In a most optimistic scenario, the code would
> have to do a few isprints…

I don't think it's generally possible to figure out by how much the
cursor will move when you write a given string to TTY. If it was
possible, there would be no need for %{...%}.

An alternative would be to add another flag that says that list-colors
should be percent-expanded. Or add a new parameter that is just like
list-colors but gets percent-expanded. Unlike with raw strings,
computing the length of a string that undergoes percent-expansion is a
solved prompt.

Roman.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-12-05 11:07           ` Sebastian Gniazdowski
  2019-12-05 11:19             ` Roman Perepelitsa
@ 2019-12-05 17:40             ` Oliver Kiddle
  1 sibling, 0 replies; 12+ messages in thread
From: Oliver Kiddle @ 2019-12-05 17:40 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: zsh-workers

Sebastian Gniazdowski wrote:
> This seems a less powerful than the hacky printable-LS_COLORS idea,
> which I overall like. From experience, such things often result in
> unpredictable and highly surprising + valuable solutions. Maybe it's
> worth opening this door? In a most optimistic scenario, the code would
> have to do a few isprints???

Such things also often result in weird bugs and broken feature
combinations if they haven't been thought through properly.

In this particular case, list-colors can take a form with just an
equals sign (`=') followed by a pattern. The pattern is matched
against the entire display string to specify colouring. But all the
work related to ensuring column alignment has already been done at
this stage. If you add extra visible characters, you may need to
change the alignment but it is too late for that.

As Bart mentioned there are already ways to define the exact form
of completion display strings. So this wouldn't even add anything
other than perhaps an easier configuration hook. If anyone has
specific ideas for cases where extra decoration on matches would
be useful, then patches to the relevant completion functions would
be welcome.

Oliver

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-12-04 23:27         ` Bart Schaefer
  2019-12-05  7:44           ` Oliver Kiddle
  2019-12-05 11:07           ` Sebastian Gniazdowski
@ 2019-12-07 20:58           ` zsugabubus
  2019-12-07 21:42             ` Oliver Kiddle
  2 siblings, 1 reply; 12+ messages in thread
From: zsugabubus @ 2019-12-07 20:58 UTC (permalink / raw)
  To: zsh-workers

On Wed, Dec 04, 2019 at 03:27:17PM -0800, Bart Schaefer wrote:
> OK, so what you want here is not to fiddle with the way completion
> applies colors to the grid, but the way it populates the grid with
> file names.
> 
> The first and most straightforward thing you might do is set the
> LIST_TYPES option [...]
>
> If that's not sufficient [...] you should look at the file-patterns
> zstyle...

Thanks, I know about and using both.

> If that's still not enough, then you'll want to create your own
> completion function to manage these files.  "compadd -P prefix ..."
> will attach a prefix to each string added by that call to compadd,
> where that prefix is NOT treated as part of the file name...

I tried it but my input was immediately completed by this prefix.

"ls <Tab>" -> "ls prefix".

If it's the intended behavior, I'm surely not look for this.

> For even more detail you can use something similar to:
>   compadd -o -d labels_array -a filenames_array

It looks wonderful! I think it will work for me. Can I make parts of
labels bold or colored? (Zsh seems to escape escape codes.) Or it's only
doable with "list-colors"?

-- 
zsugabubus

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Funky list-colors
  2019-12-07 20:58           ` zsugabubus
@ 2019-12-07 21:42             ` Oliver Kiddle
  0 siblings, 0 replies; 12+ messages in thread
From: Oliver Kiddle @ 2019-12-07 21:42 UTC (permalink / raw)
  To: zsugabubus; +Cc: zsh-workers

zsugabubus wrote:
> > For even more detail you can use something similar to:
> >   compadd -o -d labels_array -a filenames_array
>
> It looks wonderful! I think it will work for me. Can I make parts of
> labels bold or colored? (Zsh seems to escape escape codes.) Or it's only
> doable with "list-colors"?

From a normal completion function, you can add color specifications to
_comp_colors. It helps if you're using groups. The following will make
the strings green:

  compadd -J group -o -ld labels_array -a filenames_array
  _comp_colors+=( "(group)=*=32" )

For an example of this, see the _ps1234 function. This handles
completion for, e.g: PS1='%F{<tab>
In general, this is left up to users to configure with list-colors so
there aren't other examples.

The format style also allows attributes to be specified which is applied
to various messages or heading labels.

Oliver

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2019-12-07 21:43 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-29 12:21 Funky list-colors zsugabubus
2019-11-29 16:06 ` Bart Schaefer
2019-11-29 17:23   ` zsugabubus
2019-11-29 19:22     ` Bart Schaefer
2019-11-29 20:37       ` zsugabubus
2019-12-04 23:27         ` Bart Schaefer
2019-12-05  7:44           ` Oliver Kiddle
2019-12-05 11:07           ` Sebastian Gniazdowski
2019-12-05 11:19             ` Roman Perepelitsa
2019-12-05 17:40             ` Oliver Kiddle
2019-12-07 20:58           ` zsugabubus
2019-12-07 21:42             ` Oliver Kiddle

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).