Re: Please add pinfo completion

[Peter Stephenson <pws@xxxxxxx>]

Andrey Borzenkov <arvidjaar@xxxxxxxxxx> wrote:
> Was it intentionally sent to me personally and not to list?

No, I've been doing that ever since the default changed about ten years
ago.

> OK so we now have two possiblities
>
> - - nice localized output but without any possibility to give specific
> options' argument(s) completion
>
> - - unlimited freedom in completing options limited to hardcoded english 
> descriptions.
>
> Now when you are probably the only person understanding how _argument
> works -
> any chances to merge the above? I.e. extra option to _arguments (something 
> like _agruments -h help_option, where help_option is variable) to request 
> description for options? This does not need all this hairy processing or 
> recognizing of *=FILE or like - just fetch options with help text and use it 
> instead of supplied one if found. This gives l10n for large part of commands 
> for free.

This requires two bits, a system of supplying descriptions indicating
the text is localizable and providing an index and a system for storing and
retrieving those localized descriptions.

I think this needs to be done as low as possible in the completion system
so that as many features as possible, not just _arguments, can benefit.
This means wherever the explanation string to be passed to compadd is
modified.  In particular _describe has a lot to do with it, though
how much I don't know; it's probably the place to start.

Probably the first thing to do, however, would be to add a localization
function system under Functions to retrieve data based on keywords.  It can
then be inserted gradually into the completion system at any appropriate
level.  We need to decide:

- Where to store data.  The path should be configurable from the shell.
Files will presumably correspond to languages and I guess the usual system
of ru, ru_RU, ru_RU.UTF-8 etc. will work, though I don't know the details
of how it's searched.  Someone may be able to provide a suitable algorithm
for turning LC_ALL/LC_MESSAGE/LANG into a directory name.  We'd
want to be able to configure the top of the path before locale-specific
bit so that we can use the information in the source tree rather
than installation, for example.  They'd be in the same format and
just installed by tarring the directories, though we'd probably
want to do it module by module in the same way Functions currently is in
config.modules.

- What format the data is in.  This should make access from shell code
easy.  The simplest possibility is a file containing definitions
of associative arrays, where the keys are as discussed below.  Then
it's simply a question of sourcing the file.  However, that could
produce huge memory usage so we may want to be cleverer.  We could
add additional paths to get to the file, for example.

- How to access the data.  This is simpler.  It's probably going to be a
function that sets REPLY.  It can do the locale investigation itself,
although we may want to cache the result, e.g. if the locale is ru_RU.UTF-8
work out a path to the top of the file tree once and keep it until the
locale changes.

- The syntax for keys.  If we're clever we can use this to simplify
the data access problem.  For example, a format like
"<L10N%comp/cmd/mount%mount-point>" gives
- a reasonably specific format that isn't going to be confused
with other descriptions.  I deliberately avoided colons because they're
already overloaded in the completion system.
- the path to a file <top-of-stuff-for-current-locale>/comp/cmd/mount.zmsg
that could be sourced to give local completions
- the name of a key mount-point for the hash in that file that contains the
appropriate string to be retrieved.

This can probably be retrieved to ensure the maximum re-use, e.g. we keep
the same hash in memory while the path after the first % doesn't change
and return the requested element.  This would work neatly in a case like
this where the localization file is associated with the particular
contextual completion.

Further discussion is invited.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php