* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-28 16:57 Sven Wischnowsky
0 siblings, 0 replies; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-28 16:57 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> X-Seq: 5087
>
> On Jan 28, 12:28pm, Peter Stephenson wrote:
> } Subject: Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
> }
> } I'm increasingly of the opinion we can do without zle -C. [...]
> } So I would propose simply removing zle -C, and being ready to document
> } various how-to's in the compctl manual when the new stuff becomes
> } fixed. It hasn't been in any archived version, so I hope there won't
> } be many cries of woe.
>
> Sounds fine to me (and would give over to Sven the "-C" option). As I
> said elsewhere, I don't think anybody running any version of 3.1.x has
> much call for woeful cries; the whole point of a development version is
> to be able to change stuff until it works right. (3.0.x users are
> another matter, but not at issue here.)
Two more comments:
- complist currently accepts only simple flag lists, nothing of the
complicated stuff (-x, +, -l '', and a few more), since that would
require setting up things like the word-array each time complist is
used. We could do that (the code is there and used for `compcall')
but it would make things a bit slower (in some simple cases we can
quickly test if we need to set up things and thus sometimes avoid
doing so, but sometimes this test would be complicated).
Whereas `-C' accepts anything `compctl' accepts.
- After looking again at Peter's examples (the ones he converted from
`zle -C' to `zle -c') I'd like to point out that we could even
supply a shell function that creates such one-shot completion
widgets. So, that may be an argument for removing it...
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
1999-01-28 11:28 ` Peter Stephenson
@ 1999-01-28 16:31 ` Bart Schaefer
0 siblings, 0 replies; 14+ messages in thread
From: Bart Schaefer @ 1999-01-28 16:31 UTC (permalink / raw)
To: zsh-workers
On Jan 28, 12:28pm, Peter Stephenson wrote:
} Subject: Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
}
} I'm increasingly of the opinion we can do without zle -C. [...]
} So I would propose simply removing zle -C, and being ready to document
} various how-to's in the compctl manual when the new stuff becomes
} fixed. It hasn't been in any archived version, so I hope there won't
} be many cries of woe.
Sounds fine to me (and would give over to Sven the "-C" option). As I
said elsewhere, I don't think anybody running any version of 3.1.x has
much call for woeful cries; the whole point of a development version is
to be able to change stuff until it works right. (3.0.x users are
another matter, but not at issue here.)
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-28 14:25 Sven Wischnowsky
0 siblings, 0 replies; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-28 14:25 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> Could somebody who's managed to keep track of all this stuff (Sven? Peter?)
> please post a complete summary for _both_ zle -c and zle -C of
>
> * the new commands (compadd, complist, compcall, etc.)
> * the new variables (what's in them and when they're available)
> * the parameters passed to a user's shell functions in each case
>
> Unfortunately, I haven't had time to study Sven's posts enough to do it.
>
> A whole lot of stuff has gone by recently that sounds good in the abstract
> but that feels, in Sven's words, "rather hackish." If it were all written
> down in one place it might become obvious how it could all be made to fit
> together better.
Well...
New style completion stuff:
zle -c name comp func
This defines a widget named `name' that calls the shell function
`func' to produce matches. All the other things completion does, like
displaying a list, deciding what to insert in the line, deciding if
menu-completion should be used and so on is currently only controlled
by the C-code. To allow the user to say how he would like this widget
to behave, (s)he has to give the name of one of the builtin
completion-widgets as the `comp' argument, e.g.:
zle -c my-comp expand-or-complete my-comp-func
Defines the widget `my-comp', makes it call the shell function
`my-comp-func' and makes the completion code behave as if
`expand-or-complete' were used.
Now, inside the shell function the completion code sets up some
variables and offers a few extra builtins and condition codes (the
stuff below is copied and updated from message 4850):
The parameters are:
PREFIX the prefix of the current word from the command line
IPREFIX an ignored prefix (see below)
SUFFIX the suffix of the current word
COMMAND this is something like the `direct context'; for completion
of arguments it contains the command name, but for
subscripts or when completion the right hand side of a
parameter assignment this holds the name of the parameter;
also, when completing a redirection, this holds the
redirection operator itself (the command is still in argv)
CONTEXT the context we are currently completing in, this can be
any of:
`command' we are completing in command position
`argument' we are completing in argument position
`redirect' ... after a redirection operator
`math' ... in a math environment
`subscript' ... in a subscript
`value' ... in the value of an variable assignment
`condition' ... inside `[[...]]'
argv if completing an argument this holds the argument strings
(not including the command name); when completing an
redirection it contains the command line strings (including
the command name); when completing on the right hand side
of an array assignment this holds the strings in the
parentheses
CURRENT this is the index into `argv' pointing to the current word
NMATCHES this is the number of matches produced (and accepted) so far
These variables are settable, the example file contains two convenient
aliases to save and restore them. The completion code uses a wrapper
function to reset them to their old values at the end of each function
executed from the completion widget.
The conditions work on the contents of these variables, probably
changing them, they are modeled directly after the `compctl -x'
condition code:
-prefix str
is true if PREFIX starts with str
-iprefix str
like `-prefix', but makes the matched portion be
ignored; this is done by appending the matched
portion to IPREFIX and removing it from PREFIX
-position beg [end]
is true if we are currently in position `beg' (or between `beg'
and `end' if that is given); if `end' is given COMMAND, CONTEXT,
CURRENT, and argv are changed so that they contain only the range
of words between these positions
(as always when one of these condition takes an integer argument
an expression may be given, like `-position a+1')
-word index str
is true if the `index'th argument is `str'
-mword index pat
like `-word' but with pattern matching
-current index str
-mcurrent index pat
like `-word' and `-mword' but the `index' is take relative to the
current position
-string str
-string index str
true if the current word contains `str'; anything up to the
`index'th occurrence of `str' is ignored (or anything up to the
last occurrence if no `index' is given, again this sets IPREFIX
and PREFIX)
-class str
-class index str
like `-string' but the `str' is taken as a character class
-words min [max]
true if we have at least `min' arguments (and less than or equal
to `max' arguments if that is given)
-between s1 s2
true if we are between an argument equal to `s1' and before an
argument equal to `s2' (if there is such an argument)
-mbetween p1 p2
like `-between' but with pattern matching
-after str
true if we are after an argument equal to `str'
-mafter pat
like `-after' but with pattern matching
-nmatches num
true if we have generated `num' matches
Of course, tests can also be done by using the normal condition stuff
and the above variables (probably changing them), but these condition
codes may be faster and/or easier to use.
The builtins are:
complist ...
This gets almost the same arguments as compctl, except the more
complicated ones (like xor'ed completions, `-x', `-l', ...).
When using this builtin, the completion code uses the current values
of the variables above, so that the combination of this builtin and
the condition codes makes life really simple...
compadd [options] matches...
This allows access to the structure used internally used for storing
matches. When using this builtin the variables are not used and the
completion code does not check if the strings added match what is
one the command line, so you should know what you are doing.
Supported options are:
-q, -Q, -U, -P str, -S str, -J name, -V name
these are used like the options with the same names in compctl and
complist
-f
if this option is given the strings are treated like filenames
(showing files types with LISTTYPES)
-a
this says to put the matches in the alternative set (those that
are build for fignore ignored)
-n
this keeps the strings from appearing in the list of matches
-i str
this gives an ignored previous to use when inserting the match;
such a string is not listed and inserted before a prefix given
with the `-p' option
-p str
this gives another prefix that is not listed; but it is inserted
and used for testing file types
-s str
like `-p' but giving a suffix
When I announced all this I said that this is least stable part of
the new completion stuff because I hadn't had the time to check most
of this. Now, the example file contains a function that heavily uses
this builtin and seems to work fine.
It is intended as a utility to give full control to the things stored
for each match. I would like to add some more functionality to make
it easier to use for things people can be expected to want to have.
For example:
- a flag that says that the matches are filenames and that makes the
code automatically check fignore; this could also automatically
try to list only path name components and the like (but I think we
an extra option to support this would be better, since the results
may probably be unexpected or unwanted)
- a flag that says that normal matching rules should be applied
(together with support for the `-M' option known from compctl and
complist); this is important to have since currently all words
given to compadd are taken even if they don't match what's on the
line, so you have to do all the matching yourself (which can get
complicated if you use `-M'); also, this isn't that hard to add
since most of the code is already there
- a way to specify when a added -S-suffix should be removed
(i.e. after which characters are typed should the suffix be
removed)
Of course, other things may also turn out to be interesting, we'll
see.
compcall [ -[TD] ]
This is the youngets of the builtins. It allows to call the
`compctl'-stuff from a new style completion widget. It takes no
arguments, only two options. Normally, `compctl -T' and `compctl -D'
are not used when calling `compctl's, since I expect this to be used
mainly for command-`compctl's. However, if you want them to be used
you can give the respective option to `compcall' and you'll get them
used. The completion code called is made to believe that the line
looks like the stuff described in the parameters above (PREFIX,...).
For this we needed some conversion and copying-around which may not
be fully correct yet (so here is some code that at least needs some
verifying, more likely some changes).
If this turns out to be interesting enough to stay alive (and I
almost expect it to be), there are many things we might to want add
or change, e.g.:
- make it take arguments which are to be taken as the words the
`compctl'-code should think are on the command line
- let it accept options with strings for the stuff which is
currently taken from the parameters
- for now, the status-return is always zero, it may be interesting
or even important to let it return some useful things; this can be
information about continuing (`compctl -t<c>'), some kind of
signal if a compctl has been processed, and so on.
compctl -K ' foo'
This is as hackish as can be. This special syntax (note the space
before the function name `foo') currently allows us to call `foo'
from `compctl'-code in the same way as new style completion widgets
are called, i.e. with the parameters set up and allowed to call
`complist', `compadd', and `compcall'. I didn't bother to search a
free option character for it (although, if I remember correctly,
there still was one, but not many more than one), because I'm not
too convinced, that we should support this, although I admit that it
may be interesting to have in some cases. But we may as well keep
it, especially since this (currently) adds only two lines of code.
The examples in `new-completion-examples':
This file contains all the code you need to try all this new
completion stuff, including the definition of a completion widget
and the call to `bindkey' to bind it to TAB.
It has two functions to define completion handlers, `defcomp' and
`defpatcomp', where the first defines a handler for commands or one
of the special contexts (like `subscript') and the second one
defines handlers that should be used when the command name matches a
given pattern.
The master function of the code is `main-complete'. It first calls
`compcall' to get access to the old `compctl's, then calls the
equivalent of `-T' and finally has a look at CONTEXT to find out
which handler it should call. If you are completing a command or
argument, `do-complete' is called to handle that, finding matching
patterns and normal handlers or the equivalent of `-D'. This also
emulates the `use last path-name component' and the `=' special
handling done by the `compctl'-completion code.
To really call the handler, `call-complete' is invoked. This looks
up the definition, which may be a array name or a function name. If
it is a function, it is called (and will use `complist', `coompadd',
and friends). If it is an array, `complist' is called with the
contents of the array as arguments. This allows one to keep simple
definitions simple, as in:
defcomp __command --command--
__command=( -c )
For the functions there are some helpers:
- `compsave' and `compreset' can be used to save and restore the
states of the special parameters; this is important to have when
using the conditions and if you want to make more than one test
in the same function
- `compsub' calls `do-complete' again with the current settings of
the special parameters; this is the replacement for `compctl -l'
- `compalso' can be used to add the matches for another command or
special context (intended for e.g. `subscript includes math')
- `pfiles' does partial-path completion. It gets no arguments or
one of `-f', `-/', or `-g' known from `compctl'. If you use `-g'
the patterns to search should be given after the `-g', one per
argument (*not* all in one string). As its first two arguments,
it accepts `-W <paths>' where `<paths>' looks like the things
you can give to `compctl -W'. With all this, `pfiles' is
intended as a replacement for `comp{ctl,list} -[f/g]', giving
you multicomp-like partial path completion everywhere.
- `files' just calls `pfiles' with the arguments it got and, if
that doesn't produce any matches, calls `pfiles' again with no
arguments, producing all filenames. This is a replacement for
`compctl -[f/g] ... + -f'.
Yes, this could do with some work...
One thing that is not yet correct is the continuation-stuff. The
main functions use the return values of the handler functions for
this: zero means that other handlers should be tried, non-zero means
that no more matches should be produced. I still have to check all
the example handler functions if they behave correctly with respect
to this.
Mixed comments (most of them are from the old message):
- I haven't used an associative array for the variables since I would
then like to put [LR]BUFFER and so on into it and I didn't want to
change to many parts of the shell for this first version.
Also: using separate variables makes handling them so easy...
- When using `complist' the completion code still does normal completion
after `~', `=', and `$' (unless that is in IPREFIX, of course).
- Later we may add a way to access the matches produced and to control
what is done with the collected data (inserting, listing, ...)
- With `complist' you can make functions be called with `-K' and `-y'
put they can't use `read' to get at the comamnd line data. This is
because the new style completion uses a different way to store them
(the above parameters).
- When using conditions that change the parameter values the behavior
may be irritating since following tests use the changed values. To
avoid this you have to put the test into a separate function so that
the previous state is automatically restored by the completion code
or you have to restore the state by hand. Since I expect that many
users will want to put all their tests for a command in one function
(making things better readable) restoring by hand and forgetting to
do so in the right places will become inconvenient. This is the
reason for the `compsave' and `compreset' helper aliases, I *really*
would like to find a way to take this burden from the user.
- The condition codes behave a bit different from their `compctl -x'
counterparts since they can only access the arguments (not the
command name).
- The attentive reader of the patch will notice some hunks in zsh.h
and in mem.c. This implement a way to re-use older heaps. In fact
there are functions that allow one to temporarily switch to another
heap, go back to an older heap, and to temporarily switch to another
heap. The patch for zsh.h implements some macros like HEAPALLOC that
make it easy to use this mechanism.
- The value of `COMMAND' may be a bit irritating, since it depends on
the `CONTEXT', we might want to rename it, change it, add another
one, or something like that.
Ok, I hope this helps for now.
Bye
Sven
P.S.: So long a message, and not even a patch, tststs ;-)
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-28 11:59 Sven Wischnowsky
0 siblings, 0 replies; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-28 11:59 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> I'd better leave zle -c to Sven, since I haven't had much time to look
> at all the details. I mentioned some time ago I was unhappy about the
> setting/unsetting of the existing zle parameters like $BUFFER, which
> still needs looking at, I don't know if it applies to Sven's new ones.
I remember that there was aproblem, but don't remember which, we'll see...
> ...
>
> So I would propose simply removing zle -C, and being ready to document
> various how-to's in the compctl manual when the new stuff becomes
> fixed. It hasn't been in any archived version, so I hope there won't
> be many cries of woe.
Hm, your stuff is still simpler (although I'd like to inherit the
upper case `C' ;-).
> By the way: I stumbled on compadd -p ${match:h}/ -f ${match:t}
> to get the listing to work the way it normally does for files. Is
> this the approved way, or is the something better?
Yes, this is what I expected, but I'll comment in this in my reply
which I'm working on.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
1999-01-28 7:06 ` Bart Schaefer
@ 1999-01-28 11:28 ` Peter Stephenson
1999-01-28 16:31 ` Bart Schaefer
0 siblings, 1 reply; 14+ messages in thread
From: Peter Stephenson @ 1999-01-28 11:28 UTC (permalink / raw)
To: zsh-workers
"Bart Schaefer" wrote:
> Could somebody who's managed to keep track of all this stuff (Sven? Peter?)
> please post a complete summary for _both_ zle -c and zle -C of
>
> * the new commands (compadd, complist, compcall, etc.)
> * the new variables (what's in them and when they're available)
> * the parameters passed to a user's shell functions in each case
I'd better leave zle -c to Sven, since I haven't had much time to look
at all the details. I mentioned some time ago I was unhappy about the
setting/unsetting of the existing zle parameters like $BUFFER, which
still needs looking at, I don't know if it applies to Sven's new ones.
I'm increasingly of the opinion we can do without zle -C. All the
uses I have for it can be replaced; I've just quickly converted my
current list of zle -C's into (this uses the new glob
sorting/selecting mechanism, too):
zle -c history-complete-word complete-word __history_complete_word
__history_complete_word() { complist -Q -H 0 ''; }
bindkey "\e/" history-complete-word
bindkey "\M-/" history-complete-word
zle -c most-recent-file complete-word __most_recent_file
__most_recent_file() {
local match
if [[ $PREFIX = *\** ]]; then
match=(${~PREFIX}${~SUFFIX}(Om[1]))
else
match=(${~PREFIX}*${~SUFFIX}(Om[1]))
fi
[[ -n $match ]] && compadd -p ${match:h}/ -f ${match:t}
}
bindkey "\C-x." most-recent-file
zle -c complete-filename complete-word __complete_filename
__complete_filename() { complist -f; }
bindkey "\C-xf" complete-filename
zle -c complete-directory complete-word __complete_directory
__complete_directory() { complist -/; }
bindkey "\C-x\C-d" complete-directory
So I would propose simply removing zle -C, and being ready to document
various how-to's in the compctl manual when the new stuff becomes
fixed. It hasn't been in any archived version, so I hope there won't
be many cries of woe.
By the way: I stumbled on compadd -p ${match:h}/ -f ${match:t}
to get the listing to work the way it normally does for files. Is
this the approved way, or is the something better?
--
Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
1999-01-26 11:52 ` Andrej Borsenkow
@ 1999-01-28 7:06 ` Bart Schaefer
1999-01-28 11:28 ` Peter Stephenson
0 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 1999-01-28 7:06 UTC (permalink / raw)
To: zsh-workers
Could somebody who's managed to keep track of all this stuff (Sven? Peter?)
please post a complete summary for _both_ zle -c and zle -C of
* the new commands (compadd, complist, compcall, etc.)
* the new variables (what's in them and when they're available)
* the parameters passed to a user's shell functions in each case
Unfortunately, I haven't had time to study Sven's posts enough to do it.
A whole lot of stuff has gone by recently that sounds good in the abstract
but that feels, in Sven's words, "rather hackish." If it were all written
down in one place it might become obvious how it could all be made to fit
together better.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-27 15:21 Sven Wischnowsky
0 siblings, 0 replies; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-27 15:21 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> > `compcall' accepts no other option or argument, for now. It would
> > be easy to make it accept arguments for the command line words to
> > use, for the command name to use, etc. If this turns out to be
> > interesting to have, I'll add it.
>
> I won't be able to test it for some time, but this occured to me today:
>
> compctl -T -K " __default"
>
> function __default() {
> compcall -T
> }
Damn. Yesterday I thought about this, but today I forget to handle
it. Since there is no easy way to correctly avoid recursions, let's
use a depth counter (until we find a better solution, if we ever find
a better solution).
Bye
Sven
--- os/Zle/zle_tricky.c Wed Jan 27 16:16:32 1999
+++ Src/Zle/zle_tricky.c Wed Jan 27 16:18:58 1999
@@ -3449,10 +3449,21 @@
} SWITCHBACKHEAPS;
}
+/* A simple counter to avoid endless recursion between old and new style *
+ * completion. */
+
+static int cdepth = 0;
+
+#define MAX_CDEPTH 16
+
/**/
void
makecomplistctl(int flags)
{
+ if (cdepth == MAX_CDEPTH)
+ return;
+
+ cdepth++;
SWITCHHEAPS(compheap) {
HEAPALLOC {
int ooffs = offs, lip, lp;
@@ -3488,6 +3499,7 @@
clwpos = op;
} LASTALLOC;
} SWITCHBACKHEAPS;
+ cdepth--;
}
/* This function gets the compctls for the given command line and *
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
1999-01-27 12:25 Sven Wischnowsky
@ 1999-01-27 15:04 ` Andrej Borsenkow
0 siblings, 0 replies; 14+ messages in thread
From: Andrej Borsenkow @ 1999-01-27 15:04 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
Oh, great man!
> `compcall' accepts no other option or argument, for now. It would
> be easy to make it accept arguments for the command line words to
> use, for the command name to use, etc. If this turns out to be
> interesting to have, I'll add it.
>
I won't be able to test it for some time, but this occured to me today:
compctl -T -K " __default"
function __default() {
compcall -T
}
/andrej
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-27 12:25 Sven Wischnowsky
1999-01-27 15:04 ` Andrej Borsenkow
0 siblings, 1 reply; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-27 12:25 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> What I think about, is two interfaces: compctl->new completion and new
> completion->compctl. That is
The patch below implements this:
new->old:
The builtin `compcall' can be called from a new style completion
function and makes the `compctl's for the current settings of
COMMAND, IPREFIX, PREFIX, SUFFIX, and argv be used. Currently this
builtin accepts only to options: `T' and `D'. Without any options
the `compctl's for first completion (`-T') and for default (`-D')
completion are *not* tried. You can switch this on by using the
appropriate option.
`compcall' accepts no other option or argument, for now. It would
be easy to make it accept arguments for the command line words to
use, for the command name to use, etc. If this turns out to be
interesting to have, I'll add it.
old->new:
I'm not too sure that I like to support this way, so this is rather
hackish at the moment (meaning: even more than the rest of the new
style completion). If you give the `-K' option to `compctl' a string
that begins with one space, the named function will be called with
the variables and arguments as expected by new style completion
functions.
Ok. Even though I said that this is very experimental, I strongly
suggest to use this patch. First, it makes testing the new stuff
easier, and second, the patch contains also a minor fix (compadd now
accepts zero arguments).
The patch also changes the file `new-completion-examples' to use
`compctl's that are defined. With that you should be able to just
source this file, use the new completion stuff and still be able to
use your `compctl's. You may want to modify or delete some of the
examples in the file. You may also want to alter the way compcall is
invoked, see the comments in the file after applying this patch (or
look at the end of this patch).
[The patch looks big, but this is almost only because it contains a
lot of moving-code-around and re-indent-stuff.]
Bye
Sven
diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h Tue Jan 26 14:24:21 1999
+++ Src/Zle/comp.h Wed Jan 27 11:14:43 1999
@@ -267,3 +267,8 @@
#define CLF_MISS 4
#define CLF_DIFF 8
#define CLF_SUF 16
+
+/* Flags for makecomplist*(). Things not to do. */
+
+#define CFN_FIRST 1
+#define CFN_DEFAULT 2
diff -u os/Zle/compctl.c Src/Zle/compctl.c
--- os/Zle/compctl.c Tue Jan 26 14:24:21 1999
+++ Src/Zle/compctl.c Wed Jan 27 12:07:24 1999
@@ -1677,7 +1677,7 @@
Compctl cc;
int ret = 0;
- if (!incompfunc) {
+ if (incompfunc != 1) {
zerrnam(name, "can only be called from completion function", NULL, 0);
return 1;
}
@@ -1706,7 +1706,7 @@
char *pre = NULL, *suf = NULL, *group = NULL;
int f = 0, q = 0, m = 0, ns = 0, a = 0;
- if (!incompfunc) {
+ if (incompfunc != 1) {
zerrnam(name, "can only be called from completion function", NULL, 0);
return 1;
}
@@ -1800,6 +1800,15 @@
return 0;
}
+/**/
+static int
+bin_compcall(char *name, char **argv, char *ops, int func)
+{
+ makecomplistctl((ops['T'] ? 0 : CFN_FIRST) |
+ (ops['D'] ? 0 : CFN_DEFAULT));
+ return 0;
+}
+
#define VAR(X) ((void *) (&(X)))
static struct compparam {
char *name;
@@ -1855,7 +1864,7 @@
static int
comp_wrapper(List list, FuncWrap w, char *name)
{
- if (!incompfunc)
+ if (incompfunc != 1)
return 1;
else {
char *octxt, *ocmd, *opre, *osuf, *oipre;
@@ -1906,7 +1915,7 @@
static int
comp_check(void)
{
- if (!incompfunc) {
+ if (incompfunc != 1) {
zerr("condition can only be used in completion function", NULL, 0);
return 0;
}
@@ -2118,7 +2127,8 @@
static struct builtin bintab[] = {
BUILTIN("compctl", 0, bin_compctl, 0, -1, 0, NULL, NULL),
BUILTIN("complist", 0, bin_complist, 1, -1, 0, NULL, NULL),
- BUILTIN("compadd", 0, bin_compadd, 1, -1, 0, NULL, NULL),
+ BUILTIN("compadd", 0, bin_compadd, 0, -1, 0, NULL, NULL),
+ BUILTIN("compcall", 0, bin_compcall, 0, 0, 0, "TD", NULL),
};
static struct conddef cotab[] = {
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c Tue Jan 26 14:24:23 1999
+++ Src/Zle/zle_tricky.c Wed Jan 27 12:55:02 1999
@@ -3172,6 +3172,105 @@
} LASTALLOC;
}
+/* This calls the given function for new style completion. */
+
+/**/
+static void
+callcompfunc(char *s, char *fn)
+{
+ List list;
+ int lv = lastval;
+
+ if ((list = getshfunc(fn)) != &dummy_list) {
+ LinkList args = newlinklist();
+ char **p, *tmp;
+ int aadd = 0, usea = 1, icf = incompfunc;
+
+ addlinknode(args, fn);
+
+ zsfree(compcontext);
+ zsfree(compcommand);
+ compcommand = "";
+ if (inwhat == IN_MATH) {
+ if (insubscr) {
+ compcontext = "subscript";
+ compcommand = varname ? varname : "";
+ } else
+ compcontext = "math";
+ usea = 0;
+ } else if (lincmd)
+ compcontext = (insubscr ? "subscript" : "command");
+ else if (linredir) {
+ compcontext = "redirect";
+ if (rdstr)
+ compcommand = rdstr;
+ } else
+ switch (inwhat) {
+ case IN_ENV:
+ compcontext = "value";
+ compcommand = varname;
+ usea = 0;
+ break;
+ case IN_COND:
+ compcontext = "condition";
+ break;
+ default:
+ if (cmdstr) {
+ compcontext = "argument";
+ compcommand = cmdstr;
+ } else {
+ compcontext = "value";
+ if (clwords[0])
+ compcommand = clwords[0];
+ }
+ aadd = 1;
+ }
+ compcontext = ztrdup(compcontext);
+ tmp = quotename(compcommand, NULL, NULL, NULL);
+ untokenize(tmp);
+ compcommand = ztrdup(tmp);
+ if (usea && (!aadd || clwords[0]))
+ for (p = clwords + aadd; *p; p++) {
+ tmp = dupstring(*p);
+ untokenize(tmp);
+ addlinknode(args, tmp);
+ }
+ zsfree(compprefix);
+ zsfree(compsuffix);
+ if (unset(COMPLETEINWORD)) {
+ tmp = quotename(s, NULL, NULL, NULL);
+ untokenize(tmp);
+ compprefix = ztrdup(tmp);
+ compsuffix = ztrdup("");
+ } else {
+ char *ss = s + offs, sav;
+
+ tmp = quotename(s, &ss, NULL, NULL);
+ sav = *ss;
+ *ss = '\0';
+ untokenize(tmp);
+ compprefix = ztrdup(tmp);
+ *ss = sav;
+ untokenize(ss);
+ compsuffix = ztrdup(ss);
+ }
+ zsfree(compiprefix);
+ compiprefix = ztrdup("");
+ compcurrent = (usea ? (clwpos + 1 - aadd) : 1);
+ compnmatches = mnum;
+ incompfunc = 1;
+ startparamscope();
+ makecompparamsptr();
+ NEWHEAPS(compheap) {
+ doshfunc(fn, list, args, 0, 1);
+ } OLDHEAPS;
+ endparamscope();
+ lastcmd = 0;
+ incompfunc = icf;
+ }
+ lastval = lv;
+}
+
/* The beginning and end of a word range to be used by -l. */
static int brange, erange;
@@ -3224,100 +3323,10 @@
ccused = newlinklist();
ccstack = newlinklist();
- if (compfunc) {
- List list;
- int lv = lastval;
-
- if ((list = getshfunc(compfunc)) != &dummy_list) {
- LinkList args = newlinklist();
- char **p, *tmp;
- int aadd = 0, usea = 1;
-
- addlinknode(args, compfunc);
-
- zsfree(compcontext);
- zsfree(compcommand);
- compcommand = "";
- if (inwhat == IN_MATH) {
- if (insubscr) {
- compcontext = "subscript";
- compcommand = varname ? varname : "";
- } else
- compcontext = "math";
- usea = 0;
- } else if (lincmd)
- compcontext = (insubscr ? "subscript" : "command");
- else if (linredir) {
- compcontext = "redirect";
- if (rdstr)
- compcommand = rdstr;
- } else
- switch (inwhat) {
- case IN_ENV:
- compcontext = "value";
- compcommand = varname;
- usea = 0;
- break;
- case IN_COND:
- compcontext = "condition";
- break;
- default:
- if (cmdstr) {
- compcontext = "argument";
- compcommand = cmdstr;
- } else {
- compcontext = "value";
- if (clwords[0])
- compcommand = clwords[0];
- }
- aadd = 1;
- }
- compcontext = ztrdup(compcontext);
- tmp = quotename(compcommand, NULL, NULL, NULL);
- untokenize(tmp);
- compcommand = ztrdup(tmp);
- if (usea && (!aadd || clwords[0]))
- for (p = clwords + aadd; *p; p++) {
- tmp = dupstring(*p);
- untokenize(tmp);
- addlinknode(args, tmp);
- }
- zsfree(compprefix);
- zsfree(compsuffix);
- if (unset(COMPLETEINWORD)) {
- tmp = quotename(s, NULL, NULL, NULL);
- untokenize(tmp);
- compprefix = ztrdup(tmp);
- compsuffix = ztrdup("");
- } else {
- char *ss = s + offs, sav;
-
- tmp = quotename(s, &ss, NULL, NULL);
- sav = *ss;
- *ss = '\0';
- untokenize(tmp);
- compprefix = ztrdup(tmp);
- *ss = sav;
- untokenize(ss);
- compsuffix = ztrdup(ss);
- }
- zsfree(compiprefix);
- compiprefix = ztrdup("");
- compcurrent = (usea ? (clwpos + 1 - aadd) : 1);
- compnmatches = mnum;
- incompfunc = 1;
- startparamscope();
- makecompparamsptr();
- NEWHEAPS(compheap) {
- doshfunc(compfunc, list, args, 0, 1);
- } OLDHEAPS;
- endparamscope();
- lastcmd = 9;
- incompfunc = 0;
- }
- lastval = lv;
- } else
- makecomplistglobal(s, incmd, lst);
+ if (compfunc)
+ callcompfunc(s, compfunc);
+ else
+ makecomplistglobal(s, incmd, lst, 0);
endcmgroup(NULL);
@@ -3362,11 +3371,11 @@
if (*p == '\\')
bslash = 1;
else {
- if (*p == '$') {
+ if (*p == '$' || *p == '=') {
if (bslash)
p[-1] = Bnull;
else
- *p = String;
+ *p = (*p == '$' ? String : Equals);
}
bslash = 0;
}
@@ -3425,16 +3434,59 @@
} SWITCHBACKHEAPS;
}
+/**/
+void
+makecomplistctl(int flags)
+{
+ SWITCHHEAPS(compheap) {
+ HEAPALLOC {
+ int ooffs = offs, lip, lp;
+ char *str = comp_str(&lip, &lp), *t;
+ char *os = cmdstr, **ow = clwords, **p, **q;
+ int on = clwnum, op = clwpos;
+
+ clwnum = arrlen(pparams) + 1;
+ clwpos = compcurrent - 1;
+ cmdstr = ztrdup(compcommand);
+ clwords = (char **) zalloc((clwnum + 1) * sizeof(char *));
+ clwords[0] = ztrdup(cmdstr);
+ for (p = pparams, q = clwords + 1; *p; p++, q++) {
+ t = dupstring(*p);
+ ctokenize(t);
+ remnulargs(t);
+ *q = ztrdup(t);
+ }
+ *q = NULL;
+ offs = lip + lp;
+ incompfunc = 2;
+ makecomplistglobal(str,
+ (!clwpos && !strcmp(compcontext, "command")),
+ COMP_COMPLETE, flags);
+ incompfunc = 1;
+ offs = ooffs;
+ compnmatches = mnum;
+ zsfree(cmdstr);
+ freearray(clwords);
+ cmdstr = os;
+ clwords = ow;
+ clwnum = on;
+ clwpos = op;
+ } LASTALLOC;
+ } SWITCHBACKHEAPS;
+}
+
/* This function gets the compctls for the given command line and *
* adds all completions for them. */
/**/
static void
-makecomplistglobal(char *os, int incmd, int lst)
+makecomplistglobal(char *os, int incmd, int lst, int flags)
{
Compctl cc;
char *s;
+ ccont = CC_CCCONT;
+
if (lst == COMP_WIDGET) {
cc = compwidget->u.cc;
} else if (inwhat == IN_ENV)
@@ -3463,16 +3515,17 @@
cc = &cc_default;
else {
/* Otherwise get the matches for the command. */
- makecomplistcmd(os, incmd);
+ makecomplistcmd(os, incmd, flags);
cc = NULL;
}
if (cc) {
/* First, use the -T compctl. */
- makecomplistcc(&cc_first, os, incmd);
-
- if (!(ccont & CC_CCCONT))
- return;
+ if (!(flags & CFN_FIRST)) {
+ makecomplistcc(&cc_first, os, incmd);
+ if (!(ccont & CC_CCCONT))
+ return;
+ }
makecomplistcc(cc, os, incmd);
}
}
@@ -3481,18 +3534,19 @@
/**/
static void
-makecomplistcmd(char *os, int incmd)
+makecomplistcmd(char *os, int incmd, int flags)
{
Compctl cc;
Compctlp ccp;
char *s;
/* First, use the -T compctl. */
- makecomplistcc(&cc_first, os, incmd);
-
- if (!(ccont & CC_CCCONT))
- return;
+ if (!(flags & CFN_FIRST)) {
+ makecomplistcc(&cc_first, os, incmd);
+ if (!(ccont & CC_CCCONT))
+ return;
+ }
/* Then search the pattern compctls, with the command name and the *
* full pathname of the command. */
makecomplistpc(os, incmd);
@@ -3520,9 +3574,11 @@
(cc = ccp->cc)) ||
((s = dupstring(cmdstr)) && remlpaths(&s) &&
(ccp = (Compctlp) compctltab->getnode(compctltab, s)) &&
- (cc = ccp->cc)))))
+ (cc = ccp->cc))))) {
+ if (flags & CFN_DEFAULT)
+ return;
cc = &cc_default;
-
+ }
makecomplistcc(cc, os, incmd);
}
@@ -3811,12 +3867,12 @@
ccont |= (cc->mask2 & (CC_CCCONT | CC_DEFCONT | CC_PATCONT));
- if (!incompfunc && findnode(ccstack, cc))
+ if (incompfunc != 1 && findnode(ccstack, cc))
return;
addlinknode(ccstack, cc);
- if (!incompfunc && allccs) {
+ if (incompfunc != 1 && allccs) {
if (findnode(allccs, cc)) {
uremnode(ccstack, firstnode(ccstack));
return;
@@ -4424,45 +4480,50 @@
/* Add user names. */
maketildelist();
if (cc->func) {
- /* This handles the compctl -K flag. */
- List list;
- char **r;
- int lv = lastval;
-
- /* Get the function. */
- if ((list = getshfunc(cc->func)) != &dummy_list) {
- /* We have it, so build a argument list. */
- LinkList args = newlinklist();
- int osc = sfcontext;
-
- addlinknode(args, cc->func);
-
- if (delit) {
- p = dupstrpfx(os, ooffs);
- untokenize(p);
- addlinknode(args, p);
- p = dupstring(os + ooffs);
- untokenize(p);
- addlinknode(args, p);
- } else {
- addlinknode(args, lpre);
- addlinknode(args, lsuf);
+ if (cc->func[0] == ' ')
+ /* Temporary hack for access to new style completione. */
+ callcompfunc(os, cc->func + 1);
+ else {
+ /* This handles the compctl -K flag. */
+ List list;
+ char **r;
+ int lv = lastval;
+
+ /* Get the function. */
+ if ((list = getshfunc(cc->func)) != &dummy_list) {
+ /* We have it, so build a argument list. */
+ LinkList args = newlinklist();
+ int osc = sfcontext;
+
+ addlinknode(args, cc->func);
+
+ if (delit) {
+ p = dupstrpfx(os, ooffs);
+ untokenize(p);
+ addlinknode(args, p);
+ p = dupstring(os + ooffs);
+ untokenize(p);
+ addlinknode(args, p);
+ } else {
+ addlinknode(args, lpre);
+ addlinknode(args, lsuf);
+ }
+
+ /* This flag allows us to use read -l and -c. */
+ if (incompfunc != 1)
+ incompctlfunc = 1;
+ sfcontext = SFC_COMPLETE;
+ /* Call the function. */
+ doshfunc(cc->func, list, args, 0, 1);
+ sfcontext = osc;
+ incompctlfunc = 0;
+ /* And get the result from the reply parameter. */
+ if ((r = get_user_var("reply")))
+ while (*r)
+ addmatch(*r++, NULL);
}
-
- /* This flag allows us to use read -l and -c. */
- if (!incompfunc)
- incompctlfunc = 1;
- sfcontext = SFC_COMPLETE;
- /* Call the function. */
- doshfunc(cc->func, list, args, 0, 1);
- sfcontext = osc;
- incompctlfunc = 0;
- /* And get the result from the reply parameter. */
- if ((r = get_user_var("reply")))
- while (*r)
- addmatch(*r++, NULL);
+ lastval = lv;
}
- lastval = lv;
}
if (cc->mask & (CC_JOBS | CC_RUNNING | CC_STOPPED)) {
/* Get job names. */
@@ -4619,7 +4680,7 @@
}
/* No harm in allowing read -l and -c here, too */
- if (!incompfunc)
+ if (incompfunc != 1)
incompctlfunc = 1;
sfcontext = SFC_COMPLETE;
doshfunc(cc->ylist, list, args, 0, 1);
@@ -4686,7 +4747,7 @@
clwords += brange;
}
/* Produce the matches. */
- makecomplistcmd(s, incmd);
+ makecomplistcmd(s, incmd, CFN_FIRST);
/* And restore the things we changed. */
clwords = ow;
--- om/new-completion-examples Tue Jan 26 16:48:34 1999
+++ Misc/new-completion-examples Wed Jan 27 12:36:17 1999
@@ -90,11 +90,20 @@
# arguments from the command line are gives as positional parameters.
main-complete() {
- emulate -R zsh
+ # emulate -R zsh
local comp
setopt localoptions nullglob rcexpandparam globdots
unsetopt markdirs globsubst shwordsplit nounset
+
+ # We first try the `compctl's. This is without first (-T) and default (-D)
+ # completion. If you want them add `-T' and/or `-D' to this command.
+ # If this produces any matches, we don't try new style completion. If you
+ # want to have that tried anyway, remove the `[[ -nmatches ... ]] ...'
+ # below.
+
+ compcall
+ [[ -nmatches 0 ]] || return
# An entry for `--first--' is the replacement for `compctl -T'
# The `|| return 1' is used throughout: if a function producing matches
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-26 13:58 Sven Wischnowsky
0 siblings, 0 replies; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-26 13:58 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> ...
>
> What I think about, is two interfaces: compctl->new completion and new
> completion->compctl.
Until now I was only thinking about using `compctl's from completion
function (but in the same way you did). But I think we should give it
some arguments, e.g.: should `-T' be used, should `-D' be used, etc.
Hm... [time passes, thinking], no currently this doesn't look too hard
to implement, but when dealing with the completion code you'll never
know ;-)
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
1999-01-25 13:27 ` Peter Stephenson
@ 1999-01-26 11:52 ` Andrej Borsenkow
1999-01-28 7:06 ` Bart Schaefer
0 siblings, 1 reply; 14+ messages in thread
From: Andrej Borsenkow @ 1999-01-26 11:52 UTC (permalink / raw)
To: Peter Stephenson, zsh-workers
>
> I haven't got around to considering the new completion in detail, but
> it did occur to me it could be better integrated with the widget
> completion I added, i.e. zle -c and zle -C could be made more similar.
Actually, after looking at new completion examples, I really think, all
three current ways to do completion should be merged.
compctl is suitable and enough in probably 90% of all cases - and with
post-3.1.5 additions even more (am I wrong?) And if you are lucky to have
the case from remaining 10%, the cool new completion stuff is excellent tool
to extend compctl.
What I think about, is two interfaces: compctl->new completion and new
completion->compctl. That is
compctl->new completion
we need a way to call completion functions with environment set up
as expected by new functions. Unfortunately, it is incompatible with
current -K usage (as we need setup different args); do we have any
character else free? :-) O.K., let's assume for now that it is 'K'
new completion->compctl
there is already complist, that can be used to specify completion
directly. Now, what is needed, is the way to tell: "use completion,
defined for this command by compctl, if available". It is much the way,
zle -C works already. Let's call it compcall :-)
The way, in which compctl is called, must use the same convention
(arg list and variables) as new completion. This will provide for nice
recursive calls.
Consider two examples:
compctl -T -K __redirect_handler
function __redirect_handler () {
case $CONTEXT in
redirect )
do completion of redirections
;;
esac
}
This gives easy way to enable completion after redirection without actually
messing up all traditional compctl stuff. Yes, for those who already use -T,
it means some additional work ... But it only one function in this case :-)
Another one is small rewrite of new completion example:
compctl -K __precmd noglob nocorrect exec command builtin
__precmd() {
COMMAND="$1"
shift
(( CURRENT-- ))
if [[ CURRENT -eq 0 ]] then
CONTEXT=command
else
CONTEXT=argument
fi
compcall -c "$1" # -- this calls compctl completion, defined for "$1"
# -- now compctl "sees" only modified arguments,
# -- that will be passed to any functions called
}
I actually feel very uneasy about replacing compctl interface with new
stuff. But it is really a pity to not use it.
Is it hard to implement? This will give you full flexibility of all three
ways to do completion and free choice, which one to use.
/andrej
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
1999-01-25 13:15 Sven Wischnowsky
@ 1999-01-25 13:27 ` Peter Stephenson
1999-01-26 11:52 ` Andrej Borsenkow
0 siblings, 1 reply; 14+ messages in thread
From: Peter Stephenson @ 1999-01-25 13:27 UTC (permalink / raw)
To: zsh-workers
Sven Wischnowsky wrote:
> > I would like to start play with new completion stuff. But I do not want to
> > completely lose all current compctl's I have.
>
> No, currently I'm not sure how to do this.
I wondered about this, too, and while I'm spending most of my time
replying to zsh-workers mail...
I haven't got around to considering the new completion in detail, but
it did occur to me it could be better integrated with the widget
completion I added, i.e. zle -c and zle -C could be made more similar.
Then you should be able to use arbitrary old-style compctls from any
zle function. One way of doing this is using compctl -L to get the
old definition, dumping that straight into a widget with zle -C, and
calling that --- I think that can even be done now with a bit of sed
or equivalent, although -C doesn't handle different completion
functions as well as -c does, which is the main user-visible change
I'd like to make.
However, it might be better to allow a modified zle -C which copies
the widget from an existing compctl --- maybe it should even call it
straight away and delete it, i.e. then you get what Andrej is asking
for in one go. Internally, I don't think that's too hard.
--
Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-25 13:15 Sven Wischnowsky
1999-01-25 13:27 ` Peter Stephenson
0 siblings, 1 reply; 14+ messages in thread
From: Sven Wischnowsky @ 1999-01-25 13:15 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
>
> I would like to start play with new completion stuff. But I do not want to
> completely lose all current compctl's I have. What I would really like, is
> something like
>
> if defined new style completion
> do it
> else
> use compctl completion
>
> Is it possible?
I knew someone would ask for this...
No, currently I'm not sure how to do this. Providing a builtin
(`compold' or whatever) to generate the completions from a compctl
shouldn't be too hard. But if you have a definition for default
completion in the new style stuff you probably want to use compctl's
only if there is one for the command (not -T, -D, ...). On the other
hand some people may want them to be used, or only sometimes, or...
Maybe we should instead provide a function that automatically converts
compctls into definitions for the new completion stuff. Transforming
them by hand as I did at the weekend is very tedious anyway.
But then again, the things in `new-completion-examples' are only
examples. One advantage of the new style is that you can almost
completely define the way completion is done by implementing your own
functions. So we could only write a function to convert to the style
used currently in `new-completion-examples', there is no way to write
a generic function for this. Also, the example stuff still isn't
complete, for example I currently use function return values as a
replacement for `-t', but not all functions do this correctly or
handle those return values.
But for those who only want to play with it: you can probably bind the
new completion to a different key, keeping TAB for the compctl-stuff,
by changing the bindkey-argument in `new-completion-examples'.
Bye
Sven
P.S.: Sorry.
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* zsh-3.1.5-pws-5: mixing "old" and "new" completions?
@ 1999-01-25 12:11 Andrej Borsenkow
0 siblings, 0 replies; 14+ messages in thread
From: Andrej Borsenkow @ 1999-01-25 12:11 UTC (permalink / raw)
To: ZSH workers mailing list
I would like to start play with new completion stuff. But I do not want to
completely lose all current compctl's I have. What I would really like, is
something like
if defined new style completion
do it
else
use compctl completion
Is it possible?
TIA
/andrej
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1999-01-28 16:57 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-28 16:57 zsh-3.1.5-pws-5: mixing "old" and "new" completions? Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
1999-01-28 14:25 Sven Wischnowsky
1999-01-28 11:59 Sven Wischnowsky
1999-01-27 15:21 Sven Wischnowsky
1999-01-27 12:25 Sven Wischnowsky
1999-01-27 15:04 ` Andrej Borsenkow
1999-01-26 13:58 Sven Wischnowsky
1999-01-25 13:15 Sven Wischnowsky
1999-01-25 13:27 ` Peter Stephenson
1999-01-26 11:52 ` Andrej Borsenkow
1999-01-28 7:06 ` Bart Schaefer
1999-01-28 11:28 ` Peter Stephenson
1999-01-28 16:31 ` Bart Schaefer
1999-01-25 12:11 Andrej Borsenkow
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).