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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> [ 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?

Ah, so the difference is in the way they're compiled.  The OS factor is
just "an accident".

> Yes I see. But for me it's definitely better not to pair in those
> situations

But you'll also do the opposite: if there's an extra " somewhere far in
the rest of the file (somewhere the user can't see and/or can't care
less about), and the user has added a spurious " nearby, she will expect
her next " to not-pair up (so as to complete the locally-unmatched, tho
globally matched quote), whereas your code will decide to pair.

> Anyway the "oh, it didn't pair..." disappointment is better than

Yes, but the code can go wrong both ways.

> "Something acceptible" then is "not pairing", just the self-insertion
> the user asked for, rught?

Yes.  Actually both pairing and non-pairing are acceptable.  What is not
would be to signal an error, for example.

> If (+ (point) <constant>) is less than (point-max) and inside a string
> we additionally assert that at least that string is paired.

Let's say (+ (point) <constant>) falls on the second line of the text
below:

   foo "bar" baz "toto
   titi
   tata "tutu" "blabla"

should it say "yup, we're within the string 'toto\ntiti\ntata ' or
should it say "no, we're not within a string"?

If we agree that using (point-max) is a bad idea, then the only other
option is to try and find some other spot in the buffer (and after
point) which is somehow known to be "outside of a string", and in
general we don't know how to find such a thing (point-max is the only
one we know in general).  Hence electric-pair-string-bound-function
(or give up on this idea and do something different).

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

I think this will fail when unmatched ' appear in comments.  You could
fix that by not changing the syntax-table, i.e. only replace syntax-ppss
with parse-partial-sexp, but then you'll find other cases (more corner-case
and harder to reproduce) where the lack of syntax-propertization causes
parse-partial-sexp to get it wrong (e.g. unmatched quotes in here-documents).


        Stefan