From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs 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 Message-ID: <87czp8fdmm.fsf@gmail.com> References: <021853bf-0169-c158-ab3d-296b6c144e08@gmail.com> <83r1dufgxu.fsf@gnu.org> <94c7b4ec-813b-515f-d947-116c294dd74b@gmail.com> <716194ea-817f-eaad-f9ce-7d600ad359b1@gmail.com> <83k0jh9jn6.fsf@gnu.org> <87o88s3d87.fsf@gnus.org> <871r5o3biv.fsf@gnus.org> <87fsu4h2oa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13952"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Jim Porter , Lars Ingebrigtsen , 50538@debbugs.gnu.org, Dmitry Gutov To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 16 22:52:38 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQyN3-0003SV-PC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Sep 2021 22:52:37 +0200 Original-Received: from localhost ([::1]:52232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQyN2-0002vs-Jx for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Sep 2021 16:52:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQyMU-0002uk-N8 for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 16:52:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45171) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQyMU-00059o-FW for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 16:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQyMU-000765-8l for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 16:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Sep 2021 20:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50538 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 50538-submit@debbugs.gnu.org id=B50538.163182548527222 (code B ref 50538); Thu, 16 Sep 2021 20:52:02 +0000 Original-Received: (at 50538) by debbugs.gnu.org; 16 Sep 2021 20:51:25 +0000 Original-Received: from localhost ([127.0.0.1]:56717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQyLs-00074z-SJ for submit@debbugs.gnu.org; Thu, 16 Sep 2021 16:51:25 -0400 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:42989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQyLq-00074h-My for 50538@debbugs.gnu.org; Thu, 16 Sep 2021 16:51:23 -0400 Original-Received: by mail-wm1-f48.google.com with SMTP id u19-20020a7bc053000000b002f8d045b2caso5466249wmc.1 for <50538@debbugs.gnu.org>; Thu, 16 Sep 2021 13:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=FtmTkl6EjiY8YyXCrD0hRCU7wOdw2Zj0cbggJeuvwkE=; b=MNUseeuD4vFvH8/0SbfXS8Ak4fdnEoKKv1UELhiA93z6Fc0edDEbrAYh0IReIBiSJE iqTmFzNF37L4SGdp1VoauERN8Jr/+kH4LMOACNP825nco2DsX7WFnqSq7u+UCOIm0naW 4+CTte/wARd9M9R6VC4X+3ERp6szIK6yqq7WqwUCSj4uzRwzRi4t91UwBpiew2gyEvsE 3Pb50Yx1Bh//2bJ39MfI46FaAs8bP8Zavmp/QmiEOwlan/3UOlpnHQcEQ+yUeFqgNIT9 lYN9X8OIIvl4+IwPZwEcoxmet3jXWkeoQI0Q886nP6bBZmM2IsYMJT1mOJmY8hvYNH2f AVGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=FtmTkl6EjiY8YyXCrD0hRCU7wOdw2Zj0cbggJeuvwkE=; b=doeI0lQnE6CQv4rgDs9c1fgU00ZrDIVxDIF/ckaTTq4ibTjLV5uR65lMBCgOoxgg4u EipUfHRFisIcv0vLj51z/k0E/Tjjbl5h+j00XTO71lszDs0vj3qNdfemAo7PvTnWDSBW 74jBiQGmK7QSul9Hl4JLRMhT6rlEfniGLFRIEjWurLmWkfSd15KRI6o4hdfTmIWGMsTx 1xqyCpNdQlccegDA5LIcIoLQV3ujp4uxenWWy1qEjooyJ/9aRJcgykaDPmLtusKtJYnC k6Pz0jGJh7V5Er+yIKK6hSqsq6jtGLpufgEVQ7aaP3+uZq1mxBGXa0sldoUnsMtQ3G/o F+WQ== X-Gm-Message-State: AOAM533FWRSg+KVc+v/XleMHt5tLfxGl2Vy1vOdHvmAp4oZbiyE/7wAL VdZ+6UXlqYMONbAKG34Sf0+H+04ud7A= X-Google-Smtp-Source: ABdhPJwsJSXofK3u21tQ3BG8NQZ6bmH1ZZub6QyuTaRHbuTrg7eK09ISo3hn8PQhw2+dKCVMT/YBJw== X-Received: by 2002:a1c:4d7:: with SMTP id 206mr11972269wme.158.1631825476241; Thu, 16 Sep 2021 13:51:16 -0700 (PDT) Original-Received: from krug (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id r2sm4841063wrg.31.2021.09.16.13.51.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 13:51:15 -0700 (PDT) In-Reply-To: (Alan Mackenzie's message of "Thu, 16 Sep 2021 19:05:56 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214508 Archived-At: Hello Alan, [I apologize in advance for any spelling mistakes, my spell checker has taken a vacation in this new operating system.] Alan Mackenzie 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=C3=A3o [1]: https://github.com/joaotavora/autopair/ [2]: https://www.emacswiki.org/emacs/AutoPairs [3]: https://github.com/Fuco1/smartparens