Re: known hosts tab completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 24,  5:49pm, Peter Stephenson wrote:
} Subject: Re: known hosts tab completion
}
} On Sat, 23 Jun 2012 20:28:00 +0200
} Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
} > The default matcher-list for host completion does have the . in it, or
} > rather it uses a hardcoded compadd -M
} 
} That seems a bit of hole in the system.  I wonder what the neatest fix is.

The matcher and matcher-list have always been a bit of a problem.  In
order to loop over the matchers at a high enough level, matcher-list
is looked up so early in the process that the context isn't even known
yet, but then the spec passed to compadd -M is appended to whatever is
already in use.

Further the matcher style doc asserts that

    This style is tested separately for each tag valid in the current
    context.

So theoretically you should be able to abandon matcher-list and instead
define a bunch of individual matcher styles, but in fact that style is
only looked up by _description, so any completer that calls compadd
without first using _description to build the compadd argument list
will render that invalid.

(As an aside, _description is also responsible for making the actual
call to _compadd when any of the "fake" styles is defined for a context,
so it may more generally be incorrect for any completer to bypass
_description.)

} A function front-end to compadd for completions that supply
} matchers is the obvious answer (I mean something specific like
} compadd_match, not overriding compadd which is obscure and conflicts
} with approximate matching).

Potentially then the right thing for this hypothetical wrapper to do
is to look up the matcher style and only use the -M spec passed to the
wrapper when there is not a user-defined style in the same context.

Next question would be whether this duplicates code from _description,
calls _description, or is in some way called *by* _description ...

} We'd need it only to do that for specific
} enough matches, i.e. not your standard matcher-list.  Not sure what
} constitutes "specific enough".

There are other completers that call compadd -M but they are also passing
the -O or -D options which means they're only capturing possible matches
into an array for later filtering by another call to compadd which may
or may not have a different -M option.

A grep-derived (and therefore possibly inaccurate) list of completers that
appear to bypass _description in at least some cases:

Completion/Darwin/Command/_defaults
Completion/Debian/Command/_debfoster
Completion/Redhat/Command/_rpm
Completion/Unix/Command/_cvs
Completion/Unix/Command/_gprof
Completion/Unix/Command/_gs
Completion/Unix/Command/_mh
Completion/Unix/Command/_mpc
Completion/Unix/Command/_mtools
Completion/Unix/Command/_ssh
Completion/Unix/Command/_tin
Completion/Unix/Command/_vim
Completion/Unix/Command/_yp
Completion/Unix/Type/_ctags_tags
Completion/Unix/Type/_dict_words
Completion/Unix/Type/_domains
Completion/Unix/Type/_file_systems
Completion/Unix/Type/_global_tags
Completion/Unix/Type/_hosts
Completion/Unix/Type/_java_class
Completion/Unix/Type/_path_files
Completion/Unix/Type/_signals
Completion/X/Command/_mozilla
Completion/X/Command/_netscape
Completion/X/Command/_x_utils
Completion/X/Type/_x_color
Completion/X/Type/_x_cursor
Completion/X/Type/_x_extension
Completion/X/Type/_x_font
Completion/X/Type/_x_keysym
Completion/X/Type/_x_modifier
Completion/X/Type/_x_visual
Completion/Zsh/Command/_bindkey
Completion/Zsh/Command/_compdef
Completion/Zsh/Command/_zstyle
Completion/Zsh/Type/_options
Completion/Zsh/Type/_options_set
Completion/Zsh/Type/_options_unset

-- 
Barton E. Schaefer