Re: Emacs pretest -- electric-pair-mode change

[Stefan Monnier]

>> (since it will syntax-propertize any part of the buffer not yet
>> propertized).
> This suggests it's a kind of one-time delay per buffer, but that's not
> the case at least for the large python above

A modification at position X flushes all syntax propertization after X.
So it's a "one time delay" but only until the next buffer modification.

> The quote part does seem to be the most problematic.  In the big
> lisp/ldefs-boot.el I get just under a second on windows for pairing a
> parens, and should be much faster on linux.
[ Unrelated: it's odd that the speed should depend on the OS.  ]

BTW, while speed is a factor, it's not the only one: if the unpaired
string is very far away, the user might be very surprised/disappointed
by electric-pair's behavior (where it will pair when the user expects
it not to and vice-versa).

>> In many languages, strings can't span multiple lines, or they can
>> only do so if end-of-lines are somehow escaped.  Maybe we could use
>> that to try and reduce the scope of the test.
> Maybe (how?).

Don't know.  Maybe use a buffer-local variable like
electric-pair-string-bound-function which major-modes can set to
a function that jumps to some buffer position which should not be within
a string according to the language rules.  E.g. in C it could search for
"[^\\]\n".  In Python, I think that wouldn't help, since triple-quoted
strings can contain anything whatsoever, IIUC.  But python-mode could
use a heuristic and look for the next "thing that looks like code" and
hope that strings containing code will be rare enough.

> But even even in those languages, syntax (and fontification) works
> across newlines, so do we pair for the language or for the syntax?

In Emacs we often use the simplifying assumption that we only try to
make the code work right in the case where the buffer's content is
"correct" and if the buffer's content is "incorrect" then we reduce our
expectation to something like "we do something acceptable".  IOW, we
write the code assuming that the buffer is correct (and failing
gracefully if it is not).

In this case, of course, the test itself is trying to figure out if the
code is correct, so "assume that it is correct" needs to be refined.

> Anyway, best I can come up with right now is the following, but with
> frequent false negatives in oversize buffers. I don't know if I'd
> rather have false positives (meaning less electricity in oversize
> buffers)

Checking (nth 3 (syntax-ppss (+ (point) <constant>))) doesn't make much
sense, since we have no reason to assert that (+ (point) <constant>)
should be outside of a string.


        Stefan