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: Wed, 28 Jul 2021 22:00:16 +0300 Message-ID: <83wnpas1q7.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6905"; 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 Wed Jul 28 21:03:08 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 1m8opf-0001YY-5g for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Jul 2021 21:03:07 +0200 Original-Received: from localhost ([::1]:51570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8opd-0006Wp-Bi for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Jul 2021 15:03:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57666) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8on3-0003ks-K8 for emacs-devel@gnu.org; Wed, 28 Jul 2021 15:00:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36140) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8on1-0000mK-Te; Wed, 28 Jul 2021 15:00:23 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1704 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 1m8on1-0000r0-8i; Wed, 28 Jul 2021 15:00:23 -0400 In-Reply-To: <24808548-23F4-4068-877E-37C7190A02B0@gmail.com> (message from Yuan Fu on Wed, 28 Jul 2021 14:46:03 -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:271778 Archived-At: > From: Yuan Fu > Date: Wed, 28 Jul 2021 14:46:03 -0400 > Cc: Stephen Leake , > cpitclaudel@gmail.com, > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > > The adherence to narrowing is for the use cases where TS is _always_ > > invoked on the same narrowed region. You seem to be thinking about > > changes in the narrowing while TS is parsing, or between consecutive > > re-parsing calls, but I see no interesting/important use cases which > > would need to do that. And if there are some tricky cases which do > > need this, the respective Lisp programs will have to deal with the > > problem. > > That makes sense. However it bring up a problem. Consider such a buffer: XXAAXX. Say lisp narrows to AA and creates a tree-sitter parser. Then lisp widens the buffer, and user inserts B in front of AA. Now the buffer is XXBAAXX. Emacs has two options to convey this change to the tree-sitter parser: 1) it does not, then tree-sitter still thinks the buffer is AA, essentially the portion where tree-sitter sees is pushed forward by one character, 2) it tells tree-sitter the user inserted a character at the beginning, then tree-sitter thinks the buffer is BAA. Which option is correct depends on how does lisp later narrows: if lisp narrows to AA, then option 1 is correct, if lisp narrows to BAA, then option 2 is correct. But how do we know which option is correct before lisp narrows? We don't need to know. The Lisp program which needs to handle this situation will have to figure out what is right in that case, "right" in the sense that it produces the desired results after communicating the changes to TS.