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, 05 Nov 2019 23:11:16 +0000 Message-ID: <87sgn1yl4b.fsf@gmail.com> References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> <87h83ipoi0.fsf@gmail.com> <3f7afc8e-b3d1-07a4-9350-3bfc5775ba21@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="95929"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 06 00:12:12 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 1iS7zd-000Omx-0a for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 00:12:09 +0100 Original-Received: from localhost ([::1]:51410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iS7zb-0003hP-Mw for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2019 18:12:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42023) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iS7yt-0003gz-VH for emacs-devel@gnu.org; Tue, 05 Nov 2019 18:11:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iS7ys-0004hv-4i for emacs-devel@gnu.org; Tue, 05 Nov 2019 18:11:23 -0500 Original-Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:52554) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iS7yr-0004cO-UM for emacs-devel@gnu.org; Tue, 05 Nov 2019 18:11:22 -0500 Original-Received: by mail-wm1-x335.google.com with SMTP id c17so1256821wmk.2 for ; Tue, 05 Nov 2019 15:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=cBf8a6QsY3R8mQJuoiMVAyO2mnWDOTk4g3S4S+dJOWk=; b=tmxEKKxshTDJBCP7iviKfIZ9jq7vBySElYsgKpSIP+E5a3Q84CRzwAodhWKDQ8ID9z e2w3FQn+pNnvd6R6cZJviHIBE4ly/eg5zvub6y/bfn0YDrsKSK6Dn5TfSZhjy/TFAlk6 PZW1HprJPyYen8H1uUkkUVQp6Og80ygKo0nkNNEkoNWIEv6l3UUomdv1pkh8ar2CoS8G mAWJnkdEXYA3p8ZrHS2CwH0WyQ3R69H821j0lD82xPxSlGXzynHmtzml7SwcU7V3wNts kxgwZf1hpcPrhWFhQeGhhifVmC6HVMLMuHoOjZ8yOX0uLYglp16VyY7eDmZQ9cBtRUrU VfJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=cBf8a6QsY3R8mQJuoiMVAyO2mnWDOTk4g3S4S+dJOWk=; b=daBZddowwXgKI2r8IZXPuiNms75uNEh5vPuPICm3nm4ewNuCy9uXWcGDis9cB8MObT eZLv8G0+q9TX91xs2UpWxDV5wfzVcKobQ7zDT3vR7PP4FhWpnM9YMX09nGmC63S8jYMH do9fNdp4oGSKKvqC+dBY8mTzYd2BCFxqc8PgioJ6QlFj5sZ2ULkpW6dkHhDTnLuBC72v HjeOiNGb9xa8jTxHKIwhOdl58m31Dt1O+k78g74Mb4wvcpFPlLBhy1jyxCs8mRYG1s6S 0vjk+WTLV18hj3Eh/X1llB11vrvDO3stksL1oV5LEHHPJFaK9NA5C4ZGBMYFz1+vMEqz dHxg== X-Gm-Message-State: APjAAAVtVlp1NmGlCvIkoEWtDoOwIJFr/Bt+LpMLvCDaO6LbLmWYRFOK NpDJfAurDhLjGEThwlz59xQHg0EI X-Google-Smtp-Source: APXvYqzZDMOaEAem/UB8hiZ8AHNhzaLSteAqg+z5muOio4Ar8lCdkEzMlEQpNokQZSREonquoRMcmw== X-Received: by 2002:a1c:e0c4:: with SMTP id x187mr1213695wmg.93.1572995479612; Tue, 05 Nov 2019 15:11:19 -0800 (PST) Original-Received: from lolita.yourcompany.com ([2001:818:d820:9500:1ebb:afd8:ab26:f0f6]) by smtp.gmail.com with ESMTPSA id o10sm15605875wrq.92.2019.11.05.15.11.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 15:11:18 -0800 (PST) In-Reply-To: <3f7afc8e-b3d1-07a4-9350-3bfc5775ba21@yandex.ru> (Dmitry Gutov's message of "Wed, 6 Nov 2019 00:22:33 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::335 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:241836 Archived-At: Dmitry Gutov writes: > On 05.11.2019 18:31, Jo=C3=A3o T=C3=A1vora wrote: > >> I would rather say that setting a change to Emacs defaults as a bar to >> clear is counter-productive.=C2=A0 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=20 > 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. Yes, but much more controlled. This particular change in defaults so is done so that the explanatory part that people (presumably) like about the current 'basic' match highlighting is still preserved. > Your proposal would add a different styling for different completion > styles. That would require some code as well, likely a similar amount. No, we are not talking about the same thing. In my latest proposal, two faces are renamed, obsolete alias are created, and completion-pcm--hilit-commonality is trivially changed to use 'completions-emphasis' instead of 'completions-common'. >> > > 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? No, no. I just lightheartedly commented that in response to your "all can be improved". Like "all animals can fly, even pigs, provided you attach a large enough rocket". > algorithm itself, but any subsequent bottlenecks would not be triggered. > > This approach really relies on good and fast scoring, though. If we're going to do extensive changes in the name of performance, isn't it better to use Daniel's generator.el library? It sounds like just the thing. >> > One just has to make sure not to cache the result improperly. >> Cache invalidation, one of the "hard" problems in computing.=C2=A0 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. Possibly/probably by using delayed evaluation techniques. >> > As you can imagine, IMHO this part "making sense" is less important t= han >> > 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. And that's cool, I maintain that this isn't broken at all by my proposal. Can you explain how it would be? >> > > What I'm proposing is no different from say, mode-line-emphasis, wh= ich >> > > lisp/man.el and lisp/vc/vc-dispatcher.el use in "two wildly differe= nt >> > > 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.=C2=A0 It depends on whether I'm using a >> "prefix" >> or "flex" style.=C2=A0 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. I don't aggree with your quantification of useful/wasful sinapses, obviously. And it seems we are confusing two things here (and I may be at fault, too). One thing is "discovering what style Emacs is using" the other thing is "why is this particular style showing me this visual feedback". The first can be solved by other means (by hinting to temporarily in the mode-line for example). >> 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. No. I think it's unreasonable to ask that. > 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. We agree, totally, but that's not going to happen anytime soon. So we should make sure that whoever does that 'setq' or customizes that variable doesn't get a strange "alien" experience. >> 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. Why annoying? >> Finally it also dicounts 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 re= ally >> 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=20 > 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=20 > logic or something. In other words, less frequent situations than > simply typing code. Every 'grep' search also brings that visual explanation of the matches. So does every search engine I've tried. Why shouldn't 'flex' or 'p-c-m' or 'string'? We've seen how all other editors, except Vim (apparently), highlight them by default. Jo=C3=A3o