From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Mon, 26 Jul 2021 11:32:23 -0700 Message-ID: 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: multipart/alternative; boundary="0000000000000fc45a05c80afad3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30609"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , EMACS development team , Stephen Leake , =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , Stefan Monnier To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 26 20:33: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 1m85QA-0007k2-Pt for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 20:33:46 +0200 Original-Received: from localhost ([::1]:43982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m85Q9-0008Pv-Rs for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 14:33:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m85P5-0007KW-Ua for emacs-devel@gnu.org; Mon, 26 Jul 2021 14:32:39 -0400 Original-Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:42785) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m85P4-0001RA-9Y; Mon, 26 Jul 2021 14:32:39 -0400 Original-Received: by mail-lf1-x132.google.com with SMTP id u3so17157530lff.9; Mon, 26 Jul 2021 11:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vFDE3Se7WZ6d17a6jRzY1P4/DJ2SjPH6XvzfWFAr0+w=; b=AQQxFKR5SHAACt/BAhMoXrWsybaI5wvIXpe2Knonu/PZJbdeqhKAHY7mHBkPrYTmyi irjGTGv/CegAhbwdpyMNZ8NreG4m0bqpKSv7sw3FTldlXqEw+/Bm+2h1LfIay7FZXLqo TLirsa+sVqg4WxMUI3DkXGt87P9z4xW5dOzOS0wuu3CYZGaStb6iRZKA9CzSGmDvQSZ9 COcBddY8ujVubzUzaJlMGWCYLKLVLBAgcwdRLJTKxQzB2Thanoo8DN7LGjW367hEM9ft fgMg8Xgj9XEvGN+JA8Kssavk7M9snIx+D+phB8+jhTXat6pLYaTdxVT5Rf2iEyPMfXna QMhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vFDE3Se7WZ6d17a6jRzY1P4/DJ2SjPH6XvzfWFAr0+w=; b=haWYjE8/92fAj7Lqbe7r1zcHbHPQrQMVQOrb97lngioPqXWq1un6UT3c89FIguS2d/ QM6D8SIt6u2//wTOGW0RbTLukBnm3MnuGNXqFIkL35AHu++cYg8V3XJTiN1HknSXm5J5 Xz5cd/p7XgKChwf68SlYctvbBYTR4/lzhR8vqjTDHVM2pSOnTZFCkFBy6DleEbq2eDrq MvenHJqgve9e1i3DMd3jW0Xy91gBmfw5thrKW9/k2l0oXBvbxhQWpx/Sz/p01oelhASK nWFmD0NMf4m4UMyvkLLyPyUxco2x+CGx5A5MOapapuHGj9pefT7GplKZe09lZ9A5mYGn nLcw== X-Gm-Message-State: AOAM53243BDTSuW+UHZkbKDcZRroqYZZG8AL/6B790jAjMBaJMe9Bm10 9gBs68mJnAWzWmBMGULZQdMjXOS3Cp5N9S9y1xwV3PerVpQ= X-Google-Smtp-Source: ABdhPJzkQGhb3FBKAth+xNDte8Bysp7JhQRNKAxS/vy8nnTGxCaeNGEvzzR3hjD4tdsrbBWAXnTsxkUi63ZX3Ajn5Oc= X-Received: by 2002:ac2:4da5:: with SMTP id h5mr13737224lfe.239.1627324354117; Mon, 26 Jul 2021 11:32:34 -0700 (PDT) In-Reply-To: <83r1fluikh.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=yandros@gmail.com; helo=mail-lf1-x132.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:271656 Archived-At: --0000000000000fc45a05c80afad3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 26, 2021 at 9:49 AM Eli Zaretskii wrote: > > It doesn=E2=80=99t harm for tree-sitter to see the rest of the buffer, = it > doesn=E2=80=99t modify anything, all it does it reading the text. OTOH, r= estricting > tree-sitter to the bounds of narrows adds complexity for no benefit (as f= ar > as I can see). > > Which complexity does it add? You just compare with BEGV_BYTE instead > of BEG_BYTE etc. > 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 Hope that helps, ~Chad --0000000000000fc45a05c80afad3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 26, 2021 at 9:49 AM Eli Z= aretskii <eliz@gnu.org> wrote:
> It doesn=E2= =80=99t harm for tree-sitter to see the rest of the buffer, it doesn=E2=80= =99t modify anything, all it does it reading the text. OTOH, restricting tr= ee-sitter to the bounds of narrows adds complexity for no benefit (as far a= s I can see).

Which complexity does it add?=C2=A0 You just compare with BEGV_BYTE instead=
of BEG_BYTE etc.

In order to exercise m= any 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 minimi= zed changes. If emacs+ts were to remove everything outside the narrow and t= hen re-add it each time something temporarily narrowed a file (say, to enha= nce mental focus), then emacs+ts would be (wastefully) throwing away some o= f the underlying=C2=A0assumptions 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 b= uffer from other parts. Tree-sitter has a separate abstraction for doing th= is -- the developer can have ts use different internal objects for differen= t 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.)=C2=A0

Using the ts multiple parsers support inside emacs+ts to "handle"= ; narrowing seems like a strong idea, but there are likely some complexitie= s involved in "switching" back and forth between the full-file pa= rse and the narrowed parse, plus making sure that the right parses are upda= ted 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= 9;s primarily a matter of what level of itch people want to start scratchin= g when.=C2=A0=C2=A0


Hope that helps,
~Chad
--0000000000000fc45a05c80afad3--