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: Thu, 14 Nov 2019 11:45:35 +0200 Message-ID: <83v9rm7pvk.fsf@gnu.org> References: <83bltne6oq.fsf@gnu.org> <87lfsrqs63.fsf@gmail.com> <838soqeuzr.fsf@gnu.org> <87ftiyn07t.fsf@gmail.com> <8336eycvpf.fsf@gnu.org> <83pni2bcws.fsf@gnu.org> <83imnubax9.fsf@gnu.org> <83h83eb8od.fsf@gnu.org> <83d0e2b32k.fsf@gnu.org> <83r22ha64z.fsf@gnu.org> <831ruh9siv.fsf@gnu.org> <83y2wp8cnq.fsf@gnu.org> <83woc983so.fsf@gnu.org> <86c1b45c-0a25-b1ed-ffb1-7dc0e50bd5d9@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="81067"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, emacs-devel@gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 14 10:47:45 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 1iVBj7-000Kwe-4Z for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 10:47:45 +0100 Original-Received: from localhost ([::1]:54882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVBj4-0007W2-Lp for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 04:47:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37147) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVBhI-0007Vt-EN for emacs-devel@gnu.org; Thu, 14 Nov 2019 04:45:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVBhH-0004E4-GY; Thu, 14 Nov 2019 04:45:51 -0500 Original-Received: from [176.228.60.248] (port=4339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVBhG-00019p-Pu; Thu, 14 Nov 2019 04:45:51 -0500 In-reply-to: <86c1b45c-0a25-b1ed-ffb1-7dc0e50bd5d9@yandex.ru> (message from Dmitry Gutov on Sun, 10 Nov 2019 11:18:46 +0200) 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:242138 Archived-At: > Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 10 Nov 2019 11:18:46 +0200 > > On 09.11.2019 17:31, Eli Zaretskii wrote: > > I think you are looking at this from the implementation POV. From > > users' POV, an option (or a minor mode) is a better way when we are > > talking not just about changing colors and other face attributes, but > > about changing behavior in significant ways. In this case, what is > > implemented via faces changes the behavior, because a face prominently > > different from the default becomes like the default, and another face > > makes the reverse transformation. Think of this as a binary mode that > > makes either the first-difference or the common part prominent: > > flipping a variable is an easily understood and easily discovered way > > of getting each user the behavior he/she wants. > > How would that work? Having two faces have different default definitions > depending on the value of the variable? Either that or a function that redefines the face definitions, e.g. by aliasing/copying from other faces. > Any custom face would override that decision. And chasing all theme > authors to make them honor the variable is a lot of effort. I'm not sure I understand what customization scenarios you have in mind, so I don't think I see the problem.