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: jit-lock-antiblink-grace Date: Sun, 13 Oct 2019 12:22:11 +0300 Message-ID: <83o8ylknjw.fsf@gnu.org> References: <834l0enw8c.fsf@gnu.org> <83y2xqm6m4.fsf@gnu.org> <83o8ymlzkk.fsf@gnu.org> <835zktm9o0.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="239436"; mail-complaints-to="usenet@blaine.gmane.org" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 13 11:23: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 1iJa5f-00109l-Ez for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 11:23:03 +0200 Original-Received: from localhost ([::1]:38394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJa5e-0002An-An for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 05:23:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54495) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJa54-0002AX-Hz for emacs-devel@gnu.org; Sun, 13 Oct 2019 05:22:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iJa54-00076e-9N; Sun, 13 Oct 2019 05:22:26 -0400 Original-Received: from [176.228.60.248] (port=2166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iJa4y-0003Rt-Oh; Sun, 13 Oct 2019 05:22:24 -0400 In-reply-to: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sun, 13 Oct 2019 09:47:24 +0100) 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:240951 Archived-At: > From: João Távora > Date: Sun, 13 Oct 2019 09:47:24 +0100 > Cc: emacs-devel , Stefan Monnier > > > > From what I can remember, you didn't weigh in on the specific case I was > > > referring to (the one being brought up again in the side thread), where > > > c-mode was modified in a truly backward-incompatible, uncustomizable way > > > to address a related problem. > > > > I don't remember the particular case, but I can make mistakes, can I? > > Anyway, I'm not sure I understand what you are trying to say here. > > Are you saying that I treat you differently from others? If so, > > that's not the case, and if I said something that could be interpreted > > otherwise, I apologize. > > All I'm trying to say is one of the motivations for my proposed feature > A is to be an alternative to another feature B in Emacs (which I > consider harmful) and you are holding my feature to a higher standard > (regarding backward compatibility, performance, doc, etc) than you did > the other one. In absolute terms, that's just fine, but in relative > terms there is a discrepancy that was trying to understand. If it was > simply an oversight, it's perfectly OK. All I can say is that I consider each proposal on its own terms, and try to apply the same considerations in all cases. There's no higher standard for you or anyone else, and lower standards for others, at least not intentionally. > > Very simply: the behavior is different from what we had previously. > > Of course, there is different behaviour in every feature except a > refactorization. No, bug fixes make changes that don't change behavior, not in general. New features do change behavior, and we normally don't turn them all on by default, not unless we have a very good reason. > Do I explain myself? Yes, but I already knew all that, so there's no misunderstanding on my part. > Anyway, your point seems to be to minimize the probability of incessant > debug chatter in *Messages* which would supposedly render an Emacs with > a buggy jit-lock.el unusable. It's not just the *Messages* buffer: each call to 'message' causes redisplay, so we will have a flood of redisplays, which is not nice. > I can use a suitably parameterized > 'warn', a cl-assertion, an error, or just get rid of it. Thanks.