unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: Jim Porter <jporterbugs@gmail.com>,
	50538@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>,
	acm@muc.de, Lars Ingebrigtsen <larsi@gnus.org>
Subject: bug#50538: [PATCH] 28.0.50; electric-pair-mode fails to pair double quotes in some cases in CC mode
Date: Fri, 17 Sep 2021 18:12:57 +0000	[thread overview]
Message-ID: <YUTaqbD28eSEOUW8@ACM> (raw)
In-Reply-To: <87czp8fdmm.fsf@gmail.com>

Hello, João.

On Thu, Sep 16, 2021 at 21:51:13 +0100, João Távora wrote:
> Hello Alan,

> [I apologize in advance for any spelling mistakes, my spell checker has
> taken a vacation in this new operating system.]

> Alan Mackenzie <acm@muc.de> writes:

> > I think it is up to both of us to make this relationship less rocky.

> Agreed.  But I'm afraid I don't have much to add the discussion.  I've
> made all my points.  And so have you.

I was thinking more along the lines of coding, not discussion.

> I understand, though I respectfully disagree with your standpoint.
> And so do you, I hope.  I have, in a way, given up on this
> integration.  electric-pair-mode doesn't support cc-mode or any more
> directly derived from it "officially".  That harmony ended in Emacs
> 25.x, I believe (might have been 26.x).  After that, you may have some
> success with it, or you may not.

Why such a negative attitude?  CC Mode is an important package, and so
is electric-pair-mode.  There doesn't seem to be any intrinsic reason
why they shouldn't work together better.

> >>        (add-hook 'c-mode-common-hook
> >>                  (lambda ()
> >>                    (kill-local-variable 'electric-pair-inhibit-predicate)))))

> > Needless to say, my point of view with respect to the above is somewhat
> > different.  Succinctly put, the minor modes electric-.... are MINOR
> > modes, and are quite new.
> > In particular, they interfered with CC Mode features which had existed
> > for 20 years at the time.

> My belief is that the term "minor" (which you so emphasize) in the name
> "minor-mode" doesn't mean "less important" in any way.

No, that's not how I meant it.  It's more that the layout of the text on
the screen, and the process of changing it ARE the major mode.  Any
interference with the major mode in its primary role is a buggy
situation needing fixing.

> In my view, it means merely "transversal".  You've often pitched e-p-m
> and cc-mode against each other in terms of their relative ages,
> implying a hierarchy of importance, deference or prestige.

More a regret that when the electric-... modes were developed, they paid
no attention to CC Mode, even when the feature originated there.  This
was bound to lead to conflict sooner or later, and that is where we are
at now.

> My belief is that this is unproductive.  Emacs minor modes, old or
> new, are not less or more important.  All other things being equal,
> they don't deserve less or more care and attention than Major or "old"
> modes.  The only criteria to motivate a change is technical.

Right now, CC Mode binds post-self-insert-hook to nil when calling
self-insert-function, so as to get it functioning predictably, then
attempts to compensate later by calling e.g.
electric-pair-post-self-insert-function directly.  I think you'll agree
with me this is suboptimal.  I can't see any way of getting around it
without amendments to electric-pair-mode.

> > modes, and are quite new.  They were implemented in a way which
> > interfered with major modes,

[ .... ]

> > and I can't see there was any need for this.

> I hope you will first notice I didn't adjectify or make any value
> judgement on the motivation, necessity or pertinence of your work in CC
> mode.

You seem to me to be doing exactly this by declining to work to improve
the interface between CC Mode and e-p-m.

> Therefore, I would appreciate if you could return the courtesy.  If
> you can't personally "see" the need for my work or how it was
> performed, that's fine.

I can.  I can also see problems with it, and regret your very negative
attitude towards fixing problems in your own area of speciality.

CC Mode has existed in one form or another for around 40 years.  I think
it would be reasonable for a new minor mode to take due account of it
when being developed.  As far as I can see, this didn't happen with
electric-pair-mode to a sufficient degree.

> I don't demand that you do, though I have gone to some lengths in the
> past to inform you of the motivation.  But that isn't the same as
> there not being a such a need, or that I worked spuriously,
> gratutiously or recklessly or with the intent to interfere with
> anything.

I am not implying such, and don't believe I ever have done.

> In fact, the Git log and users memory records clearly that when e-p-m
> was first introduced in Emacs, it worked harmoniously with cc-mode for
> a number of years until cc-mode was modified by you to change that
> harmony.

The use of post-self-insert-hook to make buffer changes has never worked
well with CC Mode.  It cannot work in any major mode which uses
self-insert-command as part of a mode command.

You seem to be implying that my motivation in developing CC Mode was to
damage the workings of e-p-m.  I think that's somewhat uncalled for.  CC
Mode is under continual development, and has traditionally been at the
forefront of new techniques.  Electric indentation, subword mode, and
the correct fontification of unterminated strings are just three
examples of this.

When you drew attention to problems, I put considerable effort into
fixing and ameliorating these in CC Mode.

> Moreover, as far as I gather, electric-pair-mode is a fairly popular
> minor mode, so at least some significant group of people adhere to the
> same need that I saw.  Even e-p-m's now abandoned predecessor,
> "autopair"[1], is still fairly popular today.  Before archiving it some
> time ago, I was still seeing healthy download counts.  See also [2] for
> some Emacswiki user's (not me) account of the history and relationship
> between autopair, e-p-m and other autopairing solutions for Emacs.

Yes, CC Mode and e-p-m are both popular and important.  They don't work
well enough together.

> Now, to practical matters:

> * If CC-mode users agree with you about the absence of a need for such a
>   thing as e-p-m, they may simply not turn it on (same goes for
>   electric-layout-mode and electric-foo-mode I suppose).  I believe you
>   yourself and Eli are in this group.

I'm not in such a group.  I accept the need for e-p-m.  I just don't
want to use it myself.

> * If CC-mode users disagree with you, they must find some alternative to
>   CC-mode that lets them confortably turn on those modes there.  My two
>   self-described hacks are such alternatives.  Not ideal ones, but
>   reasonably workable.

Why don't you put some work in to make e-p-m work better with CC Mode?
Maybe I'm misremembering here, but when the problems raised themselves I
don't recall you making, or being prepared to make any amendments to
electric-pair-mode.  Why not?

> As a user, I chose the latter option.  I look forward to a different
> Major mode for editing C/CC code.  That is my personal ambition as a
> user.

You might have a long wait.  And people who run from things because they
don't like them often don't like what they find instead, either.

Are you saying that your aim is to _prevent_ e-p-m working well with CC
Mode?

> As a developer, changing electric-pair-mode's core principles that work
> harmoniously (if not downright flawlessly) for any other major mode not
> based on cc-mode is not on the table.

That's a bit callous, isn't it?  CC Mode is a highly important part of
Emacs, and you're deliberately not catering to it?  Why?

Why not amend e-p-m so that it will work harmoniously with _any_ major
mode, not just the simple ones?  Where's the difficulty?

[ .... ]

[ Details of particulars of electric-pair-mode operation read with
thanks. ]

> Best regards,
> João

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2021-09-17 18:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-12  3:58 bug#50538: [PATCH] 28.0.50; electric-pair-mode fails to pair double quotes in some cases in CC mode Jim Porter
2021-09-12  6:26 ` Eli Zaretskii
2021-09-12 18:05   ` Jim Porter
2021-09-15 22:17     ` Jim Porter
2021-09-16  5:25       ` Eli Zaretskii
2021-09-16 12:40         ` Lars Ingebrigtsen
2021-09-16 12:59           ` Dmitry Gutov
2021-09-16 13:17             ` Lars Ingebrigtsen
2021-09-16 17:04               ` João Távora
2021-09-16 17:11                 ` Eli Zaretskii
2021-09-16 17:33                   ` João Távora
2021-09-16 17:29                 ` Jim Porter
2021-09-16 19:05                 ` Alan Mackenzie
2021-09-16 20:51                   ` João Távora
2021-09-17 18:12                     ` Alan Mackenzie [this message]
2021-09-16 18:26         ` Alan Mackenzie
2021-09-16 20:49     ` Alan Mackenzie
2021-09-16 21:36       ` Jim Porter
2021-09-17 17:08         ` Alan Mackenzie
2021-09-23  2:01           ` bug#50538: [PATCH v3] " Jim Porter
2021-09-26 20:58             ` Alan Mackenzie
2021-09-28  4:57               ` bug#50538: [PATCH v4] " Jim Porter
2021-10-03 17:58                 ` bug#50538: [PATCH v5] " Jim Porter
2021-11-06  0:22                   ` bug#50538: [PATCH] " Lars Ingebrigtsen

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=YUTaqbD28eSEOUW8@ACM \
    --to=acm@muc.de \
    --cc=50538@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=joaotavora@gmail.com \
    --cc=jporterbugs@gmail.com \
    --cc=larsi@gnus.org \
    /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).