Re: wish for a colored completion system

Re: wish for a colored completion system

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 9,  9:24am, Sven Wischnowsky wrote:
> } Subject: Re: wish for a colored completion system
> }
> } Bart Schaefer wrote:
> } 
> } > I'm not sure why ':completion:*:ssh:*' doesn't work for the combined
> } > listing; perhaps it's a bug.  Sven?
> } 
> } Hm, yes, the description in the docs make it sound as if it should
> } work. The problem is that without separate groups there is no way for
> } the completion code to find out that with
> } 
> }   zstyle ':completion:*:ssh:*:hosts' list-colors '=a*=31'
> }   zstyle ':completion:*:ssh:*:users' list-colors '=b*=32'
> } 
> } hosts starting with `b' should be coloured with `32'. We would need a
> } per-match colouring for that and that's too expensive.
> 
> I think you misunderstood my question.  I didn't ask why
> 
>     zstyle ':completion:*:ssh:*:hosts' list-colors '=a*=31'
> 
> doesn't work.  I asked why
> 
>     zstyle ':completion:*:ssh:*' list-colors '=a*=31'
> 
> doesn't work.  There isn't any group involved there at all; I don't ask
> for the hosts to be colored separately from the users; I just ask for
> anything that happens to be there (and that begins with `a') to work.
> But it doesn't, unless I set group-name ''.

;-) I understood that -- and noticed that the part you quoted doesn't
answer the question. That's why the next paragraph started the way it
did:

> And to come back to the question, the completion code only looks up
> the style with the tag in the context and it can't find out that the
> pattern used in the definition doesn't contain the tag. If we wanted
> to solve that, we would have to make _setup get the name of the group
> (which may be -default-) as an argument (when called from
> _description) and use that name in ZLS_COLORS. But then we would be
> back to what I said above.
> 
> So, we could (quite easily) change it, but that set-for-one-tag-and-
> used-for-others-too made me do it in the way we have it now, I would
> be willing to write the change if people say that they prefer it,
> though (I have group-name == '', so I don't care much about this).

I.e. _setup just uses the tag in ZLS_COLORS, as you've seen. To get
this right, we would shouldn't just make the colors be (almost) always 
used (11847) because that works only for functions using the
argument-* tags. Probably even more confusing.

The problem is really that the code in _setup can't find out what
pattern was used when defining the style. It should use the value for
`...:*:ssh:*' everywhere but it should use the one defined for
`:...:*:ssh:*:hosts' only for names of hosts. But since complist only
distinguishes between groups (and it can only do that), a setting for
the latter pattern would be used for usernames, too, if they are in
the same group and we change the calls to _setup as I suggested (and
then make it use that group name when adding things to ZSL_COLORS, of
course).

Hrm, maybe we should admit this and use the group name instead of the
tag when looking up list-colors.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Tags vs. groups, and ZLS_COLORS (Re: wish for a colored completion system)

[Bart Schaefer]

On Jun 13, 11:25am, Sven Wischnowsky wrote:
} Subject: Re: wish for a colored completion system
}
} Bart Schaefer wrote:
} 
} > I didn't ask why
} > 
} >     zstyle ':completion:*:ssh:*:hosts' list-colors '=a*=31'
} > 
} > doesn't work.  I asked why
} > 
} >     zstyle ':completion:*:ssh:*' list-colors '=a*=31'
} > 
} > doesn't work.
} 
} ;-) I understood that -- and noticed that the part you quoted doesn't
} answer the question. That's why the next paragraph started the way it
} did:
} 
} > And to come back to the question, the completion code only looks up
} > the style with the tag in the context and it can't find out that the
} > pattern used in the definition doesn't contain the tag.

I've been re-reading this explanation at least once a day for the past
four days, and it still doesn't make any sense to me.

} > If we wanted
} > to solve that, we would have to make _setup get the name of the group
} > (which may be -default-) as an argument (when called from
} > _description) and use that name in ZLS_COLORS. But then we would be
} > back to what I said above.

But _setup *DOES* get the name of the group as an argument when called
from _description!  And it DOES use that name in ZLS_COLORS.  Look:

+_alternative:28:while for then: _description hosts expl remote host name
+_description:3: local name gropt=-J format gname hidden hide match opts
+_description:5: opts=( ) 
+_description:7:if: [[ hosts == -([12]|)[VJ] ]]
+_description:12: _lastdescr=(  remote host name remote host name ) 
+_description:14: _setup hosts
+_setup:3: local val nm=0
+_setup:5:if: zstyle -a :completion::complete:ssh:argument-1:hosts list-colors val
+_setup:6:then: zmodload -i zsh/complist
+_setup:7:then if: [[ hosts == default ]]
+_setup:10:then else: eval ZLS_COLORS="(hosts)${(j.:(hosts).)${(@)val:gs/:/\\:}}:${ZLS_COLORS}"
+_setup:10:then else: ZLS_COLORS=(hosts):(argument-1): 

[I didn't happen to have a list-colors style set when generating that trace,
but that doesn't matter.]

} > So, we could (quite easily) change it, but that set-for-one-tag-and-
} > used-for-others-too made me do it in the way we have it now

Don't ask me how I got from there to here, but:  The problem REALLY is --
as can begin to be seen in the last line of that trace output -- that the
value of $ZLS_COLORS is the concatenation of the list-colors styles for
every tag that has been looked up in the whole completion.  So if any of
those styles lacks a (group) qualifier, it might be applied to the wrong
groups.  Hence _setup attempts to be sure that the group qualifier is
there, with sometimes-inappropriate results.

} The problem is really that the code in _setup can't find out what
} pattern was used when defining the style.

I don't think that's the problem.  Note in the trace above that we end up
with `:(argument-1)...:' in $ZLS_COLORS.  That's nonsensical; there's no
group named `argument-1'.  The problem is that _setup can't differentiate
between a "real tag" and a group name being used as a tag.  The *right*
behavior, I think, is for all "real tag" lookups to use `(-default-)' in
ZLS_COLORS, whereas group names being used as tags use their actual name.

Can we devise a way to tell _setup whether $1 is a real tag, or a group?
Treating `default' as the only real tag is just not cutting it.  Or else
don't try to use _setup to set ZLS_COLORS (see the other bug report about
how seldom it is being properly reset again).

Miscellaneous other things that I notice while staring at this:

Using a sensible-looking style like

    zstyle ':completion:*:ssh:*' list-colors '(users)=a*=31'

leads _setup to make the assignment

    ZLS_COLORS=(argument-1)(users)=a*=31:

which is syntactic garbage.

In _description, `_setup "$1"' is called BEFORE the group-name style is
looked up and used to determine $gname, so you're never guaranteed to get
the right group name in ZLS_COLORS in spite of all of _setup's efforts.

} Hrm, maybe we should admit this and use the group name instead of the
} tag when looking up list-colors.

It almost seems to me that it should be the other way around -- admit that
it doesn't work to look up list-colors by group name and require the group
name to be embedded in parens in the value of the style instead.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Tags vs. groups, and ZLS_COLORS (Re: wish for a colored completion system)

[Bart Schaefer]

On Jun 18,  4:42am, I wrote:
}
} } The problem is really that the code in _setup can't find out what
} } pattern was used when defining the style.
} 
} I don't think that's the problem.  Note in the trace above that we end up
} with `:(argument-1)...:' in $ZLS_COLORS.  That's nonsensical; there's no
} group named `argument-1'.  The problem is that _setup can't differentiate
} between a "real tag" and a group name being used as a tag.  The *right*
} behavior, I think, is for all "real tag" lookups to use `(-default-)' in
} ZLS_COLORS, whereas group names being used as tags use their actual name.
} 
} Can we devise a way to tell _setup whether $1 is a real tag, or a group?

(Sound of hand smacking forehead.)

If $1 is a real tag, then it'll be the same as the last field of the
context, right?  E.g. this bit of trace output:

+_setup:5:if: zstyle -a :completion::complete:ssh:argument-1:argument-1 list-colors val

So what if _setup was to do the following?

if zstyle -a ":completion:${curcontext}:$1" list-colors val; then
  zmodload -i zsh/complist
  if [[ "$1" = default ]]; then
    ZLS_COLORS="${(j.:.)${(@)val:gs/:/\\\:}}"
  elif [[ "$curcontext" = *:"$1" ]]; then
    eval "ZLS_COLORS=\"(-default-)\${(j.:(-default-).)\${(@)val:gs/:/\\\:}}:\${ZLS_COLORS}\""
  else
    eval "ZLS_COLORS=\"(${1})\${(j.:(${1}).)\${(@)val:gs/:/\\\:}}:\${ZLS_COLORS}\""
  fi

  # ...

fi

This seems to do exactly the right thing in the few cases I attempted.  Of
course, it doesn't address the problem with (group-name) in the value of
the list-colors style, nor the gname problem in _description ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wish for a colored completion system

[Bart Schaefer]

On Jun 10,  3:34am, Bart Schaefer wrote:
} Subject: Re: wish for a colored completion system
}
} I asked why
} 
}     zstyle ':completion:*:ssh:*' list-colors '=a*=31'
} 
} doesn't work.

The following does something more like I would expect, but I won't commit
it because I'm sure I've missed something.

Index: Completion/Core/_setup
===================================================================
@@ -4,7 +4,7 @@
 
 if zstyle -a ":completion:${curcontext}:$1" list-colors val; then
   zmodload -i zsh/complist
-  if [[ "$1" = default ]]; then
+  if [[ "$1" = (default|(|*-)argument-*) ]]; then
     ZLS_COLORS="${(j.:.)${(@)val:gs/:/\\\:}}"
   else
     eval "ZLS_COLORS=\"(${1})\${(j.:(${1}).)\${(@)val:gs/:/\\\:}}:\${ZLS_COLORS}\""

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wish for a colored completion system

[Bart Schaefer]

On Jun 9,  9:24am, Sven Wischnowsky wrote:
} Subject: Re: wish for a colored completion system
}
} Bart Schaefer wrote:
} 
} > I'm not sure why ':completion:*:ssh:*' doesn't work for the combined
} > listing; perhaps it's a bug.  Sven?
} 
} Hm, yes, the description in the docs make it sound as if it should
} work. The problem is that without separate groups there is no way for
} the completion code to find out that with
} 
}   zstyle ':completion:*:ssh:*:hosts' list-colors '=a*=31'
}   zstyle ':completion:*:ssh:*:users' list-colors '=b*=32'
} 
} hosts starting with `b' should be coloured with `32'. We would need a
} per-match colouring for that and that's too expensive.

I think you misunderstood my question.  I didn't ask why

    zstyle ':completion:*:ssh:*:hosts' list-colors '=a*=31'

doesn't work.  I asked why

    zstyle ':completion:*:ssh:*' list-colors '=a*=31'

doesn't work.  There isn't any group involved there at all; I don't ask
for the hosts to be colored separately from the users; I just ask for
anything that happens to be there (and that begins with `a') to work.
But it doesn't, unless I set group-name ''.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wish for a colored completion system

[Bart Schaefer]

On Jun 8,  5:02pm, Peter Stephenson wrote:
}
} It's perfectly possible to write a front-end to compile styles, though,
} which you give command names, colours, patterns, etc., and which produces
} the zstyle command.

Yes, I was thinking about that; it'd also be nice to document somewhere
the mapping from numbers to colors.  I realize we haven't done so because
it's defined in some other standard, but it seems to be relatively stable
so maybe we should at least mention that `dircolors --print-database` is
usually the way to find out (at least if you have GNU stuff around).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wish for a colored completion system

[Peter Stephenson]

> It's the normal way of configuring things for the new completion
> system and I definitely think colouring should be done like all other
> setup for it. The `=pat=col' syntax was partly chosen because we
> (well, some people here) wanted the possibility to use their $LS_COLOR
> for zsh, too. That left us not too many syntax extensions to use.

It's perfectly possible to write a front-end to compile styles, though,
which you give command names, colours, patterns, etc., and which produces
the zstyle command.  It's not really suitable for sticking in compinstall
at the moment since it needs quite a lot of work to handle non-default
contexts in a natural way.  You can specify a context at the moment, but
it's a bit bemusing for the average user who hasn't spent their weekends
wading through the manual, and it would be better to make it easier to
change the context from within the normal menu hierarchy rather than going
back to the top level each time.  Plus it ought to be called
`compconfigure', but there were things of that nature at the time.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070