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 19:49:02 +0300 Message-ID: <83r1fluikh.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> 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="34350"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, stephen_leake@stephe-leake.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 26 18:49:57 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 1m83nh-0008m2-Ab for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 18:49:57 +0200 Original-Received: from localhost ([::1]:35220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m83ng-0003Hn-DF for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 12:49:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44044) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m83my-0002ay-VX for emacs-devel@gnu.org; Mon, 26 Jul 2021 12:49:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47804) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m83mx-00072u-Or; Mon, 26 Jul 2021 12:49:11 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4022 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 1m83mx-0006jC-DC; Mon, 26 Jul 2021 12:49:11 -0400 In-Reply-To: (message from Yuan Fu on Mon, 26 Jul 2021 12:40:31 -0400) 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:271654 Archived-At: > From: Yuan Fu > Date: Mon, 26 Jul 2021 12:40:31 -0400 > Cc: Stephen Leake , > Clément Pit-Claudel , > Stefan Monnier , > emacs-devel@gnu.org > > > Once again, we are talking about the function used by TS to read > > buffer text. Not about the parser or its caller. Low-level code, > > which knows nothing about the context, should never look beyond the > > restriction. > > It doesn’t harm for tree-sitter to see the rest of the buffer, it doesn’t modify anything, all it does it reading the text. OTOH, restricting tree-sitter to the bounds of narrows adds complexity for no benefit (as far as I can see). Which complexity does it add? You just compare with BEGV_BYTE instead of BEG_BYTE etc. If we let TS look where it wants, we will lose the ability to restrict it to a certain part of the buffer text. This is needed at least for some specialized modes, and is generally desirable, as it gives Lisp programs an easy way to impose such restrictions whenever they need. > Maybe narrowing is the context that low level code should ignore No other code in Emacs does, and for a good reason. > The only benefit that I can think of is “we firmly adhere to the ‘contract’ that no one can look beyond the narrowed region”, but is it a good contract? Is there really a contract in the first place? It served us very well until now, so yes, I think it's a good contract. > IMO, narrowing acts like masking tapes over the rest of the buffer, so that user edits like re-replace wouldn’t spill out. Demanding everything in Emacs to not have access to the rest of the buffer is dogmatic (in the sense that it is too rigid and is simply following the doctrine blindly). Again, this "dogma" is used and adhered everywhere else in Emacs by such low-level code.