From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: joaotavora@gmail.com (João Távora)
Cc: emacs-devel@gnu.org
Subject: Re: [patch] make electric-pair-mode smarter/more useful
Date: Mon, 16 Dec 2013 10:30:07 -0500 [thread overview]
Message-ID: <jwviouosu6n.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87fvps98qs.fsf@gmail.com> ("João Távora"'s message of "Mon, 16 Dec 2013 14:21:47 +0000")
> 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
next prev parent reply other threads:[~2013-12-16 15:30 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 23:31 [patch] make electric-pair-mode smarter/more useful João Távora
2013-12-07 2:09 ` Leo Liu
2013-12-07 2:36 ` Dmitry Gutov
2013-12-07 21:01 ` João Távora
2013-12-07 23:16 ` Stefan Monnier
2013-12-12 3:05 ` João Távora
2013-12-12 4:29 ` Dmitry Gutov
2013-12-12 11:26 ` João Távora
2013-12-12 16:30 ` Stefan Monnier
2013-12-12 17:06 ` João Távora
2013-12-12 20:12 ` Stefan Monnier
2013-12-13 2:55 ` Dmitry Gutov
2013-12-14 15:18 ` Stefan Monnier
2013-12-14 16:56 ` Dmitry Gutov
2013-12-15 1:39 ` Stefan Monnier
2013-12-16 0:35 ` João Távora
2013-12-16 3:34 ` Stefan Monnier
2013-12-16 19:26 ` João Távora
2013-12-17 1:54 ` Stefan Monnier
2013-12-18 2:43 ` João Távora
2013-12-18 15:32 ` João Távora
2013-12-23 14:41 ` João Távora
2013-12-24 14:29 ` Bozhidar Batsov
2013-12-07 23:07 ` Stefan Monnier
2013-12-12 3:01 ` João Távora
2013-12-12 18:08 ` Stefan Monnier
2013-12-13 1:02 ` João Távora
2013-12-13 2:32 ` Stefan Monnier
2013-12-15 22:10 ` João Távora
2013-12-16 3:22 ` Stefan Monnier
2013-12-16 14:21 ` João Távora
2013-12-16 15:30 ` Stefan Monnier [this message]
2013-12-16 18:40 ` Stefan Monnier
2013-12-16 19:06 ` João Távora
2013-12-17 1:42 ` Stefan Monnier
[not found] ` <CALDnm52AoShN891-L9=Cbng98UtYPEntzO+n_XDMmEL+UV0r-A@mail.gmail.com>
2013-12-16 19:02 ` Fwd: " João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwviouosu6n.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.