bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Dani Moncayo]

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

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Stefan Monnier]

> 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

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Dani Moncayo]

> 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

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Stefan Monnier]

> 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

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Stefan Monnier]

>> 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

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Dani Moncayo]

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

Confirmed.

Thanks a lot.

-- 
Dani Moncayo

bug#10963: 24.0.94; `dabbrev-completion' and `completion-cycle-threshold'

[Stefan Monnier]

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

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

> Thanks a lot.

> -- 
> Dani Moncayo