From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: BIKESHED: completion faces Date: Tue, 5 Nov 2019 16:31:14 +0000 Message-ID: References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> <87h83ipoi0.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a3c73a05969bf6b6" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="257341"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 05 17:32:15 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iS1kc-0014mb-4Z for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2019 17:32:14 +0100 Original-Received: from localhost ([::1]:46128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iS1ka-0000hK-NR for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2019 11:32:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58395) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iS1jt-0000Ko-Q2 for emacs-devel@gnu.org; Tue, 05 Nov 2019 11:31:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iS1jr-0004xO-Nz for emacs-devel@gnu.org; Tue, 05 Nov 2019 11:31:29 -0500 Original-Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]:37666) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iS1jr-0004x0-FT for emacs-devel@gnu.org; Tue, 05 Nov 2019 11:31:27 -0500 Original-Received: by mail-io1-xd34.google.com with SMTP id 1so23335113iou.4 for ; Tue, 05 Nov 2019 08:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lYQ3ewggQJawCCe96EFgpKb65B1IGA3QT11ffYyDU0A=; b=TK4w/qQLSfurpL6HUzUKh+q7xjw0w6y2WA2ggb6AAAON6Le9t9kPpouRQzPx/y3Pcn U8QAC1ZrptXIltU0e1xvjZPw6ppPj+kmoRk1fYd4i/nYkj5lPb25OQLM3la2VXBbdzEH mqg6qJU6fuu6G6KhOedKGRSHsUbAWk8mRge1YHxeKriqcKmjlhGUUPbzH4SM5EFPuxg3 QrXF6jBcdMou2tJsQOE38JtKnb+lzOKVzORnrLNY1h0oMqw8vvu8tG4JyFBVMSLXuN9n aX3qRRuEfqvk/89flmEaNTnEo2zyzz+/T+R7WOiGYVHgyhlX+SZjSTcTE2UP8TK6Mauy JH+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lYQ3ewggQJawCCe96EFgpKb65B1IGA3QT11ffYyDU0A=; b=QGjudTZnwVttdcN/6wCWaDWS1BgU9/TvUaJGqzz1bam+0zREDlkMuOpqNVVXL2C3n/ efkRgAlX29zlu2uOmMZFPhaxuXIocgzC33AIKBx4IsYWtCKs/MvJMAILO5zXyNLv7FrL 9ejWWqMBcg+GBu5vMbW8k58aWox4qmjUFR8i0gZ9H9W8UMVn8M96jgF/ZOHHROlp/ac3 i0lv47jlsGhjXADEQYRl4WT8jx0+i4HVN0xD1kxqSurMHutQr8cKBTTDTcLlO3TII9Vv HU44lZPyGSIAQJlQ0cWahH4Muzs23B9wCmoJmqZZpgBL2+0UzNLJXHHiDAGn+MmVX4iS YHiw== X-Gm-Message-State: APjAAAXVfa9Te05o6Yb1NiDXCGRVkosi63L85GUxfRvIitMQKUdbTz1i 5AH1GPIn9bUmbs7cu85Rwb5bX/Gm7pRpMcD+arM= X-Google-Smtp-Source: APXvYqzoOM3PXVpZA7JGTuAmq9uwHup8u/HWcpfEDLbNXJLL2g/kUqRiijQUtWUT8s6mHCKfpPpv98yIMimT/6mv/Xg= X-Received: by 2002:a5d:8b85:: with SMTP id p5mr8302218iol.9.1572971485577; Tue, 05 Nov 2019 08:31:25 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d34 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241808 Archived-At: --000000000000a3c73a05969bf6b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [sorry for the duplicate email Dmitry, I forgot to cc emacs-devel] On Tue, Nov 5, 2019 at 2:57 PM Dmitry Gutov wrote: > > On 05.11.2019 13:10, Jo=C3=A3o T=C3=A1vora wrote: > > >> We agree, yes. Although I'm more in favor of changing the defaults, > > > > So are we all, but that's a non-starter. I'm sure everyone here thinks > > "their" settings should be the defaults. > > The implication would be that trying to improve the defaults is useless > or hopeless. I disagree. I would rather say that setting a change to Emacs defaults as a bar to clear is counter-productive. And frequently demotivational. 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. > > 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. The patch is a bit too large for reviewing right now. 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. > > 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... > 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. > 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. > > But in matching systems like icomplete-mode > > it isn't a problem (in terms of responsiveness) because icomplete-mode > > has a while-no-input trick in it. Perhaps so should company (presuming > > that's what you are using). > I'm trying it out with 'M-x completion-at-point'. Then the slowness you're experiencing stems from the fact that that is blocking, eager, interface, i.e. it's not a "kink" in flex. > >> I disagree that it's a significant problem, though. Enabling 'flex' is > >> one line. Customizing the face is just another line. > > Isn't true for custom.el users. And it just doesn't make sense that to > > enable "good" flex matching you have to go touch two places. We're > > discussing usability, after all. > 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. > >> highlighting would be applied to two fairly different things. > > > > So is 'shadow' and 'bold' and many more. It all has to do with how you > > design the semantics, something that is our prerrogative. > > I wouldn't use 'shadow' or 'bold' for the new face either. Nothing that > matches completions-common-part of completions-first-difference exactly. > > > The current > > face semantics were designed for 'prefix', they just don't scale well > > for other pattern-matching strategies. > > > > 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. 2. If I see that every completion has its second character highlighted, I know I'm using prefix. This is discounting the fact that I probably want to know and control whether I'm using flex or prefix anyway. Using both is strange. 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. 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. Jo=C3=A3o --000000000000a3c73a05969bf6b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[sorry for the duplicate email Dmitry, I forgot to cc= emacs-devel]

On Tue, Nov 5, 2019 at 2:57 PM D= mitry Gutov <dgutov@yandex.ru>= ; wrote:
>
> On 05.11.2019 13:10, Jo=C3=A3o T=C3=A1vora wrote= :
>
> >> We agree, yes. Although I'm more in favor of= changing the defaults,
> >
> > So are we all, but that&#= 39;s a non-starter.=C2=A0 I'm sure everyone here thinks
> > &q= uot;their" settings should be the defaults.
>
> The implic= ation would be that trying to improve the defaults is useless
> or ho= peless. I disagree.

I would rather say that setting a change to Emac= s defaults as a bar to
clear is counter-productive.=C2=A0 And frequently= demotivational.

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.=

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

Yes.=C2=A0 A new face, I presume.=C2=A0 And a generic= attempt to figure a good
place to apply it for every possible style.=C2= =A0 The patch is a bit too
large for reviewing right now.

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

> > 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 o= f difficulty.

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

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

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

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

Cache= invalidation, one of the "hard" problems in computing.=C2=A0 Buy= ing
trouble, I say.

> > But in matching systems like icompl= ete-mode
> > it isn't a problem (in terms of responsiveness) b= ecause icomplete-mode
> > has a while-no-input trick in it.=C2=A0 = Perhaps so should company (presuming
> > that's what you are u= sing).
> I'm trying it out with 'M-x completion-at-point'= .

Then the slowness you're experiencing stems from the fact that= that is
blocking, eager, interface, i.e. it's not a "kink"= ; in flex.

> >> I disagree that it's a significant prob= lem, though. Enabling 'flex' is
> >> one line. Customiz= ing the face is just another line.
> > Isn't true for custom.e= l users.=C2=A0 And it just doesn't make sense that to
> > enab= le "good" flex matching you have to go touch two places.=C2=A0 We= 're
> > discussing usability, after all.
> As you can im= agine, IMHO this part "making sense" is less important than
&g= t; 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.

> >> highlighting would be = applied to two fairly different things.
> >
> > So is = 9;shadow' and 'bold' and many more.=C2=A0 It all has to do with= how you
> > design the semantics, something that is our prerrogat= ive.
>
> I wouldn't use 'shadow' or 'bold' = for the new face either. Nothing that
> matches completions-common-pa= rt of completions-first-difference exactly.
>
> > The curren= t
> > face semantics were designed for 'prefix', they just= don't scale well
> > for other pattern-matching strategies.> >
> > What I'm proposing is no different from say, m= ode-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 figur= e out
> what the highlighting in the *Completions* buffer means?
<= br>OK, let's take that example.=C2=A0 It depends on whether I'm usi= ng a "prefix"
or "flex" style.=C2=A0 But even if I&#= 39;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 match= ed in the middle of a lot of
completions, I know what it means: I'm = using 'flex' and/or 'substring'
and that is the characte= r that's matched. =C2=A0

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

Thi= s is discounting the fact that I probably want to know and control
wheth= er I'm using flex or prefix anyway.=C2=A0 Using both is strange.
It's also discounting the fact that in 2. prefix completion should, IM= O,
use my proposed "emphasis" face to highlight the first -- n= ot the second
-- character. I've argued before that no loss of expla= natory power would
materialize from this.

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

Jo=C3=A3o
--000000000000a3c73a05969bf6b6--