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 11:10:47 +0000 Message-ID: <87h83ipoi0.fsf@gmail.com> References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> 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="205063"; 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@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 05 12:11:37 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 1iRwkK-000rAX-4s for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2019 12:11:36 +0100 Original-Received: from localhost ([::1]:42968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iRwkI-000642-GD for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2019 06:11:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40870) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iRwjg-00063w-GR for emacs-devel@gnu.org; Tue, 05 Nov 2019 06:10:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iRwjf-0001Bz-AN for emacs-devel@gnu.org; Tue, 05 Nov 2019 06:10:56 -0500 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:38349) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iRwjf-00015W-1k for emacs-devel@gnu.org; Tue, 05 Nov 2019 06:10:55 -0500 Original-Received: by mail-wr1-x435.google.com with SMTP id j15so182031wrw.5 for ; Tue, 05 Nov 2019 03:10:54 -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=qovx++RENqF16qrmGF+NeSO/dxixT33JIDExJj6MLYg=; b=faYW5I5MH9B8SZGPrh+WbCfWqIgWAEN3i98irAeTym+PzpDZj1qz/k3lce/szEArGK D4MVshVQYR366U103/8hRI+N15yriLYos4+d2hUcGe4sZmluYJg6YhXRKACpDZphpP8V x6m0kIFT78cghySOtakCBTgUvdCbkOPQHQk92LAGakTDHy9dONuS3MA8a7eNg5iBDGNi 08VIN8pOeYBs7KhcL0i30H0GGAEe1CsmcebzEl1NC4az9Pjn419bkNvNcO7CLOvzEnPW /0esk2280gj5GQENiU6oMHs4bivu5ULRMVtzKiX6JSxckJTd2gunhWpKvT1aDLVX/IRt sBsg== 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=qovx++RENqF16qrmGF+NeSO/dxixT33JIDExJj6MLYg=; b=dx6RGToDfu0hnw6gTX6BVUKSiW9h1apnyualHGs/gt62MRXHFjOT2y+Fy5rgI+a7iD Dzgc4Yz+fcvTXK6nT8FRtFl8NKCIG0gizh19pWPGuqM3ztCCdb4mtNxujLPA9jYBXBqi 7wfxHduAq2QVsDhJXPszHHWwxZWN0jLoVACBRRtN31prQaDZTcslbiSCQx/mIROQg3Eu b+fQrqciMq3j98BhMJp/hUqZX2+Fvl6fF6fKXQEYfUdD+YBhU87RMrjCLTLsh1ZESftD jTyNSQ2KJWkIJSH6vdLSam51mlcz2idfX5RpYvsFL6zNu3ikGwVaog4CKL52LmZ0SUt7 BzQA== X-Gm-Message-State: APjAAAX6ukqGjkijzO/ReyQt7riwMiSQJ5p0Msu5xYGLv2Cs+YA0g4m0 egu+olOvAf2NAFhLFCppQJhGtuXg X-Google-Smtp-Source: APXvYqy99+2dbrN50maYwfAZNYIhV5Rjg4Ad9/XIedF/RowQLpeVRJL8tMQyFf2W75O2RS7ul+htKA== X-Received: by 2002:a5d:6448:: with SMTP id d8mr24345430wrw.88.1572952253129; Tue, 05 Nov 2019 03:10:53 -0800 (PST) Original-Received: from lolita.yourcompany.com ([2001:818:d820:9500:1ebb:afd8:ab26:f0f6]) by smtp.gmail.com with ESMTPSA id f20sm16879797wmb.6.2019.11.05.03.10.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 03:10:49 -0800 (PST) In-Reply-To: (Dmitry Gutov's message of "Tue, 5 Nov 2019 01:25:29 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::435 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:241799 Archived-At: Dmitry Gutov writes: > On 05.11.2019 0:52, 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. So what you are proposing with the "do-nothing" approach amounts to a lose-lose. > as soon as the kinks are worked out (e.g. flex is a bit slow when > prefix is 1-2 chars). You have to think about this "slowness". A part of it might be discovering if the 1-2 chars are in the potential match. Another different part of it might be due to the fact that the set of matches is much greater when the pattern in short. The former part can be improved in flex, the latter can't: it's intrinsic to the technique. 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). >> So the next best thing is to add new functionality with a minimum of >> customization necessary. So, IMO, it's nonsensical to ask users to >> customize the matching style to 'flex' AND also ask them customize a >> face so that that more-than-familiar matching strategy reveals its >> familiarity. > > 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. >> This is better: I think this would lead you to my idea of a new >> `completion-relevant` face, which we would set to bold or something very >> prominent. For the 'prefix' the relevant part is the "next character" >> and for the 'flex' style is whatever has matched. >> completions-first-difference could then be made an alias of that new >> face. > > Hmm, I don't like this changing of terms, sorry. This way, the same > 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. 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". Of course, another way out, at the expense of yet another face, is to add completions-flex-emphasis or something like that. Jo=C3=A3o