From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Mon, 26 Jul 2021 14:44:24 -0400 Message-ID: References: <83h7gw6pyj.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: multipart/alternative; boundary="------------mmJ38Krwuwdshyd694ye5R70" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7049"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 26 20:45:19 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 1m85bL-0001e8-FV for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 20:45:19 +0200 Original-Received: from localhost ([::1]:53430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m85bK-00074j-Hw for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 14:45:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36556) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m85ab-0006OD-Lu for emacs-devel@gnu.org; Mon, 26 Jul 2021 14:44:33 -0400 Original-Received: from hacklheber.piermont.com ([2001:470:30:84:e276:63ff:fe62:3400]:51822) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m85aZ-0000lL-GM for emacs-devel@gnu.org; Mon, 26 Jul 2021 14:44:33 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with UTF8SMTP id A794D118 for ; Mon, 26 Jul 2021 14:44:24 -0400 (EDT) Original-Received: from [10.160.2.107] (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with UTF8SMTP id 78EFA2DE88E for ; Mon, 26 Jul 2021 14:44:24 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2001:470:30:84:e276:63ff:fe62:3400; envelope-from=perry@piermont.com; helo=hacklheber.piermont.com X-Spam_score_int: -22 X-Spam_score: -2.3 X-Spam_bar: -- X-Spam_report: (-2.3 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.438, 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:271657 Archived-At: This is a multi-part message in MIME format. --------------mmJ38Krwuwdshyd694ye5R70 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/26/21 14:32, chad wrote: > > 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.) > > 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. In > that sense, it seems like it's primarily a matter of what level of > itch people want to start scratching when. > >  emacs-dev islands discussion: > https://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00585.html > I strongly agree with what's said here. I'll also note that some languages will not parse correctly if you narrow to (say) only a block or part of a function and not a whole file, and it would be unexpected by users to narrow to a part of their code and suddenly have things like tree sitter go haywire. If I narrow to a part of a function, I'd like my indentation and highlighting to remain correct. My suggestion is that we at least experiment with allowing Tree Sitter to see the whole file or just the narrowed parts, and see what works in practice works better. Perry --------------mmJ38Krwuwdshyd694ye5R70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/26/21 14:32, chad wrote:

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.) 

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. In that sense, it seems like it's primarily a matter of what level of itch people want to start scratching when.  


I strongly agree with what's said here. I'll also note that some languages will not parse correctly if you narrow to (say) only a block or part of a function and not a whole file, and it would be unexpected by users to narrow to a part of their code and suddenly have things like tree sitter go haywire. If I narrow to a part of a function, I'd like my indentation and highlighting to remain correct.

My suggestion is that we at least experiment with allowing Tree Sitter to see the whole file or just the narrowed parts, and see what works in practice works better.

Perry


--------------mmJ38Krwuwdshyd694ye5R70--