GNU bug report logs - #10963
24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10963 in the body.
You can then email your comments to 10963 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'
Date: Tue, 6 Mar 2012 23:18:19 +0100

Recipe from "emacs -Q":

1. Eval: (setq completion-cycle-threshold 4)

2. Type: foo1 RET foo2 RET foo3 RET

3. Type: foo C-M-/

--> This "foo" expands to "foo3" (the first completion candidate -
ok), although the echo area shows a "Scanning for dabbrevs..." message
which remains there forever, until I send another command.  This is
confusing, because the message doesn't change even after that
"scanning" has ended.

4. Type: C-M-/

--> Expected result: the first completion candidate picked up in step
#3 ("foo3") is replaced with the next one ("foo2").
--> Observed result: the echo area shows the message
[dabbrev-completion: No dynamic expansion for "foo3" found] and thus
I'm unable to cycle through the completion candidates.


-- 
Dani Moncayo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10963 <at> debbugs.gnu.org
Subject: Re: bug#10963: 24.0.94;
	`dabbrev-completion' and `completion-cycle-threshold'
Date: Mon, 12 Mar 2012 09:09:41 -0400

> Recipe from "emacs -Q":
> 1. Eval: (setq completion-cycle-threshold 4)
[...]
> 4. Type: C-M-/
> --> Expected result: the first completion candidate picked up in step
> #3 ("foo3") is replaced with the next one ("foo2").
> --> Observed result: the echo area shows the message
> [dabbrev-completion: No dynamic expansion for "foo3" found] and thus
> I'm unable to cycle through the completion candidates.

I believe this is now fixed in the trunk, please confirm,


        Stefan

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10963 <at> debbugs.gnu.org
Subject: Re: bug#10963: 24.0.94;
	`dabbrev-completion' and `completion-cycle-threshold'
Date: Mon, 12 Mar 2012 14:41:36 +0100

> I believe this is now fixed in the trunk, please confirm,

Thanks, Stefan.

It mostly works, but there is one detail that seems to need a fix:
Consider this scenario:
1. M-: (setq completion-cycle-threshold 4) RET
2. foo1 RET foo2 RET foo3 RET foo

Now, repeated `C-M-/' commands cycle like this:
  foo3/foo1/foo2

but repeated `M-/' commands cycle like this:
  foo3/foo2/foo1

I think that the cycling order should be equal in both cases, and IMO
the right order is the one followed by `M-/'  (ISTR that I've read
something about this in the manual, but right now I can't find the
place).

-- 
Dani Moncayo

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10963 <at> debbugs.gnu.org
Subject: Re: bug#10963: 24.0.94;
	`dabbrev-completion' and `completion-cycle-threshold'
Date: Mon, 12 Mar 2012 12:00:58 -0400

> It mostly works, but there is one detail that seems to need a fix:
> Consider this scenario:
> 1. M-: (setq completion-cycle-threshold 4) RET
> 2. foo1 RET foo2 RET foo3 RET foo

> Now, repeated `C-M-/' commands cycle like this:
>   foo3/foo1/foo2

> but repeated `M-/' commands cycle like this:
>   foo3/foo2/foo1

> I think that the cycling order should be equal in both cases, and IMO
> the right order is the one followed by `M-/'  (ISTR that I've read
> something about this in the manual, but right now I can't find the
> place).

That will require more changes: the current cycling order of C-M-/ is
completely different from the one of M-/ because the completion table
used is an obarray (a sort of hash-table), so dabbrev's ordering is
completely lost, and after that the completion code uses its default
sorting (which gives preference to shorter completions, which in this
case makes no difference).  So we'll need to stop using an obarray, and
to pass an ad-hoc sorting function to the completion code.


        Stefan

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10963 <at> debbugs.gnu.org
Subject: Re: bug#10963: 24.0.94;
	`dabbrev-completion' and `completion-cycle-threshold'
Date: Mon, 12 Mar 2012 16:21:21 -0400

>> It mostly works, but there is one detail that seems to need a fix:
>> Consider this scenario:
>> 1. M-: (setq completion-cycle-threshold 4) RET
>> 2. foo1 RET foo2 RET foo3 RET foo

>> Now, repeated `C-M-/' commands cycle like this:
>> foo3/foo1/foo2

>> but repeated `M-/' commands cycle like this:
>> foo3/foo2/foo1

>> I think that the cycling order should be equal in both cases, and IMO
>> the right order is the one followed by `M-/'  (ISTR that I've read
>> something about this in the manual, but right now I can't find the
>> place).

> That will require more changes: the current cycling order of C-M-/ is
> completely different from the one of M-/ because the completion table
> used is an obarray (a sort of hash-table), so dabbrev's ordering is
> completely lost, and after that the completion code uses its default
> sorting (which gives preference to shorter completions, which in this
> case makes no difference).  So we'll need to stop using an obarray, and
> to pass an ad-hoc sorting function to the completion code.

OK, I think it's fixed now, can you confirm?


        Stefan

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10963 <at> debbugs.gnu.org
Subject: Re: bug#10963: 24.0.94;
	`dabbrev-completion' and `completion-cycle-threshold'
Date: Mon, 12 Mar 2012 21:30:19 +0100

> OK, I think it's fixed now, can you confirm?

Confirmed.

Thanks a lot.

-- 
Dani Moncayo

Message #25 received at 10963-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 10963-done <at> debbugs.gnu.org
Subject: Re: bug#10963: 24.0.94;
	`dabbrev-completion' and `completion-cycle-threshold'
Date: Tue, 13 Mar 2012 08:43:45 -0400

>>>>> "Dani" == Dani Moncayo <dmoncayo <at> gmail.com> writes:

>> OK, I think it's fixed now, can you confirm?
> Confirmed.

> Thanks a lot.

> -- 
> Dani Moncayo

Previous Next

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