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

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>]

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