|
From: | Dmitry Gutov |
Subject: | bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes |
Date: | Tue, 28 Mar 2023 02:06:17 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 |
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? There is, again, a fair amount of confusion there, but 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. And for harder narrowing, users could have a separate command, or a prefit arg, or etc.
When I'm talking user-level, I mean interactive 'C-x n', of course.
[Prev in Thread] | Current Thread | [Next in Thread] |