[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minibuffer-completion-help: make sorting of completions customizable?
From: |
T.V. Raman |
Subject: |
minibuffer-completion-help: make sorting of completions customizable? |
Date: |
Tue, 25 Jan 2011 13:47:10 -0800 |
Stefane,
I hear you. I actually spent some time looking through the
completion table code to see where things were getting sorted,
and had to resort to debug-on-entry to figure out that the
sorting happened in minibuffer-completion-help --- so the design
you propose is actually the right one.
But this somewhat simplistic change I proposed lets
me implement google-suggest much better in package g-client which
is part of emacspeak
http://emacspeak.googlecode.com/svn/trunk/lisp/g-client/gweb.el
Basically, Google Suggest gives me the suggestions sorted by
number of hits; getting that list sorted using string-lessp loses basdly.
--
On 1/25/11, Stefan Monnier <address@hidden> wrote:
>> As implemented, minibuffer-completion-help *always* sorts the
>> completion list using string-lessp. This works most of the time,
>> except when the caller has already
>> set up the completions to reflect a desired order. Could the
>> implementation be updated to provide a setting that could be let
>> bound by the caller?
>
> I've resisted it, because I think the right way is for the
> completion-table itself to provide this function (the difference becomes
> significant when completing things that are made of various parts, some
> of which may be sorted one way and others some other way), but this is
> a much more significant change.
>
> It basically means extending the `boundaries' method into a generic
> `meta-info' method that will include not just boundaries but also
> sort-order, type (e.g. it can tell whether you're completing buffers,
> files, or something else, which can then be associated to a config
> variable to use different completion-styles for different types of
> data), (un)quoting rules (needed for reliable completion of file names
> in *shell* buffers), a different separator than \n to use in the
> *Completions* buffer, ...
>
>
> Stefan
>