Re: Major modes using `widen' is a good, even essential, programming practice.

[Eli Zaretskii]

> Date: Sat, 6 Aug 2022 20:13:13 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Narrowing is primarily a user feature.  Users can arbitrarily narrow a
> buffer to ANY contiguous region of text.

This feature doesn't interfere with user-level narrowing.

> So when a major mode needs to examine text even slightly distant
> from point, it MUST widen

No, it doesn't.  It shouldn't.  If the buffer is narrowed, the
portions outside the narrowing don't exist, period.  That's how most
of Emacs behaves, starting from display and ending with navigation and
search commands.  With display, for example, narrowing a buffer in a
certain way can completely disrupt how bidirectional text is shown,
and yet we intentionally do nothing to avoid that.  Neither should any
major mode.

A mode is not exempt from obeying the narrowing.  It cannot claim that
it "knows better".  If some features of the mode work in suboptimal
fashion in the presence of narrowing, the mode has no business
"fixing" that -- it's what whoever did the narrowing wanted, so that
is what they should get.

> Also, in font locking, a major mode might need to examine text
> arbitrarily far from the fontification region.

It shouldn't.  The Emacs display code specifically asks the mode to
fontify only a relatively small chunk of text, and it does so for a
very good reason: performance, especially in large buffers.

That CC Mode unilaterally decided not to be bound by these
consideration is IMNSHO a very unfortunate decision, to say the least,
that causes us and me personally (as someone who works on C and C++
code a lot) a lot of grief.  Editing C/C++ code is lamentably becoming
more and more slow and sluggish with each new Emacs release, even on
moderately fast machines.  Significantly, it doesn't become more
stable, as bugs keep being reported.

As I've said many times, if this is the direction you think CC Mode
should be developed, I'd prefer less accurate fontification that would
give us simpler, faster, less buggy, and more easily maintained code.

My hope is that tree-sitter integration will perhaps solve this for
good, because frankly, I'm sorry to say that I've lost all hope that
CC Mode by itself will ever be fixed to perform better.

> For example, to know whether or not a particular place is inside a
> comment or a string, or to know whether to fontify a string opener
> with f-l-warning-face (when the string is unterminated) or
> f-l-string-face (for a validly terminated string).

If a string begins outside of the narrowing, it is not a string,
period.

> There's no "weren't supposed to do" involved anywhere.  Major modes,
> like all Emacs Lisp programs, have, by design, access to the full range
> of Emacs's facilities.

No, they don't, they shouldn't.  You have it backwards: the design of
Emacs in the presence of narrowing is to behave as if the text outside
of the restriction didn't exist.

> I've recently spent many hours reading the discussion for bug #56682 and
> its predecessor bug, and if I recall correctly, you have put the
> `widen'/ `narrow-to-region' "bug" into other hooks called from
> redisplay.  If I'm right, there, was there any specific reason for this?
> Like, did it dramatically speed anything up (and I'm not talking about a
> mere 10%, say, here)?

The speedups are dramatic.  You can easily try that yourself; the
recipe for doing that was described here many times.

> Several times in the thread when other posters have complained about the
> new long lines facility, you have invited them to "set
> long-line-threshold to nil".  That doesn't allow them to use the other
> benefits of the facility whilst retaining fully functional `widen',
> 'narrow-to-region' and font-locking.  Would it be possible, please, to
> add an option to enable such a mix of features?

Which "facility" are you talking about, specifically?  The changes
related to long lines involve locked narrowing in several places; they
don't involve anything else.