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

[João Távora]

Stefan Monnier <address@hidden> writes:

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

I'm using two relatively similar dual-core machines. In windows I use
the builds of http://sourceforge.net/projects/emacs-bin/. Didn't I read
somewhere that these are compiled without optimization flags?

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

Yes I see. But for me it's definitely better not to pair in those
situations (you seem to agree with me in your explanation of the
"simplifying assumption" below). Anyway the "oh, it didn't pair..."
disappointment is better than finding the unpaired string later, and at
least in my workflow, leads me to try a one-off M-x check-parens and fix
stuff before I continue hacking.

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

Hmmm, sounds a little complicated, but will give it a go if all else
fails.

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

Ok we agree perfectly then. "Something acceptible" then is "not
pairing", just the self-insertion the user asked for, rught?

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

If (+ (point) <constant>) is less than (point-max) and inside a string
we additionally assert that at least that string is paired. If it's not,
we say "incorrect" which is always true. Otherwise we say "correct" and
risk a false judgement and a surprising pair. How often? Don't
know. Anyway I agree it's not a very good perfect heuristic.

What about this? Seems to be much much faster in the python buffer i've
been testing with (even on windoze :-)

    (defvar electric-pair-no-strings-syntax-table
      (let ((table (make-syntax-table)))
        (dotimes (char 256) ;; only searches the first 256 chars,
          (let* ((entry (aref table char))
                 (class (and entry
                             (syntax-class entry))))
            (when (and class (eq ?\" class))
              (modify-syntax-entry char "w" table))))
        table))
     
    (defun electric-pair--unbalanced-strings-p (char)
      (let ((table (make-syntax-table electric-pair-no-strings-syntax-table))
            (ppss (syntax-ppss)))
        (modify-syntax-entry char "\"" table)
        (with-syntax-table table
          (save-excursion
            (nth 3 (parse-partial-sexp (or (and (nth 3 ppss)
                                                (nth 8 ppss))
                                           (point))
                                       (point-max)))))))
         


João