>>> 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.