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

[João Távora]

Stefan Monnier <address@hidden> writes:

>>> [ 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
> Ah, so the difference is in the way they're compiled.

Of course, scheduling aside, in the end that's always true :-). I might
have misunderstood Eli Zaretskii's:

   http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00930.html

But in general, is the machine-code for windows builds exactly the same
(or very similar) as linux for things involved in these operations? If
so, how can I check the compile flags of a build? Because mine really is
slower. My OSX build is also much slower, FWIW, not as slow as windows
tho.

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

True, with this important detail: she had the second surprise coming,
since the spurious " she added nearby *didn't* pair, which is an early
indication of unbalacing.

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

It will be mistake itself say "everything's fine, proceed with the
pairing", which is one of the cases where it's wrong, as I had already
admitted. But when it says "it's wrong,.don't pair" it will be always
right. And if constant is made big enough the number of mistakes
decreases (though not by much I admit).

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

Hmmm I understand your idea better. Using that with a default
implementation returning (point-max) might be a good idea, modes that are
experiencing trouble can then write their complicated versions.

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

I see. I did that syntax-table change thinking *that* would make it
faster, but it was using `parse-partial-sexp' that did (why?). Anyway, I
think I could live with those cases of mispairings like those
here-documents. Do you have other prominent cases? I always think of
electric-pair-mode's balancing as a best-effort thing.