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 10:44:43 -0400 Message-ID: References: <838s0eyyjg.fsf@gnu.org> <83eea5ygub.fsf@gnu.org> <835yvgyijv.fsf@gnu.org> <83eea4wilj.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="38802"; 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 16:46:26 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 1mMWw6-0009p9-2d for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 16:46:26 +0200 Original-Received: from localhost ([::1]:52138 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMWvz-00013q-Oo for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 10:46:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMWua-0008Ae-1i for emacs-devel@gnu.org; Sat, 04 Sep 2021 10:44:52 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17245) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMWuX-0006Hs-Dz; Sat, 04 Sep 2021 10:44:50 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B17CC44058F; Sat, 4 Sep 2021 10:44:46 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 05EA144058B; Sat, 4 Sep 2021 10:44:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1630766685; bh=AAxnP/+VzcO7cbvcQNnsaRdgcsB0OsiZszG5Wgy/n/0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OYioMLdOV7PNa/rDmddnUlmjhNu0708sd975xzEOuRfDvdlDy8qBxB7mmcR4Pheo2 wUJ8UiwZzAOuTLdhDWLxC1aKzPD5LkCmTs1Hsx9g55YbkX/ISK2nbCq7f2k1j1zfEV D7MeC4piA4Byj/6YWUJFa6W58m+4JusTkqtM63aQHAiwpNq8YWwLnQMPHQZMU3CmTr Hoe7ujXgNPqdgr2wiCM8JCTKZ31vFZ8eTaxJz+abEidCQKhfGpgLwqn0Tl0WRX9nFF UfvXtABi/J9IYhOEL6ec3KFvnxqx9Q15FT3GXbPhmKeIUQLEbNE1pklJO4oPQ3vJZ1 Y3Pbv6c/UOkng== Original-Received: from milanesa (unknown [104.247.244.135]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B97EE120264; Sat, 4 Sep 2021 10:44:44 -0400 (EDT) In-Reply-To: <83eea4wilj.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Sep 2021 16:55:36 +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:273888 Archived-At: >> > 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? > To achieve their goals, of course. [ I'll call "client functions" those functions passed to `jit-lock-register`, like `font-lock-fontify-region`, `goto-address-fontify-region`, `bug-reference-fontify`, ... ] I still can't see in which way the specific details of how jit-lock chooses the BEG...END arguments and uses the returned `jit-lock-bounds` affects the authors of client functions. > I really don't understand why we are having this conversation. It's > almost as if you claimed that documenting non-trivial behavior is a > bad idea, or a luxury. But you cannot be seriously thinking that. I think it's a bad idea to document internal details, yes. Those who need to know those details can look at the code. But my understanding of what you're saying is that you don't consider "how `jit-lock-bounds` are used" to be an internal detail. Instead you consider these to be part of the "protocol" that the writer of client functions needs to know in order for those functions to work correctly. And I can't understand why you'd think that. I think even in the current situation, none of what we have discussed has prompted a need or desire to change client functions: they're oblivious to the change being discussed. The only part where it might be visible is in a new argument to `jit-lock-register` that would specify whether a client function would like to come first or not. > Excuse me, but the jit-lock-bounds was almost completely undocumented, > until I did that a few days ago. So what description are you alluding > to which has been valid? The implicit one that comes from the range of ways those client functions could be called in the past and how their return value could be used. The change makes almost no difference in this respect (it might change the frequency of some cases, but most of the behaviors that are possible in the new setup were also possible in the old setup). >> I don't see in what sense "the results will be different". >> Which results are you talking a bout? > The results of running jit-lock-functions. those which really perform > fontifications result in faces, others result in whatever they do. Yes, the code is different, so there are differences in the result of some internal steps. But those "results" are internal. Why would anyone care about them. Who and how or when would notice them? Do you claim that it can result in a different rendering on screen? Or do you claim that it can result in the need to write client functions differently? If so, could you give some kind of scenario where that could happen? If not, what else? Stefan