zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: matching in the new completion system
Date: Wed, 28 Apr 1999 09:44:08 +0200 (MET DST)	[thread overview]
Message-ID: <199904280744.JAA16859@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Tue, 27 Apr 1999 21:37:59 -0700


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@informatik.hu-berlin.de


             reply	other threads:[~1999-04-28  7:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-28  7:44 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-04-26 13:39 Sven Wischnowsky
1999-04-26 13:25 ` Peter Stephenson
1999-04-28  4:37 ` Bart Schaefer
1999-04-14  8:31 Sven Wischnowsky
1999-04-14  6:19 Sven Wischnowsky
1999-04-14  7:50 ` Peter Stephenson
1999-04-13 13:18 Sven Wischnowsky
1999-04-13 14:39 ` Peter Stephenson
1999-04-14  6:15   ` Andrej Borsenkow
1999-04-13 10:39 Sven Wischnowsky
1999-04-12  9:07 Sven Wischnowsky
1999-04-13  9:56 ` Andrej Borsenkow
1999-04-13 12:46 ` Andrej Borsenkow
1999-04-13 12:35   ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199904280744.JAA16859@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).