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 13:11:22 +0000 Message-ID: <20131007131122.GC3859@acm.acm> References: <20130929091017.GA3161@acm.acm> <20131002200737.GA3895@acm.acm> <20131003105600.GB3211@acm.acm> <20131005165034.GA2943@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1381151661 20154 80.91.229.3 (7 Oct 2013 13:14:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Oct 2013 13:14:21 +0000 (UTC) Cc: 15478@debbugs.gnu.org To: Josh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 07 15:14:20 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 1VTAdg-0004hp-Ir for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Oct 2013 15:14:20 +0200 Original-Received: from localhost ([::1]:59298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTAdg-0003ek-4l for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Oct 2013 09:14:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTAdZ-0003ed-5k for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 09:14:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTAdU-0002Yk-3M for bug-gnu-emacs@gnu.org; Mon, 07 Oct 2013 09:14:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTAdO-0002Xy-Fa; Mon, 07 Oct 2013 09:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VTAdO-0008Ey-0p; Mon, 07 Oct 2013 09:14:02 -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 13:14: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 15478-submit@debbugs.gnu.org id=B15478.138115160631624 (code B ref 15478); Mon, 07 Oct 2013 13:14:01 +0000 Original-Received: (at 15478) by debbugs.gnu.org; 7 Oct 2013 13:13:26 +0000 Original-Received: from localhost ([127.0.0.1]:59675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTAck-0008Dx-9L for submit@debbugs.gnu.org; Mon, 07 Oct 2013 09:13:26 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:39018 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTAce-0008Dj-Dz for 15478@debbugs.gnu.org; Mon, 07 Oct 2013 09:13:20 -0400 Original-Received: (qmail 56390 invoked by uid 3782); 7 Oct 2013 13:13:15 -0000 Original-Received: from acm.muc.de (pD951B381.dip0.t-ipconnect.de [217.81.179.129]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 07 Oct 2013 15:13:14 +0200 Original-Received: (qmail 4623 invoked by uid 1000); 7 Oct 2013 13:11:22 -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:78982 Archived-At: Hi, Josh. On Sun, Oct 06, 2013 at 10:45:59AM -0700, Josh wrote: > On Sat, Oct 5, 2013 at 9:50 AM, Alan Mackenzie wrote: > > On Fri, Oct 04, 2013 at 02:21:22PM -0700, Josh wrote: > > > On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier If CC Mode performs indentation only after character insertion, > why couldn't it continue to do its own electric indentation entirely > after being actuated by this hook, returning `no-indent' to ensure it > had complete control? This is more or less what I have in mind. > If CC Mode reindentation is additionally or only triggered by events > other than character insertion, what are those events? Timers? > Hooks? This is what I was getting at when I asked how the existing > delegation mechanisms fall short. CC Mode reindentation is done only at character insertion; each electric character key is bound to a function, e.g. c-electric-brace, which performs its own electric actions. > > > Is there a reason why CC Mode couldn't supply a function here that > > > would perform appropriate indentation and then return `no-indent' to > > > stop traversal of electric-indent-functions? > > It would be a lot of work to rearrange things, and it might leave the > > Emacs 24.4 version incompatible with other CC Mode versions. > My previous question was based on a supposition (perhaps naive, as I'm > not at all familiar with the CC Mode code) that its indentation > functionality was either already centralized into a some "indent this > line properly" function or that it would be desirable and feasible to > make it so. If that were so, it seemed to me that such a function > could be pressed into service as an electric-indent-function without > too much trouble. That could indeed be done, but the "too much trouble" would arise from having to maintain separate versions of this code for the current Emacs, and for Xemacs and historical Emacsen. Have a look at the code for `c-electric-brace' in cc-cmds.el. > > > Although I agree with your earlier point that major modes are best > > > suited to make decisions about /how/ to perform electric behavior for > > > their specific domains, which also seems to be borne out by the existing > > > delegation support, I've seen no justification for a major mode deciding > > > to disregard (!) my configuration of /whether/ to perform it at all. > > Currently, that configuration is done by setting `c-electric-flag', > > either in your .emacs or by C-c C-l. `electric-indent-mode' is the new > > kid on the block. Concrete suggestions for integrating `c-electric-flag' > > and `electric-indent-mode' haven't been copious up till now. I've one or > > two ideas myself, but it's not trivial. > Indeed, it would have been better for this discussion to have taken > place concurrently with the introduction of a piece of global > configuration specifying default behavior at odds with that of > existing mode-granular configuration, but that's water under the > bridge. Indeed so. I accept my share of the blame for this not being done. > As for their integration, I have already confessed to being unfamiliar > with CC Mode code, but perhaps until a better long-term solution has > been specified and implemented a reasonable stopgap measure would be to > set the default value of c-electric-flag to > (or c-force-electric-flag electric-layout-mode electric-indent-mode) That's not going to gain anything, since `c-force-electric-flag' would need to default to t to preserve existing behaviour. > .... Even so, it would be a vast improvement for newbies who do not > want this behavior. Yes, but it would be undesirable for those other newbies who do want automatic indentation. "Newby" here means those unfamiliar with `c-toggle-electric-state' and `electric-indent-mode'. > > Perhaps there need to be three values here, 'default, t and nil. > Perhaps so, but until that time I expect my global configuration > settings to be observed regardless of whether they remain at the > default values or whether the developers of some mode or library > I'm using think those defaults are sensible. Other people expect their default settings (of `c-electric-flag') to be observed, too. Those defaults clash. This problem is getting resolved. -- Alan Mackenzie (Nuremberg, Germany).