* bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'
@ 2012-03-06 22:18 Dani Moncayo
2012-03-12 13:09 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Dani Moncayo @ 2012-03-06 22:18 UTC (permalink / raw)
To: 10963
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
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'
2012-03-06 22:18 bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold' Dani Moncayo
@ 2012-03-12 13:09 ` Stefan Monnier
2012-03-12 13:41 ` Dani Moncayo
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2012-03-12 13:09 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10963
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'
2012-03-12 13:09 ` Stefan Monnier
@ 2012-03-12 13:41 ` Dani Moncayo
2012-03-12 16:00 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Dani Moncayo @ 2012-03-12 13:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10963
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'
2012-03-12 13:41 ` Dani Moncayo
@ 2012-03-12 16:00 ` Stefan Monnier
2012-03-12 20:21 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2012-03-12 16:00 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10963
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'
2012-03-12 16:00 ` Stefan Monnier
@ 2012-03-12 20:21 ` Stefan Monnier
2012-03-12 20:30 ` Dani Moncayo
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2012-03-12 20:21 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 10963
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-03-13 12:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-06 22:18 bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold' Dani Moncayo
2012-03-12 13:09 ` Stefan Monnier
2012-03-12 13:41 ` Dani Moncayo
2012-03-12 16:00 ` Stefan Monnier
2012-03-12 20:21 ` Stefan Monnier
2012-03-12 20:30 ` Dani Moncayo
2012-03-13 12:43 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).