Re: match again

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> It looks better, but is it enough to sort out all possible cases where you
> might want to use `:*:'?  Or are there even more cases where we might get
> into trouble with that?  I'm worried we could be barking up the wrong tree,
> and should, for example, fix the fields of the pattern to
> e.g. :completion:completer:command-or-context:arguments:tag (this may not
> even be complete) with unrequired fields set to null strings but retaining
> the colons, so you can always guarantee to pick out the appropriate
> bit (unless there are extra colons inside the fields).  This will mean a
> lot of multiple colons, but I don't think that's a major problem (in fact,
> that's where we're heading anyway).
> 
> Any other uses of colons in the pattern --- e.g. to indicate a command name
> --- would have to be rethought, but replacing the second `:' by a `-' might
> be enough.  Or just have commands and other contexts specified in different
> fields (i.e. one is ...::command:... and the other ...:context::).
> 
> Probably the big headache would be enforcing consistency in the code as it
> stands --- virtually every use of styles would have to be rewritten.  But
> I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick
> a particular word of $acontext to check.

Yes, I'd like that, too -- and changing almost every function has been
done before. I don't think that we would need to change that many
functions anyway.

The problem is with `nested' completions a la `cvs add ...' where it
is very convenient to be able to stuff the `add' into the context
name, but maybe `cvs-add' is just as good. And in cases like
`find . -exec cvs add <TAB>' we probably don't need to have both
`find' and `cvs' in the final context name.

All this has been suggested before, btw (by Bart). He even suggested
using an array. I'd prefer to still use a simple string to make
testing and re-defining faster and cheaper, but if we don't use extra
fields for the `nested' cases above, it would be nice to be able to
access fields directly -- which suggests using a tied array at least
in those functions that modify some fields (instead of just
saving/restoring $curcontext or appending one of the basic name
components).

We may need another field: my suggested nslookup function sticks a
`:nslookup' after the `:completion' -- but maybe we don't really need
that. For things like the `cvs-add' above and the number of errors
accepted by correct and approximate using another separation character 
might be a good idea... opinions?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx