Re: Thinking about Functions/Completion/* differently

Re: Thinking about Functions/Completion/* differently

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
>
> ... (with the usual caveats about contexts like
> parameter substitution that need some other key than "command name") ...

And before I forget to mention this: people using the new style
completion stuff may have noticed that completion after `$', `=', and
`~' still automagically works if complist is used independent of the
options given to it. This is due to the fact that this is still
handled very deeply in the completion code. I was thinking about
skipping over this code when the completion code is called from a
completion widget and instead testing for it and reporting this to the 
widget as different CONTEXTs. This sound like the correct behavior, right?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Thinking about Functions/Completion/* differently

[Bart Schaefer]

On Feb 12,  9:42am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: compadd (+ questions)
}
} The problem is that the current approach is completion-centered, not
} command-centered. Just think about someone who wants to use one of the
} example completions for another command.

I think we need to be neither command-centered nor completion-centered.
We need a relational rather than operational view.

We have all these files, many of which amount to nothing more than a map
from a name like __aliases to an old compctl option letter.  We need to
recognize that this mapping is even more important than what the files
contain.

} I haven't thought that much about all this yet, but it would go like
} this:
} 
} We have a collection of context-names (completely shell-code based,
} this is only vaguely connected to the CONTEXT parameter). For each
} such context we have a definition saying what should be completed in
} this context (such a definition could again be a function or an array, 
} re-using some of the code).

This sounds OK so far ...

} There would be a dispatcher-function that
} gets the context-name as its argument and then invokes the
} corresponding handler.

What's the reason to do this with a dispatcher-function that takes an
argument, rather than simply using a "case ... esac"?

} We would then come up with files containing context-definitions (some
} of the files are exactly that already and have names that show it, I
} think that the fact that for other files names of commands seemed more
} natural may be a hint that something went wrong).

Not entirely.  By contexts, here, you mean things like "now we are
completing path names," "here we complete user names," "here we want
alias names," "now file names ending in .gz," etc.  Right?

There are only a few such contexts that are general enough to apply to
a wide range of commands.  Most of those are already represented by old
compctl options that take no arguments, and therefore can be directly
implemented by calling complist.  I don't think it's very useful to
have separate files for defining each of these cases.

Then there are a few other cases, like __x_options and __dvi, that are
specific to a particular class of commands; and lastly there are the
commands like __dd that have so many unique options that they form a
context of their own.  So if the goal was to have one file per context,
you aren't far off.

The hint that something is wrong is not the file names; it's the fact that
some only do match generation, whereas others do what might be called
"second-level dispatch."  Match generation is actually NOT the hard part!
The hard part is determining, from the command line, which context is the
one in which you're completing.

} Then we would need a way to connect command-names to context-names,
} preferably in some automagically collected way.

Connecting command-names to context-names isn't enough.  A single command
may have multiple contexts.

So it seems that what we need (with the usual caveats about contexts like
parameter substitution that need some other key than "command name") are:

1.  For each command, something that maps the command line and cursor
    postion to one of a set of a contexts.  (Some commands will never
    have more than one context.)

2.  For each context that can be generated by (1), something that maps
    the command name to the set of possible matches for that context.
    (Some contexts will never care about the command name or other key.)

3.  For each set of matches that can be generated by (2), something that
    maps the command and context to the code to insert the matches into
    the command line.  (There's lots of builtin support for this already.)

Some of those mappings may actually be multi-level, e.g., to implement
completion after the -exec for "find ... -exec ...".

Does this make sense?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com