From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-tree-sitter and Emacs Date: Fri, 03 Apr 2020 21:39:18 +0300 Message-ID: <831rp4wh0p.fsf@gnu.org> References: <83eeta3sa0.fsf@gnu.org> <86369ojbig.fsf@stephe-leake.org> <83lfnfz6jr.fsf@gnu.org> <864ku3htmb.fsf@stephe-leake.org> <83v9mix9vk.fsf@gnu.org> <87pncq55f8.fsf@md5i.com> <83imihyl42.fsf@gnu.org> <865zehgw5r.fsf@stephe-leake.org> <831rp5xbtp.fsf@gnu.org> <86h7y0fpnt.fsf@stephe-leake.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="26498"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 03 20:40:53 2020 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 1jKRFM-0006nO-Vq for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 20:40:52 +0200 Original-Received: from localhost ([::1]:59666 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKRFM-0001p6-1x for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 14:40:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54255) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKRE5-00015P-D9 for emacs-devel@gnu.org; Fri, 03 Apr 2020 14:39:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jKRE4-0002lW-PE; Fri, 03 Apr 2020 14:39:32 -0400 Original-Received: from [176.228.60.248] (port=2169 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jKRE3-0002ma-8y; Fri, 03 Apr 2020 14:39:31 -0400 In-Reply-To: <86h7y0fpnt.fsf@stephe-leake.org> (message from Stephen Leake on Fri, 03 Apr 2020 09:24:38 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246356 Archived-At: > From: Stephen Leake > Date: Fri, 03 Apr 2020 09:24:38 -0800 > > > I meant BEG_UNCHANGED and END_UNCHANGED. > > Ah; I was unaware of those. It would be good if these values were > accessible from modules and elisp. We can discuss this. It wasn't needed up until now. > Hmm. Browsing the emacs C source to see if there is such a function (I > didn't find one, but I could have missed it), I found this in keyboard.c: > > /* If the previous command tried to force a specific window-start, > forget about that, in case this command moves point far away > from that position. But also throw away beg_unchanged and > end_unchanged information in that case, so that redisplay will > update the whole window properly. */ > > BUF_BEG_UNCHANGED (b) = BUF_END_UNCHANGED (b) = 0; > > which means BEG_UNCHANGED can indicate changes when there are actually > none. Yes. This machinery exists for use by redisplay, and redisplay has its own methods of finding out what changed and where. These two values are optimizations that allow redisplay examine only part of the buffer for possible changes; it is okay to disable optimizations when unoptimized code produces the correct result.