[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: Dmitry Gutov
Subject: Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness
Date: Sun, 24 Feb 2019 03:03:34 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Thunderbird/66.0

On 19.02.2019 19:10, Stefan Monnier wrote:
So, not only it will only work with some completion tables, but for that
you'll need to introduce "wrong" code in those completion tables.
Since we seem to want to redo completion tables in a major way anyway,

That's no guarantee that it will happen soon or at all, and it will have
to provide some backward compatibility.  And the more hacks we see using
the current system, the more difficult backward compatibility may become.

Very well.

This may be off topic now, but to the best of my recollection this discussion started from the question of the ability to add flex matching to particular completion tables. So that's where I was coming from, FWIW.

But those are orthogonal: the completion style can offer one kind of
sorting and that should work for all completion tables.

Orthogonal indeed, but it should be easier, implementation-wise, to only have one way that defines sorting logic. And also easier to port to the "new system", whenever that comes.

Also also, combining the flex sorting with most other kinds will most likely make the flex sorting hard to notice.

But please don't take this as a strong disagreement. Just an opinion.

Completion tables can also offer their own kind of sorting (and it
should work with all completion styles).

How 'bout:

- Add global sorting config var(s?), to choose which kind of sorting to
   use, which would default to sorting based on "scores first and
   alphabetical after that".

Put those defaults into completion-category-defaults, and you basically have my proposal, isn't that right?

- Let completion-category-overrides specify other choices.

This leaves some questions unanswered, tho:

- What about the distinction between cycle-sort and display-sort?

TBH, I still don't know what's the difference between these. Meanwhile, company-capf has not support for the former, company has different kinds of paging through the popup, and it's working okay.

- Should the new var and new entries in completion-category-overrides
   contain directly sorting functions, or should they contain just the
   name of "sorting styles" with a separate table mapping those styles to
   actual functions (e.g. because a given style like `date` might be
   implemented differently for different completion tables?).

Erm, I'd try the simpler approach first.

If the tables A and B are supposed to be sorted differently, couldn't they return different (but similarly sounding) category names?

Or if that's not generally feasible, what else would the sorting styles dispatch on? The tables themselves?

- Should we allow completion tables to offer several sorting choices?

You mean different completion scores?

If you just mean other kinds of orderings, I think the user will choose via completion-category-overrides.

In any case, in the mean time we can probably just introduce the new
sorting based on "scores first and alphabetical after that" and use it
by default.


I think it'd be annoying for users to have to not only add `flex` to
their completion-styles but also change some sorting option at the same
time before that completion style becomes usable (in most cases, the
current alphabetical sorting works really poorly for `flex`).

Apparently you're proposing to fix that by making the default sorting function to be flex-compatible. That sounds okay.

reply via email to

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