[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
- Re: [patch] make electric-pair-mode smarter/more useful, (continued)
Re: [patch] make electric-pair-mode smarter/more useful, Stefan Monnier, 2013/12/07
- Re: [patch] make electric-pair-mode smarter/more useful, João Távora, 2013/12/11
- Re: [patch] make electric-pair-mode smarter/more useful, Stefan Monnier, 2013/12/12
- Re: [patch] make electric-pair-mode smarter/more useful, João Távora, 2013/12/12
- Re: [patch] make electric-pair-mode smarter/more useful, Stefan Monnier, 2013/12/12
- Re: [patch] make electric-pair-mode smarter/more useful, João Távora, 2013/12/15
- Re: [patch] make electric-pair-mode smarter/more useful, Stefan Monnier, 2013/12/15
- Re: [patch] make electric-pair-mode smarter/more useful, João Távora, 2013/12/16
- Re: [patch] make electric-pair-mode smarter/more useful,
Stefan Monnier <=
- Re: [patch] make electric-pair-mode smarter/more useful, Stefan Monnier, 2013/12/16
- Re: [patch] make electric-pair-mode smarter/more useful, João Távora, 2013/12/16
- Re: [patch] make electric-pair-mode smarter/more useful, Stefan Monnier, 2013/12/16
Message not availableFwd: [patch] make electric-pair-mode smarter/more useful, João Távora, 2013/12/16