From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7% Date: Thu, 02 Sep 2021 14:46:51 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31808"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 02 20:48:02 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 1mLrkn-00080c-1a for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Sep 2021 20:48:01 +0200 Original-Received: from localhost ([::1]:57760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLrkl-0007FX-Gh for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Sep 2021 14:47:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLrjm-00069o-Os for emacs-devel@gnu.org; Thu, 02 Sep 2021 14:46:58 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52710) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLrjj-0007GR-LK for emacs-devel@gnu.org; Thu, 02 Sep 2021 14:46:57 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 27908100135; Thu, 2 Sep 2021 14:46:54 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BB55510000E; Thu, 2 Sep 2021 14:46:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1630608412; bh=UY8uWopJ2ru9TmcetGc1/aqZxvTcZ6GDHkJRjkbktMc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=f2AstvzMs5SwC0r4mRc0vBhNZiskdSYyPPBuc45uTUalFkHQVTt4Jw5ixvs3LgZET 9pnqpOV7nXIZvVPYvcZOvivfiVziYkjEIOKy92rmZ31CdN0SchY7K3VcbswwqytOMc 1qpJ0DTkq1HY7ARmOJF1B2myHiu8Gos7sUd+y2sHDui/gMgHFQnTwPignHYmoa0G5Y IxrFAdiehxIIj33jVzNCUryQ2tLCz9XarIcQW/tcM9pqI2cZtln23BuypD087yPtSJ z9VO58BcLOFHTe7NsPWefxAINeJCzZr2hMDsMgXVOZDzTzY5pFm/oeccGdYnzRipld Hx6vN4HLITesQ== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7F94812029C; Thu, 2 Sep 2021 14:46:51 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Thu, 2 Sep 2021 16:57:19 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:273724 Archived-At: >> > However, this mechanism is rendered ineffective if a second function >> > is add-hook'd onto jit-lock-functions. Maybe this could be fixed, >> > though it looks difficult. >> I think we can "easily" handle this specific case if the >> `bug-reference-prog-mode` function is added to the end of the hook >> rather than to its beginning and use a patch along the lines of the >> one below. > Yes. How about an optional parameter to jit-lock-register meaning "put > this function at the beginning of jit-lock-functions", with the default > meaning put the function at the end? Sure. Basically, the idea is that the function which is most likely to grow the bounds (or to grow them most) should come first. > I haven't tried it, but I don't think the patch below is quite enough. I'd be surprised if it is, indeed, I just thought it was a better description of the intention than whatever I could come up in words. Stefan