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: Mon, 26 Jul 2021 22:09:36 +0300 Message-ID: <83mtq8vqmn.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> 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="14795"; 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 Mon Jul 26 21:10:47 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 1m85zz-0003aB-K4 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 21:10:47 +0200 Original-Received: from localhost ([::1]:39152 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m85zy-0000bI-Mm for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 15:10:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41280) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m85z1-0008DH-SP for emacs-devel@gnu.org; Mon, 26 Jul 2021 15:09:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51816) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m85z0-00015x-73; Mon, 26 Jul 2021 15:09:47 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4646 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 1m85yz-00071A-QW; Mon, 26 Jul 2021 15:09:46 -0400 In-Reply-To: (message from chad on Mon, 26 Jul 2021 11:32:23 -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:271660 Archived-At: > From: chad > Date: Mon, 26 Jul 2021 11:32:23 -0700 > Cc: Yuan Fu , Clément Pit-Claudel , > Stephen Leake , Stefan Monnier , > EMACS development team > > In order to exercise many of its over-all benefits, tree-sitter builds and maintains a parse tree of the whole > file, and takes care to modify that tree in-place with minimized changes. If emacs+ts were to remove > everything outside the narrow and then re-add it each time something temporarily narrowed a file (say, to > enhance mental focus), then emacs+ts would be (wastefully) throwing away some of the underlying > assumptions that makes ts useful. > > Emacs' internals use narrow/widen *and mostly honor them at most levels* because they are emacs' > abstraction for separating parts of a buffer from other parts. Tree-sitter has a separate abstraction for doing > this -- the developer can have ts use different internal objects for different parts of the file. This allows editors > like Atom (a major influence on ts' original feature set) to support what emacs would call multiple major > modes. (Emacs could still use some help here, c.f. Alan's proposal for "islands" from a few years back.) We are mis-communicating. The issue is not _whether_ to allow TS to access most or all of the buffer text, the issue is _on_what_level_ should this be controlled. All I'm saying is that the right level is NOT the function which accesses buffer text, the right level is higher. At that higher level, if some parser (or even almost every parser) needs to access the entire buffer, some code should call 'widen'. By contrast, if the text-reading function always treats the buffer as widened, we will never be able to invoke a TS parser on a portion of the text, something that is needed by specialized features. It makes no sense to require those features to start using TS-specific means of restricting access to portions of the buffer to that effect, when a simple restriction is good enough and is already being used. > Using the ts multiple parsers support inside emacs+ts to "handle" narrowing seems like a strong idea, but > there are likely some complexities involved in "switching" back and forth between the full-file parse and the > narrowed parse, plus making sure that the right parses are updated when the buffer changes. With that in > mind, it might be easier to start with an emacs+ts prototype that always uses the full-file parse, and then > adding the "sub-parses" later. I disagree. The cost of having the text-reading function look only inside the restriction is very small: a single call to 'widen' in the caller. The cost of having that function ignore the restriction is much higher.