RE: RFD: Zsh styles and OOP ...

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Andrej Borsenkow wrote:

> > > This is certainly interesting.  Unfortunately it's going to
> > make the whole
> > > thing even more complicated, both for implementation and use.
> > Furthermore,
> > > we really need this to be right in 3.1.7 --- I would be against
> > rewriting
> > > the configuration for completion yet again.
> >
> > You are not alone here...
> >
> 
> The only problem is, it will be more and more hard to change anything after
> ZSH is released.

Guess why I'm trying to be as active as possible in this discussion.

> > I may also repeat my suggestion that we can put the context-finding
> > code from _complete and _normal into a separate function. This could
> > then be called at the very beginning (bindable commands,
> > _main_complete). It would at least fill the context/command field of
> > the context name.
> 
> It is not a question of missing context bits. The problem is, these bits are
> completely meaningless in some cases. Unless we want to use different
> completers for different commands, it does not help to know, what command is
> being completed.
> 
> I just wish, that context names properly reflect there usage :-)

Does this boil down to: if I don't care about the (possibly empty)
value of a certain context field (we currently call them fields in the 
context names we have now, you may call them sub-contexts or
whatever), I don't want to have to mention it in the pattern I give?

If so, is it really that irritating to have to use `*' in some
places. And, from the other side, what's the big difference between an 
empty and an non-existing field. I mean, ok, without reading the
documentation a context like ':completion:::::' may look weird, but if 
you always think about the field-tuple this actually conveys some
meaning, saying that the values for some fields (think of them as
separate sub-contexts now) is not yet known or `there is nothing'.
E.g., if the function-field is empty, this actually says something,
namely that the completion system was called due to a key press, not
from some function.

Oh, and when I said that we can set up at least one more field at the
beginning, this of course (automatically, given the way style lookup
works) means that one can give different completers for different
commands. Which may be useful. And this means that it would make sense 
to tell users about that field from the beginning.

All in all (with the change suggested), there would be only one field
-- the argument field -- that would always be empty in context names
used by completers. And here this empty string doesn't tell us
anything interesting. But letting it appear even then has the nice
effect that context names always have the same length.


Unless, of course, we want to change the context stuff completely.
Really completely. Not even using simple strings for context
names. But I need a lot more ideas and suggestions, possibly even
syntax for definition and lookup before I can talk about that. Just
saying that something isn't good and should be done differently isn't
exactly helpful ;-)

Bye
 Sven


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