emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]