Re: completion grouping

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

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