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

[Stefan Monnier]

>> On which part (the quoted text has at least 2 separate arguments)?
> Sorry, the second one. I like comments and strings to have prog-mode
> syntax, so I can get half-assed quote balancing there. So in my config
> I'll set `electric-pair-text-syntax-table'to `prog-mode-syntax-table'.

I'm not completely set on using text-mode-syntax-table.  I think I can
be convinced to try prog-mode-syntax-table.

> The buffer situation "())", for example, has too many closers. But, to
> help balance, you want it to *not* autopair at the beginning and *do*
> autopair at the end.

Maybe you could handle this by considering

   (- (car (syntax-ppss))
      (save-excursion (car (syntax-ppss (point-max))))

But that doesn't solve the mixed-parens issue.
      
> Your simplification for `electric-pair--looking-at-mismatched-string-p'
> was also found to fail some tests, so I kept my previous naive
> version.

It'd be useful to keep track of which ones.

>> You might give this obvious example somewhere in a comment.
> I added a section there in the middle explaining the gist of it.

Great, thanks.

>>>> 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).
> Here too, I've kind of changed my mind :-) Balancing can already be
> turned off by customizing two variables:
>   electric-pair-inhibit-predicate
>   electric-pair-skip-self

The thing is that the two kinda go together.  Having to tweak both
together sounds like "coding" rather than "configuring".

> Lastly, if you insist, then do create `electric-pair-preserve-balance'
> variable and set the above two vars to 2 new "default" functions that
> check it and delegate to the "balance" functions appropriately. However
> i think that defeats the kind simplicity of the defcustom (though I
> don't much use `custom').

We could have the two functions check a new defcustom
electric-pair-preserve-balance and if nil fallback on the old default.

>>>>> +(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?
> Explained above again.  Using prog-mode-syntax-table allows me to get
> some quote balancing in comments and strings.

This is not really an example, let alone example*S*.  Which quotes?
Why are they there?  Is it only for quotes?

> It also does when it detects it's in c-mode or c++-mode, since in my
> testing syntax-ppss is sometimes broken there (tried in in
> src/syntax.c)

I'm not really surprised, sadly, but please report it as a bug (the fix
is probably to make cc-mode use syntax-propertize-function, which is
not a quick&easy fix since cc-mode currently sets the syntax-table in
a very contorted way spread over various places and times).

>>> shoudn't newline-and-indent also call the post-self-insertion hooks?
>> I guess so, yes.
> OK.  And is the `(not (or executing-kbd-macro noninteractive))' valid?

I don't understand why you'd want (not (or executing-kbd-macro
noninteractive)) rather than any non-nil constant.  Where does this (not
(or executing-kbd-macro noninteractive)) come from?

> +(put 'electric-pair-post-self-insert-function   'priority  20)
> +(put 'electric-layout-post-self-insert-function 'priority  40)
> +(put 'electric-indent-post-self-insert-function 'priority  60)
> +(put 'blink-paren-post-self-insert-function     'priority 100)

These belong next to the corresponding functions.

Also, if you know why the order is this way, please add comments
explaining it (I do know for blink-paren-post-self-insert-function and
electric-indent-post-self-insert-function, but not sure why
electric-layout-post-self-insert-function should come after
electric-pair-post-self-insert-function rather than the opposite).

> +(defcustom electric-pair-skip-whitespace t
> +  "If non-nil skip whitespace when skipping over closing parens.
> +
> +The symbol `chomp' specifies that the skipped-over whitespace
> +should be deleted.
> +
> +Can also be a function of no arguments, in which case that function's
> +return value is considered instead."

This docstring still needs to be improved, because it still doesn't
explain what really happens.  More specifically, which whitespace
is skipped (before or after the skipped paren?).

Other than those nitpicks, feel free to install those changes,


        Stefan