From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie 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: Fri, 17 Sep 2021 18:12:57 +0000 Message-ID: References: <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> <87czp8fdmm.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38177"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , 50538@debbugs.gnu.org, Dmitry Gutov , acm@muc.de, Lars Ingebrigtsen To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 17 20:14:53 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 1mRINx-0009i7-5e for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Sep 2021 20:14:53 +0200 Original-Received: from localhost ([::1]:34894 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRINv-0008CT-Ki for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Sep 2021 14:14:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRIN8-0008BX-0i for bug-gnu-emacs@gnu.org; Fri, 17 Sep 2021 14:14:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49656) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRIN7-0001cN-PI for bug-gnu-emacs@gnu.org; Fri, 17 Sep 2021 14:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mRIN7-0000qb-LC for bug-gnu-emacs@gnu.org; Fri, 17 Sep 2021 14:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Sep 2021 18:14:01 +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.16319023873183 (code B ref 50538); Fri, 17 Sep 2021 18:14:01 +0000 Original-Received: (at 50538) by debbugs.gnu.org; 17 Sep 2021 18:13:07 +0000 Original-Received: from localhost ([127.0.0.1]:32969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRIMF-0000pH-1z for submit@debbugs.gnu.org; Fri, 17 Sep 2021 14:13:07 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:57243 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mRIMD-0000of-04 for 50538@debbugs.gnu.org; Fri, 17 Sep 2021 14:13:06 -0400 Original-Received: (qmail 74909 invoked by uid 3782); 17 Sep 2021 18:12:58 -0000 Original-Received: from acm.muc.de (p4fe159e7.dip0.t-ipconnect.de [79.225.89.231]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 17 Sep 2021 20:12:57 +0200 Original-Received: (qmail 8001 invoked by uid 1000); 17 Sep 2021 18:12:57 -0000 Content-Disposition: inline In-Reply-To: <87czp8fdmm.fsf@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:214576 Archived-At: 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 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).