>>>> Wouldn't it make sense to also limit the portion of the buffer to 
>>>> which pre-/post-command-hook have access (see below)?
>>>
>>> Those generally don't belong to the display department, so I'd 
>>> hesitate doing so.  Which pre-/post-command-hook functions did you 
>>> find that cause slowdown because of long lines.
>>
>> jit-lock--antiblink-post-command
>
> OK, but is it TRT to "punish" every one of these hooks for the "crimes" 
> of the few?  Maybe we should instead handle the problematic ones 
> locally, by exposing the long_line_optimizations_p flag to Lisp (through 
> an accessor), and then modifying those that misbehave to "behave"?
>

It's the same problem than with fontification-functions.  We cannot know 
what all these hooks that are installed by major and minor modes will do, 
we cannot hope to fix them one by one, so it seems to me that with 
long_line_optimizations_p, which is an unusual case anyway, it makes sense 
to "punish" them all in the same way.

>> That's theory, isn't it?  With 64-bit builds we are limited to files 
>> that are less than 2047 Po.  No computer on this planet has that much 
>> RAM.
>
> You forget that we are talking about VM.
>
> But let's not restart that argument, okay?
>

Hmmm... okay 😉

>
> If JS mode wants to access the entire buffer for fontifications, then 
> IMO the problem is in JS mode, and should be fixed there. 
> narrow-to-region is available to Lisp programs as well ;-)
>
> IOW, it isn't an infrastructure problem that needs to be fixed in 
> display code.  (It is even possible that tree-sitter integration will 
> fix this, or at least alleviate it, as a side effect.)
>

Agreed.  My point was only that Emacs now behaves a bit better when 
editing a single-line very large file compared to a multi-line very large 
file.