From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7% Date: Sat, 04 Sep 2021 17:56:14 +0300 Message-ID: <83a6kswfsh.fsf@gnu.org> References: <838s0eyyjg.fsf@gnu.org> <83eea5ygub.fsf@gnu.org> <835yvgyijv.fsf@gnu.org> <83eea4wilj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 04 16:57:17 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 1mMX6b-0001fi-6V for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 16:57:17 +0200 Original-Received: from localhost ([::1]:36106 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMX6Z-0001HK-Me for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 10:57:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMX5b-0000Xk-HL for emacs-devel@gnu.org; Sat, 04 Sep 2021 10:56:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33868) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMX5b-0007em-07; Sat, 04 Sep 2021 10:56:15 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3896 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMX5a-0008GP-3y; Sat, 04 Sep 2021 10:56:14 -0400 In-Reply-To: (message from Stefan Monnier on Sat, 04 Sep 2021 10:44:43 -0400) 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:273894 Archived-At: > From: Stefan Monnier > Cc: acm@muc.de, emacs-devel@gnu.org > Date: Sat, 04 Sep 2021 10:44:43 -0400 > > 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. We have the reason right before our eyes: what Alan needs to do. If these details are not important, why does he work on changing them? > 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. That's one thing to be documented (if being the first is indeed important). And you cannot explain that without telling something about how this stuff works. > > 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. According to Aristotle's logic, you can tell anything you want about a non-existing thing, and no one will be able to prove you wrong. > >> 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. They aren't internal, because faces are visible. > Do you claim that it can result in a different rendering on screen? That's one possibility, yes. And for the functions that do something other than fontifications, who knows what the results could be? > If so, could you give some kind of scenario where that could happen? Why do I need to come up with a scenario, when it's clear as a day that programming blindly to an insufficiently documented interface is asking for trouble?