GNU bug report logs - #50538
[PATCH] 28.0.50; electric-pair-mode fails to pair double quotes in some cases in CC mode

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Jim Porter <jporterbugs <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>, 50538 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#50538: [PATCH] 28.0.50; electric-pair-mode fails to pair double quotes in some cases in CC mode
Date: Thu, 16 Sep 2021 21:51:13 +0100

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 <at> 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 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.

>>        (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.  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.  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.

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

You mention "major modes" in the plural form, but it is fair for me to
point out that only sub-modes of the cc-mode which you command entirely
are in that set.  If I'm forgetting any others, you're welcome to
refresh my memory.

> 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.  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 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.  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.

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.

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.

* 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.

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.

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.

>> On the C++/C editing-front, I am eagerly waiting for Treesitter to
>> arrive so that is it becomes possible to write a new major mode for c++
>> and c from scratch.
>
> I am also looking forward to Treesitter, though I think starting a new
> C++ Mode from scratch would not be a good use of time, and would be
> needlessly disruptive for current CC Mode users.

I certainly didn't want to imply it would be _your_ time.  I believe
what other people do with the time they generously offer us is their
business.  Certainly, I wouldn't dream of implying that the features
you're adding to cc-mode's ever-growing code base are not a good use of
your time.  Furthermore, I think Emacs is fertile in alternative ways to
solve similar problems.  I know others disagree, but I think this is a
quality.

> Could you please express your expert view?  In Jim's opening post he
> implies that:
> (i) electric-pair-mode should be active inside comments.
> (ii) In some circumstances at least, typing a " immediately in front
>   of another " causes two "s to be inserted.  Are these circumstances
>   spelt out anywhere?
> (iii) Typing a " inside a string causes two "s to be inserted, leaving
>   point between the two new adjacent strings formed.  This feature is
>   not intended to work in C++ raw strings, or other similar multi-line
>   strings in other CC Mode modes.
> Are these three features all intended in electric-pair-mode?

(i) Yes.  Much as syntax tables and C-M-f , C-M-b, C-M-u,
    etc. navigation work is comments, so does e-p-m.

(ii) As you well note, it depends on the circumstances.

     The circumstances are well spelt out in the tests.  I can name one
     here.

     If you have the buffer with contents

       "hello"

     And you type a double quote at buffer ends, you get

       "hello"""

     This example was taken from one of the tests of the group
     'pair-some-quotes-skip-others', found in electric-tests.el, as I
     think you know.

     As I think you also know, the principle of
     'electric-pair-preserve-balance' stipulates that
     'electric-pair-mode' will only make 'self-insert-command' do
     "suprising electric behaviour" -- insert two delimiters or skip one
     -- if that action helps keep or improve the balance of said
     delimiter in the buffer.

     Therefore, if you find a circumstance where e-p-m inserts two
     quotes and that happens to _worsen_ the balancing of the buffer
     (i.e. creates an unterminated string somewhere where previously
     there wasn't), then you have found a bug in e-p-m.  In that case,
     please describe it clearly as a bug report.

     However, and very importantly, you must find this circumstance in
     any major mode _other_ than cc-mode.  Because -- as I've tried to
     make clear -- "all bets are off in cc-mode", so to speak.  So if
     you are finding this misbehaviour in e-p-m _in conjunction with
     cc-mode_, I wouldn't bother reporting it.  We've established that
     the solution that I would propose to you is very likely not going
     to appeal to you.

(iii) Yes.  That is the way that e-p-m always worked.  By behaving so,
      the balancing state of the buffer is preseved.

      Some packages, (like smartparens [3], I believe) will insert a
      single quote preceded by an escape character.  That action also
      keeps the balance.

      Perhaps e-p-m could accomodate this behaviour from smartparens.
      If some users would like it, I think it can be easily done.

Best regards,
João

[1]: https://github.com/joaotavora/autopair/
[2]: https://www.emacswiki.org/emacs/AutoPairs
[3]: https://github.com/Fuco1/smartparens

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.