From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: BIKESHED: completion faces Date: Wed, 6 Nov 2019 10:18:42 +0200 Message-ID: References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> <87h83ipoi0.fsf@gmail.com> <3f7afc8e-b3d1-07a4-9350-3bfc5775ba21@yandex.ru> <87sgn1yl4b.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="139267"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Stefan Monnier , emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 06 09:20:07 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 1iSGXu-000a5y-M3 for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 09:20:06 +0100 Original-Received: from localhost ([::1]:53656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSGXt-0005Gt-2M for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 03:20:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40332) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSGWf-0005Fw-Fj for emacs-devel@gnu.org; Wed, 06 Nov 2019 03:18:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSGWd-0003Pg-Uo for emacs-devel@gnu.org; Wed, 06 Nov 2019 03:18:49 -0500 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:33990) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iSGWd-0003P3-OY for emacs-devel@gnu.org; Wed, 06 Nov 2019 03:18:47 -0500 Original-Received: by mail-wr1-x429.google.com with SMTP id e6so22743381wrw.1 for ; Wed, 06 Nov 2019 00:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eb1UCyWd2ntwANCn3iO2D7R5vrMmQtn8KDX3G3D6DZ4=; b=dU4RMDG5rd1cJ+NYK4AG+xlHb2Qtqh7REDgCqdD4XZHlQB0JBDvfX1TfmjRaGznuJN DG2Okdb2D71+khrLYykwvdhUJRTdbyzZbqaumkPZLc31KH64y+DPFDgcZfqRTkV7YXHg Kl/9RTw8A6xyvrvQnHRcJ6GShQ6PIalxVNt0qwv2tjmYPyofAL1muvKxECJr33o3tt9z UxJWd4KzmaoWlZ6adPELKPptr9mJ3YymeOMs2FTZIjYSijfsQE/Wt4bimH7tfPx3Rcqe LMDgkizf+pv8kwBWvAWLTaFkoj0JxF3xl1UxUr+XscU8hvVZJkdFCzVKHRzZ25bCKk68 MvkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eb1UCyWd2ntwANCn3iO2D7R5vrMmQtn8KDX3G3D6DZ4=; b=BQdnneSzGkC9AsUJeyV0+QuZlqWaonuIRmuxlyKgR+lsxN/jnbiFW3L3haVTivqHB1 2B7l6ZiYKvitou3fY/JoWhcjX5K0ZJDWpmKD2PaEV4z56puO1sHPnDpyma7n9hMbcqM2 t/ijdannU5C8iWvpbxHKbGjZNPD6rLEXld6zciKaTwybJJ/eoBWe+JL+meppFsjM6c6y XD5za+riF46JJ0AOGZ0+s1PanFJTzVugyCCdJVQQRKc8NZ+Ai/ynp7TjR75lWofx7EaH cknqSLVUaHqhMaJxquWJLJWQCdXP8HniCb+jyPbAHl/nsHWB4wI4CPiN2hffi1nvyuSd UFaw== X-Gm-Message-State: APjAAAVHhDDvrXhUWGu9rZYCz8yXBNsM7IZsOjep6YLlGohG08xlCsYG PRjU3L6trBmSq023negM5AoDj4NWs+g= X-Google-Smtp-Source: APXvYqwuI9vPo1DLfEyd6BINVLupdE8PEY3zi4wX0NlPl0GUBGqGaTWnS7D6AgwdQ2TFCRZrKjTUPQ== X-Received: by 2002:adf:e890:: with SMTP id d16mr1456246wrm.105.1573028325416; Wed, 06 Nov 2019 00:18:45 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id v9sm21958358wrs.95.2019.11.06.00.18.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 00:18:44 -0800 (PST) In-Reply-To: <87sgn1yl4b.fsf@gmail.com> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::429 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:241843 Archived-At: On 06.11.2019 1:11, João Távora wrote: >>> 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. I might have missed what you are referring to here exactly. >> 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'. OK. Renames aside, you'll have completions-common use bold, right? And hide first-difference. The first one will result in long annoying columns with prefix-only completion (this won't happen in other editors because a) they use flex, b) popup is limited in height), the second one will remove a bit of extra information. >>> > > 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". That kind of discounts the valid and useful avenues for improvement we still have. >> 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. Last I checked, it's not very relevant. Or if it is, it'll just be a minor implementation detail. >>> > 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. >> 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. My limiting the number of completions, most likely. And/or doing it all in C++/Java. >>> > 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. >> 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? Hiding first-difference will lose some info when suffix is non-empty.