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: Sat, 12 Oct 2019 16:32:51 +0300 Message-ID: <83y2xqm6m4.fsf@gnu.org> References: <834l0enw8c.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="254138"; 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 Sat Oct 12 15:33:37 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 1iJHWa-0013zv-Ap for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 15:33:36 +0200 Original-Received: from localhost ([::1]:33340 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJHWY-0007ps-F0 for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 09:33:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33429) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJHW3-0007pe-IC for emacs-devel@gnu.org; Sat, 12 Oct 2019 09:33:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iJHW3-00028h-9p; Sat, 12 Oct 2019 09:33:03 -0400 Original-Received: from [176.228.60.248] (port=4757 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iJHW2-0006oY-E1; Sat, 12 Oct 2019 09:33:03 -0400 In-reply-to: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sat, 12 Oct 2019 11:57:39 +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:240915 Archived-At: > From: João Távora > Date: Sat, 12 Oct 2019 11:57:39 +0100 > Cc: emacs-devel , Stefan Monnier > > > Bother: this unconditionally adds a post-command-hook, which will > > necessarily slow down paging through a file. > > Everything slows down everything, the question is where and by how much. The post-command-hook is notorious for slowing down cursor motion. Many complaints I hear about Emacs being sluggish eventually boil down to some minor mode inserting itself into that hook and doing non-trivial stuff there. We should therefore do so very cautiously. This case is more important than others because JIT font-lock is enabled by default, so this change will affect every user out there, in any possible major mode. > Can you tell me more about the kinds of files you're anxious about > and exact meaning of "paging"? Is it C-n'ing from the first line to > the last? I could benchmark. C-n and C-v. Try C mode for starters, and then Emacs Lisp. > > If there's no better solution than using that over-used hook, > > My very first version relied on an extension of the existing > jit-lock-context-time, but I seem to remember it broke down here and > there sometimes. I agreed with Stefan (possibly off-list) to use a > post-command-hook, which is safer. But I can have a look at the > original version and re-study those problems more closely. We also have display-related hooks. If you could use one of them, that might be better, because one could generally type quite a few commands before redisplay kicks in, and post-command-hook runs once for every command. > > then at the very least we should give users a way of NOT adding a > > post-command-hook when this feature is disabled. > > Given that I intend for this to be controlled via a customization > variable, I only see it done via a `:set` hook or something like that. I'm not sure I understand. What I wanted to suggest is that when the new defcustom is nil (which seems to be the way to disable this feature), the post-command-hook should not be added. In addition, I think major modes which present read-only buffers should also disable this feature, and not add to post-command-hook. > > > +Setting this to a positive number of seconds helps avoid the > > > +fontification "blinking" behaviour observed when adding temporarily > > > +unterminated strings to source code. If the user has recently created > > > +an unterminated string at EOL, jit fontification allows this idle > > > +"grace" period to elapse before deciding it is a multi-line string and > > > +fontifying the remainder of the buffer accordingly. > > > > This should be simplified and shortened. (In general, copy/paste of > > doc strings into NEWS is not a good idea.) In particular, if the > > default is to have this behavior (see below), the NEWS entry should > > tell how to disable that. > > OK. Supposing you've already already gotten the idea, I invite you to > submit a suggestion. I'd rather had you try. I think it's important that more people can write good documentation, and I think in this case it isn't hard. You can use other entries as examples. > > (I question the wisdom of making this the default behavior, btw.) > > What's bothering you? It's a backward-incompatible behavior, and is not being developed due to bug reports, so why make it the default right from the start? It also slows down cursor motion (which should probably be in the doc string as well). > > I don't understand the "at EOL" part: isn't any unterminated string > > appear as if it is "at EOL"? > > An unterminated string at EOL might be terminated somewhere _after_ EOL, > i.e. a perfectly legitimate (as "in your intentions") multiline string. I still don't think I understand what would constitute an "unterminated string at EOL", then. Could you show two examples, one where there is such a string, the other where there isn't? > Moreover this is a hint as to how the system is implemented, which some > users may appreciate. This kind of stuff should be in comments, not ion doc strings, IMO. > > Please don't use such cryptic variable names, at least not on the file > > level (preferably also not locally inside functions). > > The docstring explains the abbreviation. I'm afraid that given current > naming practice (prefix, double dash, sub-feature) I couldn't do much > better. I think jit-lock--antiblink-l-b-p is a better name than > jit-lock--antiblink-pos, or jit-lock--pos, because it makes the reader > "chase" the doc and learn of the exact meaning of the abbreviation. The variables don't need to use jit-lock--antiblink- prefix, they could use jit-lock-- prefix instead. jit-lock--last-line-begpos doesn't sound too long to me, for example. > > > + (when jit-lock--antiblink-grace-timer > > > + (message "internal warning: `jit-lock--antiblink-grace-timer' not null")) > > > > We should in general avoid calling 'message' here, because such a > > message will appear after every command, which is a nuisance. Is this > > really needed? > > This is an internal consistency check, i.e. a run-time assertion. It > should never happen, except when the program is buggy. I had this set > to 'warn', but Stefan suggested I change it. What do you suggest? > Perhaps I could warn and turn off the feature. Why not just lose the message? Why is it important to display it?