GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
>>> Emacs is not in the business of preventing people from shooting
>>> themselves in the foot. If we need this narrowing to be enforced
>>> because Emacs would otherwise crash, then it's OK, but if not, then we
>>> *should* provide a way to undo it.
>>
>> And how do you define "crash"?
>
> Core dump.
>
Aha, interesting! So an infinite loop is not a crash, according to that
definition?
>> Is Emacs becoming unresponsive because an operation takes say two
>> minutes to complete and cannot be interrupted a "crash"? Or is a
>> "crash" only a segfault?
>
> Try `M-: (use-global-map (make-keymap)) RET`
>
> Should we prevent users from doing that?
>
It's a misleading question. No "user" would ever do that. Sure, it's a
nice example, but only an Elisp hacker would do that, in the middle of a
debugging session, and they would do that on purpose (although perhaps
without knowing the effect in advance). Which has nothing to do with a
regular user who just opens a file.
>
> Let's focus on making it easy to make it work well, rather than making
> it impossible to make it work poorly.
>
You lost me here. I've read that sentence twenty times, and cannot
understand what you mean.
>> But you didn't answer my question: is it not possible to design a
>> version of syntax-ppss that would approximate, with some heuristics,
>> what syntax-ppss does, but on a smaller chunk of the buffer?
>
> The answer is basically "no" but even before getting there, I have to
> remind the reader that it hasn't really been requested.
>
It has, now 😉 Not "requested", however. I respectfully, with all due
respect, ask whether doing such a thing would be possible.
>
> In order to know if POS is within a string (which is one of the main
> uses of `syntax-ppss`), you basically need to know if there's an odd or
> even number of quotes before POS, which fundamentally needs to look at
> all the chars between POS and BOB. Of course we use a cache to try and
> avoid looking at them over and over again, but the cache can't be of any
> use the first time around.
>
But if you use heuristics, as I said, you don't need to look at all the
chars between BOB and POS. You try your best to guess, on a small (a few
kilobytes) portion of the buffer, where the strings most likely start and
stop. And if you're only right in 95% of the cases, that's more than
fine.
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.