From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7% Date: Wed, 1 Sep 2021 19:19:07 +0000 Message-ID: References: <83r1e8p4w8.fsf@gnu.org> <83mtowp430.fsf@gnu.org> <83lf4gp2u6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30032"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 01 21:20:06 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mLVmI-0007bj-5C for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Sep 2021 21:20:06 +0200 Original-Received: from localhost ([::1]:37402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLVmH-0001vN-4U for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Sep 2021 15:20:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLVlR-0001FR-07 for emacs-devel@gnu.org; Wed, 01 Sep 2021 15:19:13 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:26329 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mLVlO-0002Yr-Rs for emacs-devel@gnu.org; Wed, 01 Sep 2021 15:19:12 -0400 Original-Received: (qmail 66081 invoked by uid 3782); 1 Sep 2021 19:19:08 -0000 Original-Received: from acm.muc.de (p4fe15865.dip0.t-ipconnect.de [79.225.88.101]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Sep 2021 21:19:08 +0200 Original-Received: (qmail 7473 invoked by uid 1000); 1 Sep 2021 19:19:08 -0000 Content-Disposition: inline In-Reply-To: <83lf4gp2u6.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:273682 Archived-At: Hello, Eli. On Wed, Sep 01, 2021 at 21:28:49 +0300, Eli Zaretskii wrote: > > Date: Wed, 1 Sep 2021 18:20:25 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > Then I think the easiest fix is to get bug-reference-prog-mode > > > return a suitable value, or wrap it in a function that would. > > > Every function that puts itself on jit-lock-functions without > > > actually fontifying anything should return BOB..EOB as the region > > > it fontified, right? > > I'm not sure that's the right fix. If font-lock mode were disabled, > > say, bug-reference-fontify would be the only function on > > jit-lock-functions. > But that never happens, does it? I just did M-x font-lock-mode. bug-reference-fontify was the only thing left in jit-lock-functions. > Or if we want to be holier than the Pope, bug-reference-fontify could > check if it's the only function on the list, and then change its > return value accordingly. That's horrible! ;-) There might be two such functions that each returns nil, and so on. > > The mechanism with `jit-lock-bounds' in jit-lock.el is a good idea, > > but somehow it's not quite optimal at the moment. > It was designed for functions that actually fontify something. We > need to either extend it for functions that don't, or change those > functions to pretend they do, but in a way that doesn't disrupt > jit-lock-bounds. I'm more in favour of enhancing the mechanism in jit-lock.el. The protocol to the fontifying functions is very stable, robust, and simple. > > For example, if the first jit-lock-functions element returns > > (... (new-BEG . new-END)) we might be able to supply new-BEG, new-END as > > the arguments to the second element. Or something like that. > I think it's too late to change the protocol, since it was in use for > too long. Does that change the protocol? It merely gives a different chunk to the later functions. Given that they're expecting a sequence of contiguous chunks in successive invocations, why does it matter if we pass (501 1050), (1050 2000), .... as successive argument regions rather than (501 1001), (1001 1501)? There seem to be two types of jit-lock-functions elements. The first, which uses the `jit-lock-bounds' mechanism and the second which returns a random value like nil. I'm only aware of font-lock-fontify-region in the first type. So all we need to do is make sure that f-l-fontify-region is the first function in jit-lock-functions. All we need for that is an &optional parameter to jit-lock-register meaning "put this function first in the list". Maybe. Perhaps Stefan will say something about this problem. -- Alan Mackenzie (Nuremberg, Germany).