Questions (and PATCH: small change to _complete)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

[ 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@xxxxxxxxxxxxxxxxxxxxxxx