zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: zsh-workers@sunsite.dk
Subject: Re: Strange _values completion on accept-and-menu-complete and menu selection
Date: Sat, 11 Dec 2004 13:05:58 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.61.0412111229070.16206@toltec.zanshin.com> (raw)
In-Reply-To: <200412111311.27916.arvidjaar@mail.ru>

On Sat, 11 Dec 2004, Andrey Borzenkov wrote:

> Apparently it does not work any more for _values; I presume it did work 
> once because _urpmi completion includes _values usage in question.

Looking at the code, I can't see any way it ever worked.  There's been no 
interesting change anywhere near or beyond (in the function call sense) 
the point where complist.c handles accept-and-menu-complete.

The problem is that accept_last() is called, which eventually always calls 
iremovesuffix(' ', 1).  If "compadd -R" had been used, the suffix function
would be called and could subvert the behavior of iremovesuffix(), but as
it stands the suffix is always zapped.

The deeper problem seems to be that the complist module doesn't really 
know anything about compvalues; e.g., as far as complist is concerned it's 
selecting among shell words, not from a set of values that are part of a 
word.  That it comes as close as it does to working is serendipitous.

A fix seems to be something in the direction of this pseudo-patch (do NOT
apply it as-is) to compresult.c, but I don't know how to get the boolean
value for "we are not completing values from compvalues" at this location.

@@ -1241,16 +1241,19 @@
 	lastbrbeg->str[l + 1] = '\0';
     } else {
 	int l;
+	int rem = /* We are not completing values from compvalues */;
 
 	cs = minfo.pos + minfo.len + minfo.insc;
-	iremovesuffix(' ', 1);
+	if (rem)
+	  iremovesuffix(' ', 1);
 	l = cs;
 	cs = minfo.pos + minfo.len + minfo.insc - (*(minfo.cur))->qisl;
 	if (cs < l)
 	    foredel(l - cs);
 	else if (cs > ll)
 	    cs = ll;
-	inststrlen(" ", 1, 1);
+	if (rem)
+	  inststrlen(" ", 1, 1);
 	minfo.insc = minfo.len = 0;
 	minfo.pos = cs;
 	minfo.we = 1;


  reply	other threads:[~2004-12-11 21:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-11 10:11 Andrey Borzenkov
2004-12-11 21:05 ` Bart Schaefer [this message]
2004-12-12 16:15   ` Andrey Borzenkov
2004-12-12 17:51     ` Bart Schaefer
2004-12-12 21:06       ` Andrey Borzenkov
2004-12-12 21:44         ` Bart Schaefer
2004-12-13 10:43           ` Peter Stephenson
2004-12-25 17:32           ` Andrey Borzenkov

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=Pine.LNX.4.61.0412111229070.16206@toltec.zanshin.com \
    --to=schaefer@brasslantern.com \
    --cc=arvidjaar@mail.ru \
    --cc=zsh-workers@sunsite.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).