Re: completion grouping (PLEASE read this)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

(I'm replying to Bart here, even though I don't quote his messages...)


I have already several times failed to raise a discussion, but I'll
try it again and take Bart's message as a starting point.

NOTE: this is a request for help (please, please, please).


I often have problems expressing what I really mean in English (anyone 
who has ever tried to read things I wrote in the manual will know
that), so I can only hope I'll succedd this time.

The grouping and configuration stuff I wrote about lately certainly
sounded like an attempt to make things even more complicated. It wasn't.
Actually -- and that's what I wanted to say when mentioning that I
want an easier user interface for the configuration stuff -- I would
like to make it simpler.

For example: when I said that I'd like to put the tag- and old-
configuration stuff together then I said that because I thought that
it would be easier for users to have to deal with only one such
configuration mechanism (I guess you all understood that). What I
would like to have is an easy-to-use configuration mechanism that
should keep simple things simple to achieve. However, when users
step-by-step get used to it and they find problems or things they
would like to do, the mechanism should already be powerful enough to
solve them or extensible enough so that we (or the user himself) can
add new things.

I /think/ (another of my problems is that I'm not very good at
guessing how easy to understand the things I write are) that for users 
(as distinguished from completion function writers for now) a really
good interface to things like the configuration stuff is the crucial
bit. I think it's enough if we have something with which users can
easily get started, something they don't have to learn/understand in
all its power for their first steps. Later they can work their way
into it when they need or want it. And, btw, that's also why I would
like to replace the more complicated config keys with a more general
(hopefully) well-defined interface.
Another thing that may help is adding good default values for our
configuration parameters (this is a bit like the discussion about the
options that we decided to set by default). When I first started
adding config keys I sometimes asked if people think we should add a
default for them -- due to no replies I later gave up asking that. But
again, this is really my fault -- I really couldn't expect that
everyone read every of my messages.

One last comment about the interface: the `mini-language' mentioned by 
Bart sounds like a good idea. I hadn't thought about that (again).

Now for the other side: writing completion functions. First of all,
simple functions are still possible, of course -- and with the
auto-autoloading really easy to write/add. However, it is certainly
true that writing a really `good' completion function is already quite 
complicated and this tags stuff would make it even harder. That, btw,
is why it took me so long to write the first proposed patch for it. I
was searching for something really simple to use, probably even
something that could be build on top of already existing things like
the description stuff (I failed again, yes). Maybe it could be made
easier. If only I had a larger brain...

(Aside: the current state of the tags stuff even isn't enough -- I
remembered the contexts mentioned by Peter yesterday. We certainly
should have that, but I think this would only add very little
complexity to the `_tags' function and its uses. Again, functions like
`_arguments' are a bit of a problem here, but I think most of this
could be hidden from users of that function.)

And finally, good documentation would help, too, of course. This would 
mean Peter's Guide and changing the manual to better reflect (or
describe at all), how the completion system really works. I'd like to
have it described more from a user's perspective (but, again, I have
to say that I'm very bad in writing this kind of stuff). It would
probably mention how the functions really get called (how and under
which circumstances), it would mention that functions may have
different contexts and in these contexts may generate different types
of matches. With that said it would explain how users can influence
which types of matches should be generated, and so on. And, of course
there should then be a list of all or at least the most commonly used
functions, their contexts, tags and so on. I think Peter's suggestion
for online-help aimed at that: give users an easy way to find out
where he is and how he can configure that if he doesn't like what he
sees. Problem is that at least I don't see a nice, easy way to achieve 
that (from the function writers point of view) -- see my previous
posts about this.


So, like Bart I'd really like to have things stabilize. The tags- and
config- stuff is partly meant as a final cleanup (partly; the other
part is to add a missing bit I should have thought about from the
beginning). But I need help. It would already help to hear about your
experiences, descriptions about how you use the completion stuff. How
you learnt about it. Do you use configuration? How would you wish to
have things changed? Did you ever think things like `now, why did they
do it *this* way, why didn't they just...'? Are there things you are
missing? Or (more probably?) do you find it too overwhelming? How hard
is it for you to write completion functions? How can we help?


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx