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: complist doc, and some small problems
Date: Thu, 24 Jun 1999 11:55:16 +0200 (MET DST)	[thread overview]
Message-ID: <199906240955.LAA31432@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Thu, 24 Jun 1999 10:41:34 +0200


Peter Stephenson wrote:

> I still have some problems, which by now are rather minor.
> 
> 1.  Actually, this one isn't minor, but I just discovered it trying to get
>     the others to show up with zsh -f.  Any completion (!) with zsh -f
>     gives a core dump at the top of printfmt() in zle_tricky.c.  It seems
>     the fmt passed is invalid.  Looking back, it seems ilistmatches is
>     calling printfmt with `e' which points to a null string.

Forgot to change the second argument of ilistmatches().

> 2.  I finally tracked down my problems with spaces appearing after a
>     menu item when selection was used.  It happens if you
>     - load new completion
>     - setopt menucomplete
>     - use menu-select, highlight a directory
>     - abort with ^G
>     - hit <TAB> again
>     - the key point is I'm using _oldlist, so that this sets
>       compstate[old_list]=keep to use the existing list.
>     - The list items which aren't directories all have a space after them.

That's the compstate[insert] behaviour I described when I implemented
it. I'm pretty sure I asked if this space should be there or not at
the time, and here seems to be the answer to that question.
So the patch makes the space not be inserted in this case.
Btw. I was thinking about cases where one selects one match from those 
generated and wants to insert only that -- leaving completion. In such 
a case the space is the right thing, so I may enhance the use of the
insert key some day to be able to select both.

>       Also with zsh -g it seems to be beeping all the time.  This seems to
>       be tied to old_list, too, presumably with LISTBEEP taking effect
>       too often.  I've tried this with an old version, and it doesn't
>       seem to be related to my feeping changes, nor the other bug I've
>       just mentioned.

That test at the end of do_ambiguous() is one of the things I started
to dislike long ago...

> 3.  Also, the documentation advertises that undo works to remove a
>     completion.  If this means it's supposed to work invoking undo
>     to remove a completion while menu-select is still active, it doesn't.
>     It works after you've aborted, of course.

Hm, works for me (note: only completions inserted with
accept-and-{menu-complete,hold}).

Bye
 Sven

diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Thu Jun 24 11:08:17 1999
+++ Src/Zle/complist.c	Thu Jun 24 11:22:47 1999
@@ -623,14 +623,14 @@
 domenuselect(Hookdef dummy, Chdata dat)
 {
     Cmatch **p;
-    Cmgroup amatches = dat->matches, *pg;
+    Cmgroup *pg;
     Thingy cmd;
     Menustack u = NULL;
     int i = 0;
     char *s;
 
     if (getcols(NULL) || (dummy && (!(s = getsparam("SELECTMIN")) ||
-				    dat->num < atoi(s))))
+				    (dat && dat->num < atoi(s)))))
 	return 1;
 
     selectlocalmap(mskeymap);
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Jun 24 11:08:19 1999
+++ Src/Zle/zle_tricky.c	Thu Jun 24 11:45:09 1999
@@ -7477,7 +7477,8 @@
     if (isset(LISTBEEP))
 	ret = 1;
     if (uselist && (usemenu != 2 || (!showinglist && !oldlist)) &&
-	(!showinglist || (usemenu == 3 && !oldlist)) &&
+	((!showinglist && (!listshown || !oldlist)) ||
+	 (usemenu == 3 && !oldlist)) &&
 	(smatches >= 2 || (compforcelist && *compforcelist)))
 	showinglist = -2;
     return ret;
@@ -7652,7 +7653,7 @@
 	    inststrlen(&(m->autoq), 1, 1);
 	    minfo.insc++;
 	}
-	if (!menucmp) {
+	if (!menucmp && usemenu != 3) {
 	    inststrlen(" ", 1, 1);
 	    minfo.insc++;
 	    if (minfo.we)
@@ -7897,7 +7898,7 @@
 
 /**/
 int
-ilistmatches(Hookdef dummy, Cmgroup amatches)
+ilistmatches(Hookdef dummy, Chdata dat)
 {
     Cmgroup g;
     Cmatch *p, m;
@@ -8150,6 +8151,7 @@
     struct cmgroup dg;
     int vl = validlist, sm = smatches;
     char *oclp = complastprompt;
+    Cmgroup am = amatches;
 
     if (listshown)
 	showagain = 1;
@@ -8159,7 +8161,9 @@
     validlist = 1;
     memset(&dg, 0, sizeof(struct cmgroup));
     dg.ylist = (char **) makearray(l, 1, &(dg.lcount), NULL);
-    ilistmatches(NULL, &dg);
+    amatches = &dg;
+    ilistmatches(NULL, NULL);
+    amatches = am;
 
     validlist = vl;
     smatches = sm;

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


             reply	other threads:[~1999-06-24  9:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-24  9:55 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-06-24  8:41 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=199906240955.LAA31432@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).