GNU bug report logs - #15362
24.1; pcomplete unnecessarily restricts tab-completion entry points

Previous Next

Full log

Message #8 received at 15362 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 15362 <at> debbugs.gnu.org
Subject: Re: bug#15362: 24.1;
 pcomplete unnecessarily restricts tab-completion entry points
Date: Thu, 12 Sep 2013 23:35:38 -0400

> In an erc buffer, I tried to tab-complete a nick: The initial tab completion
> showed many possibilities - I typed an extra character, which should have
> limited it to a small enough number for tab-completion-cycling to kick in...
> but instead TAB just unconditionally completed to the first of the remaining
> candidates, and never offered me the chance to pick any of the others.

> It turns out that pcomplete assumes that the interactive entry point
> (activating command) can only ever be one of a handful of commands,
> and specifically checks for those when deciding whether to enter the
> code path that starts cycling through the remaining completions.

Hmm... but in Emacs-24.1, ERC does not use the `pcomplete' command to do
the completion but completion-at-point (which ends up calling
pcomplete-completions-at-point to get pcomplete to return the set of
completions).

So if cycling is to take place, it should presumably not be done by
pcomplete but by completion-at-point (e.g. obeying
completion-cycle-threshold).

IOW, I don't understand how your patch can fix your problem.
Can you provide a reproducible recipe starting from "emacs -Q"?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.