Re: [patch] make electric-pair-mode smarter/more useful

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

>> I think this change is for the worst.  I often rely on ".." pairing in
>> things like text-mode where they don't have `string' syntax.
> But if you "rely" on those in text-mode, isn't the correct thing to give
> them that syntax there?

Not really, because then font-lock would make use of it, and they're not
always properly balanced.  IOW, yes, kind of but it has downsides, so
being forced to do it is rather annoying.

Why would it be a problem to keep them there?

>> The explanation for removing (?\" . ?\") doesn't make much sense: you
>> seem to say that the list should be kept empty because balance can't be
>> provided, but until now balance wasn't provided either.
> I suggested in the docstring that before adding to this list, since it
> has priority, the lower priority buffer's syntax table should be used
> instead, as it also helps balancing.

Still: you changed the default on the grounds that "it doesn't work
well", but it's worked well enough so far.

>> Of course, when the syntax-table gives string syntax to ", then this
>> entry should be ignored since the syntax table gives more info, which
>> allows balancing.
> So you mean inverting the lookup order?

Yes.

> If so, it seems like a good idea.  I got the opposite idea from the
> original implementation of `electric-pair-syntax' and the mention of
> "regardless of major mode" in `electric-pair-pairs''s docstring.

In the original behavior, the order was largely irrelevant.

>> I suggest you use "text" rather than "non-code" in the variable names
>> (and indeed, the behavior in strings and comments should largely be the
>> same as in text-mode).
> I disagree, but won't insist.

On which part (the quoted text has at least 2 separate arguments)?

>> (save-excursion (car (syntax-ppss (point-max))))
> This works... but only for one kind of parenthesis. It incorrectly
> reports 0 for a buffer with '[)',

Ah, I guess that indeed introduces some complications, indeed.
Thanks for clearing things up.  You might give this obvious example
somewhere in a comment.

>> So I think we need a "electric-pair-preserve-balance" flag to control
>> those features.
> OK, but I would set it to t.

Yes, it should default to t (unless too many people complain).

>> The priorities can be added as symbol properties, so the "sort" function
>> doesn't need to know about the existing hooks.
> Sounds a bit overkill for this particular case, unless we
> make it more generic, like maybe adding this to add-hook's understanding
> of its APPEND arg. But OK.

I agree it's not too serious a problem, but, I think even in this case
it can slightly simplify the code, since the comparison function can be
a simpler (lambda (x y) (< (or (get x 'priority) 0) (or (get
y 'priority) 0))).  And additionally that might be useful for other
people's post-self-insert-hooks.

[ FWIW: I just added such priority support to add-function and
advice-add.  ]

>>> +(defvar electric-pair-non-code-syntax-table prog-mode-syntax-table
>> Why prog-mode-syntax-table, rather than (say) text-mode-syntax-table?
> Explained above, but I don't object to text-mode-syntax-table.

Can you give more concrete examples?

>> BTW, syntax-ppss will get majorly confused if you call it while
>> a different syntax-table is temporarily installed.
> Never bit me, but thanks for the heads-up.

It rarely bites, because in most cases syntax-ppss is pre-computed
during font-locking.  Which also means that when it does bite it tends
to do so in fleeting, apparently unexplainable and unreproducible ways.

>>> +  (setq-local electric-pair-skip-whitespace 'chomp))
>> 
>> Hmm... lemme think... well... maybe we can't keep it tentatively.
>> I suspect it will bite me sometimes, but let's give it a chance.
> I don't undestand: we "can" or we "can't" keep it?

Sorry, damn typo.  It was "can".

> No, it doesn't belong here, sorry :-) Some earlier attempt at making the
> related newline-between-pairs feature. But since you spotted it,
> shoudn't newline-and-indent also call the post-self-insertion hooks?

I guess so, yes.


        Stefan