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: VOTE: Changing completions-common-part face's default Date: Sat, 09 Nov 2019 14:04:43 +0200 Message-ID: <83zhh58dd0.fsf@gnu.org> References: <87pni7p83l.fsf@gmail.com> <87h83ipoi0.fsf@gmail.com> <93235eb5-8e04-7182-e2a4-49fbe610ee2b@yandex.ru> <28d4ae09-daca-324b-2fa6-9d7138d710fa@yandex.ru> <87zhh82d8c.fsf@gmail.com> <1e1aa5a7-a35b-2ef5-6caf-10e02dd0c6ea@yandex.ru> <3cfbe69a-c274-f4f2-f3f5-9eb4c8500bb8@yandex.ru> <83lfspa4ma.fsf@gnu.org> 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="249777"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, drew.adams@oracle.com, dgutov@yandex.ru To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 09 13:05:09 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 1iTPUK-0012sl-Pt for ged-emacs-devel@m.gmane.org; Sat, 09 Nov 2019 13:05:08 +0100 Original-Received: from localhost ([::1]:36122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTPUI-0002Ea-IW for ged-emacs-devel@m.gmane.org; Sat, 09 Nov 2019 07:05:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59036) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTPU9-0002CB-MV for emacs-devel@gnu.org; Sat, 09 Nov 2019 07:04:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iTPU4-0002Kf-5L; Sat, 09 Nov 2019 07:04:53 -0500 Original-Received: from [176.228.60.248] (port=2352 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iTPU3-00062h-1W; Sat, 09 Nov 2019 07:04:51 -0500 In-reply-to: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 9 Nov 2019 11:42:31 +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:242037 Archived-At: > From: João Távora > Date: Sat, 9 Nov 2019 11:42:31 +0000 > Cc: Dmitry Gutov , Stefan Monnier , > Drew Adams , emacs-devel > > > It is OK to have special needs, > > I could just as well illustrate your use 'prefix' > need-to-see-the-first-difference case as a special need. You could, but since that's how Emacs worked for the last 11 years, I don't see how such a claim would stand. > "special" in contrast to what I would suppose is the "norm" > is not very useful here, especially when applied to a new > feature. My position is that your argument is weak also > because you don't have enough first-hand knowledge to > talk about special needs __in the "flex" context__ I tried that with different styles, including flex, and I still don't agree with you about the need to reverse the emphasis. So what you think must be the default at least for me doesn't sound 100% correct, as I find flex very usable for me with the current method of emphasis. > I gave my example as a data point. Take my word that it affects > more people that I work with. SLIME's authors must also felt > the "special need" back in 2006. Probably all the authors/users > of every other flex system in the world also feel that "special > need" (though, they are using other editors and have stated your > don't value their opinion much -- contrary to me.). I'm sorry, but that's not how defaults in Emacs change, not because you give me your word or describe what other applications do. Not when the proposed behavior is in such stark contrast to what we've been doing for years. We first introduce such a new feature as optional, and later change it to be the default based on user reports and complaints. I suggest to do the same in this case.