Re: New configuration -- should we...

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

[ I wanted to reply to this on Friday and then forgot... sorry. ]

Bart Schaefer wrote:

> } > 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.
> 
> For (3) I thought almost entirely of `how groups are sorted in the list'
> and `order by rows or by columns' and maybe even `use menu-completion or
> menu-selection' and that kind of thing.  `always' or `only if a certain
> prefix is on the line' are part of (1); `with descriptions if possible'
> is a part of (2).

First aside: This reminded me that I wanted to make the options affecting
completion be controllable via $compstate. I had forgotten to do that
for the new list options.

Second aside: Hm, wouldn't users probably think that `with descriptions 
if possible' is part of (3), even if it is part of (2) for the
completion function writer?


We could make things like these configurable via styles, too. I.e. I
don't see a reason for using a different configuration mechanism for
things like that. It would then affect groups of matches as a whole
which I like anyway. But that would also mean that a) it is even more
important that everyone uses `_description' whenever adding matches
and b) that we should always use grouping (otherwise we can't really
control such things on a per-group basis).

We could then even implement styles that allow users to say if they
want the group sorted and/or uniquified. And we could make the new
listing-options be settable per-group and let users define which types 
of matches they want packed.

Some of the things (like menu-completion), however, can obviously not
be controlled on a per-group basis. Only in the sense of `if there
*are* any matches in this group (meaning: for this tag)', then use
menu-completion or -selection or whatever.

Another thing would be the naming of groups. The completion system
heads into the direction of having a one-to-one relationship between
tags and groups. We could make the group names (the ones used
internally) be configurable, defaulting to the tag-name. Users could
then specify if they want to put matches for different tags into the
same group by specifying mappings from tags to group names.

The `how groups are sorted in the list' finally is probably the most
interesting one but also the most complicated. The problem is that the 
completion code just displays the groups in the order in which they
were added. So we would either have to implement a way so that
completion functions can change that order before the completion code
starts listing the stuff or we would have to make the completion
system actually add the groups in a different order. For that we would 
have to change the tag-loops we have now into two nested loops.

Hm. The first one reminds me of the access-to-match-information stuff
I've been talking about sometimes. Maybe if we had a special array
containing the names of the groups added (or an association mapping
group names to some information) we could allow users to modify that
array and the completion code would then use the groups in the order
in which they appear in the array after the widget has returned. I
can't think of a good way to configure this, though.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx