Re: PATCH: 3.1.6-pws-11: Completion suggestions + fixes + sorting tags

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> Here are some points for discussion.  Anything I thought was unambiguously
> wrong is in the patch below.  I know compinstall still needs rewriting
> completely.  Probably it should also convert a 3.1.6 installation into a
> 3.1.7 one.
> 
> 1. One significant change which I have hubristically included in the patch
>    is the addition of the sort-tags style.  This is a simpler alternative
>    to redefining _sort_tags.  For example,
> 
>    zstyle :completion:complete::gunzip: sort-tags \
>     'globbed-files directories' all-files
> 
>    will try globbed files and directories first at the same time,
>    then all-files.  This allows you to do everything you could with
>    specifying priorities much more simply.

Grin. We (mostly Bart and I) had some discussion about this and
somehow we agreed that it's nice to separate the sorting from the
other stuff. But when I added _sort_tags I said that we could use
configuration to... but held myself back.

However, I'll change your patch for this a bit when I find the time
for that. Hope you don't mind.

> 2. I don't really like the way ZLS_COLORS is sidelined.  There doesn't seem
>    to be any point in it if you're using new completion.  Perhaps if it's
>    set when completion is initialised it could be set to the default for
>    the list-colors style.

Hm, my bad English shows... There doesn't seem to be a point in what?

> 3. I'm also not that keen on the default style for process completion.
>    If you type `disown <TAB>', nothing happens because it needs you to type
>    a `%'.  This is a bit silly in this case, since real process numbers
>    can't be used.  The same is true of many of the other builtins.
> 
>    Also, if you just have one process and hit tab, it shows up as a number
>    and you don't get a list.  It's a bit uninformative just being told you
>    are going to disown %1 (and at that point it's too late to ask for a
>    list).  It would be quite nice to get process to show up as %name if
>    that's unambiguous and numbers otherwise.

One point in my todo list is still `adding good defaults'. Setting the 
strings style might be one. Or, probably better, replacing it with a
`numbers' style so that completing strings is the default if the style 
is not set. And then we could add a special value for the style that
gives one strings if they don't look too clumsy and numbers otherwise.

The first thing above is the effect of prefix-needed being set by
default. Maybe we should change the places where that style is used to 
automatically ignore the style being set to true if there are no other 
completions.

> 4. There's no real problem about proliferating tags, I don't think, because
>    they are specific to particular contexts.  To cut down the number of
>    tags listed in the main list in the manual, would it be better to move
>    tags only used in one context, e.g. for the users-hosts lookup etc.,
>    into the description of that context?  Then the tags list would only be
>    of those that are used throughout completion.  A counter-argument is
>    that you then don't know what tags to use if you're adding a new
>    function/context.

I've been thinking about this, too. About the last part: I'm not sure
that the current list would help here anyway. If you add new functions 
you could look at `similar' functions and see which tags they use,
would probably be easier than the (mostly rather generic)
`description' in the docs.

>    Various style entries talk about `the default tag'.  This is not
>    mentioned in the section on tags, nor is there apparently any indication
>    that there is a default tag.  It might be nice to say why it's
>    necessary, which I'm not absolutely clear about.  For example, as
>    instructed I have '*:default' for list-colors.  But shouldn't '*' be
>    enough, given that all `default' means is `not if there's anything more
>    specific', which is already implied by the pattern-lookup rules?
>    `default' should only be necessary as an alternative to some other
>    options, whereas here there don't seem to be any.  On what occasions do
>    I actually need the word `default' to remove ambiguity?

I used the `default' tag mainly to make lookup cleaner, trying to
never do lookup without a tag -- which I haven't fully managed to
do. However, ther may be a reason: if a function uses tag A with style 
B and the same style is also tested without a default tag and a user
sets `zstyle ":completion:*" B ...' the function using B with tag A
will get that value, too, even if it uses the value in a completely
different way. This is at least easier to avoid if we use an explicit
default tag. I think.

>    Is the `cvs' tag really necessary?  The documentation says:
>      used only to look up the value of the tt(disable-stat) style
>    in which case, surely the context is already specific enough,
>    i.e. shouldn't the context already be `:complete::cvs:'?
> 
>    On the same theme again, what about the `paths' tag in _path_files,
>    used with various styles for file insertion?  I suppose it's there
>    because otherwise the context is rather non-specific, e.g. just
>    :completion:complete.  But it's still a little confusing in that
>    it doesn't currently add any information.  I suppose it's future-proof
>    in case other contexts start using cursor etc.  Plus of course
>    there's nothing to stop you turning it into a wildcard.  I suppose
>    the dilemma really is that you want to be in some specific context
>    that is the parent of all the more specific file contexts, but
>    that would make the context in the latter case unnecessarily complex.

See above, I wanted to never do lookups without a tag. But you get ten
points out of ten for finding the two tags which I don't like at all.

The paths tag is really used to be able to easily come up with a
pattern that can be used to set a style used by _path_files
independent of the tag used to *add* the matches. That may be something
like files, all-files, etc., but the expand, cursor and special-dirs
styles are always looked up using the paths style because they control 
how the files are presented or generated, no matter what kind of files 
we are adding.

> 5. I'm also not sure why there isn't always a final : at the end of a
>    context like there is at the beginning, and for the same reason.
>    It doesn't happen if the last entry is a tag, but (see 7.)
>    it seems to me the context should be pretty much transparent
>    as to what each element actually represents.

a) They were modeled after pathnames. b) There is only a colon at the
end when we have just added the command name (in _normal). c) Hm. Should
we change that...?

> 6. Incremental completion may be missing a few things, for example
>    a way of switching it off after it's completed a word with tab, it
>    annoys me that it doesn't, and an option to complete unambiguous bits
>    automatically.  The function doesn't seem to be described anywhere, but
>    I think someone already suggested the zle functions needed their own
>    manual entry.

Incremental completion is a hack, yes. Have you had a look at
predict-on lately? It can do completion, too, nowadays.

> 7. I haven't altered this, but it's a little confusing that we have two
>    notions of context described in the manual:  one without :completion
>    in front and no tag behind, and one with.  It should be possible to
>    rewrite the description or if necessary the code, so that the context
>    is a unique string up to the depth we have currently reached
>    (i.e. the tag is added if and only if it's relevant, the :completion
>    is always present).

Yep. I tried to make this difference clear in some places but we
should make it cleaer. Probably just using different names (a la
pathname vs. relative pathname vs. absolute pathname under Unix),
define these names cleanly and use them throughout the docs. Would
that be enough?

> 7. The description of the `glob' style refers to a `complete' style, which
>    doesn't seem to exist.

That should have been `completions'. Patch follows.

> Things in the patch, apart from the `sort-tags' style:
>  - compconf was using the `accept' style, which is now max-errors.

I had almost given up making changes to compconf. Getting that right
is now quite difficult.

>  - I've converted _description in _mh to _wanted, since you get better
>    output from ^Xh.  I don't know of any other consequences of the change.
>  - I've `improved' the new sections on styles and tags in the compsys.yo
>    manual page, by trying to simplify the explanations and be a bit more
>    specific.  I've moved the detail description of _sort_tags in the
>    function section, since presumably it's not the first thing a user will
>    need to know and it interrupts the more general description.

Right, I was worried a bit about this, too. But I also tried to put
all the configuration stuff at the beginning because I think many
(most?) users will never write their own completion function and hence 
don't have to care about the functions described in the functions
section.

And that section is a bit weird anyway. It mentions _parameters but
not functions like _pids, etc. etc.

>    I'm hoping that the necessity of altering it will be largely eliminated.
>  - I've rewritten the _regex_arguments documentation, possibly mangling
>    it in places.
>  - incremental-complete-word was still using _style.  I've tried to replace
>    this, but I wasn't watching properly when _style was around, so this
>    needs checking, but it seems to be OK.

Oops. Sorry. And yes, looks good.


Thanks!


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx