From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: BIKESHED: completion faces Date: Wed, 06 Nov 2019 18:03:36 +0200 Message-ID: <83bltpgffr.fsf@gnu.org> References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> <83h83ignrz.fsf@gnu.org> <83ftj2gma8.fsf@gnu.org> <87zhhaxalt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="12302"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 06 17:06:04 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 1iSNop-00033Z-SF for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 17:06:04 +0100 Original-Received: from localhost ([::1]:60650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSNon-0001al-4n for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 11:06:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53496) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSNml-000096-Tl for emacs-devel@gnu.org; Wed, 06 Nov 2019 11:03:57 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iSNml-0000gU-71; Wed, 06 Nov 2019 11:03:55 -0500 Original-Received: from [176.228.60.248] (port=3113 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iSNmh-0001bb-Cf; Wed, 06 Nov 2019 11:03:52 -0500 In-reply-to: <87zhhaxalt.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Tue, 05 Nov 2019 21:43:42 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:241858 Archived-At: > From: João Távora > Cc: monnier@iro.umontreal.ca, dgutov@yandex.ru, emacs-devel@gnu.org > Date: Tue, 05 Nov 2019 21:43:42 +0000 > > > If we have one efficient way, why do we need to consider others? > > Indeed we don't, you're totally right, not for the 'prefix/basic' > completion. However some people have made a point that there should be > some kind of consistency at this level between completion styles, that > the thing emphasized in 'prefix/basic' should have some semantic > relation to the thing emphasized thing for 'flex' and 'substring' too. > > So, to "please greeks and trojans" [1], an equally efficient AND > cross-style-consistent style could be found, we could keep the "common" > and "first-difference" face names, and 'flex' would ship without a > default "crippling" (see below).. Sorry, but I see no reason for any kind of "consistency" here. We need to highlight to help the user specify the right completion candidate, all the rest is secondary IMO. > >> One of them is to highlight the preceding character. > > > > ??? How does this help me to select what to type next? > > Did you try the experiment I proposed (swap the two faces)? I have no > problem recognizing the character "to type next" when I do it. See the > attached gif another-way-to-see-the-first-difference.gif I did try that, and it makes the task of finding the next character to type much harder for me. > > I don't see why it's important to explain how did the completion > > algorithm arrive at a particular candidate. The completion algorithm > > is there to intuit what we mean in the most efficient way, but the > > details of how it does that are immaterial. The only ones who may be > > interested are those who study completion algorithms ;-) > > I may sound like a completion scholar to you, but you also sound like > you haven't experimented with 'flex' for more than 1 second, otherwise > you wouldn't be asking that question ;-) There's no need to make such assumptions just because I happen to disagree with something you consider self-evident. I did play with that long enough to make up my mind. > So I attach another Emacs -Q gif, crippled-flex.gif, where you see > the current problem, and yet another gif, useful-flex.gif, where the > matching part is highlighted bold. Thanks, but it doesn't change my mind. > I think you will agree it's not a detail. The reason we want to > highlight matching parts in flex is the same reason grep and every > search tool and search engine I know decides to highlight matching > parts: to call attention to the part that matched. Grep's goal is to find the match, so it makes sense to highlight that match. The goal here is quite different, so highlighting the match makes much less sense in this context. > Of course, fixing that crippled default state of 'flex' is a couple of > customizations away (Put the common face to 'bold' and the > first-difference to nothing). But, IMHO, it would be a shame if we were > to release Emacs 27 with this familar matching method and no good > default faces to go with it. If you are saying that the default face needs to be changed, it is a completely different issue. This thread AFAIU is mainly about defining new faces that are put on other parts of the candidate strings. It is not about highlighting the same parts, but with different colors or other attributes. > > No, "first difference" is always the character to be typed after > > point. At least for the vastly important case that point is at the > > end of what you typed, i.e. you don't move point back after typing > > something. > > But for the 'flex' case (among others more obscure) that first character > "to be typed" -- presumably to narrow down the set further -- might be > any character following 'point', for each completion, not just the one > in the 'point+1' position. So show all of them ,with the same face. That's not what this thread started with, AFAIU, it started with an assertion that completion-first-difference is flawed as a concept, and should be replaced with something new and different. > Finally, I believe other UI's that have this kind of flex search (I > think they are not rare at all nowadays, not just in editors) also use a > prominent (often bold) face, to mark the common part. That's a different issue.