Zsh Mailing List Archive
Messages sorted by:
Re: RFD: Zsh styles and OOP ...
- X-seq: zsh-workers 9737
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: RFD: Zsh styles and OOP ...
- Date: Tue, 15 Feb 2000 11:10:36 +0100 (MET)
- In-reply-to: Peter Stephenson's message of Mon, 14 Feb 2000 19:13:53 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: