From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.bugs Subject: bug#15478: cc-mode does not obey electric-indent-mode Date: Fri, 4 Oct 2013 14:21:22 -0700 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: multipart/alternative; boundary=089e01536b6a23918b04e7f0e464 X-Trace: ger.gmane.org 1380921737 7631 80.91.229.3 (4 Oct 2013 21:22:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Oct 2013 21:22:17 +0000 (UTC) Cc: 15478@debbugs.gnu.org, Alan Mackenzie To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 04 23:22:19 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 1VSCpE-0000vR-7B for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Oct 2013 23:22:16 +0200 Original-Received: from localhost ([::1]:49648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSCpD-0001r1-GI for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Oct 2013 17:22:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSCp5-0001qp-Vz for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 17:22:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSCp1-0003Zl-2J for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 17:22:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSCp0-0003ZY-Uc for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 17:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VSCp0-0004JM-KC for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2013 17:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Josh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Oct 2013 21:22: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.138092171616561 (code B ref 15478); Fri, 04 Oct 2013 21:22:02 +0000 Original-Received: (at 15478) by debbugs.gnu.org; 4 Oct 2013 21:21:56 +0000 Original-Received: from localhost ([127.0.0.1]:54662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VSCot-0004J1-O6 for submit@debbugs.gnu.org; Fri, 04 Oct 2013 17:21:56 -0400 Original-Received: from mail-qa0-f44.google.com ([209.85.216.44]:40505) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VSCor-0004Is-8f for 15478@debbugs.gnu.org; Fri, 04 Oct 2013 17:21:54 -0400 Original-Received: by mail-qa0-f44.google.com with SMTP id j7so1471183qaq.17 for <15478@debbugs.gnu.org>; Fri, 04 Oct 2013 14:21:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=sN82tDoDEqB/kIa4VgcQvOYR7iGDemB39ubz5DgeBwY=; b=R9OWlpW4UL12OxdUOJJ19HBFynh91gLAEIecVrAJvuzX16pyGhmmPiM7KAg/ORcqFF r+DUOHAtu/KbkI0qVTIAu71ElfLMLnBE2a0j9aTPDa5CNn0Z4gMfWDp8LwxkN8pxP6Gh tK8T6e1+0B//+Gbv+gud8fel/4lSKirRZimu2DQA0deuXLe8WtkCj0dzyH5oSadDeqeq 7wsXig1w8q/qPntzgSeGDZs6KN7L5DPJDnmUlmsBf49gzIuha0aBH2zg5oG8NXPx7+bh i+usNyM6xiJm8bpmau/35O3m+atABOcOLY4KbbrhmD6hBEub+T/HCgm+YK0DFQYwsXMp jV4w== X-Gm-Message-State: ALoCoQnxAxlf/E1l19s8DEw7uS3uI/AZNAi3ARu7KSvNOrWf0CUg9+iAtZ1yVbLW5+MQd19rmykA X-Received: by 10.224.57.138 with SMTP id c10mr21242885qah.57.1380921712540; Fri, 04 Oct 2013 14:21:52 -0700 (PDT) Original-Received: by 10.49.38.162 with HTTP; Fri, 4 Oct 2013 14:21:22 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: TgHrmgxT-bmIJcdU8LkCQvnBMtA 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:78932 Archived-At: --089e01536b6a23918b04e7f0e464 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier wrote: > > 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. Unless I'm misunderstanding, the indentation hook you're describing seems very close to `electric-indent-functions': electric-indent-functions is a variable defined in `electric.el'. Its value is nil This variable may be risky if used as a file-local variable. Documentation: Special hook run to decide whether to auto-indent. Each function is called with one argument (the inserted char), with point right after that char, and it should return t to cause indentation, `no-indent' to prevent indentation or nil to let other functions decide. 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? Delegation of newline insertion decisions is similarly already supported via `electric-layout-rules': electric-layout-rules electric-layout-rules is a variable defined in `electric.el'. Its value is nil Documentation: List of rules saying where to automatically insert newlines. Each rule has the form (CHAR . WHERE) where CHAR is the char that was just inserted and WHERE specifies where to insert newlines and can be: nil, `before', `after', `around', or a function of no arguments that returns one of those symbols. If either or both of these delegation mechanisms are insufficient to satisfy CC Mode's requirements, it would be interesting to hear how they fall short. 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. I read the electric-*-mode docstrings describing the exact behavior in question and I disabled it. That should be the end of the story. Josh --089e01536b6a23918b04e7f0e464 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote= :
> > What I'm suggesting is some sort of hook so that electri= c-indent-mode
> > (and electric-layout-mode, too, I suppose) invokes the "elec= tric
> > engine" in CC Mode rather than trying to do the elec= tric
> > indentation itself.
> Sounds OK.

Unless I= 9;m misunderstanding, the indentation hook you're describing
seems very close to `electric-indent-functions':

=A0=A0=A0 elect= ric-indent-functions is a variable defined in `electric.el'.
=A0=A0= =A0 Its value is nil
=A0=A0=A0=A0=A0 This variable may be risky if used = as a file-local variable.
=A0=A0=A0 Documentation:
=A0=A0=A0 Special hook run to decide whether to= auto-indent.
=A0=A0=A0 Each function is called with one argument (the i= nserted char), with
=A0=A0=A0 point right after that char, and it should= return t to cause indentation,
=A0=A0=A0 `no-indent' to prevent indentation or nil to let other functi= ons decide.

Is there a reason why CC Mode couldn't supply a func= tion here that
would perform appropriate indentation and then return `n= o-indent' to
stop traversal of electric-indent-functions?

Delegation of newline i= nsertion decisions is similarly already supported
via `electric-layout-r= ules':

=A0=A0=A0 electric-layout-rules
=A0=A0=A0 electric-lay= out-rules is a variable defined in `electric.el'.
=A0=A0=A0 Its value is nil
=A0=A0=A0 Documentation:
=A0=A0=A0 List of= rules saying where to automatically insert newlines.
=A0=A0=A0 Each rul= e has the form (CHAR . WHERE) where CHAR is the char
=A0=A0=A0 that was = just inserted and WHERE specifies where to insert newlines
=A0=A0=A0 and can be: nil, `before', `after', `around', or a fu= nction of no
=A0=A0=A0 arguments that returns one of those symbols.
<= br>If either or both of these delegation mechanisms are insufficient to
= satisfy CC Mode's requirements, it would be interesting to hear how the= y
fall short.

Although I agree with your earlier point that major mode= s are best
suited to make decisions about /how/ to perform electric beha= vior 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 decidin= g
to disregard (!) my configuration of /whether/ to perform it at all.= =A0 I read
the electric-*-mode docstrings describing the exact behavior= in
question and I disabled it.=A0 That should be the end of the story.

= Josh

--089e01536b6a23918b04e7f0e464--