GNU bug report logs - #33794
26.1; electric-pair-mode breaks auto-newline minor mode of cc-mode

Previous Next

Packages: cc-mode, emacs;

Reported by: bea <at> klebe.blog

Date: Tue, 18 Dec 2018 17:48:02 UTC

Severity: normal

Found in version 26.1

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #65 received at 33794 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: João Távora <joaotavora <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 33794 <at> debbugs.gnu.org
Subject: Re: bug#33794: 26.1; electric-pair-mode breaks auto-newline minor
 mode of cc-mode
Date: Sat, 22 Dec 2018 12:33:28 +0000
Hello, João.

On Sat, Dec 22, 2018 at 03:22:47 +0000, João Távora wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > Hello, Beatrix.

> > As maintainer of CC Mode, I earnestly recommend you NOT to follow João's
> > suggestion.  It will not work, and will waste your time.

> What, exactly, will not work?

Can't say exactly, but a quick hack on some minor mode which violates
and attempts to duplicate the conventions of the major mode, not
intensively tested, is not going to work.

> > Even if it appears to work, you will end up picking out bugs for an
> > indeterminate period.

> What bugs?  If you know of any, it would be good to report them, right?

See above.

> > Basically, electric-pair-mode as it is currently built is incompatible
> > with CC Mode, as I have pointed out here, albeit somewhat
> > undiplomatically.

> > I suggest you do nothing until tempers amongst Emacs developers have
> > cooled down, and hopefully a genuine solution to the bug has been worked
> > out and implemented.

> If you don't like electric-layout-mode, don't use it.  I'm trying to
> develop an alternative to c-toggle-auto-newline ....

Which is the wrong thing to do.

> .... within the electric-*-mode frame.  It's an experiment which I
> don't even know if Stefan will agree to, but it seems to work.  If
> Beatrix wants to cooperate, why shouldn't she?

My reading of the situation is that Beatrix reported a bug,
expecting/hoping for it to be fixed, so that she can get on with her
work more effectively.  I don't think she wants to spend lots of time
debugging (which is our job).

> I'm not asking you to nuke c-toggle-auto-newline or anything, ....

It looks rather that we to me, I must say.

> .... but should we all be forced to use it?  I don't think it's
> sensible in a free software project, Alan (and my temper is quite cool
> when saying this :-))

Eh??  The auto-newline facility is there and is optional.  It is an
integral part of CC Mode.  Where is this "forcing" you're referring to?

I think the situation is that the various electric-... facilities can
only work with major modes designed in a particular restricted fashion -
they are not universal.  Your answer is to try and impose these
restrictions on all major modes.  That can't work, since we don't
control all such modes, and imposing restrictions is a Bad Thing
generally.

> Again, I said I don't have anything against making eletric-pair-mode
> compatible with c-toggle-auto-newline if someone comes up with a good
> solution that doesn't break e-p-m for other modes.  I will not invest
> time in looking into that solution, but you or someone else may, of
> course.

As I've said elsewhere, the key to the fix is fixing the breakage of
self-insert-command.  That is going to involve extensive changes to
electric-pair-mode, but will fix the problem rather than trying to work
around it.

My idea at the moment is to change from using post-self-insert-hook to
using post-command-hook, thus fixing self-insert-command.  There should
also be a buffer local variable holding the function to insert the
matching paren with, defaulting to self-insert-command, or similar.
Would this work, and if not, where would it fail?

Is there any documentation for the connections between
electric-pair-mode and the other electric-... facilities?

As I've also said elsewhere, the fundamental root of the current problem
is social: somebody inventing facilities which impose constraints on
Emacs in general, and imposing these on Emacs without public discussion.
That cannot end well, and it hasn't ended well.

> In the meantime let people explore alternatives, right?

It does not lie within my power to stop them.  ;-)

> João

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 6 years and 187 days ago.

Previous Next


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