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: Thu, 12 Dec 2013 21:32:45 -0500 [thread overview]
Message-ID: <jwvd2l15wja.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87r49h7eby.fsf@gmail.com> ("João Távora"'s message of "Fri, 13 Dec 2013 01:02:41 +0000")
>> I think this change is for the worst. I often rely on ".." pairing in
>> things like text-mode where they don't have `string' syntax.
> But if you "rely" on those in text-mode, isn't the correct thing to give
> them that syntax there?
Not really, because then font-lock would make use of it, and they're not
always properly balanced. IOW, yes, kind of but it has downsides, so
being forced to do it is rather annoying.
Why would it be a problem to keep them there?
>> The explanation for removing (?\" . ?\") doesn't make much sense: you
>> seem to say that the list should be kept empty because balance can't be
>> provided, but until now balance wasn't provided either.
> I suggested in the docstring that before adding to this list, since it
> has priority, the lower priority buffer's syntax table should be used
> instead, as it also helps balancing.
Still: you changed the default on the grounds that "it doesn't work
well", but it's worked well enough so far.
>> Of course, when the syntax-table gives string syntax to ", then this
>> entry should be ignored since the syntax table gives more info, which
>> allows balancing.
> So you mean inverting the lookup order?
Yes.
> If so, it seems like a good idea. I got the opposite idea from the
> original implementation of `electric-pair-syntax' and the mention of
> "regardless of major mode" in `electric-pair-pairs''s docstring.
In the original behavior, the order was largely irrelevant.
>> I suggest you use "text" rather than "non-code" in the variable names
>> (and indeed, the behavior in strings and comments should largely be the
>> same as in text-mode).
> I disagree, but won't insist.
On which part (the quoted text has at least 2 separate arguments)?
>> (save-excursion (car (syntax-ppss (point-max))))
> This works... but only for one kind of parenthesis. It incorrectly
> reports 0 for a buffer with '[)',
Ah, I guess that indeed introduces some complications, indeed.
Thanks for clearing things up. You might give this obvious example
somewhere in a comment.
>> 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).
>> The priorities can be added as symbol properties, so the "sort" function
>> doesn't need to know about the existing hooks.
> Sounds a bit overkill for this particular case, unless we
> make it more generic, like maybe adding this to add-hook's understanding
> of its APPEND arg. But OK.
I agree it's not too serious a problem, but, I think even in this case
it can slightly simplify the code, since the comparison function can be
a simpler (lambda (x y) (< (or (get x 'priority) 0) (or (get
y 'priority) 0))). And additionally that might be useful for other
people's post-self-insert-hooks.
[ FWIW: I just added such priority support to add-function and
advice-add. ]
>>> +(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?
>> BTW, syntax-ppss will get majorly confused if you call it while
>> a different syntax-table is temporarily installed.
> Never bit me, but thanks for the heads-up.
It rarely bites, because in most cases syntax-ppss is pre-computed
during font-locking. Which also means that when it does bite it tends
to do so in fleeting, apparently unexplainable and unreproducible ways.
>>> + (setq-local electric-pair-skip-whitespace 'chomp))
>>
>> Hmm... lemme think... well... maybe we can't keep it tentatively.
>> I suspect it will bite me sometimes, but let's give it a chance.
> I don't undestand: we "can" or we "can't" keep it?
Sorry, damn typo. It was "can".
> No, it doesn't belong here, sorry :-) Some earlier attempt at making the
> related newline-between-pairs feature. But since you spotted it,
> shoudn't newline-and-indent also call the post-self-insertion hooks?
I guess so, yes.
Stefan
next prev parent reply other threads:[~2013-12-13 2:32 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 [this message]
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
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=jwvd2l15wja.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.