From: "João Távora" <joaotavora@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 73688@debbugs.gnu.org, marc@soda.fm,
Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>,
monnier@iro.umontreal.ca
Subject: bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode
Date: Sat, 30 Nov 2024 12:30:43 +0000 [thread overview]
Message-ID: <CALDnm52P+PNY01rehdCHEP=p4sSv6f6SJ9i_uzMeOTAVeC9bMw@mail.gmail.com> (raw)
In-Reply-To: <86frn981ix.fsf@gnu.org>
On Sat, Nov 30, 2024 at 10:22 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > Implementing it would lead to deprecating
> > electric-pair-inhibit-predicate(should be still working though for X
> > major versions), and beyond this use-case there doesn't seem to be that
> > many other use cases for inhibit-predicates anyway. But this would give
> > us a lot more flexibility for whenever they appear, since this seems to
> > be the proper solution here.
>
> Stefan and João, any comments or suggestions?
I see some talk of multiple ORd predicates, and deprecating electric-pair-i-p
saying it's not flexible, and I don't think that's true.
I don't think it's a good idea to hardcode in some intermediate level of
just-what-I-want customization when there are already two levels:
- a relatively blunt customization-based one that fits a majority of users,
- a finer-grained powerful based on Elisp add-function one that fits
very specific
needs.
To me that's a good example of Alan Kay's “Simple things should
be simple; complex things should be possible.".
So I think it's a better idea to add snippet examples to the documentation
that describe how to achieve these complex things.
João
next prev parent reply other threads:[~2024-11-30 12:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 3:10 bug#73688: [PATCH] electric-pair-mode - preserve balance in conservative mode Marc Soda
2024-10-12 12:21 ` Eli Zaretskii
2024-10-12 19:47 ` Marc Soda
2024-10-12 20:36 ` João Távora
2024-10-12 20:43 ` Marc Soda
2024-10-12 23:36 ` João Távora
2024-10-17 16:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-26 17:48 ` Marc Soda
2024-10-26 18:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-09 9:22 ` Eli Zaretskii
2024-11-09 10:30 ` Nikolay Kudryavtsev
2024-11-09 15:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-10 14:28 ` Nikolay Kudryavtsev
2024-11-23 12:22 ` Eli Zaretskii
2024-11-23 17:37 ` Nikolay Kudryavtsev
2024-11-30 10:21 ` Eli Zaretskii
2024-11-30 12:30 ` João Távora [this message]
2024-12-01 10:25 ` Nikolay Kudryavtsev
2024-12-01 12:27 ` João Távora
2024-11-23 17:29 ` Marc Soda
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='CALDnm52P+PNY01rehdCHEP=p4sSv6f6SJ9i_uzMeOTAVeC9bMw@mail.gmail.com' \
--to=joaotavora@gmail.com \
--cc=73688@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=marc@soda.fm \
--cc=monnier@iro.umontreal.ca \
--cc=nikolay.kudryavtsev@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).