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