|
From: | Dmitry Gutov |
Subject: | bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes |
Date: | Wed, 29 Mar 2023 00:08:53 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 |
On 28/03/2023 14:32, Eli Zaretskii wrote:
Date: Tue, 28 Mar 2023 02:06:17 +0300 Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org From: Dmitry Gutov <dgutov@yandex.ru> On 27/03/2023 16:39, Eli Zaretskii wrote:Date: Mon, 27 Mar 2023 08:24:42 +0000 From: Gregory Heytings<gregory@heytings.org> cc: Eli Zaretskii<eliz@gnu.org>,wkirschbaum@gmail.com,casouri@gmail.com, 62333@debbugs.gnu.orgWhich is a fragile, semi-broken means, as we all know.What is a broken mess, is user-level narrowing. And how the downstream code can never guess the purpose the narrowing was applied for.Note that this is what labeled narrowings attempts to solve.Labeled narrowing cannot solve this because it does nothing to alleviate the problems with user-defined narrowing. So if the user narrows the buffer, we cannot do anything to safely widen in the general case, and labeled narrowing cannot help us.Is that because we don't think the user level narrowing is done purely for visual effect?Indeed, it isn't always for visual effect.
When isn't it? Is there a way to determine that from code?
judging by regular user requests for make this or that command ignore user-level narrowing, it seems like "purely visual" should be the default interpretation.I think you base your judgment on feedback from users who are not used to take advantage of narrowing in editing. I think most young people aren't, since this feature is more-or-less unique to Emacs.
Either narrowing should be used to change lexical/grammatical/etc context, or it should not. Do we have any documentation that says one or the other way? That should affect how Lisp code deals with narrowing -- which interactive functions should widen, and so on.
[Prev in Thread] | Current Thread | [Next in Thread] |