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, 27 Jul 2021 16:59:37 +0300 Message-ID: <838s1rvovq.fsf@gnu.org> References: <83h7gw6pyj.fsf@gnu.org> <83y2a764oy.fsf@gnu.org> <83v95b60fn.fsf@gnu.org> <00DD5BFE-D14E-449A-9319-E7B725DEBFB3@gmail.com> <83r1fz5xr9.fsf@gnu.org> <1AAB1BCC-362B-4249-B785-4E0530E15C60@gmail.com> <83czri67h0.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> <83mtq8vqmn.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="10625"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org, stephen_leake@stephe-leake.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 27 16:01:17 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 1m8Ne0-0002WD-FS for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Jul 2021 16:01:16 +0200 Original-Received: from localhost ([::1]:56428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8Ndy-00077e-7E for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Jul 2021 10:01:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8NcX-0006Hf-QR for emacs-devel@gnu.org; Tue, 27 Jul 2021 09:59:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47524) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8NcX-0001Mf-DX; Tue, 27 Jul 2021 09:59:45 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1882 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 1m8NcX-0002r7-13; Tue, 27 Jul 2021 09:59:45 -0400 In-Reply-To: (message from chad on Mon, 26 Jul 2021 12:48:00 -0700) 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:271693 Archived-At: > From: chad > Date: Mon, 26 Jul 2021 12:48:00 -0700 > Cc: Yuan Fu , Clément Pit-Claudel , > Stephen Leake , Stefan Monnier , > EMACS development team > > I think I understand your point, and I agree that it would be ill-advised to remove the ability to change the > "scope" in question from lisp's control. What I'm trying to say (and I think Yuan Fu is also suggesting) is that > while emacs necessarily has *one* view of the buffer, narrowed or not, tree-sitter might want to maintain > multiple trees of that buffer, with the default being the same as emacs' widened view, and narrowed views > being separate parse trees created as needed. Lisp programs which use TS in a way that causes TS to store such multiple views will have to widen the buffer at strategic places (when TS needs access to buffer text). > I'm suggesting this as an alternative to having emacs+ts > effectively throw away most of the parse tree every time the user narrows, then have to re-build it on each > widen. No one says that when Emacs narrows a buffer for some reason, we need to communicate that immediately to TS. If the restriction is ephemeral, it will most probably be lifted by the time we need to update TS with the editing changes.