From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#15478: cc-mode does not obey electric-indent-mode Date: Wed, 2 Oct 2013 20:07:37 +0000 Message-ID: <20131002200737.GA3895@acm.acm> References: <20130928201147.GC11317@acm.acm> <20130929091017.GA3161@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1380744623 8157 80.91.229.3 (2 Oct 2013 20:10:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Oct 2013 20:10:23 +0000 (UTC) Cc: 15478@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 02 22:10:26 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VRSkY-00008t-B9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Oct 2013 22:10:22 +0200 Original-Received: from localhost ([::1]:37686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRSkX-0000Ty-Ly for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Oct 2013 16:10:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRSkN-0000Sz-0M for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2013 16:10:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRSkF-0008AO-Kw for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2013 16:10:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRSkF-00089n-I4 for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2013 16:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VRSkE-0005D4-Fw for bug-gnu-emacs@gnu.org; Wed, 02 Oct 2013 16:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Oct 2013 20:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15478 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15478-submit@debbugs.gnu.org id=B15478.138074456819963 (code B ref 15478); Wed, 02 Oct 2013 20:10:02 +0000 Original-Received: (at 15478) by debbugs.gnu.org; 2 Oct 2013 20:09:28 +0000 Original-Received: from localhost ([127.0.0.1]:50189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRSjg-0005Bu-0m for submit@debbugs.gnu.org; Wed, 02 Oct 2013 16:09:28 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:56482 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRSjd-0005Bk-Hq for 15478@debbugs.gnu.org; Wed, 02 Oct 2013 16:09:26 -0400 Original-Received: (qmail 13462 invoked by uid 3782); 2 Oct 2013 20:09:23 -0000 Original-Received: from acm.muc.de (p5492CAA7.dip0.t-ipconnect.de [84.146.202.167]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 02 Oct 2013 22:09:22 +0200 Original-Received: (qmail 4342 invoked by uid 1000); 2 Oct 2013 20:07:38 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78869 Archived-At: Hi, Stefan. On Mon, Sep 30, 2013 at 02:23:55PM -0400, Stefan Monnier wrote: > > I'm not familiar enough with these other modes to be able to say. But > > what exactly are you saying here? Even if CC Mode is not different from > > the other modes, that doesn't change the fact that electricity must be > > enabled by default in CC Mode. > I don't see anything that requires electric-indent to be enabled by > default in cc-mode. Without electricity, correct indentation would require continual pressing of the key. E.g., in C Mode, k&r style (set with C-c .), enter the following, pressing C-j at the end of each line: 1. int foo (bar) 2. { 3. if (foo) 4. | "|" indicates the position of point. Now type "{". With electricity, the "{" is instantly indented to its correct position under the "if". Without electricity, the user needs to remember to type before C-j on L4. This is an unacceptable default state, IMAO. > Most major modes don't enable electric-layout by default (and AFAICT > most users care more about "indent after newline", which cc-mode > doesn't enable anyway). "Indent after newline" seems redundant in CC Mode; the line will have been electrically indented by the semicolon, brace, or comma typed just before the C-j. Are you saying that, in CC Mode, users would prefer electric indentation on the C-j rather than the semicolon, etc.? If so, what evidence do you have for this? > So, yes, I do think that the default behavior of cc-mode should be changed. Such a change could involve extensive work - the electric behaviour is coded individually in defuns like `c-electric-brace' and includes more electric behaviour than just indentation - for example, auto-newlining. > > Perhaps not, but there is a good deal of thinking and scheming needed > > before this can be done. For CC Mode simply to `and' in the variable > > electric-indent-mode when testing c-electric-flag would cause breakage, > > confusion and bug reports. Or perhaps should CC Mode set a buffer-local > > copy of e-i-m to t at initialisation? Should C-c C-l be extended also > > to toggle e-i-m? And so on.... > There are several separate issues, and they can be handled somewhat > separately. First, let's see what we'd ultimately want to have as > behavior, disregarding backward compatibility and preservation of > previous behaviors. As an exercise, yes. But disregarding existing behaviour should not be done frivolously; CC Mode's electric behaviour has been remarkably stable, with (as far as I am aware) only one complaint about it (not counting the current one) in at least 12 years (see below). > For me, I'd like cc-mode to do as little as possible besides adding > ?\;, ?\{, and ?\} to electric-indent-chars. These characters should not trigger electric indentation when typed inside a string or a comment. electric-indent-mode isn't best placed to make such distinctions. It doesn't seem to be the Right Thing to split the electric activity between electric-indent-mode (for indentation) and c-electric-brace and friends (for auto-newlining and clean-ups). > I'm not convinced there's a real need for a key binding that toggles > electric-indent buffer-locally, but if there is, then I don't see why > cc-mode needs it more than any other mode. There was a complaint sometime at or before 2005 that CC Mode text was "jumping all over the place", from a new Emacs user. The solution, after some discussion (in which you were involved) was to introduce `c-electric-flag' with C-c C-l to toggle it. That way, the newbie can easily disable the electricity, yet equally easily experiment with turning it on as soon as she feels she has got some control back again. It is a handy toggle to have around when editing chaotically indented code, or indeed small amounts of code indented differently from the current style. ######################################################################### I think electric-indent-mode, as it currently is, is capable of improvement. It is a single flag, but really needs to be major-mode dependent; it fouls up Python indentation (unless that's been recently fixed) and I think I recall reading that it messed up something in Outline Mode; yet CC Mode needs electricity. electric-indent-mode needs to be buffer local. Each major mode needs its own default for e-i-m: something like `electric-indent-mode-alist', analogous with `auto-mode-alist'. This default would be consulted at mode initialisation time. A buffer's setting of e-i-m should also be more than just nil or t. That is inflexible to an un-Emacs like degree. At the very least, there should be some sort of setting that means "electric indentation is performed entirely by the major mode". > Stefan -- Alan Mackenzie (Nuremberg, Germany).