[Top][All Lists]

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

Re: BIKESHED: completion faces

From: Dmitry Gutov
Subject: Re: BIKESHED: completion faces
Date: Wed, 6 Nov 2019 00:22:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 05.11.2019 18:31, João Távora wrote:

I would rather say that setting a change to Emacs defaults as a bar to
clear is counter-productive.  And frequently demotivational.

Emacs has a problem of trying to accommodate too many workflows in the same UI. The result sometimes turns out to not be optimal for any of them. I'm trying to avoid this problem here.

Best solutions arise when we can understand exactly what it is that
people like about current defaults, and can accomodate that specific
preference in a new system, so that they barely notice it.

That sounds like a change in defaults, though.

 > > So what you are proposing with the "do-nothing" approach amounts to a
 > > lose-lose.
 > Have you read my other idea, then?

Yes.  A new face, I presume.  And a generic attempt to figure a good
place to apply it for every possible style.

Yup. Okay.

By the way, every other proposal in this thread, is trivial.  Only yours
adds significant new logic.  Not saying that's bad, but it's a drawback
the others don't have.

Your proposal would add a different styling for different completion styles. That would require some code as well, likely a similar amount.

 > > The former part can be improved in flex, the latter can't: it's
 > > intrinsic to the technique.
 > All can be improved, just with varying degrees of difficulty.

Sure, a pig and a large enough rocket...

Is that because the current completion system is not optimal for flex?

 > But there
 > are other techniques, like limiting the number of matches shown at a
 > time.

Sure, I was talking about parts of 'flex' itself.  There are of course
improvements outside it (even besides the large enough rocket).  Say,
generators and lazy evaluation in completions could indeed be useful.
But that's a possibly big big change in minibuffer.el and, much worse,
all its users.

minibuffer.el will likely need changes, yes.

But as for "outside"... I was thinking of a data structure where you would accumulate completions in a sorted tree, of sorts. And, when a new one is added, if the maximum allowed number of completions has been reached, the least-scored one is evicted. Or we do the eviction at the end, whatever.

Point is, we end up with a limited-size list containing only the best matches. That wouldn't avoid performance problems with the flex algorithm itself, but any subsequent bottlenecks would not be triggered.

This approach really relies on good and fast scoring, though.

 > One just has to make sure not to cache the result improperly.

Cache invalidation, one of the "hard" problems in computing.  Buying
trouble, I say.

Let us not forget that we're competing with other editors who routinely show off flex matching and somehow deal with accompanying performance problems.

 > As you can imagine, IMHO this part "making sense" is less important than
 > the consistency in highlighting.

It's only "inconsistent" if you you refuse to accept that concepts such
as "relevance" or "emphasis" are more important the specifics of the
matching technique implemented.

I'm more interested in highlighting being consistent and relevant to whatever the next action the user should perform.

 > > What I'm proposing is no different from say, mode-line-emphasis, which
 > > lisp/man.el and lisp/vc/vc-dispatcher.el use in "two wildly different
 > > things".
 > Here's an example. When the input is one char, how will you figure out
 > what the highlighting in the *Completions* buffer means?

OK, let's take that example.  It depends on whether I'm using a "prefix"
or "flex" style.  But even if I'm using them both together, or I'm such
a doofus that I don't remember anymore:

1. If I see that "one char" being matched in the middle of a lot of
completions, I know what it means: I'm using 'flex' and/or 'substring'
and that is the character that's matched.

That implies an extra thinking step. Whatever synapses take part it that, my brain could've used for something else.

2. If I see that every completion has its second character highlighted,
I know I'm using prefix.

_Probably_, but you won't know for sure until you also read those characters. There could be just 2-3 completions anyway, so you wouldn't get the picture at a glance.

This is discounting the fact that I probably want to know and control
whether I'm using flex or prefix anyway.

But you probably won't. Or other users won't. That's the idea behind completion-styles anyway. If you are the "controlling" type anyway, you would probably customize faces anyway.

And here's also the argument for waiting until the default changes: because if the new default is (setq completion-styles '(flex)), then the dilemma we have before us now is easily dismissed.

It's also discounting the fact that in 2. prefix completion should, IMO,
use my proposed "emphasis" face to highlight the first -- not the second
-- character. I've argued before that no loss of explanatory power would
materialize from this.

No loss of explanatory power indeed. The only argument we've made is that it'll probably be annoying.

Finally it also dicounts the fact that yours is an extremely contorted
example.  I almost never want completions for stuff that contains or
starts with a specific single character.  Flex/substring becomes really
useful when you type 2-4 characters, and you are made visually aware of
the subsequence they matched within the candidate.

But okay, should those really be emphasized more than "first difference"? The latter tells the user what they might want to type next. The former is mostly useful to see "why am I getting these completions at all" or they're bored and want to study the completion logic or something. In other words, less frequent situations than simply typing code.

reply via email to

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