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: Mon, 7 Oct 2013 20:37:38 +0000 Message-ID: <20131007203738.GA3099__32033.1080853522$1381178504$gmane$org@acm.acm> References: <20131002200737.GA3895@acm.acm> <524CDA92.1030107@dancol.org> <20131003094543.GA3211@acm.acm> <20131007103041.GB3859@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1381178494 20198 80.91.229.3 (7 Oct 2013 20:41:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Oct 2013 20:41:34 +0000 (UTC) Cc: gnu-emacs-bug@moderators.isc.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 07 22:41:37 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 1VTHcW-0006qo-Va for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Oct 2013 22:41:37 +0200 Original-Received: from localhost ([::1]:33428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTHcW-0005yZ-Ir for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Oct 2013 16:41:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTHcI-0005nX-05 for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:41:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTHc8-0003by-HE for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:41:21 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTHby-0003HS-8a; Mon, 07 Oct 2013 16:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VTHbx-0002Eq-Ow; Mon, 07 Oct 2013 16:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 07 Oct 2013 20:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15478 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by submit@debbugs.gnu.org id=B.13811784038525 (code B ref -1); Mon, 07 Oct 2013 20:41:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 7 Oct 2013 20:40:03 +0000 Original-Received: from localhost ([127.0.0.1]:32853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTHay-0002D2-Q4 for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:40:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34336) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTHaw-0002Ct-19 for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:39:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTHam-0002cG-De for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:39:57 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:55044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTHam-0002cC-Ae for submit@debbugs.gnu.org; Mon, 07 Oct 2013 16:39:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTHac-0005cw-RQ for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:39:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTHaT-0002WQ-CL for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:39:38 -0400 Original-Received: from four.schnuerpel.eu ([2a01:4f8:120:9382::145]:46982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTHaT-0002Vi-1t for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 16:39:29 -0400 Original-Received: from mail.muc.de (colin.muc.de [193.149.48.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moderators.schnuerpel.eu (Postfix) with ESMTPS id 80FA47C7 for ; Mon, 7 Oct 2013 22:39:27 +0200 (CEST) Original-Received: (qmail 88790 invoked by uid 3782); 7 Oct 2013 20:39:26 -0000 Original-Received: from acm.muc.de (p5492CEB1.dip0.t-ipconnect.de [84.146.206.177]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Oct 2013 22:39:24 +0200 Original-Received: (qmail 3164 invoked by uid 1000); 7 Oct 2013 20:37: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-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). 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:78995 Archived-At: 'Evening, Stefan. On Mon, Oct 07, 2013 at 12:14:19PM -0400, Stefan Monnier wrote: > >> Emacs has never provided this feature in any mode that I know, cc-mode > >> included. Some major modes (such as CC-mode) try to provide some vague > >> approximation of it, using "electric keys" that trigger indentation > >> "often enough" that it works more or less OK in some common cases. > > :-). I think CC Mode DTRT practically 100% of the time. There haven't > > been bug reports asking for the details of the electric indentation to be > > improved. > I can assure you it doesn't work 100%: in many circumstances you have to > hit TAB (or M-C-\ or M-C-q) manually before the text's indentation > reflects the modifications that took place. Electric indentation only works on the current line, and I'm not sure extending it to subsequent lines would be a good idea. Could you specify cases where it doesn't work on the current line? > I don't think it's a failure of your code, tho (and > electric-indent-mode fails in the exact same way). How do they fail? > > from 1992. Somebody (RMS? Barry Warsaw?) clearly thought it very > > important. > I thought it's important enough to embark on electric-indent-mode > (which is reasonably easy to implement, except it's hellish to get all > the various authors to get back in line and start using the generic > infrastructure, for the long term benefit of end users, at the cost > of short term disruption and extra work). ;-). That, you should have expected. It's a standard conflict of interests - those of Emacs (as a whole) against those of the individual modes. Having all the arguments, though, will result in a better electric-indent-mode which interacts better with the other modes. > >> The core is then: how should we make cc-mode integrate better with Emacs > >> and use the generic electric-*-mode functionality instead of > >> rolling its own? > > How about aliasing `c-electric-mode' and `electric-indent-mode' and > > making them buffer-local in CC Mode buffers? Then setting CC Mode's > > value of `electric-indent-chars' to nil, for now, and in the medium > > future (once e-i-m has percolated through to old versions and XEmacs) > > integrating CC Mode into electric-indent-mode properly? > Poor, but does satisfy the requirements. Do you want to elaborate? > > How about introducing `global-electric-indent-mode' and redefining e-i-m > > to be buffer-local? Or, alternatively, leaving e-i-m as it is and > > defining `local-electric-indent-mode'? > `electric-indent-local-mode' sounds good. > > What about defining a property `no-electric-indentation' which could > > be set on python-mode and others? > I wouldn't use a property. Just a buffer-local variable > `electric-indent-inhibit' which those modes can set. > For Python and Haskell, this should only inhibit *re*indentation, while > still calling indent-according-to-mode after inserting a newline. Electric indentation is precisely about the *re*indation of the current line, isn't it? indent-according-to-mode after NL isn't electric indentation. > >> For the record: CC-mode is not the only major mode in this boat. > >> I've already converted several major modes to use electric-indent-mode, > >> and for some of them this also involved changing the default behavior. > > Would you identify (some of) these modes, please, so I can go and have a > > look. > If you "grep electric-indent- **/*.el" you'll find some of them (I also > changed a few external ones like sml-mode). OK, I'll do this. > Note that in most cases I made the change by completely side-stepping > the old code (i.e. the define-key that rebinds the keys to electric > versions was either removed or made conditional on something like > (fboundp 'electric-indent-mode)). > And those were usually simpler than what cc-mode does, with the > exception maybe of octave.el where the old behavior was a bit more > complex, and replaced by a mix of electric-indent-mode, > electric-layout-mode. > But in most of those cases, I only made a minimal effort at trying to > preserve old behavior and user's customization. I've seen a few > questions about "why foo-mode doesn't indent as before", and the answer > "it's now controlled by electric-indent-mode" always seemed to satisfy > the user. OK. > Stefan -- Alan Mackenzie (Nuremberg, Germany).