RE: RFD: Zsh styles and OOP ...

RE: RFD: Zsh styles and OOP ...

[Sven Wischnowsky]

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

RE: RFD: Zsh styles and OOP ...

[Andrej Borsenkow]

> >
> > 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.

>
> 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 :-)

/andrej

Re: RFD: Zsh styles and OOP ...

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Re: RFD: Zsh styles and OOP ...

[Peter Stephenson]

"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.  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.

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.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

RFD: Zsh styles and OOP ...

[Andrej Borsenkow]

Unfortunately, no ready-for-implementation ideas ... just some speculations.

To put in general way, styles are used to define properties of objects. Even
if we speak only about completion, there are already more than one sort
(type? class?) of objects there.

1. list of generated matches
2. completion functions (every functions - not just completers)
3. completion system widgets
4. completion system as whole

Each of these classes really has it's own hierarchy (if at all) and should
reasonably have it's own namespace.

Unfortunately, the way contexts are defined currently makes no difference
between different objects putting all of them in single namespace (that
actually is appropriate only for matches list). This gives way to confusing
settings like

zstyle :completion:* completers _complete

that implies, that you can define different copmpleters for diff and gzip,
while completers is actually a property of completion widget(s)

Another example is setting of ps arguments, hosts dastabase, rgb database
and such. I can hardly imagine setup, where kill and killall would use
different settings for ps arguments; or different X commands would use
different rgb or font database. Again, these styles are actually property of
completion system as a whole or at least some helper functions. And in any
case, they are independent of current command, argument position etc.

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 ...

/andrej