Zsh Mailing List Archive
Messages sorted by:
Re: new completion behaviour version 2
- X-seq: zsh-workers 4593
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: new completion behaviour version 2
- Date: Mon, 9 Nov 1998 15:09:37 -0800
- In-reply-to: <199811090904.KAA07856@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- References: <199811090904.KAA07856@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Nov 9, 10:04am, Sven Wischnowsky wrote:
} Subject: Re: new completion behaviour version 2
} Bart Schaefer wrote:
} > 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
Well, yes, that's why I said I could easily be convinced otherwise; but:
} > 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.
It's quite a burden on the widget writer to check for LISTAMBIGUOUS and
spit out the listing if so. On the other hand, the widget ought to be
able to emit a listing (and have zle deal with it properly) even when
the LISTAMBIGUOUS is not set.
It seems to me there are three ways to deal with this:
1. The widget function always produces the entire list of matches, with
an annotation for how and where to insert them.
+ Returning a single value forces recexact.
+ The function always executes in the same way and always returns
the same values, so its easier to write.
+ Efficient, compiled builtin code handles menus and listings, and
tests for menucomplete, automenu, autolist, and listambiguous.
+ There's only one call to interpreted user code per set of results.
- The annotations have to describe prefix/suffix removal, replacement,
or addition for correct insertion on the command line.
- It may be unclear exactly what to display in a listing, i.e., what
if any prefix/suffix changes to perform on the returned strings.
2. The widget function always produces one match at a time, with an
annotation for how and where to insert it.
+ Builtin code still tests for menucomplete, automenu, autolist, and
+ The function can change the insertion annotations on every match.
- The function has to be told which match to produce; it's harder to
write efficient functions because it's necessary e.g. to branch on
whether the full list has previously been generated and on whether
the prefix has changed.
- Lots of calls to interpreted code when generating listings and when
cycling through menus.
- It requires either an annotation or two calls to the function to
- It still may be difficult to determine what to display for a listing.
3. The widget function not only produces the matches, but also either
inserts them or produces a listing as appropriate.
+ The function can drive zle directly (e.g., through $BUFFER) to do
+ No annotations are needed.
+ The function can produce exactly what should appear in the listing.
- The function has to be told what match to produce or to produce a
complete list of possible matches; it's even harder to write simple
- Lots of calls to interpreted code when generating menus.
- The widget writer has to figure out all the prefix/suffix changes
to perform on every insertion, including dealing with menus (but an
implicit "undo" of the last insertion before calling the function
for the next item could make that easier).
- The widget itself has to test automenu, autolist, and listambiguous.
There are of course points somewhere in between each of these choices, but
they all have something of those flavors. I think the choice of which to
provide depends on what we can come up with in terms of the annotations
needed by the first two.
} > compadd $disabled
} > instead of
} > compadd -dFB
} I like this. But I wouldn't like to have to do
} compadd $(compinfo -disabled)
I agree; if the choice is between that and something like
then I'd take the latter.
} > [[ ]] 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
Yes, but I've been thinking that perhaps the tests supported by [[ ]]
should be extensible through the modules mechanism anyway.
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: