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: Sun, 25 Jul 2021 22:03:38 +0300 Message-ID: <83a6maw705.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8199"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 25 21:04:53 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 1m7jQi-0001wi-Rq for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Jul 2021 21:04:52 +0200 Original-Received: from localhost ([::1]:50574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7jQg-0003cl-Vn for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Jul 2021 15:04:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7jPk-0002xY-1D for emacs-devel@gnu.org; Sun, 25 Jul 2021 15:03:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43238) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7jPj-0000X8-Lw; Sun, 25 Jul 2021 15:03:51 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3012 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 1m7jPj-00066i-9F; Sun, 25 Jul 2021 15:03:51 -0400 In-Reply-To: <86pmv66yqg.fsf@stephe-leake.org> (message from Stephen Leake on Sun, 25 Jul 2021 11:21:27 -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:271622 Archived-At: > From: Stephen Leake > Cc: casouri@gmail.com, cpitclaudel@gmail.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Sun, 25 Jul 2021 11:21:27 -0700 > > >> > But that's how the current font-lock and indentation work: they never > >> > look beyond the narrowing limits. > >> > >> And that's broken > > > > ??? Of course, it isn't: it's how Emacs has worked since v21.1. > > Ada (and other languages, but not all) requires the full file text to > properly compute font and indent; narrowing breaks that. Not relevant: if a major mode's fontification code knows it needs to do that, it will call 'widen'. The issue was what should the TS reader function do. My firm opinion is that it should not look beyond the restriction, because it isn't its business to make those decisions. If the caller needs to widen, it will. > >> unless the narrowing is for multi-major-mode. > > > > And what would you do in that case, if you allow TS to look beyond the > > restriction? > > In the multi-major-mode case, there is a separate parser for each > language, and each sub-mode region in the text would get its own parser > tree (ie, it acts like a separate file), and that parser tree is only > told about changes to those regions. So the parser will never try to > look outside the region; it doesn't need to know about narrowing. 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.