emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: [patch] make electric-pair-mode smarter/more useful
Date: Mon, 16 Dec 2013 10:30:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>    F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-c++-mode
>        With ""foo""bar", try input " at point 1. Should become """"foo""bar" 
> and point at 2

Why should it become """"foo""bar"?

>> We could have the two functions check a new defcustom
>> electric-pair-preserve-balance and if nil fallback on the old default.
> Yes, that's what I meant, too. OK. So in the existing 2 variables custom
> menu there will be basically 4 options:
> - "always" or "never" (depending on whether it's pair or skip)
> - "balance, maybe"    (the default we're discussing)
> - "balance, always"
> - "don't balance, be conservative"

Not sure what the "balance, always" refers to or why we need it, but
other than that, yes.  The "balance" entry will be a "balance maybe".

>>> 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?
> OK. So Emacs -Q, M-x electric-pair-mode and then in the scratch buffer
> go to some place in the comment's text and type a double quote. You get
> it autopaired. If you type it again you get a skip. OK.
> Now go back to the first quote and type it again. You get a skip. In my
> opinion, not so nice. Delete the first quote, go back some words and
> type another quote. You'll get an unbalanced string inside the
> comment. Again not so nice.
> Now if you do (setq electric-pair-text-syntax-table
> prog-mode-syntax-table) and repeat the second paragraph, you'll get
> results that I personally think are nicer.
> BTW these are exactly the results that you mostly loose if you do the
> `electric-pair--looking-at-mismatched-string-p' simplification above.

>> 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?
> I read it in `called-interactively-p''s docstring...

That's different: this `or' test is to distinguish between two different
notions of "interactively" (i.e. whether the user interactively
triggered this specific function, vs whether the function was called
using call-interactively).

> I mean, if one calls `newline-and-indent' from lisp it shouldn't call
> newline with interactive=t right?

Maybe, maybe not (it probably depends on the specific case), but since
it's very rarely called from Lisp, I think we'd better not worry about
it until someone reports an actual problem with it.

>>> +(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.
> Do they? The relative order is between them,

The whole point of using priorities is to make them not depend on each
other but on some external total order.

So blink-paren-post-self-insert-function gets 100 because it does
a sit-for so it has to be "at the very end".
electric-indent-post-self-insert-function gets 90 because it does some
generic post-processing which should end happen "towards the end,
without needing to be the absolute last".

For the other two, I don't know what to say, because I don't know why
they should come after "other functions" (i.e. why they're >0), nor why
pair is smaller than layout.

>   (put 'electric-pair-post-self-insert-function
>        'priority '(before electric-layout-post-self-insert-function))

No, the whole point is to eliminate mutual dependencies.  They should
know as little about each other as possible.

> In js-mode layout rules, pairing must come before layout, there's a test
> for that.

Do you know the underlying reason why the test fails if you do it the
other way around?

> Hmmm, I don't know if I have write privs.

Ah, indeed, you don't.  OK, send me your latest code and I'll install
it, thank you.


        Stefan



reply via email to

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