unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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



  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).