zsh-workers
 help / color / mirror / code / Atom feed
* completion behaviour (was: zsh-workers: zsh-3.1.5 released)
@ 1998-11-02 10:36 Sven Wischnowsky
  1998-11-02 10:39 ` Peter Stephenson
  1998-11-02 11:29 ` Zefram
  0 siblings, 2 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1998-11-02 10:36 UTC (permalink / raw)
  To: zsh-workers


Zefram wrote:

> 
> Sven: would you please update your completion patches, and post
> new versions based on vanilla 3.1.5.  Specifically, the patches for
> inclusive ORing, grouping of completions, and the configurable fuzziness
> of matching.  I like all of these features.
> 

Before I start incorporating these things into 3.1.5 I'd like to ask a
few questions.

We had some discusssion about a new way to define completion behaviour 
which (seemingly) settled on: let's use shell functions and offer a
few new builtins. So, if I implement this, do we really want the
changes to compctl (note: I mean compctl, most of the changes in the
completion code itself would be used anyway) or should we leave
compctl alone and offer the new possibilities through the new way to
define completion behaviour, thereby giving some incentive to switch
to the new way?

Anyway, here is my suggestion for this new completion definition
stuff:


We use zle widgets, probably a new kind of widgets that uses some more 
special variables, like:

  CMDSTR   - the name of the current command, with some special values
             it could be used for certain contexts (conditions, math
             expressions, ...)
  words    - the words of the current command (an array)
  CURWORD  - the number of the current word (for words[CURWORD])
  PREFIX   - the prefix of the current word
  SUFFIX   - ...
  NMATCHES - the number of matches produced so far

Of course, many more interesting things can be thought of.

Using a special widget for this ensures that we have a common wrapper
function in the C code that must be used. The new builtins can be
called only from  such a widget or functions called from it and in the 
C code this should make it possible to leave most of the completion
code unchanged (especially the allocation behaviour).

The general procedure would be to define such a completion widget that
serves as a kind of main loop, calls other functions to produce the
matches and finally decides what to do with the matches (listing,
inserting, ...)

To make the definition and calling of completion functions for certain
commands easier there could be a new builtin, say `compfunc':

  compfunc -a <func-name> <cmd-names-or-patterns ...>

    Makes <func-name> be called for the given command. <func-name> may 
    be one of a few special strings for replacing `compctl -C -T -D'.

  compfunc -d <cmd-names-or-patterns ...>

    Deletes definitions.

  compfunc -c [ <cmd-str> ]

    Makes all of the defined functions for $CMDSTR or the given
    <cmd-str> be called (this is most of the main loop of the current
    completion code). We could use the return code of the completion
    functions to decide whether more functions should be called or
    not.

  compfunc [ -L ]

    Lists the definitions, probably in a form that could be used in
    .zshrc or wherever.

For producing the actual matches there is another builtin, say
`compadd'. For simplicity we could make it use the same flags
`compctl' uses now, but without `-x', `+', and the like, i.e. only the 
simple match-producing flags. This would allow us to re-use most of
the code for compctl and since only the simple flags would be
supported, the irritating part of compctl would not be inherited.

On the other side we might wih to clean things up and make `compadd'
get new options for the things to produce. This could also be combined 
with a different way to handle control flags (-U, -q,
grouping,...). We could make these flags be used `from now on' and
probably have a way to save/restore the current set of control flags
(whose state would be stored together with the matches produced),
e.g. (in an easy-to-read syntax):

  compadd -push
  compadd -quote -suffix '/'
  compadd -files               # optional glob pattern here
  ...
  compadd -pop

I'm not quite sure which would be better. But of course it should be
possible to write some helper functions that offer one of the syntaxes 
and internally uses the other.

Probably the most important change would be how xor'ed completion,
extended completion, and the like are handled - using shell
constructs.

Xor'ed completion is simple if we have the special variables mentioned 
above (or some way to get this information from the completion code):

  old=$NMATCHES
  compadd ...                        # try to produce some matches
  ...
  if [[ $old -eq $NMATCHES ]] then   # this is the xor test
    compadd ...
    ...
  fi
                                     # more xor tests could be here

More interesting is the replacement for `compctl -x'. As Bart already
pointed out, we could use things like:

  if [[ "$words[CURWORD-1]" = "-I" ]] then
    compadd -W /usr/include -/
  fi

I.e. use the normal shell tests and the special variables. But there
is a problem with this: with compctl the `-x' - tests not only test
for a certain condition, but also report some information back,
namely: the length of an prefix that should be ignored in the
completion string and (with `r[a,b]') a restriction on the command
words that should be used with `compctl -L'. Both of them are
important to have and aren't that easy to do by hand, so we might want 
to add a builtin for testing, say `comptest' that has options for the
different tests and automatically makes the completion code use the
resulting restrictions. Since these restrictions should be used only
for some `compadd's, we would also need a way to switch back to the
original (or previous) state, e.g.:

  if comptest -suffix '-'; then      # makes `-' be ignored
    compadd ...
    ...
    comptest -fin                    # old state again
  fi

Alternatively we could have a option meaning: activate the
restrictions resulting from the last test.

Finally we would need a way to insert the matches or the unambiguous
string for normal completion in the line. Since we are in a zle widget 
we could just add a way to get the prefix/suffix to insert from the
completion code and than fiddle with [LR]BUFFER (there is a problem
with automatically removable suffixes).

So we might add a builtin to control all this, e.g.:

  complist -i [ <number> ]

    The first effect of this is that the completion code calculates
    the things the user might want to insert. Without argument this
    inserts the unambiguous string, with argument it inserts the
    <number>'th match (this is needed to implement the menu-completion
    behaviour).

  complist -k

    This notifies the completion code that the list of matches is to
    be kept so that the next invocation of the completion widget can
    test if there is still a valid list of matches and then continue
    menu-completion.

  complist -c

    This is the counterpart of `-k'. If the completion widget still
    has a a valid list but the completion string has changed we need
    to clear the list so that we can produce the matches for the new
    string.

`complist' should also offer ways to access some more information,
especially we need a way to decide if the recexact and listambiguous
behaviour should be emulated.

Finally we need a way to make the completion code list the matches
found. This could be done with `complist' or by using the return code
of the completion widget.

Some final remarks:

- Using special variables isn't necessary, we could offer a way to
  make the information be stored in some variables with use-supplied
  names (and partially we already have this, of course).
- The new builtins may have different names and options. Also I'd like 
  to think about combining soome of the builtins.
- The matching control could be improved, too (not only the syntax ;-). 
  We might have a builtin/optio to some builtin for defining sets of
  matching controls under a user-supplied name and a flag to `compadd' 
  that uses these names.
- Using shell functions may also be a first step in supporting
  higher-level descriptions, e.g.:

    function opt-arg() {
      [[ "$words[CURWORD-1]" = "$1" ]] && compadd "$argv[2,-1]"
    }

  With that we could make paths in `/usr/include' after `-I' be
  completed with: 

    opt-arg -I -W /usr/include -/


So, now I would like to read some comments about all this ;-)

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: new completion behaviour version 2
@ 1998-11-09  9:04 Sven Wischnowsky
  1998-11-09 23:09 ` Bart Schaefer
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 1998-11-09  9:04 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> ...
> 
> 
> If we're going to add associative arrays anyway (which I take it would
> just be some kind of parameter syntax for frobbing a hash table) then
> I'd just as soon have the set of scalars (CMDSTR, CURWORD, etc.) be in
> such an associative array.

Interesting idea, I'll have to think about this a bit more...

> 
> As for the words of the current command ... I'm thinking I'd like them
> to come in as the positional parameters.  We already have syntax for
> altering the $* array (shift, set, and 3=foo among other things); it
> should be possible to recapture the contents after the function exits;
> and it is an extremely intuitive way to refer to the command line.
> 
> (You can almost do this today by using
> 	read -Ac argv ; shift
> in a compctl -K function, except that stomps the $1/$2 prefix/suffix.)

Yes, sounds good.

> 
> } For producing the actual matches there is another builtin, say
> } `compadd'.  [...]
> } with a different way to handle control flags (-U, -q,
> } grouping,...). We could make these flags be used `from now on' and
> } probably have a way to save/restore the current set of control flags
> } (whose state would be stored together with the matches produced),
> } e.g. (in an easy-to-read syntax):
> } 
> }   compadd -push
> }   compadd -quote -suffix '/'
> }   compadd -files               # optional glob pattern here
> }   ...
> }   compadd -pop
> 
> The main problem I have with this is that it's too easy to forget the
> "pop".  If you want to do something of this sort, it really needs its
> own syntax.  One way to accomplish that without having to muck about
> with the zsh parser is to supply ONLY the "push" version of the command,
> but define it to extend exactly to the end of the current function, as
> for "local" variables and "setopt localoptions".  The user can control
> scope by defining functions that call one another.
>  

I wasn't too happy about this, just because this `pop'. On the other
side I think that the function scope may be too big for this. But
maybe we can just do what you suggest and if we find out that we would 
like to have a possibility to `pop' to a previous state we can add it
later.

> } I.e. use the normal shell tests and the special variables. But there
> } is a problem with this: with compctl the `-x' - tests not only test
> } for a certain condition, but also report some information back,
> } namely: the length of an prefix that should be ignored in the
> } completion string and (with `r[a,b]') a restriction on the command
> } words that should be used with `compctl -L'.
> 
> Pardon my density, but I don't follow the connection between r[a,b] and
> `compctl -L'.  Do you mean `compctl -l'?

Yep, of course, this was a typo.

> 
> }   complist -k
> }   complist -c
> 
> Incidentally, with respect to menu completion, I don't think the widget
> should get involved directly in cycling through the menu choices.  (I
> can easily be convinced otherwise, but right now I don't see a compelling
> argument.)  Once the the control flags have indicated that you have a
> menu of choices, don't invoke the widget again until the prefix changes.
> That is, the widget can say "here are the completions, and here is where
> you insert them" but then let hardwired code take over cycling through
> the menu if there are multiple matches.

Interesting point of view. I thought we wanted to give the user the
possibility to build widgets that have full control over the
completion mechanism, i.e. the possibility to re-implement all the
things the completion code offers now.
But again, yes, we probably should start with a minimal solution and
improve that later if we need/want to have it.

> ...
> 
> Recexact can be emulated entirely by the wiget by simply producing only
> a single match.  Listambiguous can be a flag attached to the generated
> list of matches, can it not?
> 

Yes. The question is: should the completion code do this automatically 
or should the user request it explicitly.

> ...
> 
> What I had in mind a while back was an interface to add one or more
> matches with options for the controls associated with that collection
> of matches; plus interfaces (possibly commands, possibly variables) to
> obtain the information that's currently only available to compctl and
> pass it to the add-matches interface.
> 
> So for example there would be a command or an array variable that gives
> the names of all the disabled commands, and you'd do
> 
> 	compadd $disabled
> 
> instead of
> 
> 	compadd -dFB
> 
> (That's probably not the best example, but just to give the idea.)
> 

I like this. But I wouldn't like to have to do

    compadd $(compinfo -disabled)

The $(...) is what I don't like. Using variables would be much more
effective, but these would be special variables and there seems to be
reluctance against more special variables (not from me, I always liked 
them).

> ...
>
> I agree, and I liked your comptest idea.  For example, something like
> 
> 	if comptest index -1 / ; then
> 
> to mean what n[-1,/] accomplishes now.  (There could even be a flag in
> [[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the
> above.)

I didn't think about changing [[...]], interesting. (Although that
would require changes in completely differnt parts of the code, of
course.)

> ...
> 
> Recursively invoking completion functions is a good idea, and IMNSHO is
> the best argument that I can think of for passing the command words as
> the positional parameters.  (There is of course still the issue of $0,
> but that's not too terrible.  Just assign to CMDSTR or whatever takes
> its place in the associative array, before calling the other function.)

Of course. My suggestion was to have a top-level function that calls
other functions which might call other functions...


> 
> On Nov 3,  4:58pm, Sven Wischnowsky wrote:
> } Subject: new completion behaviour version 2
> }
> } The coding scheme for xor'ed completion is trivial. The code for `-x'
> } stuff will be done using `if'-tests with the information stored in
> } local variables. We then need a way to notify the completion code
> } about two things it will have to use (to be able to do the same things 
> } `-x' can): the length of an ignored prefix of the current word and
> } (for `-L') which part of the words-array should be taken as command
> } words.
> 
> I still think you must mean `-l' there.  Un-confuse me, please.

Yes, this was `copying a typo without further thinking'.


Bye
 Sven


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


^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~1998-11-09 23:14 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-11-02 10:36 completion behaviour (was: zsh-workers: zsh-3.1.5 released) Sven Wischnowsky
1998-11-02 10:39 ` Peter Stephenson
1998-11-02 11:29 ` Zefram
1998-11-02 12:00   ` Sven Wischnowsky
1998-11-02 12:31     ` Zefram
1998-11-02 13:48       ` Sven Wischnowsky
1998-11-03 15:58         ` new completion behaviour version 2 Sven Wischnowsky
1998-11-03 17:15           ` Bart Schaefer
1998-11-06 19:02           ` Bart Schaefer
1998-11-09  9:04 Sven Wischnowsky
1998-11-09 23:09 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).