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: Thu, 29 Jul 2021 20:38:45 +0300 Message-ID: <83czr1rpei.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> 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="15908"; 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 Thu Jul 29 19:40:15 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 1m9A10-0003ws-M5 for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Jul 2021 19:40:14 +0200 Original-Received: from localhost ([::1]:35004 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9A0z-0007zh-Fr for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Jul 2021 13:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m99zx-0007Iw-Mg for emacs-devel@gnu.org; Thu, 29 Jul 2021 13:39:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43666) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m99zv-0004o8-ID; Thu, 29 Jul 2021 13:39:07 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1488 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 1m99zt-0008QA-S1; Thu, 29 Jul 2021 13:39:07 -0400 In-Reply-To: (message from Yuan Fu on Thu, 29 Jul 2021 12:59: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:271795 Archived-At: > From: Yuan Fu > Date: Thu, 29 Jul 2021 12:59:43 -0400 > Cc: Stephen Leake , > Clément Pit-Claudel , > Stefan Monnier , > emacs-devel@gnu.org > > >> I don’t think the current implementation guesses anything. Let me turn around and ask you what is TRT: if the buffer is xxxAAAxxx, and lisp narrows to AAA and creates a parser, parser sees AAA; now widen, user inserts BBB in front of AAA, what do we tell tree-sitter? Nothing changed, or BBB inserted at the beginning? > > > > Neither. We should tell TS that instead of AAA there's now > > xxxBBBAAAxxx, because the narrowing was removed. > > This is the common usage that I imagined: > > Narrow > Calls tree-sitter (for fontification etc) > Widen > > Users edit the buffer > > narrow > Calls tree-sitter (for fontification etc) > Widen > > Ideally, tree-sitter only sees the narrowed region because everytime it is called, the buffer is narrowed. However, tree-sitter doesn’t work that way, it needs to be updated when user edits the buffer, when the buffer is widened. If your goal is give lisp control of what tree-sitter sees, we can’t just give tree-sitter the whole buffer whenever the user makes some change. In the above scenario, then the Lisp program that narrows the buffer should figure out how to do that correctly. The call to TS will then express the changes in the narrowed region only. > > Anyway, you are once again bothered by a scenario that should not > > happen at all: a Lisp program should not call TS first with, then > > without narrowing (or the other way around). I don't see why such > > situation should happen, and if they do, the Lisp programs which need > > them will have to figure out what to do and how. > > Even if lisp always call tree-sitter with narrowing, we still need to update tree-sitter when the buffer is widened. No, I don't think so. Why would we need to? From the TS POV the text outside the restriction doesn't exist because it never sees it.