From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Fu Yuan Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Tue, 3 Aug 2021 08:00:46 -0400 Message-ID: References: <83eeban40n.fsf@gnu.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5989"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 03 14:02:27 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 1mAt7q-0001N9-Tz for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 14:02:26 +0200 Original-Received: from localhost ([::1]:38566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mAt7p-0004Ms-NF for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 08:02:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAt6L-0003Sz-Kn for emacs-devel@gnu.org; Tue, 03 Aug 2021 08:00:54 -0400 Original-Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]:46055) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mAt6J-00050i-Ha; Tue, 03 Aug 2021 08:00:53 -0400 Original-Received: by mail-qk1-x72b.google.com with SMTP id 190so19515434qkk.12; Tue, 03 Aug 2021 05:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YBJZlffMVu3/C9Xxb3hFQWkJ0usZnkFotipgBn1aVgo=; b=kHxCXOpzTid68Uacghyoz0hVMF1shXFnDNXyMH2dAX015CkLZ/2zdyd9SePjCNJCbH hRIO1ZoYRIeSABh1gGlDY0w73i0J+EwCrPNhCM8CPmMqPinNYKmxBCU/yKtqaH/DxfQJ k6QROT4WD9qwruWIKPjPL2kmTV+WhVYNufAkdiWtns4OahpCzuWFbnGYKqELgJD1kF+7 10tNbRaM7MUmvsPRocupKecHUtW/0Uh1pYbJ/04Ux/8nL3iMXQE+fBMmC08ibWSARPQE lQ6iJ0gsDyi2kDe6w3E9ipplFqtZFCijl2Md+zNxUcXpzZ8Sh9zT9pOpVk0oBfa7VA4D xoMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YBJZlffMVu3/C9Xxb3hFQWkJ0usZnkFotipgBn1aVgo=; b=RenFFunun2xmKRd9FlKPgfccL67pRhw/vwFL4VdahRF3pWunQ/niNR888QdEmovIEY WzMOQVWycXxwJvgUCR909YG0S8ruNGJaTthKc9nhDnCJyvGz7WlsWrIqUYgvfY235Bs6 BWgPEvzC9GIg7b1aylV546ozhgmJQ3AdEBcLrT2Dnu/06PyeQELN8K5uKixeNNZ99XmH Y0c/0jw7bA5wpQgafO9ebwzCyjVcuAgwJXKkWeFMOUKMRo9ACp42tQqpEQnEiDDRbqcv gt6KspxWrEwZ5YjWv+PEDGPosvh6MO2ooMAxaEPA6Z+uARsXf7qridMtfThjyfMpJoML jMxw== X-Gm-Message-State: AOAM530cZg4UFiQ4di2vUeX7VTmhQnhubtFGWycMaLjCDiPqzYkSurY5 3b2my0AFjPfcyu1px7m7EaA= X-Google-Smtp-Source: ABdhPJznhnHcINHrr8uERSDi8cR12dcO7iif8Tcd2tvNbzi+8OkwkDxqudL0ZCcsSXfWTu3Cf63PtQ== X-Received: by 2002:a37:6c1:: with SMTP id 184mr19940661qkg.454.1627992049152; Tue, 03 Aug 2021 05:00:49 -0700 (PDT) Original-Received: from ?IPv6:2607:fb90:a902:79bf:ece0:4f2a:436e:c17b? ([2607:fb90:a902:79bf:ece0:4f2a:436e:c17b]) by smtp.gmail.com with ESMTPSA id o18sm7987372qko.63.2021.08.03.05.00.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Aug 2021 05:00:48 -0700 (PDT) In-Reply-To: <83eeban40n.fsf@gnu.org> X-Mailer: iPhone Mail (17H35) Received-SPF: pass client-ip=2607:f8b0:4864:20::72b; envelope-from=casouri@gmail.com; helo=mail-qk1-x72b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:271964 Archived-At: > =E5=9C=A8 2021=E5=B9=B48=E6=9C=883=E6=97=A5=EF=BC=8C=E4=B8=8A=E5=8D=887:48= =EF=BC=8CEli Zaretskii =E5=86=99=E9=81=93=EF=BC=9A >=20 > =EF=BB=BF >>=20 >> From: Yuan Fu >> Date: Fri, 30 Jul 2021 10:17:22 -0400 >> Cc: Stephen Leake , >> Cl=C3=A9ment Pit-Claudel , >> Stefan Monnier , >> emacs-devel@gnu.org >>=20 >>> 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? >>=20 >> Yes, I do clip the change to the visible portion: >>=20 >> ts_record_change (ptrdiff_t start_byte, ptrdiff_t old_end_byte, >> ptrdiff_t new_end_byte) >> { >> eassert(start_byte <=3D old_end_byte); >> eassert(start_byte <=3D new_end_byte); >>=20 >> Lisp_Object parser_list =3D Fsymbol_value (Qtree_sitter_parser_list); >>=20 >> while (!NILP (parser_list)) >> { >> Lisp_Object lisp_parser =3D Fcar (parser_list); >> TSTree *tree =3D XTS_PARSER (lisp_parser)->tree; >> if (tree !=3D 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 =3D XTS_PARSER (lisp_parser)->visible_beg; >> ptrdiff_t visible_end =3D XTS_PARSER (lisp_parser)->visible_end; >>=20 >> ptrdiff_t visible_start =3D >> max (visible_beg, start_byte) - visible_beg; >> ptrdiff_t visible_old_end =3D >> min (visible_end, old_end_byte) - visible_beg; >> ptrdiff_t visible_new_end =3D >> min (visible_end, new_end_byte) - visible_beg; >>=20 >> ts_tree_edit_1 (tree, visible_start, visible_old_end, >> visible_new_end); >> XTS_PARSER (lisp_parser)->need_reparse =3D true; >>=20 >> parser_list =3D Fcdr (parser_list); >=20 > 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? Tree-sitter doesn=E2=80=99t care about the content in a change, it will re-s= can the buffer content when it re-parses. We only need to inform it the rang= e of the change, so it knows where to re-scan when it re-parses. When the bu= ffer is widened, we will tell tree-sitter that range [BUF_BEG, BUF_BEGV] has= changed, and it will re-scan that part when re-parsing. So the part outside= the narrowed region will be parsed correctly. Yuan=