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: Thu, 3 Oct 2013 10:56:00 +0000 Message-ID: <20131003105600.GB3211@acm.acm> References: <20130928201147.GC11317@acm.acm> <20130929091017.GA3161@acm.acm> <20131002200737.GA3895@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1380797902 29178 80.91.229.3 (3 Oct 2013 10:58:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Oct 2013 10:58:22 +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 Thu Oct 03 12:58:24 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 1VRgbt-0003cp-D5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Oct 2013 12:58:21 +0200 Original-Received: from localhost ([::1]:42069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRgbt-0003DE-4C for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Oct 2013 06:58:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRgbi-0003D4-Vl for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2013 06:58:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRgbb-0006eu-Jq for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2013 06:58:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRgbb-0006eq-Fn for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2013 06:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VRgba-0000a8-OG for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2013 06:58: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: Thu, 03 Oct 2013 10:58: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.13807978762224 (code B ref 15478); Thu, 03 Oct 2013 10:58:02 +0000 Original-Received: (at 15478) by debbugs.gnu.org; 3 Oct 2013 10:57:56 +0000 Original-Received: from localhost ([127.0.0.1]:51432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRgbS-0000Zn-KC for submit@debbugs.gnu.org; Thu, 03 Oct 2013 06:57:55 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:38786 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRgbM-0000Za-M1 for 15478@debbugs.gnu.org; Thu, 03 Oct 2013 06:57:50 -0400 Original-Received: (qmail 60100 invoked by uid 3782); 3 Oct 2013 10:57:46 -0000 Original-Received: from acm.muc.de (pD951A7BB.dip0.t-ipconnect.de [217.81.167.187]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Oct 2013 12:57:45 +0200 Original-Received: (qmail 3489 invoked by uid 1000); 3 Oct 2013 10:56:00 -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:78885 Archived-At: Hi, Stefan. On Wed, Oct 02, 2013 at 09:50:06PM -0400, Stefan Monnier wrote: > > Without electricity, correct indentation would require continual pressing > > of the key. > Yes. Just as is the case in all major modes. No. Electric indentation is completely unneeded in Emacs Lisp Mode, because the indentation of each line is dependent only on previous lines, not the content of the line itself. > > "|" 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. > That's because *you* like electric-indent-mode. Not because C is special. No, it's not just my preference. All modes should indent correctly automatically, by default. Electricity is essential to CC Mode's achieving this. > > "Indent after newline" seems redundant in CC Mode; > Redundancy is not a problem, AFAIK. In my case, for example, CC-mode's > electric indentation on {, }, and semi-colon is redundant, because I hit > TAB anyway without even thinking about it (and C-x C-s very soon after > that ;-). But you need to hit _after_ typing the brace, but _before_ typing C-j. This doesn't seem like an effective way of working. Do you really run C Mode without electric indentation? > > Such a change could involve extensive work > Could be. And maybe not only in CC-mode but also in electric.el. > > the electric behaviour is coded individually in defuns like > > `c-electric-brace' and includes more electric behaviour than just > > indentation - for example, auto-newlining. > `electric-layout-mode' provides similar functionality, IIUC. OK. I didn't know about `electric-layout-mode'. > > 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). > There's been several request to "turn off indentation" over the years > (usually answered with something like "set c-syntactic-indentation") > which would not have occurred without those electric keys: it's easy to > rebind TAB or avoid hitting TAB, but if after that "random other keys" > keep insisting on indenting for you, it gets very frustrating. Setting c-syntactic-indentation to nil was an unsatisfactory workaround. The problem was solved (with c-electric-flag and C-c C-l) around 2005. > >> 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. > Why not? Because each such distinction is going to be major mode specific. CC Mode additionally suppresses electric indentation when a repeat count is given before typing the character. > > 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). > As explained, there's electric-layout-mode for auto-newlining. Not sure > what "clean-ups" is about, but we can probably work something out. Clean-ups, for example, remove auto-newlines when it later transpires they're unwanted. For example, one clean-up converts } else { to } else { on typing the "{". > > 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. > I'm all for improving electric-indent-mode. And indeed, it needs > improvement for indentation-sensitive modes like Python and Haskell. Does it even make sense for these modes? > > Each major mode needs its own default for e-i-m: > I disagree with it: some major modes need their own default because > their syntax has something very special, e.g. incompatible with > electric-indent-mode (Python/Coffescript/Haskell), ... Does that even make sense? How can Python have its own default, yet C not? > ... but most modes should just obey the default setting which reflects > the user's preference. The default setting doesn't reflect a user's preference, if that preference is ON for C, OFF for Python, and the major mode specific optimum for everything else. > > something like `electric-indent-mode-alist', analogous with > > `auto-mode-alist'. This default would be consulted at mode > > initialisation time. > I don't see why the major mode can't just set a var in its major-mode > function for the rare cases where it can be needed, and why the user > can't make his own choice via the major-mode's hook, if needed. Because, as so often in this list, we're talking about defaults, not the extent to which an experienced user can customise his Emacs. Defaults are important. > > 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". > I don't understand what you're suggesting. You seem to be suggesting dismantling not only CC Mode's electric indentation, but its auto-newlining too. The generic replacements for them are going to be less good. What I'm suggesting is some sort of hook so that electric-indent-mode (and electric-layout-mode, too, I suppose) invokes the "electric engine" in CC Mode rather than trying to do the electric indentation itself. Dismantling electricity in CC Mode and replacing it by generic functionality would be a massive amount of work for no functional gain. It would break advanced users' setups and cause maintenance pain, due to incompatibility with the CC Mode standalone version and the XEmacs version. Let's not go down that road. > Stefan -- Alan Mackenzie (Nuremberg, Germany).