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: How to add pseudo vector types Date: Tue, 03 Aug 2021 14:47:52 +0300 Message-ID: <83eeban40n.fsf@gnu.org> References: <83h7gw6pyj.fsf@gnu.org> <46BBFF88-76C3-4818-8805-5437409BEA93@gmail.com> <83wnpq46uk.fsf@gnu.org> <533BD53B-4E85-4E9E-B46A-346A5BBAD0F5@gmail.com> <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <8335s64v10.fsf@gnu.org> <5380C92B-6C15-4490-A1E0-1C3132DBB16A@gmail.com> <83k0li2shw.fsf@gnu.org> <86wnpg82v3.fsf@stephe-leake.org> <83lf5wyn0z.fsf@gnu.org> <86pmv66yqg.fsf@stephe-leake.org> <83a6maw705.fsf@gnu.org> <83r1fluikh.fsf@gnu.org> <88007ACB-31E5-440F-876D-9F43C8EE02CC@gmail.com> <86fsw05lom.fsf@stephe-leake.org> <8A3823DD-5D5A-4A33-8EF9-93F05497CE4C@gmail.com> <864kcf5cmv.fsf_-_@stephe-leake.org> <18D745F5-DBB1-46CC-91D3-4ADAA9D37AB9@gmail.com> <834kcetmly.fsf@gnu.org> <831r7itjc8.fsf@gnu.org> <24808548-23F4-4068-877E-37C7190A02B0@gmail.com> <83wnpas1q7.fsf@gnu.org> <83k0l9rvf5.fsf@gnu.org> <83fsvxrszr.fsf@gnu.org> <83czr1rpei.fsf@gnu.org> <83a6m5rmp4.fsf@gnu.org> <574573B6-8844-45CC-9ACB-D5F75AE465E5@gmail.com> <83sfzwqowk.fsf@gnu.org> <4F02FE4E-0B48-4A94-B1D4-8C4878F51493@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23615"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, stephen_leake@stephe-leake.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 03 13:49:34 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 1mAsvN-0005uG-Kv for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 13:49:33 +0200 Original-Received: from localhost ([::1]:58154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mAsvM-00065p-HI for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 07:49:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54458) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAsts-0004uh-OX for emacs-devel@gnu.org; Tue, 03 Aug 2021 07:48:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46912) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mAstr-0001n5-VP; Tue, 03 Aug 2021 07:47:59 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2858 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 1mAstr-0006Mp-Hr; Tue, 03 Aug 2021 07:47:59 -0400 In-Reply-To: <4F02FE4E-0B48-4A94-B1D4-8C4878F51493@gmail.com> (message from Yuan Fu on Fri, 30 Jul 2021 10:17:22 -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:271962 Archived-At: > From: Yuan Fu > Date: Fri, 30 Jul 2021 10:17:22 -0400 > Cc: Stephen Leake , > Clément Pit-Claudel , > Stefan Monnier , > emacs-devel@gnu.org > > > That said, it looks like the code is correct: you should record the > > changes in the entire buffer, but only pass to TS the changes inside > > the restriction BEGV..ZV that is in effect at the time of the re-parse > > call. Btw, I don't see the code that filters changes reported to TS > > by their positions against the restriction; did I miss something? > > Yes, I do clip the change to the visible portion: > > ts_record_change (ptrdiff_t start_byte, ptrdiff_t old_end_byte, > ptrdiff_t new_end_byte) > { > eassert(start_byte <= old_end_byte); > eassert(start_byte <= new_end_byte); > > Lisp_Object parser_list = Fsymbol_value (Qtree_sitter_parser_list); > > while (!NILP (parser_list)) > { > Lisp_Object lisp_parser = Fcar (parser_list); > TSTree *tree = XTS_PARSER (lisp_parser)->tree; > if (tree != NULL) > { > /* We "clip" the change to between visible_beg and > visible_end. It is okay if visible_end ends up larger > than BUF_Z, tree-sitter only access buffer text during > re-parse, and we will adjust visible_beg/end before > re-parse. */ > ptrdiff_t visible_beg = XTS_PARSER (lisp_parser)->visible_beg; > ptrdiff_t visible_end = XTS_PARSER (lisp_parser)->visible_end; > > ptrdiff_t visible_start = > max (visible_beg, start_byte) - visible_beg; > ptrdiff_t visible_old_end = > min (visible_end, old_end_byte) - visible_beg; > ptrdiff_t visible_new_end = > min (visible_end, new_end_byte) - visible_beg; > > ts_tree_edit_1 (tree, visible_start, visible_old_end, > visible_new_end); > XTS_PARSER (lisp_parser)->need_reparse = true; > > parser_list = Fcdr (parser_list); Hmm... so a change that begins before the restriction and ends inside the restriction will be sent as if it began at BEGV? And the rest of the change will be discarded? Shouldn't you split such changes in tow, send to TS the part inside the restriction, and store the rest for the future, when/if the buffer is widened?