Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: matching in the new completion system
- X-seq: zsh-workers 6129
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: matching in the new completion system
- Date: Wed, 28 Apr 1999 09:44:08 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Tue, 27 Apr 1999 21:37:59 -0700
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> On Apr 26, 3:39pm, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: matching in the new completion system
> }
> } All this is a bit like saying `hey, compadd, this is the list of
> } strings I'm working on (the array) and here are the parts of the
> } strings you should try to match (the words), modify the list for me'.
>
> I thought I was following this, until I got to (the words). Could you
> please give an example?
I'll describe how this is used in _path_files (praeter propter):
We have an array, say `matches' (in _path_files it has another name,
but...), containing all the possible completions we have collected
until now. Now we need to match only parts of the strings, not the
whole strings. Getting these parts is easy (or at least possible)
using a parameter expansion on `matches'. So, we just do:
compadd -D matches - ${matches##*/}
(if the `parts' are pathname components), after setting up PREFIX and
SUFFIX. With that, compadd will modify our list of matches in place and
we can still use the full power of parameter expansion to describe
what we want to have matched. I /think/ this makes it powerful enough
for most cases: if you collect possible completions, you will use an
array in most cases anyway, and, from another point of view, if you
have a problem where `compadd -D' might be useful, you should always
be able to use an array to take advantage of it.
In fact, this is at least as powerful as the other thing I described
(an option to make -[ps] be taken as descriptions what the prefixes
and suffixes are, which would be given in the words). And it's
easy to implement and fast.
Ok?
> A mostly-unrelated one: Now that you have the addmatches() parameters
> broken out into a struct, could you attach a comment to each line to
> explain what the field represents?
Oops. I wanted to do that anyway, seems I forgot it in the end.
Bye
Sven
diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h Tue Apr 27 11:03:33 1999
+++ Src/Zle/comp.h Wed Apr 28 09:26:51 1999
@@ -275,24 +275,24 @@
typedef struct cadata *Cadata;
struct cadata {
- char *ipre;
- char *isuf;
- char *ppre;
- char *psuf;
- char *prpre;
- char *pre;
- char *suf;
- char *group;
- char *rems;
- char *remf;
- char *ign;
- int flags;
- int aflags;
- Cmatcher match;
- char *exp;
- char *apar;
- char *opar;
- char *dpar;
+ char *ipre; /* ignored prefix (-i) */
+ char *isuf; /* ignored suffix (-I) */
+ char *ppre; /* `path' prefix (-p) */
+ char *psuf; /* `path' suffix (-s) */
+ char *prpre; /* expanded `path' prefix (-W) */
+ char *pre; /* prefix to insert (-P) */
+ char *suf; /* suffix to insert (-S) */
+ char *group; /* name of the group (-[JV]) */
+ char *rems; /* remove suffix on chars... (-r) */
+ char *remf; /* function to remove suffix (-R) */
+ char *ign; /* ignored suffixes (-F) */
+ int flags; /* CMF_* flags (-[fqn]) */
+ int aflags; /* CAF_* flags (-[QUa]) */
+ Cmatcher match; /* match spec (parsed from -M) */
+ char *exp; /* explanation (-X) */
+ char *apar; /* array to store matches in (-A) */
+ char *opar; /* array to store originals in (-O) */
+ char *dpar; /* array to delete non-matches in (-D) */
};
/* Flags for special parameters. */
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author