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 12:48:00 -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> <83mtq8vqmn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000083181d05c80c08b6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1258"; 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 21:49:24 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 1m86bK-0000CU-NF for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 21:49:22 +0200 Original-Received: from localhost ([::1]:33650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m86bJ-0002tm-3L for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 15:49:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47618) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m86aF-0001Fu-Tn for emacs-devel@gnu.org; Mon, 26 Jul 2021 15:48:15 -0400 Original-Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:43985) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m86aD-0001lq-Vw; Mon, 26 Jul 2021 15:48:15 -0400 Original-Received: by mail-lf1-x12c.google.com with SMTP id f18so17517828lfu.10; Mon, 26 Jul 2021 12:48:13 -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=SSQL9MFUs9d1HTDMsSLXz+U5hKVF4nPZCs4r+JOvIA0=; b=PjzmPgZX11HLCc1JHGffc9rDXYsTyvt0ZzCl2LGPn2xix8ubhcNgaMpw0J0zVyFHvK 0GZ5Crc6OYeY8rm6l6gGqynd8orEuMUwog8VoPSIt/Z1JXxQ2tvoe5sO46Ud96yxjzc9 xUXG/u4d0gGromerMPGpj9Ls8kB7qvGSBVY5AR35ri7dTZjizQkCG8C9uNR0ZqDnXLnz NU8qrZ5EGQCegZsvipWqtXZX5tyOiHcEWQ65RkYgEzwrvnGT8jfC2NBCc25rG20AmzEQ 7bG8m3ifrgZRaPL+VR9XyaSIHAHvEJGU2GbMgzBl67lG1nTE8W8kQ+ZF6qy7gqZVCGMz WJdA== 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=SSQL9MFUs9d1HTDMsSLXz+U5hKVF4nPZCs4r+JOvIA0=; b=uD+dopMzUWoOgBZAfx6UFVL9I5RcuOOIVjO8BvsfcxV92mLYe0kdlw/NOVcoxzbaOs 1PBbSCt5nVhM3zIyrbZTwL/qGJkq4yJ0atQV3KG8bZg0EQHC1oKlYNQK6CMva8iOT744 GpSodsvsIdGfnWxP9c+ri0n1rl+MpE+p/kDID2UHeykuGqUQG8VSz4aeB9iJHeQcHHJk kYS/R+5xZKC1LuaBrVFD71xbnoAPWcaRdEiAtbOX79Xp2kLOBjGZclHyOiCSQ7dCPyn7 EzF88U8W9rKnWBRVOq6hgwzeUAhwATtynyjy+TDGAymtLiKRBsBI168UmNIpLM3iJGvL 4K/Q== X-Gm-Message-State: AOAM532z3FtqECwF0d3oRYqWo4z4O+BQb2AJNfEOMv589AE1yt8WVQsw +r8CEbqdBQetCOJ6db8kXqyCN3TvFs8ye7jyPNfIN6wrmbE= X-Google-Smtp-Source: ABdhPJxtYaewnqGhH8C+T4BmUU/TFY9En9s6LzmUiub5MShybTDm68RG9MFMD8urV08Era294BAISJnnbThztBi9aEE= X-Received: by 2002:ac2:4ec3:: with SMTP id p3mr13745083lfr.556.1627328891523; Mon, 26 Jul 2021 12:48:11 -0700 (PDT) In-Reply-To: <83mtq8vqmn.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=yandros@gmail.com; helo=mail-lf1-x12c.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:271667 Archived-At: --00000000000083181d05c80c08b6 Content-Type: text/plain; charset="UTF-8" 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. 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. In other words, I think this might be a communication issue about the default trade-off behavior: generally keep a fully-widened tree and create/use narrowed trees as needed, versus generally keeping only a tree that matches whatever a higher-level view of the buffer might give at any one moment, rebuilding each time. Hope that helps, ~Chad --00000000000083181d05c80c08b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I understand your point, and I agree that it would= be ill-advised to remove the ability to change the "scope" in qu= estion from lisp's control. What I'm trying to say (and I think Yua= n 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 tr= ees of that buffer, with the default being the same as emacs' widened v= iew, and narrowed views being separate parse trees created as needed. I'= ;m suggesting this as an alternative to having emacs+ts effectively throw a= way most of the parse tree every time the user narrows, then have to re-bui= ld it on each widen.

In other words, I think this might = be a communication issue about the default trade-off behavior: generally ke= ep a fully-widened tree and create/use narrowed trees as needed, versus gen= erally keeping only a tree that matches whatever a higher-level view of the= buffer might give at any one moment, rebuilding each time.

<= /div>
Hope that helps,
~Chad
--00000000000083181d05c80c08b6--