[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score,

From: Drew Adams
Subject: RE: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness
Date: Mon, 11 Mar 2019 18:10:01 -0700 (PDT)

> While possible, I think in practice it will require using just one
> combined sorting function, instead of passing the list of completions
> though several independent sorting functions. Although please feel free
> to prove me wrong, because I like the list-of-functions approach.

(Caveat: I haven't been following this thread.)

Just thought I'd mention how I like to handle a
suite of sorting predicates for dealing with things,
including completion candidates, that may or may not
be comparable to varying degrees or in different ways.

When two such cannot be compared using the preferred
sorting predicate then the next-preferred predicate
is tried, and so on.

This page explains the approach:


The basic idea is to allow the use of both ordinary
two-valued (true/false) predicates and three-valued
(true/false/dunno) predicates, combining the latter
in a chain.

I use this in Bookmark+, for example, to sort
candidates that are bookmarks of different kinds.

Different kinds of bookmarks have different things
in common - fields that can be compared, for example.
They can also have fields that might not be comparable.

Depending on the purpose of a given sort, users can
want to use different comparison-predicate suites,
that is, apply different sets of predicates in
different orders of priority.

Variable `bmkp-sort-comparer' holds the current
comparison suite, which is used for sorting.

The variable value is one of the following:

* `nil', meaning no sorting;
* an ordinary 2-valued predicate; or
* a list of 3-valued predicates, optionally followed
  by a single 2-valued "fallback" predicate.

If the first 3-valued predicate in the list can
compare the two given bookmarks then it decides.  If
not then the second 3-valued predicate is tried, and
so on.  If none of the 3-valued predicates can decide
then the fallback, 2-valued predicate decides.

It's easy to combine 3-valued predicates  They
decide, themselves, whether they are applicable
to their two given arguments.  If not, they just
opt out of the deciding.

Variable `bkmp-sort-comparer' is described here:


reply via email to

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