Re: RFD: Zsh styles and OOP ...

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> "Andrej Borsenkow" wrote:
> > I believe, it would be of real help to developers as well to
> > 
> > - clear define what sorts of objects exist
> > - what properties do they have
> > - use context names, that refelect actual object hierarchy without need of
> > dummy placeholders or fake "match it all" entries
> > 
> > It would of much help to users if they had context/tags/styles descriprion
> > divided into subgroups for every object type instead of current long list.
> > 
> > Not sure how interesting it is ...
> 
> 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...

> So unless we can come up with
> something reasonably simple quite quickly --- such as an extension of
> the notion of context in a more object-oriented way --- we're probably
> stuck with what we've got.  I don't think it's so bad; I agree it's a bit
> of a nuisance that you can often only use bits of the context, but if you
> think of it as an array of entries --- which was the point of the change to
> fixed elements --- it's more logical.  It's not any worse than X fonts.

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. The only problem I have with this is with completion 
functions that call _normal. With the command name set up when the
completer style is looked up one could set it on a per-command basis
but when completing after `noglob find ...' the completer for `noglob' 
and only for that would be used.

> One half-formed idea in my mind is that you specify styles with a set of
> key/value pairs, which maps to a hash internally, in other words you can
> specify "system => completion, completer => complete, tag => directories",
> or something like that; the values are patterns as before, and anything not
> specified is a wildcard.  I don't know whether or not that has legs.

;-) I suggested something similar when all this style-stuff started.
One question that comes to mind is: do we need it? I.e. would we (be
able to) use it for more than the fields we have now? The other thing
is performance: keeping strings up to date and comparing them is quite 
fast...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx