[Top][All Lists]

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

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

From: João Távora
Subject: Re: Emacs pretest -- electric-pair-mode change
Date: Sat, 12 Apr 2014 01:42:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Re-reading Kevin's message I think there are two separate things here:
>> * deciding if the buffer is quote-balanced for pairing purposes. That
>>   can indeed only be done according to your idea Stefan, i.e. finding a
>>   safe spot the we assert to be outside a string.
>> * after having obtained reliable info that the buffer is unbalanced, we
>>   can further decide if we want to surprise/disappoint the user. This
>>   might be argued I think: if we know that there is an unbalance but
>>   that it is outside the users view, decide to pair anyway.  If it is in
>>   the user's view, try to repair the unbalance by not pairing (this
>>   second bit is what is already done)
>> I don't know if I personally would like it, perhaps it can be a
>> customization option.
> For strings, if we know that position POS, which should be outside of
> a string, is inside a string, we know that there's an imbalance.  *But*
> we don't actually know where that imbalance comes from (it's just
> "somewhere before POS"), so we can't really tell if that imbalance is
> before or after window-end unless POS is itself before window-end.

I think you're right. But if there is unbalance and one of the following
is true:

* the first non-string position searching backwards from (window-end)
  downto (point) is sucessfully asserted to be outside a string, or

* there are no strings at all between (point) and window end (basically
  implies the previous point).

then I think it is doable, i.e. there is a case for autopairing despite
the unbalance. Not sure how useful, though. Needs prototyping, and I'm
not super-motivated to do it right now.


reply via email to

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