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

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

[Bart Schaefer]

On Nov 30,  9:35am, Sven Wischnowsky wrote:
} Subject: Re: Questions (and PATCH: small change to _complete)
}
} Bart Schaefer wrote:
} 
} > 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.

Hmm.  I was thinking that the "some information about the groups" that
you'd want to be able to access would in fact be the matches that are
in that group.  Since we still haven't solved the issues of having an
assoc whose values are arrays, I'd assumed that access to the matches
would not be through an assoc, and hence that you'd need to know what
groups existed.

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

On the other hand, "dvips:-o" doesn't look like what one might actually
see on the command line, whereas "dvips -o" does.  Dunno whether that's
potentially less confusing, or more so.

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

This is somewhat like the ksh syntax for assigning to multiple keys of
an assoc.  I believe that would actually look like

  ( [completer]=complete [command]=dvips [option]=-o ... )

(I resisted attempting this for zsh because it means making the RHS of an
array assignment into a special semantic context in which globbing does
not occur unless the LHS is a normal array, and I didn't feel like doing
that much violence to the parser.)

} Maybe going a bit too far?

It does bring up the possibility of actually making $curcontext an assoc,
although that probably *is* going to far at this point.

} Or maybe not... And would probably call for 
} help by some builtin to define patterns for such names.

Eh?

} But still, saving and restoring these things would be costlier than
} the simple `local curcontext="$curcontext"' we have now.

True.

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

It would have the advantage of removing any ambiguity about whether a
given character was part of one of the elements or merely a separator.

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

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

[Sven Wischnowsky]

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@informatik.hu-berlin.de

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

[Bart Schaefer]

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

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

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

[Sven Wischnowsky]

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

Maybe this is even bettern than inserting `-argument-' or some
such. Saves some typing.


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.

Bye
 Sven

diff -u -r oldcompletion/Core/_normal Completion/Core/_normal
--- oldcompletion/Core/_normal	Wed Nov 24 17:06:54 1999
+++ Completion/Core/_normal	Thu Nov 25 10:47:30 1999
@@ -26,14 +26,16 @@
   if [[ "$command[1]" == '=' ]]; then
     eval cmd1\=$command
     cmd2="$command[2,-1]"
+    curcontext="${curcontext}::${cmd1}:"
   elif [[ "$command" == */* ]]; then
     cmd1="$command"
     cmd2="${command:t}"
+    curcontext="${curcontext}::${cmd1}:"
   else
     cmd1="$command"
     cmd2="$commands[$command]"
+    curcontext="${curcontext}::${cmd1}:"
   fi
-  curcontext="${curcontext}:${cmd1}"
 fi
 
 # See if there are any matching pattern completions.
diff -u -r oldcompletion/Core/_sort_tags Completion/Core/_sort_tags
--- oldcompletion/Core/_sort_tags	Wed Nov 24 17:06:55 1999
+++ Completion/Core/_sort_tags	Thu Nov 25 10:51:31 1999
@@ -6,17 +6,17 @@
 case "$curcontext" in
 # Some silly examples commented out:
 #
-# *p[bgpn]m*)           # change the order for file-completion
+# *::*p[bgpn]m:*)           # change the order for file-completion
 #   comptry globbed-files directories
 #   comptry all-files
 #   ;;
-# *:dvips:-o*)          # automatic context set by _arguments
+# *::dvips::-o*)            # automatic context set by _arguments
 #   comptry all-files
 #   return
 #   ;;
-# *:kill:*)
+# *::kill:*)
 #   comptry processes
-#   return              # this return ensures that we use only processes
+#   return                  # this return ensures that we use only processes
 #   ;;
 *)
   comptry globbed-files
diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- olddoc/Zsh/compsys.yo	Wed Nov 24 17:06:32 1999
+++ Doc/Zsh/compsys.yo	Thu Nov 25 10:50:22 1999
@@ -309,14 +309,19 @@
 
 The completion system represents such a context as a hierarchical name 
 with components separated by colons. For example the name
-tt(:complete:dvips:-o-1) is used when completing the first argument of 
+tt(:complete::dvips::-o-1) is used when completing the first argument of 
 the tt(-o) option of the tt(dvips) command. The tt(:complete) at the
 beginning just says that we are currently trying completion as opposed 
 to, say, correction, which can also be done using the function based
 completion system (see
 ifzman(the section `Control Functions' below)\
 ifnzman(noderef(Control Functions)) 
-for more information).
+for more information). And the tt(::dvips:) shows that we are
+completing arguments for the tt(dvips) command. Such a doubled colon
+will appear only before and after the name of the command, but note
+that the second colon after the command name is really only added when 
+there is at least one more component (otherwise the whole name ends in 
+a colon).
 
 In many of the possible contexts the completion system can generate
 matches, and often it can generate multiple types of matches. Whenever 
@@ -344,7 +349,7 @@
 
 example(_sort_tags() {
   case $curcontext in
-  (*:dvips:*)
+  (*::dvips:*)
     comptry globbed-files directories
     comptry all-files
     ;;
@@ -419,7 +424,7 @@
 example(_sort_tags() {
   ...
   case $curcontext in
-  (*:kill:*)
+  (*::kill:*)
     comptry processes
     return
     ;;
@@ -481,7 +486,7 @@
 calling the tt(ps) command). To make this builtin list the matches
 only as numbers one could call:
 
-example(compstyle '*:kill:*' description no)
+example(compstyle '*::kill:*' description no)
 
 And if one wants to see the command lines for processes but not the
 job texts one could use the fact that the tag name is appended to the
@@ -489,14 +494,14 @@
 call use (remember that the function for the tt(kill) builtin command
 uses the tags tt(jobs) and tt(processes)): 
 
-example(compstyle '*:kill*:jobs' description no)
+example(compstyle '*::kill:*:jobs' description no)
 
 As said above, the patterns given to the tt(compstyle) function are
 tested in the order in which they were given. But that isn't
 completely true. In fact, this function roughly sorts the patterns so
 that more specialized patterns are compared before more general
 patterns. Due to this, the last two examples could be defined after
-the first one because both `tt(*:kill:*)' and `tt(*:kill*:jobs)' are
+the first one because both `tt(*::kill:*)' and `tt(*::kill:*:jobs)' are
 considered to be more specific then the pattern `tt(*)' from the first
 example. To decide how specific a pattern is, the function looks at 
 the number of colons (corresponding to the number of components) used

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