Questions (and PATCH: small change to _complete)

Questions (and PATCH: small change to _complete)

[Sven Wischnowsky]

[ This has become longer than I expected, but please try to read it
  and give us your comments. And none of this `I'm not a key
  developer' busines, please. *Especially* if you think you aren't one 
  of those, I'd be interested to hear your opinions. ]


The patch below make _complete change the current context name only if 
it is called from _main_complete. This means that when using, e.g.
_match, we don't get a context name such as `:match:complete:...',
instead we get only `:match:...'.


But I really only wanted to take the opportunity to ask some questions 
for the last things I'd like to have answered before the next official 
release. Some of these I have asked already, but since some may have
missed them... here they are all in one place:


Context names:

When completing in command position, _normal appends `-complete-' to
the context name (e.g. `:complete:-command-'). This is fine. When
completing arguments of commands, however, it only appends the command 
name (e.g. `:complete:dvips'). I'm a bit worried that someday we will
find out that we have used a tag name that is also the name of a
command and then it's non-trivial to write a compstyle-pattern that
correctly matches only the command name. We could make this much
easier by letting _normal add, e.g. the pseudo-context name -argument-.
We would then have context names like `:complete:-argument-:dvips:...'
or maybe `:complete:dvips:-argument-:...'. Or we could put them
together as in: `:complete:-argument-dvips-:...' or we just extend
-command- in this way: `:complete:-command-dvips-:...'. In any of
these cases it would (obviously) be simple to write compstyle patterns 
that unambiguously match the command name. So, what do you think? And
which naming style do you prefer?


Colours (in complist) for non-files (and grouping, you'll see):

Lately someone suggested this (or asked for it, I don't remember
exactly) and I've been asking it, too. We could extend the ZLS_COLOURS 
parameters to support patterns (like the extension patterns we already 
have for filenames) that are to be used for matches which are not
files. That is simple. Trivial. Extremly that.
*But* I haven't doen that yet because I think if we support this, we
should support it on a per-group (per match-type) basis. I.e. one
should be able to say that for different groups, different colours and 
patterns should be used. From the colour-specification point of view
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. If we use a syntax such as `(foo)...' we
could also allow users to combine this with the standard capabilities
as in `(foo)di=...' and make it be used for filenames, too.
The question, however, is, where we get those group names from.
Currently they are generated in _description, which just uses the
description string. But now that we have this tag mechanism and the
one-to-one correspondence between tags and match groups I find it
tempting to throw them together even more. I.e. why not use the tag
names as group names. There may be some places hiding in Completion/*/_*
where it isn't that easy to ensure, but for now I'm quite positive
that we can make it.
With this we could also allow users more control over the groups --
something Bart has been asking for. I.e. we could support styles that
say something like `matches in this group should be put together with
matches in one of the groups...' (in the display, that is). So, if
users don't like he all-or-nothing grouping done by :matches:group
style (which would then be removed and the default), they could say
which types of matches they want to have grouped together.
I'm not entirely sure that doing this with styles is the best
solution, though. Maybe someone can think of a more convenient way to
specify this, probably together with:
About the ordering of the groups in the list (i.e. which type of
matches appears at the top, below that, ..., at the bottom): the main
problem here is that the completion code (the C side) just displays
the groups in the order in which they are created. And the of course
depends on the order in which the completion functions try the tags. I 
think changing all completions functions that could make use of such a 
control is out of the question (after all, I'm trying to make writing
completion functions easier). So we would need some other mechanism -- 
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.
Probably not the brightest idea I ever had, but I still can't think of 
anything better. 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 (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).
So, all this sounds complicated (probably only because I'm not having
enough ideas about all this yet), but what do you think? Is it
interesting enough to try to add it? I think some users would like to
be able to say that, e.g., they want to see the names of directories
only after the names for the globbed files. Things like that. And with 
all this prompt colouring stuff going on, some people would probably
also like to be able to colour all matches.


More configuration via styles:

Andrej has been asking for things like this for a long time. Currently,
some things affecting the completion stuff can only be changed with
shell options. From the beginning (well, almost from the beginning) I
wanted to make the completion code use those options only for the
initial settings for some of the $compstate keys and make the rest of
the completion code only use the settings from there. For some of the
newer options I haven't done that yet, mainly because of this:
We might want to allow users to specify these things via styles. And
to make that good, they should be able to specify them on a per-tag
basis. E.g. they could say something like: `if processes are added,
use menu-completion'. After some really ugly ideas I had about how we
could achieve this, I had this idea which I really like:
We could make the current settings of the $compstate keys in question
(turned into more-or-less boolean flags) be stored in the structs we
use for matches (the is still room anyway). That would mean that the
real behaviour isn't determined until the end, or, for some
flags/options, until the list is calculated. The completion would go
through the matches added, look at the flags and then decide what to
do. E.g. if there are matches that say that they want to be completed
in a menu-completion, menu-completion is used (for all matches). Some
of the options may really be work on a per-group basis (e.g. list_max
without the zero special case, or list-options like listpacked and
listrowsfirst). For others it may be non-trivial to implement this
merging-of-flags in the right way (e.g. auto_menu, I think). But that
shouldn't keep us from trying, I think. Also, I'm not entirely sure
about interactions with completers like _approximate which may want to 
change the default value for some options. But for now I think this
will turn out to be not so big a problem.
Apart from this there is the question if we want to make other things
configurable with styles. For example the colour stuff mentioned
above. Sounds reasonable to me.


Hidden matches in menu-selection:

Currently, menu-selection does not work at all when there are hidden
matches in the list. From a user's point of view this may be especially 
surprising because he may not know why this isn't possible for some
lists. From a completion function writer's point of view there are two 
cases: the match may explicitly added as hidden (the -n option of
compadd), here he knows that this will break menu-selection. But if
the completion function does not use -n, there may still be hidden
matches because the completion code may find out that mutliple matches 
would be displayed as the same strings in the list and in this case,
all of these matches except one will automatically be hidden.
It would be quite easy, however, to make menu-selection show these
matches, too. In non-selection lists they still wouldn't be shown. The 
question is: should we do that? It may look a bit irritating if the
same string appear more than once in the list and only moving the mark 
over them shows that they insert different things into the line. So we 
might want to make them distinguishable in the list. This can be done
by either showing all the prefixes and suffixes for such matches or by 
showing the only those prefixes or suffixes which differ from match to 
match. The former may be extremly ugly if all the matches have an
identical and very long prefix (-path, for example). The latter... I'm 
not quite sure how difficult it would be to find out the minimal set
of prefixes and/or suffixes to make the strings unambiguous.
And there is also the question if in such cases these prefixes should
be shown for all matches or only for those that would otherwise show
the same string (the latter may look weird, I think). And there is the 
question how the extra string should be displayed. E.g. something like 
`[prefix]string[suffix]', probably using different types of
parentheses for different types of prefixes/suffixes? Or something
completely different? Colours from some more ZLS_COLOURS capabilities?


Tags and styles:

I've been asking for help for this several times already (I know that
you all need some more time to get used to all this new stuff, I only
want to put all my open questions here...). We might want to reduce
the number of tags used. For example, I think we could replace many of 
those currently used by `name' or `value'.
And maybe some of the tag and style names can be changed to something
better?
Then we still need a better name for `tag' itself.
And finally, we might want to think about new styles that seem
interesting. I've only ideas for two: a `separator' style that gives
the string to use to seperate matches from `description' in the
verbose lists (the places where we currently use ` -- '). And, maybe,
just maybe, we might want to support the complete-only-names-of-
set/unset-options via style. Nowadays, the parameter module is loaded
anyway, but unfortunately we would still need _main_complete to store
the original option setting in some array. Hm.


Functions:

Before the next official release we might want to have a look if all
the completion functions are in the right directories. We've already
changed some (where it was obvious enough), but there may be more. And 
then there is the incompatibility problem Andrej somtimes remineded is 
of. Some functions may need tests on $OSTYPE or something. Oh, and I'd 
still like to have a _nis function to go along with _yp but still
don't have access to a NIS+ server. Sniff.


Ok, that's all I'm thinking about. Comments? Even answers?


Bye
 Sven

diff -u oldcompletion/Core/_complete Completion/Core/_complete
--- oldcompletion/Core/_complete	Wed Nov 24 09:03:50 1999
+++ Completion/Core/_complete	Wed Nov 24 10:08:08 1999
@@ -4,7 +4,9 @@
 # a normal completion function, but as one possible value for the
 # completer style.
 
-local comp name curcontext="${curcontext}:complete" oldcontext
+local comp name curcontext="$curcontext" oldcontext
+
+[[ "$funcstack[2]" = _main_complete ]] && curcontext="${curcontext}:complete"
 
 oldcontext="$curcontext"
 

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

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

[Sven Wischnowsky]

The patch below just fixes three thinkos (avoid to prepend the
completer name to the context if there is alredy a suitable setting
and save/restore $curcontext in _main_complete) and one typo...

Bart Schaefer wrote:

> On Nov 25, 10:54am, Sven Wischnowsky wrote:
> } Subject: Re: Questions (and PATCH: small change to _complete)
> }
> } I wrote:
> } 
> } > When completing in command position, _normal appends `-complete-' to
> } > the context name (e.g. `:complete:-command-'). This is fine. When
> } > completing arguments of commands, however, it only appends the command 
> } > name (e.g. `:complete:dvips'). I'm a bit worried that someday we will
> } > find out that we have used a tag name that is also the name of a
> } > command and then it's non-trivial to write a compstyle-pattern that
> } > correctly matches only the command name.
> } 
> } Ouch ;-) There was already the cvs tag.
> } 
> } 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?  That is, now
> you can tell that tag is not a command name, but how do you tell that a
> command name is not a tag?
> 
> What I mean is, if testing "*:cvs:*" to find the cvs tag, but the context
> is "...::cvs::..." because the command name is "cvs", then the tag branch
> is going to be taken because "*:cvs:*" matches both "::cvs::" and ":cvs:".
> It's a pain to have to test "*[^:]:cvs:*" just to be sure, especially
> since that won't match if "cvs" is the first thing in the context (or is
> that impossible for a tag name?).

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. It is only temporarily appended to that in _style to
match the style patterns defined. And of course, in _sort_tags the
tags are not appended at all, because that function decides which ones 
are to be used.

Maybe I should try to make this clearer in the docs, although I
already tried to do that in this double-colon patch.

> } And I forgot to say that before the next release we should make sure
> } that we set up good defaults for styles and probably improve the
> } default _sort_tags. But I think this should really be done at the end.
> 
> I still need some good examples of styles.  As I mentioned before, I'd
> never done much with compconf, so I didn't have anything for the "new"
> compconf to convert into styles.  Consequently, I'm now back almost to
> the bottom of the learning curve in understanding exactly what I can or
> might want to do, and how.

compinit already sets up a few default styles, trying to make things
behave almost in the same way as it did before (especially for people
like you who had no or only few compconfig's).

Well, otherwise, the docs are up-to-date. You can set prefered host,
user, group and port names and combinations thereof, as in:

  compstyle '*::rlogin:*' users-hosts user1:host1 user2:host2 ...

We have the new style that says if you complete job-names instead of
job-numbers (this is a boolean style; and this uses a pattern that
matches only the tag, btw.):

  compstyle '*:jobs' strings yes

And there are the styles for the completers saying how many errors to
accept (for correction), if the original string should be shown (for
correction and exapnsion). And, of course, the completer style. This
one also shows one nice difference to the config stuff. There we had a 
bunch of *_completer keys for normal completion, prediction,
incremental completion. Now we have only one style, the rest is done
using appropriate patterns:

  compstyle '*' completer _complete _correct _approximate
  compstyle ':incremental*' completer _complete _correct
  compstyle ':predict*' completer _complete

The mechanism that `sorts' pattern (i.e. makes more specific patterns
be tried first) automatically ensures that for these patterns the
right completer setting will be chosen. A similar cleanup happened
with all these correct_* vs. approximate_* vs correctword_* keys. Now
there are only the styles (like `original') and the pattern determines 
which setting is used:

  compstyle ':correct' max-errors 2 numeric
  compstyle 'correct-word' max-errors 2 numeric

(These styles are tested without appending a tag name. Mainly because
I couldn't think of a good one.)

The one that has changed most is `verbose', formerly known as
`description'. It is now also used to decide if things like processes, 
jobs and dirstack-entries should be listed only as numbers or with the 
text that previously was the default (and because of that, setting this 
to true is one of the defaults I added to compinit).

My favorite styles are probably:

  compstyle '*:descriptions' format '%B--------- %d:%b'
  compstyle '*:messages' format '%B%U--------- %d%u%b'
  compstyle '*:warnings' format '%B%U--------- no match for: %d%u%b'
  compstyle '*:matches' group 'yes'
  compstyle '*:options' auto-description 'specify %d'

(`Favorite' in the sense that I `see' them more often then other styles.)
If you don't like the output style this defines, then this probably
proves that having this configuarable is good.

Bye
 Sven

diff -u -r oldcompletion/Core/_approximate Completion/Core/_approximate
--- oldcompletion/Core/_approximate	Wed Nov 24 17:06:53 1999
+++ Completion/Core/_approximate	Fri Nov 26 09:36:05 1999
@@ -17,7 +17,7 @@
 
 [[ "${#:-$PREFIX$SUFFIX}" -le 1 ]] && return 1
 
-[[ "$curcontext" != *:correct ]] && curcontext="${curcontext}:approximate"
+[[ "$curcontext" != *:correct* ]] && curcontext="${curcontext}:approximate"
 
 oldcontext="$curcontext"
 
diff -u -r oldcompletion/Core/_correct Completion/Core/_correct
--- oldcompletion/Core/_correct	Wed Nov 24 17:06:53 1999
+++ Completion/Core/_correct	Fri Nov 26 09:36:33 1999
@@ -8,7 +8,9 @@
 # Supported configuration keys are the same as for `_approximate', only
 # starting with `correct'.
 
-local ret=1 opm="$compstate[pattern_match]" curcontext="${curcontext}:correct"
+local ret=1 opm="$compstate[pattern_match]" curcontext="${curcontext}"
+
+[[ "$curcontext" != :correct* ]] && curcontext="${curcontext}:correct"
 
 compstate[pattern_match]='-'
 
diff -u -r oldcompletion/Core/_expand Completion/Core/_expand
--- oldcompletion/Core/_expand	Wed Nov 24 17:06:53 1999
+++ Completion/Core/_expand	Fri Nov 26 09:24:17 1999
@@ -8,7 +8,9 @@
 # word from the line.
 
 local exp word="$PREFIX$SUFFIX" group=-V expl expl2 disp orig menu prompt
-local curcontext="${curcontext}:expand" expr descr
+local curcontext="${curcontext}" expr descr
+
+[[ "$curcontext" != :correct* ]] && curcontext="${curcontext}:correct"
 
 # First, see if we should insert all *completions*.
 
diff -u -r oldcompletion/Core/_main_complete Completion/Core/_main_complete
--- oldcompletion/Core/_main_complete	Wed Nov 24 17:06:53 1999
+++ Completion/Core/_main_complete	Fri Nov 26 09:32:35 1999
@@ -18,7 +18,7 @@
 
 
 local comp post ret=1 _compskip _prio_num=1 _cur_context format
-local context state line opt_args val_args curcontext
+local context state line opt_args val_args curcontext="$curcontext"
 typeset -U _offered_tags _tried_tags _failed_tags _used_tags _unused_tags
 
 _offered_tags=()

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

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

[Sven Wischnowsky]

I wrote:

>   compstyle ':correct' max-errors 2 numeric
>   compstyle 'correct-word' max-errors 2 numeric

Since this is in code people might want to try, I better correct this
typo. It should have been

  compstyle ':correct-word' max-errors 2 numeric

of course.

Bye
 Sven


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

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

[Peter Stephenson]

[ Thanks to an external modem, a new ISP, qmail... I finally have access to
the net under Linux, so I can reply to some things more easily... ]

Sven Wischnowsky wrote:
> When completing in command position, _normal appends `-complete-' to
> the context name (e.g. `:complete:-command-'). This is fine. When
> completing arguments of commands, however, it only appends the command 
> name (e.g. `:complete:dvips'). I'm a bit worried that someday we will
> find out that we have used a tag name that is also the name of a
> command and then it's non-trivial to write a compstyle-pattern that
> correctly matches only the command name. We could make this much
> easier by letting _normal add, e.g. the pseudo-context name -argument-.
> We would then have context names like `:complete:-argument-:dvips:...'

This looks OK, since (presumably?) it guarantees a special context after
the name of the completer --- working well with the patch included in this
post.  But for people to be sure they're matching the command name, they're
going to have to do things like :*:*:dvips:* anyway, and presumably most
people (probably including me) won't be that careful.  Still, it's
definitely neater.

I see this has now become just `::', which is OK if it's going to be used a
lot, something I can't really tell yet.  If it isn't, the full -argument-
thing might be more consisent.

> Colours (in complist) for non-files (and grouping, you'll see):
> 
>   ZLS_COLOURS='**foo:[A-Z]*=47'

I'm so far a bit agnostic on this sort of thing.  How many people are going
to go into this sort of detail to sort out groups and tags, whatever the
syntax is?  Groups in particular are fairly well buried inside completion
functions (unless something's changed here, I haven't completely absorbed
everything about the latest status yet).  But I'm not against control of
this kind.

> We might want to allow users to specify these things via styles.
> ... 

All this stuff sounds reasonable.  Styles are good because we could, as I
mentioned (without doing anything about it :-/), put them into an
extended menu-driven compinstall, so it becomes easy to alter.

> Hidden matches in menu-selection:

Maybe they should behave like a special completion group, with a message
above like `<Hidden Matches>', or something.  It makes it all explicit.

> Tags and styles:
> 
> I've been asking for help for this several times already (I know that
> you all need some more time to get used to all this new stuff, I only
> want to put all my open questions here...). We might want to reduce
> the number of tags used. For example, I think we could replace many of 
> those currently used by `name' or `value'.

OK by me.

> And maybe some of the tag and style names can be changed to something
> better?

We should make a complete list of the current ones (easy but dull) and see
what it looks like, then maybe we'll get ideas.

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

> Nowadays, the parameter module is loaded
> anyway, but unfortunately we would still need _main_complete to store
> the original option setting in some array. Hm.

Without actually looking, I don't think it would be hard to have a pointer
which always points to the top-level options, and let parameter access
that.  In fact it *sounds* pretty trivial.

> Functions:
> 
> Before the next official release we might want to have a look if all
> the completion functions are in the right directories. We've already
> changed some (where it was obvious enough), but there may be more. And 
> then there is the incompatibility problem Andrej somtimes remineded is 
> of. Some functions may need tests on $OSTYPE or something. Oh, and I'd 
> still like to have a _nis function to go along with _yp but still
> don't have access to a NIS+ server. Sniff.

Needs checking, but can safely be left till fairly late, since it's
maddening to have to do it over again after some tinkering.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

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

[Sven Wischnowsky]

Peter Stephenson wrote:

> ... [ making the command name distinguishable in context names ]
> 
> This looks OK, since (presumably?) it guarantees a special context after
> the name of the completer --- working well with the patch included in this
> post.  But for people to be sure they're matching the command name, they're
> going to have to do things like :*:*:dvips:* anyway, and presumably most
> people (probably including me) won't be that careful.  Still, it's
> definitely neater.

This `:*:*:dvips:*' is not guaranteed to work, because one can't be
sure how many components are before the command name. E.g. _complete
uses only :complete, but _approximate uses :approximate:<num-of-errors>
and both can be preceded by, e.g., :predict. Also, currently functions
may test for styles without appending a tag, so the trailing colon
wasn't guaranteed to work either. It is now, with the patch that made
the double colons be used.

> I see this has now become just `::', which is OK if it's going to be used a
> lot, something I can't really tell yet.  If it isn't, the full -argument-
> thing might be more consisent.

Yes, only time will tell. However, I've changed all the examples in
the docs (at least I hope I found all of them) and the _sort_tags
example function. So I hope people will do use that from the beginning.

> > Colours (in complist) for non-files (and grouping, you'll see):
> > 
> >   ZLS_COLOURS='**foo:[A-Z]*=47'
> 
> I'm so far a bit agnostic on this sort of thing.  How many people are going
> to go into this sort of detail to sort out groups and tags, whatever the
> syntax is?  Groups in particular are fairly well buried inside completion
> functions (unless something's changed here, I haven't completely absorbed
> everything about the latest status yet).  But I'm not against control of
> this kind.

Yes, currently, they are buried quite well. The question /behind/ the
grouping stuff I mentioned is: should we make them (more) visible? The
bit of discussion we had about the tag stuff (while you were away)
made me think that maybe we should make them visible and controllable.
But I'm far from certain if that wouldn't be too irritating to the
users. If we give control over it, I'd at least like to find a way so
that not using the mechanisms to control this stuff gives the current
behaviour as the default (probably the one without matches->group=yes, 
and then an easy way to specify exactly that behaviour with the new
mechanisms which should then be usable as a easy entry-example of how
one can control this stuff). That's also the reason why I keep trying
to connect this to tags (one-to-one correspondence between tags and
groups), because users can already see the tags and the way I tried to 
document that should make users think of tags as names of groups of
matches.

> ...
> 
> > Hidden matches in menu-selection:
> 
> Maybe they should behave like a special completion group, with a message
> above like `<Hidden Matches>', or something.  It makes it all explicit.

Ah. Hadn't thought of that. Sounds reasonable...

> > Tags and styles:
> > 
> > I've been asking for help for this several times already (I know that
> > you all need some more time to get used to all this new stuff, I only
> > want to put all my open questions here...). We might want to reduce
> > the number of tags used. For example, I think we could replace many of 
> > those currently used by `name' or `value'.
> 
> OK by me.
> 
> > And maybe some of the tag and style names can be changed to something
> > better?
> 
> We should make a complete list of the current ones (easy but dull) and see
> what it looks like, then maybe we'll get ideas.

The lists for tags and styles in the docs should be 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.

But it's also used for the #compdef- and #autoload-... err, well... -tags.

> ...
> 
> > Functions:
> > 
> > Before the next official release we might want to have a look if all
> > the completion functions are in the right directories. We've already
> > changed some (where it was obvious enough), but there may be more. And 
> > then there is the incompatibility problem Andrej somtimes remineded is 
> > of. Some functions may need tests on $OSTYPE or something. Oh, and I'd 
> > still like to have a _nis function to go along with _yp but still
> > don't have access to a NIS+ server. Sniff.
> 
> Needs checking, but can safely be left till fairly late, since it's
> maddening to have to do it over again after some tinkering.

Yep, that's what I meant, just before release.

Bye
 Sven


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

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

[Bart Schaefer]

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