zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@sunsite.dk
Cc: 486785@bugs.debian.org
Subject: Re: Bug#486785: tab completion broken
Date: Sun, 6 Jul 2008 20:51:09 +0100	[thread overview]
Message-ID: <20080706205109.7e91a057@pws-pc> (raw)
In-Reply-To: <20080630213522.5fe843de@pws-pc>

On Mon, 30 Jun 2008 21:35:22 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> I'm now a little worried it should be going into menu completion at this
> point even without the option being set; the documentation for
> _approximate says "the completer will normally start menu completion"
> but in the test case above it doesn't.

Comparing with 4.3.4 confirms this problem.

> I'm not clear how it starts menu
> completion, since _approximate only mentions menu completion in a
> comment at the top, implying it is done somewhere within that function
> that I can't find.

It comes from the combination of

  compstate[pattern_match]='*'

in _approximate and something I haven't bothered to track down setting

  compstate[insert]=menu

somewhere else.  The need for the combination, which I don't really
understand, also underlies what's going on in the code.

See the comment in the fix.  I think I've said quite enough there.

Please do report any remaining problems, since I've at least half
convinced myself I've fixed it, however unlikely that seems.

Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.94
diff -u -r1.94 compcore.c
--- Src/Zle/compcore.c	6 May 2008 16:01:19 -0000	1.94
+++ Src/Zle/compcore.c	6 Jul 2008 19:38:17 -0000
@@ -2277,6 +2277,45 @@
 			haspattern = 1;
 		}
 	    }
+	} else {
+	    /*
+	     * (This is called a "comment".  Given you've been
+	     * spending your time reading the completion time, you
+	     * may have forgotten what one is.  It's used to deconfuse
+	     * the poor so-and-so who's landed up having to maintain
+	     * the code.)
+	     *
+	     * So what's going on here then?  I'm glad you asked.  To test
+	     * whether we should start menu completion, we test whether
+	     * compstate[insert] has been set to "menu", but only if we found
+	     * patterns in the code.  It's not clear to me from the
+	     * documentation why the second condition would apply, but sure
+	     * enough if I remove it the test suite falls over.  (Testing
+	     * comppatmatch at the later point doesn't work because compstate
+	     * is likely to have been reset by the point we actually insert
+	     * the completions, after all functions have exited; this is at
+	     * least part of the problem.)  In the present case, we are not
+	     * doing matching on the code because all the clever stuff has
+	     * been done over our heads and we've simply between told to
+	     * insert it.  However, we still need to take account of ambiguous
+	     * completions properly.  To do this, we rely on the caller to
+	     * pass down the same prefix/suffix with the patterns that we
+	     * would get if we were doing matching, and test those for
+	     * patterns.  This gets us out of the hole apparently without
+	     * breaking anything.  The particular case where this is needed is
+	     * approximate file completion: this does its own matching but
+	     * _approximate still sets the prefix to include the pattern.
+	     */
+	    if (comppatmatch && *comppatmatch) {
+		int pflen = strlen(compprefix);
+		char *tmp = zhalloc(pflen + strlen(compsuffix) + 1);
+		strcpy(tmp, compprefix);
+		strcpy(tmp + pflen, compsuffix);
+		tokenize(tmp);
+		remnulargs(tmp);
+		if (haswilds(tmp))
+		    haspattern = 1;
+	    }
 	}
 	if (*argv) {
 	    if (dat->pre)


-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/


  parent reply	other threads:[~2008-07-06 19:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-19 21:15 Clint Adams
2008-06-20  0:00 ` martin f krafft
2008-06-22 22:23 ` Peter Stephenson
2008-06-27  9:15   ` Clint Adams
2008-06-30 20:35   ` Peter Stephenson
     [not found]     ` <20080701162625.GA3031@piper.oerlikon.madduck.net>
2008-07-03  2:56       ` Clint Adams
2008-07-06 19:51     ` Peter Stephenson [this message]
2008-07-07  1:09       ` Richard Hartmann
2008-07-07  8:15       ` Frank Terbeck

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=20080706205109.7e91a057@pws-pc \
    --to=p.w.stephenson@ntlworld.com \
    --cc=486785@bugs.debian.org \
    --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).