GNU bug report logs -
#62333
30.0.50; Issue with tree-sitter syntax tree during certain changes
Previous Next
Full log
View this message in rfc822 format
> Date: Tue, 28 Mar 2023 02:06:17 +0300
> Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
>
> On 27/03/2023 16:39, Eli Zaretskii wrote:
> >> Date: Mon, 27 Mar 2023 08:24:42 +0000
> >> From: Gregory Heytings<gregory <at> heytings.org>
> >> cc: Eli Zaretskii<eliz <at> gnu.org>,wkirschbaum <at> gmail.com,casouri <at> gmail.com,
> >> 62333 <at> debbugs.gnu.org
> >>
> >>>> Which 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.
> 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.
This bug report was last modified 2 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.