Re: completion grouping (PLEASE read this)

Re: completion grouping (PLEASE read this)

[Sven Wischnowsky]

(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

Re: completion grouping

[Oliver Kiddle]

Sven Wischnowsky wrote:
>
> 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.

I suppose that what we need to identify is what sort of things the
average normal user will want to configure: offering just those things
in an easy to configure way will be helpful but making to much
configurable with simple commands will just make the functions too
complex. I would expect that the main thing normal users would want is
to be able to add completions for any commands which are specific to
their system. To help this, writing completion functions should be
atleast as easy as writing the old compctls.

Where I really like the new system is that it allows us to define how to
complete various different things like URLs, jobs, files etc in one
place and then reference these in the completion for a specific command,
using a full meaning-full name. It also means that anyone can change the
way a specific type of thing is completed for all commands that complete
that type by changing the function. The trouble is that many of the
supplied functions have become very complicated.

I may not have properly understood your tags and priority system but I'm
not convinced that it is worth the extra complexity in the completion
functions to be able to configure the order that different groups are
completed. Could the system use the groups specified with compadd -V /
-J? Also, could the system be done so that for example, _jobs would call
_tags to say it is generating jobs as opposed to every completion
function which calls _jobs. Basically, what I'm saying, is can we reduce
the extra complexity that it adds to the functions.

> 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

I agree that we should put some thought into default values for the
config keys. For some, it probably makes no sense to have a default.
Also, with some, the comfig key being unset might have a significant
meaning at the moment so we would need to implement a way of specifying
that meaning.

> 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

I'd also agree on the stability point. If we get a 4.0 out, we might
also get some feedback from more normal users.

> 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?
I use the configuration though probably not a huge amount.

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

I found the system quite hard to understand initially. There are a
number of points I've never really understood properly, like the
differences between the different types of prefix/suffix or whats going
on with some of the functions which handle menu-completion. I've mostly
found it quite easy to write a completion which basically works but I'm
never very sure that it is totally correct. In many ways I find it
easier than the old compctls. I always found compctls to be very hard to
read compared to tcsh completes and tended to need the manual next to me
for constant reference on the option names which was annoying.

The main things which I would want to configure with the new completions
is often how the completions are listed and when. For example, I don't
like the job completion after bart-8 which completes by the job number
rather than the name of the command:
%<tab> will list, for e.g.:

[ 1] man less
[ 2] less config.h

And will complete to %1 or %2. I think it should return to completing
the commands after '%' or a config key should select. I also don't like
that kill will complete job names straight-away as opposed to only after
an inital '%'. It seems a bit weird when a job gets listed twice - once
as the job and once in the ps listing.

In a few cases I've found that other people's completions have taken the
approach of completing everything which is valid in a particular context
whereas I prefer to keep the number of matches down to a minimum, for
example, by only completing options after an initial '-' and jobs after
a '%'. This is the main sort of thing which I think should be
configurable.

As an aside, we seem to have a few cases where we complete to a numbered
list:
cd ~+<tab>
cd -<tab>
cd $path[<tab>
fg %<tab>
are all examples, yet we aren't very consistent in how we display the
numbers:
'[ 1] ', '1 -- ', '1)   ' are all used. Maybe this format should be
configurable.

Oliver Kiddle