Re: completion grouping

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:

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

The quick answer is: No.

Currently, the amount of work needed to make a functionm use tags is:

- for a function/context that completes only one type of matches:

    local tags
    _tags -i <tag-name> || return 1

  that's all. Currently this can only be used by users to say if they
  want any matches at all or not, so it isn't really useful. But I'd
  like to make sure we use it everywhere so that if we once add the
  online-documentation stuff we already have the needed calls
  everywhere.

- for functions adding multiple types of matches:

    local tags
    _tags <tag-names...>

    while _tags; do
      if [[ "$tags" = ... ]]; then ...; fi
      if [[ "$tags" = ... ]]; then ...; fi
      ...
      [[ <matches generated> ]] && break
    done

  (or some other tests on "$tags"). And because of this we can't move
  that code into the helper functions like `_jobs': only the calling
  function (e.g. `_kill') knows what different types of matches can be 
  generated and thus knows if there are other tags to try if one failed.

But, again: completion functions without that will work as before, so
users writing their own little functions don't really have to worry
about all this. Only if they want them to be included in an official
release it would be nice if they use/supply/support everything the
completion system offers. But in most cases it shouldn't be too hard
for one of us to add that code to functions we get (if we get any at
all).

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

I'm trying to enforce this discussion because I don't like the thought 
that we hurry to get 4.0 out of the door and later decide (based on
our experience or user requests) that it would be nice to make things
better configurable. It may well be that this would require changing
the way things are configured and user would have to change their
setup in the release-after-the-next-one. I only want to make sure that 
we release it in a form that allows us to enhance it without making
user setups invalid.

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

Basically I'd say that if they do what you want, they are correct. The 
only thing that I missed from some of the functions submitted were the 
calls to `_description'. Currently that's the only thing one really
has to remember -- and if you use one of the helper functions like
`_arguments' this should be forced (although in some cases it would be 
nice if people weren't so lazy to omit the option-descriptions -- but
I've done that myself already, so I better not complain too loudly; ahem).

> 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 did that because I once had the case where two jobs started with the 
same word (and I really hate getting `%foo\ really\ long\ argument\ list').

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

Jobs aren't only just processes, but this is *exactly* what we (at
least I, and I think Peter, too) want to achieve with this priority
mechanism. You don't like it, so you should have a way to say that you 
want to see jobs only after a `%' or that you first want pids and if
there is no match, fall back on jobs. That's also why I immediately
changed the config keys for the option/argument stuff into tags --
there we had it already and I want to make it easier/generic/less-ad-hoc
to be able to specify this in more places.

Your request to get names instead of job numbers, btw, fits nicely
into the style-mechanism I want to have (it's comparable to the describe-
options stuff).

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

See above.

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

In one of my last patches I changed the job-list to use ` -- ', too. I 
was first comparing it to the output of `jobs'. The `1)' is in the
subscript code, right? Yes, we should change that.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx