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: Sat, 04 Sep 2021 09:36:04 -0400 Message-ID: References: <838s0eyyjg.fsf@gnu.org> <83eea5ygub.fsf@gnu.org> <835yvgyijv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="613"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 04 15:36:59 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 1mMVqq-000APC-Ld for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 15:36:56 +0200 Original-Received: from localhost ([::1]:50044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMVqo-0000Nu-E6 for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 09:36:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMVqA-00080c-GP for emacs-devel@gnu.org; Sat, 04 Sep 2021 09:36:14 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMVq5-00071R-R7; Sat, 04 Sep 2021 09:36:13 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EE5AD80677; Sat, 4 Sep 2021 09:36:08 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 86112806D9; Sat, 4 Sep 2021 09:36:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1630762567; bh=hH8RPVqm3rmkQiR0x0Iw9bE3BFy2/Dx5w1zNoXjeqaM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Se2VYeR6UHo+vezgKe0NPulmb/SOZhdMaehPkkK0vPKH79ofZGR6HRcSCrNe5QpBu /aUuvSJk9s9ee6g4CH11E+A/BAkBFIvE4ANimOthg6To6dy46HJySYm/4lIoIts+hy uqcK2CKM6MqGJ71X3t8topgFt+q6GE6HqZv4/VU7c94AeGqF37WREFS7iNG1SIcoWi P4ZWrNZmQYxOvD3D/VtHY7qP0g3FAwt0LU40/pUiSgIrUe4yE83r5evn6twdtCKBqK ZWvuBbRFSb3qduCK6Xfn6TOCArSQzSRCIenrdiLHB9mUZScD/iOk/2CR1laUb8TNr6 gKow/IRkAPKMQ== Original-Received: from milanesa (unknown [104.247.244.135]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 171301201E6; Sat, 4 Sep 2021 09:36:05 -0400 (EDT) In-Reply-To: <835yvgyijv.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Sep 2021 09:13:40 +0300") 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:273867 Archived-At: >> It changes the overall behavior a bit, yes. And of course, that might >> trigger bugs somewhere, like any other change. But other than that, it >> should not change the actual final result other than how fast we get to >> it, no. > > I'm looking at this from the POV of someone who writes a function to > be registered with JIT font-lock. They need to understand these > details to be able to write code which will do what they want. Why should they? The function is asked to handle region BEG...END and it may elect to handle a larger region. For efficiency reasons, most such function will extend the BEG...END region as little as possible, so they don't really have much choice in terms of which part of the buffer to handle: as small as possible, yet larger or equal to BEG...END. As for the value those functions return, it can always be nil unless they elect to tell jit-lock about that larger region they decided to handle in which case jit-lock will try and take advantage of that info to avoid redundant work. This description has been valid for a while and the changes discussed here do not impact it at all. > They would still know about the automatic ordering because if some > other function gets put at the first place, the results will be > different, and that needs to be explained. I don't see in what sense "the results will be different". Which results are you talking a bout? What kind of difference do you foresee? Stefan