From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#15478: cc-mode does not obey electric-indent-mode Date: Thu, 03 Oct 2013 10:32:32 -0400 Message-ID: References: <20130928201147.GC11317@acm.acm> <20130929091017.GA3161@acm.acm> <20131002200737.GA3895@acm.acm> <20131003105600.GB3211@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1380913628 14754 80.91.229.3 (4 Oct 2013 19:07:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Oct 2013 19:07:08 +0000 (UTC) Cc: 15478@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 04 21:07:10 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 1VSAiU-0005Ec-Hn for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Oct 2013 21:07:10 +0200 Original-Received: from localhost ([::1]:49249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSAiU-0001Rn-2v for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Oct 2013 15:07:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSAgZ-0007Xw-QC for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 15:05:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSAgR-0001Yp-U9 for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 15:05:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSAgR-0001Y9-Q2 for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 15:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VSAgR-00014c-KG for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 15:05:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Oct 2013 19:05:03 +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.13809134744036 (code B ref 15478); Fri, 04 Oct 2013 19:05:03 +0000 Original-Received: (at 15478) by debbugs.gnu.org; 4 Oct 2013 19:04:34 +0000 Original-Received: from localhost ([127.0.0.1]:54438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VSAfx-00012u-Bm for submit@debbugs.gnu.org; Fri, 04 Oct 2013 15:04:33 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37070) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VSAfu-00012a-EU for 15478@debbugs.gnu.org; Fri, 04 Oct 2013 15:04:31 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r94J4So1006971; Fri, 4 Oct 2013 15:04:29 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 48686B41F2; Thu, 3 Oct 2013 10:32:32 -0400 (EDT) In-Reply-To: <20131003105600.GB3211@acm.acm> (Alan Mackenzie's message of "Thu, 3 Oct 2013 10:56:00 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.5 X-NAI-Spam-Rules: 2 Rules triggered WORD_END_QSTM=0.5, RV4721=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4721> : inlines <126> : streams <1050162> : uri <1555789> 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:78931 Archived-At: >> > 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, Nitpicking. >> That's because *you* like electric-indent-mode. Not because C is special. > No, it's not just my preference. That's what you say, but I don't see the evidence. So far you've only pointed to Elisp mode and Python mode as counter examples, but from where I stand it's more like Elisp and Python are the exceptions (and as soon as someone improves Elisp indentation for cl-lib constructs or :keyword arguments, Elisp won't be an exception any more). > All modes should indent correctly automatically, by default. Again, you're arguing for enabling electric-indent-mode by default. I'm not necessarily opposed to it, but it's a different issue than the one I'm concerned with in this bug-report. > 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? Of course. And cc-mode is one of the very few modes where electric-indent is so "in your face" all the time. >> >> 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. That's not a good reason, since there's no technical difficulty in making it possible for a major mode to tell electric-indent-mode which behavior is desired. >> > 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 "{". Ah, right. I don't see any particular problem here, cc-mode can provide a c-electric-cleanup-mode (or maybe we can even make it generic, so other major modes can provide their own cleanup rules). >> 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? No, it doesn't, which is the needed improvement: make it default to Off there even if it is enabled globally. >> > 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? Technically, C could have its own default as well, of course. I just don't see any reason for it. > 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. Indeed, which is why only very few major modes should override the global default. Python has a good reason to override it. C doesn't. >> > 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. My point above was arguing against using an electric-indent-mode-alist mechanism rather than one of the standard mechanisms (setq-local for the major-mode or add-hook for the user). It was not about what the default should be. >> > 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. I don't want them to be less good. They may be marginally less good, or slightly different in some corner cases, of course. But "significantly less good" would be a bug to fix by improving the generic code. As already mentioned, fixing this bug report may require fixes not just in cc-mode but also in electric.el. > 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. Sounds OK. Stefan