emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: Emacs pretest -- electric-pair-mode change
Date: Thu, 03 Apr 2014 16:54:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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

It basically means that we'll always say "don't pair" if (+ (point)
<constant>) is before the last quote in the buffer.  If (+ (point)
<constant>) is not near point-max then it'll basically "always" be
before the last quote.  So this heuristic reduces to "only try to pair
in the last <constant> chars of the buffer".

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

Right.

> I see. I did that syntax-table change thinking *that* would make it
> faster, but it was using `parse-partial-sexp' that did (why?).

Because it avoids syntax-propertize.

> Anyway, I think I could live with those cases of mispairings like
> those here-documents.

Right, but a "mispairing" will throw off all your pairing decisions
before that mispairing.  So a mispairing near the end of the file will
throw off your algorithm pretty much all the time, and the user won't
understand it because if/when she decides to go look at the end of the
file, the problem disappears.

I.e. then it *really* becomes unpredictable.  And the frequency of
those mispairing depends on the major-mode, since some major modes
depend more on syntax-propertize then others.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]