Re: Questions (and PATCH: small change to _complete)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> ZLS_COLORS is a colon-separated list already, isn't it?  Potentially
> pretty confusing to use a colon within an element as well as between.
> Using a second '=' might be better:
> 
> 	ZLS_COLORS='foo=[A-Z]*=47'

Ahem, right.

> ...
> 
> } The question, however, is, where we get those group names from.  [...]
> } why not use the tag names as group names.
> 
> I think this is a good idea.  Further, in the syntax above, group-name
> could be a pattern (including alternations with `(...|...)') to easily
> assign the same file-type and color-code to multiple groups.

Yes.

> } About the ordering of the groups in the list (i.e. which type of
> } matches appears at the top, below that, ..., at the bottom):  [...]
> } I suggested a special parameter that gives the names of the groups
> } already added and if a user modifies this, the order in which he uses
> } the group names defines the order in which they appear in the list.
> 
> This is probably fine.  One issue is what to do with any groups that
> the user deletes from the value of the parameter.  Don't display them
> at all?  Display them last?  Produce an error of some kind?  And what
> happens if the same group is added again later by some other completer?

Yes, I've been wondering about this, too. Part of the reason why I
made the other suggestion:

> } And here, too, we have the question of how we can
> } make this easily configurable. The most convenient way might be in
> } _sort_tags with an interface a bit like comptry. I.e. a builtin or
> } function that is called multiple times and gets one or more tags as
> } arguments. The matches for the tags from the first call are all put in
> } the first group, those from the second call are put in the second
> } group, etc. If this is a builtin, we could even make it do some hidden 
> } magic (creating empty groups with the right names and in the right
> } order) so that we wouldn't have to use the array-with-group names
> } business
> 
> I'm not sure I follow this.  It would be up to _sort-tags to call this
> proposed builtin with each tag in the right sequence, to create the
> sorted list?  I think separating the grouping of the matches from the
> sorting of the groups is the way to go ... does what you're proposing
> there handle that in some way?

I really had that idea while writing that message, I hadn't thought
about everything yet. Doing it in _sort_tags was just the first
thought because that's the place users fiddle with tags/groups
anyway. But I wasn't happy with throwing different controls together
again after we finally found a way to separate the tags and styles.

Hm, maybe I can think of something better, especially with the default 
behaviour I'd like to achieve (mentioned in 8797).

> } (and then that array wouldn't be in the way if we ever add a
> } possibility to access the matches and groups added in a later
> } release).
> 
> I don't see how the array would be "in the way".  It can serve the dual
> purpose of ordering the groups and of making their names known so that
> you know what groups it's sensible to ask for when accessing them.

To be able to define ordering of groups with such an array, we would
have to use a normal array. If we ever want to give raw access to the
matches and match-groups added we probably would want to use an assoc
with the group names as keys and some information about the groups as
the values (number of first/last match or whatever). Then we would
have either both or something which will probably be uglier than only
one assoc. I think. But I may be wrong.

> On Nov 26,  9:46am, Sven Wischnowsky wrote:
> } Subject: PATCHlet: was: Re: Questions (and PATCH: small change to _complet
> }
> } Bart Schaefer wrote:
> } 
> } > On Nov 25, 10:54am, Sven Wischnowsky wrote:
> } > } For now this patch makes command names be preceded and followed by two
> } > } colons. I.e. to unambiguously match the command name you can now do
> } > } `*::cvs:*' and to test for a command/tag combination: `*::command:*:tag'.
> } > 
> } > This only solves the problem in one direction, doesn't it?
> } 
> } The tag name is always the *last* component (and there is always only
> } one). In fact, it isn't really part of the context name stored in
> } $curcontext.
> 
> Here's a question ... why isn't $curcontext an array?  Is it really an
> advantage for it to be a colon-separated string?  And if it is, why not
> tie the regular array to a colon-array and get both for free?

I used the colon-separated string because 1) I liked making them look
a bit like other hierarchical names users already know (pathnames, of
course) and 2) it was clear from the beginning that they would be used 
for pattern matching and `*:dvips:-o*' looks more friendly than
`*" dvips -o"*' or some such. However, if we use an array, we could
make this look like one of those X.400 names:

  ( completer=complete command=dvips option=-o argument=1 tag=all-files)

Maybe going a bit too far? Or maybe not... And would probably call for 
help by some builtin to define patterns for such names.
But still, saving and restoring these things would be costlier than
the simple `local curcontext="$curcontext"' we have now.

Why not a tied array? Because I always forget that we have them.

And the main question: as long as we don't use the `...=...' syntax
above, when do we need to access single components? Currently we don't.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx