From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18588 invoked from network); 5 Nov 1999 10:52:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Nov 1999 10:52:42 -0000 Received: (qmail 4875 invoked by alias); 5 Nov 1999 10:52:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8563 Received: (qmail 4868 invoked from network); 5 Nov 1999 10:52:23 -0000 Date: Fri, 5 Nov 1999 11:52:18 +0100 (MET) Message-Id: <199911051052.LAA02746@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 4 Nov 1999 17:46:26 +0000 Subject: Re: completion grouping (PLEASE read this) (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@informatik.hu-berlin.de