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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10963 <at> debbugs.gnu.org
Subject: 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

Previous Next

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