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: Kevin Rodgers
Subject: Re: Emacs pretest -- electric-pair-mode change
Date: Fri, 11 Apr 2014 08:42:52 -0600
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20

On 4/3/14 11:33 AM, Stefan Monnier wrote:
[ 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).

Would replacing (+ (point) <constant>) with (window-end) give reliable
behavior, from the user's perspective?  If the extra " is not visible,
it would not impact the result.

--
Kevin Rodgers
Denver, Colorado, USA




reply via email to

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