Re: New configuration -- should we...

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> There's still the issue of parameterizing the action, which is what the
> "style" part of the tag syntax accomplishes.  Your second suggested
> implementation makes this explicit, which I like (though prefixing them
> with hyphens to look like options may not be necessary).

I'll say something about this below...

> One further thought, at the risk of distraction:  Aren't these tags just
> describing more contexts?  That is, what we're really trying to do is
> split the whole system into stages: (1) determine context, (2) generate
> appropriate matches, (3) organize matches for display.  The farther apart
> we can drive these, the better; maybe there's even some way to cause the
> tags to become context-keys for _normal, or the equivalent?

I'm not entirely sure what you mean by (3). For now I'll take it as
`say how the matches should be generated'. I.e. things like `always',
`only if a certain prefix is on the line' `with descriptions if
possible' (maybe you also meant `how they are sorted in the list' --
group-wise sorted, that is?). Anyway, this is the stuff I suggested
the styles for. See below.

About the `context-keys for _normal': that's coming back to the very
beginning of the discussion for the new completion system. And, yes,
this has been on my mind a lot lately (and your remark about wishing
that there was a better correspondance between tag-names and function-
names in a previous mail is connected to this, isn't it?).

I can only repeat what I said then: for some of these we already have
special functions (and since some time I've been trying to generate
more of these -- that's why `_pids' appeared some time ago, for
example). However, many of the sub-contexts in completion functions
are so specialised that it doesn't seem to make sense to add separate
functions for them.

But... for some... yes. Maybe we should also try to think more in this 
direction. Probably add a sub-dispatcher (in the way `_complete' and
`_normal' are global dispatchers now) which automatically calls the
right function for a certain context. Maybe some help from our friend
`compdef' for this.

I'll first think some more about the other stuff mentioned below and
once we have that, try to think more about this (please someone
remember me if I forget). I think this is possible because I currently 
can only think about such a dispatcher which could easily be build on
top of the basic tag stuff.

> ...
> 
> } There are two ways how we could make that function be called. Either
> } we do it only on the first call to `_tags' or on every call. The
> } latter would probably be more general but the first one presumably
> } would be easier when writing such a config function.
> 
> I would think this really boils down to a computation-vs-memory tradeoff.
> That is, do you want to compute the mapping once and store it forever, or
> recompute it every time to save the storage?  The function itself should
> not need to be significantly different either way, should it?

If it is called for each set, it would have to check which set is
wanted. Something like `case $attempt in 1) ...;; 2) ....;; esac'.

> } For the way how the config function says which tags are to be used I
> } currently see two possibilities (well, more than two, but these are
> } the easiest I see). In both cases the config function is only called
> } when `_tags' is called with the tags for the current state as
> } arguments, not when it is called to get the next set of tags to try.
> 
> Thus separating "determine context and organize display" from "generate
> matches."  Can you see a way to separate the first two, as well?

Again, see below.

> ...
> 
> I like this so much better that I've ignored your first suggestion.

Good. Just the way I feel myself.

> }    There could also be support to easliy set the pure config-tags,
> }    i.e. the pseudo tags we add as a replacement for the config keys we 
> }    have now. I haven't yet thought too much about that part.
> 
> Config keys / pseudo tags are the user's expression of generic behavioral
> preference.  Maybe the right way to think of them is as global defaults
> for the comptry arguments, which can then be overridden locally by each
> config function?  (Your follow-up in 8626 makes me think you're thinking
> this way, too.)

[ below:    # I'm a goto-label ]

If I'm right in thinking that `organize for display' is what the
styles are used for, then, yes, I had already realised that we would
want to be able to define them separately. In my `conf2' version I had 
added some extra syntax for giving global definitions for style.
Something like (this is just text, not actual `conf2'-syntax): for
tag `options' always use the `description' style. That effectively
defined a global default value. That was one of the things that made
me try to look at the whole thing again.

(I like the word `style' for this even if there may be better words
for it in your language, so I'll continue to use it; hope that isn't
too irritating...)

Maybe we should separate the management for the styles from the tags
stuff (at least in concept). On the completion function side, btw, it
is already this way: they say which tags they can offer, get the sets
and before trying a certain tag look at the styles set for it.

However, it would certainly make sense to be able to define styles on
the narrower context `tag so-and-so'. I mean: as you pointed out, tags 
are really a bit of a narrower context-description, or more precisely, 
the combination of completion-context (function and context-in-that
function, the latter being what I had called only `context' in
previous mails) and tag gives a narrower context. I have this image of 
a one-column table for the overall completion contexts (`-foo-' and
commands), another on-column table for the tags, separate from the
first one. And then there is a third table for the styles, containing
things like `show descriptions or not', `show a common prefix or not'.

(Btw, I think all (or most of) this is just repeating what you said,
I'm just typing-while-thinking, so please forgive me for this...)

Now, the `_tags' mechanism connects the first two tables. And since I
think the third one is more general than even the overall-context-table,
I think we could or should have a way to connect it to the first two
tables. I.e. lets define a way to say how styles should be set for a
certain command-context *or* for a certain tag *or* the narrower
context of tag-for-command-context both. That plus global defaults --
for `_tags' there is a already a way to define such global defaults by
simply using the `*)' in the examples I wrote. 

For setting global defaults and styles for certain contexts it seems
to be enough to add some builtin or function that is called from the
user's init-files. However, for the tag-plus-command-context thing it
might still be convenient to be able to just set them in the config
function where one has to work with the contexts anyway. But that
means only (and would be documented that way) that the tag-mechanism
is a friend of the style-mechanism and is able to (locally or
temporarily) register such links in the style-mechanism. It would also 
be possible for users to globally define such mappings from exact-
context-even-with-tag to styles.

Before I got your reply I had already started to think in this
direction, mainly caused by the option-syntax I suggested. I was
thinking about somthing like `global options'. And I thought that this 
might even be a another reason for using the option-syntax. Because
you could then use a global `-describe=yes' (or just `-describe') and
override it for a certain context with `-describe=no' (or
`-no-describe'). That would probably look familiar for many users.

But I still have to think some more about this separation to be able
to see if a static definition is enough or if we should try to make
this use some user-defined function, too. The latter seems cleaner
when we use this approach everwhere else. I don't know about the
how, where, when, etc. yet, though. But I've become rather cautious
(or timid) after the shock yesterday.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx