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 09:39:11 +0300 Message-ID: <835zktm9o0.fsf@gnu.org> References: <834l0enw8c.fsf@gnu.org> <83y2xqm6m4.fsf@gnu.org> <83o8ymlzkk.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="139189"; 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 08:39:30 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 1iJXXO-000a6A-13 for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 08:39:30 +0200 Original-Received: from localhost ([::1]:37910 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJXXM-00078y-Ob for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 02:39:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42590) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJXXE-00075u-QQ for emacs-devel@gnu.org; Sun, 13 Oct 2019 02:39:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iJXXE-0004nm-Dq; Sun, 13 Oct 2019 02:39:20 -0400 Original-Received: from [176.228.60.248] (port=4070 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iJXXD-0007Z3-LE; Sun, 13 Oct 2019 02:39:20 -0400 In-reply-to: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 12 Oct 2019 22:55:29 +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:240944 Archived-At: > From: João Távora > Date: Sat, 12 Oct 2019 22:55:29 +0100 > Cc: emacs-devel , Stefan Monnier > > > It doesn't have to be like that. It depends on how you arrange for > > the hook not to be added. > > I can only see one reasonably hacky way to arrange for: > > * the feature to be controlled via this variable > * the hook to disappear from p-c-h when the variable is nil > > and that's to use an "ensure hook present/gone" technique somewhere in > the places of the jit mode that the code is guaranteed to pass before > the feature would kick in. It would feel hacky and so unjustified > before any kind of performance measurements. Did you mean something > like that or something completely different that I'm not following? I didn't figure out the details, I thought it should be easy to do. Don't we already do something like that in all kinds of places? The :set attribute of a defcustom comes to mind, for example. Alternatively, the timer you add could notice the change and take that action. And I'm sure there are more ways of doing that. Or maybe I'm missing something. > > All I wanted to say was that the goal is almost in reach, and that you > > don't need to give up in this case. > > But if you think it's too hard, then okay, I will write the text when > > the time comes. > > And all I wanted to say is that something a little more constructive, > like a concrete suggestion, is whitin reach. I will try again in the > next iteration. Shorter, more to the point in NEWS and idiot-proof spec > in the docstring. Thank you. > > When I find a backward-incompatible change, I usually do try to see if > > it's justified. So I think I already do what you ask me to do in > > those other cases. > > 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. > Furthermore, calling my proposed change > "backward-incompatible" is something I don't fully understand. Perhaps > you can clarify: what behaviours, actions, etc. were observed before > that aren't observed now? Very simply: the behavior is different from what we had previously. Previously, starting a new comment would give me an almost immediate visual feedback; now that feedback is delayed by 2 sec (more, or even not at all, if I continue typing). How can we know that everybody will instantly like this new behavior? > > > Run-time consistency assertions are useful, right? > > > > Only as a debug option, > > Yes, I agree. But there is really no "debug" in Emacs, only > debug-on-error. That's not so: various packages define their own debug facilities. Examples include Tramp and smtpmail.el. We could add a debug facility to jit-lock.el as well, if you think it's important for this feature. Thanks.