From: Alan Mackenzie <acm@muc.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Fixing post-self-insert-hook.
Date: Sun, 19 Sep 2021 12:14:18 +0000 [thread overview]
Message-ID: <YUcpmnq9ZY27KkkA@ACM> (raw)
In-Reply-To: <874kahcx4h.fsf_-_@gmail.com>
Hello, João
On Sat, Sep 18, 2021 at 23:55:10 +0100, João Távora wrote:
> João Távora <joaotavora@gmail.com> writes:
> > it's just done. I've asked João about such an interface over the last
> > few years, now and then, but such has not yet been forthcoming.
> I've made my opinion clear now and then, over the years. But here I go
> again:
> 'electric-pair-post-self-insert-function' (aka e-p-p-s-i-f) existed
> before I have laid my programmer eyes on it. It's not an internal
> function, it has a defined protocol ....
It doesn't even have a doc string.
> .... and exists to be a member of 'post-self-insert-hook'.
Exactly. There is a need for a stable functional interface to
electric-pair-mode which CC Mode can use. Despite how little effort it
would be to create and formalise this, you have refused to do so over
the years.
> Its purpose is -- and has always been -- to insert aditional
> delimiters related to the one just typed or, alternatively, to delete
> the character just inserted when it happens to skip a closing
> delimiter.
Yes. Would you please write this into a doc string for
electric-pair-post-self-insert-function, together with information about
where that function gets its information from, and what it does with
point.
[ .... ]
> Nevertheless, if you want to extract things from e-p-p-s-i-f and use
> them in your function, you can refactor its innards. As long as you
> don't break anything (fortunately there are good tests) or convolute
> elec-pair.el's code beyond recognition. Don't expect me to spend my
> time any time in this effort: I won't. I think it would be a very gross
> waste of time. _My_ time, at least. You may convince someone else of
> that idea.
What a wonderful attitude for a maintainer. ;-(
You will perhaps recall bug #33794 "26.1; electric-pair-mode breaks
auto-newline minor mode of cc-mode". Despite a large part of the
problem lying within electric-pair-mode, I don't think you changed a
single line of your code to fix the problem. As a result, I was forced
to implement ugly workarounds, which are still there almost three years
later, the alternative being leaving the bug unfixed.
> My alternative suggestion, which I've offered now and then, over the
> years, is for you to study how cc-mode behaves when you bind the
> delimiter keys simply to 'self-insert-command' ....
You know full well that this is problematic.
> and refrain from re-inventing 'electric-pair-mode' inside cc-mode.
I sometimes wonder if such a reimplementation inside CC Mode might have
been less work than all the email exchange with you trying to get you to
fix things.
> I do this in my .emacs, and I see that other users have settled on the
> same practice. If you were to try that, you could theoretically
> arrive at the conclusion that it is possible to do everything cc-mode
> does today w.r.t. electricity via the existing interfaces of
> 'electric-pair-mode', 'electric-layout-mode' and
> 'electric-indent-mode'.
Sure, anything's possible. But doing so whilst retaining functionality
would fragment the code, and lead inevitably to bugs in what is
currently an exceptionally stable part of CC Mode.
> I must be honest. I don't really expect you arrive at that conclusion
> or even try that experiment.
No. I have a user base to consider.
> That's OK, I can't force anyone to reason the way I do. My personal
> hopes for C/C++/Java editing in Emacs are a completely new major mode
> where syntax is handled by TreeSitter and all the keys are bound to
> 'self-insert-command'. I'd bet good money that 'electric-pair-mode'
> is going to work there fine and with 0 configuration, like it does in
> all other major modes.
> With best regards,
> João
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2021-09-19 12:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 19:37 Fixing post-self-insert-hook Alan Mackenzie
2021-09-17 20:04 ` Stefan Monnier
2021-09-17 20:53 ` Alan Mackenzie
2021-09-17 21:45 ` João Távora
2021-09-18 6:08 ` tomas
2021-09-18 8:44 ` João Távora
2021-09-18 14:15 ` Stefan Monnier
2021-09-18 15:56 ` Alan Mackenzie
2021-09-18 18:03 ` Stefan Monnier
[not found] ` <CALDnm52z_8HyqdC92nrMgzOMOOq48h2MQ4pjbROBOsdm5N_cJg@mail.gmail.com>
2021-09-18 22:55 ` João Távora
2021-09-19 12:14 ` Alan Mackenzie [this message]
2021-09-19 12:36 ` João Távora
2021-09-19 12:59 ` Stefan Monnier
2021-09-19 14:57 ` Alan Mackenzie
2021-09-19 20:20 ` Stefan Monnier
2021-09-17 20:15 ` João Távora
2021-09-17 20:35 ` Alan Mackenzie
2021-09-17 20:48 ` João Távora
2021-09-18 5:59 ` Eli Zaretskii
2021-09-18 9:41 ` Alan Mackenzie
2021-09-18 5:50 ` Eli Zaretskii
2021-09-18 9:57 ` Alan Mackenzie
2021-09-18 11:04 ` Eli Zaretskii
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=YUcpmnq9ZY27KkkA@ACM \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
--cc=monnier@iro.umontreal.ca \
/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).