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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

Catching up a bit ... anything on which I don't comment, I agree with
what PWS already said ...

On Nov 24, 11:44am, Sven Wischnowsky wrote:
} Subject: Questions (and PATCH: small change to _complete)
}
} Colours (in complist) for non-files (and grouping, you'll see):
} 
} the cleanest possibility I see for this is to come up with a syntax
} for ZLS_COLOURS that includes the group name. E.g.:
} 
}   ZLS_COLOURS='**foo:[A-Z]*=47'
} 
} The `**' is only the tag starting a pattern to be used for non-files,
} better character sequences are certainly possible (`(foo)[A-Z]*' or
} something?). The `foo:' gives the group name, so the whole things says 
} that the matches starting with uppercase letters in the group `foo'
} the `47' should be used.

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'

Thus the syntax would be

	file-type     =  "no" | "fi" | "di" | ... | '*' pattern
	grouped-type  =  group-name '=' file-type
	color-pattern =  file-type | grouped-type
	color-spec    =  color-pattern '=' color-code

} 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.

} 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?

} 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?

} (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.

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?

On Nov 26, 10:08pm, Peter Stephenson wrote:
} Subject: Re: Questions (and PATCH: small change to _complete)
}
} > Then we still need a better name for `tag' itself.
} 
} The words which come to mind are horribly generic, like `type', or
} something involving `context' which will be ambiguous, even though it
} describes how tags are thrown up.  Unless someone has a brainwave, tag is
} at least (with our current language) reasonably unambiguous.

How about "category"?  It's a bit generic, but not "horribly" so, and it
fits in with making the tags be the names of the groups.  A category is
just a named group, no?

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