[Top][All Lists]

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

Re: VOTE: Changing completions-common-part face's default

From: Dmitry Gutov
Subject: Re: VOTE: Changing completions-common-part face's default
Date: Sat, 9 Nov 2019 01:38:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 07.11.2019 17:54, João Távora wrote:

I don't understand this. flex is deterministic. Which part exactly
cannot be trusted?

Precisely, I thought you wouldn't.  Flex is designed to let you
smash some keys that vaguely fit into your intended completion,
or at least enter the spectrum where you kinda remember the
completion to be.  Some Flex implementations even allow you
to reverse keys so that when my lazy hand types "lyaz" it still
maches "the-lazy-fox".  When scoring, flex makes some mistakes
(depending on how good/sophisticated the scoring algorithm is).
So it's important to understand why the suggestion is at that

Important for the completion style author mostly, though. It's not like a regular user could do something about it. Isn't that right?

You might think this double-checking "wastes your synapses".
It's a bargain indeed. it doesn't work for everyone. But it's
nonsensical to have flex with that crucial part crippled.

So that in the case of "lzy", I can choose between "the-lazy-fox"
and "le-zorg-yorg". Both can be reasonable intentions at different
points in time.

Okay, but... our particular flex implementation doesn't do the free-form matching like that. Do you intend to extend it in that direction?

I'm not sure I can agree with that. Company highlights the common part,
  not simply whatever part completion style chooses to highlight.

If it's somehow so important for company to highlight always the
common part, we can put a 'this-is-part-of-the-common-part' prop
there, too, for company's benetif.  Sniffing for faces, the way I
implemented it, was really a low-hanging-hack anyway.  The patch
to sniff for a property is trivial.

So I wouldn't worry about that.

Okay. That would still mean two different execution flows.

By the way, doesn't this requirement for company clash with your
view of the other Emacs frontends?  Why is it important for company
to always highlight the common part, but not for Emacs's icomplete,
or *Completions*?

Because its main frontend is a popup which looks and, to an extent, behaves like the completion popups in other editors. So it's really expected to behave more or less the same. company-tng also implements one of the simplified workflows from the other editors.

reply via email to

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