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: Sun, 6 Oct 2013 10:45:59 -0700 Message-ID: References: <20130928201147.GC11317@acm.acm> <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: multipart/alternative; boundary=047d7b5d237c8cf49404e8161d7a X-Trace: ger.gmane.org 1381081633 6854 80.91.229.3 (6 Oct 2013 17:47:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Oct 2013 17:47:13 +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 Sun Oct 06 19:47:16 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 1VSsQE-0002LC-MP for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Oct 2013 19:47:15 +0200 Original-Received: from localhost ([::1]:55978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSsQE-0001tE-1r for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Oct 2013 13:47:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSsQ7-0001st-3D for bug-gnu-emacs@gnu.org; Sun, 06 Oct 2013 13:47:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSsQ2-0005n5-P6 for bug-gnu-emacs@gnu.org; Sun, 06 Oct 2013 13:47:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSsQ2-0005mw-Kc for bug-gnu-emacs@gnu.org; Sun, 06 Oct 2013 13:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VSsQ2-0002z0-79 for bug-gnu-emacs@gnu.org; Sun, 06 Oct 2013 13:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Josh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Oct 2013 17:47: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.138108159411431 (code B ref 15478); Sun, 06 Oct 2013 17:47:02 +0000 Original-Received: (at 15478) by debbugs.gnu.org; 6 Oct 2013 17:46:34 +0000 Original-Received: from localhost ([127.0.0.1]:57929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VSsPZ-0002yI-3l for submit@debbugs.gnu.org; Sun, 06 Oct 2013 13:46:34 -0400 Original-Received: from mail-qc0-f177.google.com ([209.85.216.177]:33771) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VSsPW-0002y8-5R for 15478@debbugs.gnu.org; Sun, 06 Oct 2013 13:46:31 -0400 Original-Received: by mail-qc0-f177.google.com with SMTP id x12so4172607qcv.36 for <15478@debbugs.gnu.org>; Sun, 06 Oct 2013 10:46:29 -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=czQJq22SYe2oY1jn2tPGQiFO8hI3253yQrn21chXw1Q=; b=AQzrP+pe3e10VzZE9fqhXcDBiRw8s6r/q8dJZZATO5CFJBXUGZfmJ2cjGqiCAwBB32 onJEG6HtdttokNtkAGY3pozuTHXV/+T2Q4QsuSZgdpRNXjklb1sr3cUWgPhyUnVsM52Z Stfv6xju0EjwV4mt/quPsohh+Mb/ojbffnEzUt8usmqi1C3l5TftfkY77sXFnwmi4aRW EcWKjGgal+OXoWyq3K6T8M4M8YTxW5E7gBesrvI6MyhUAn69v7/CN9f+jJC/iBfXW6cn xMRP2Um67tA/WSgw7bvjHnrkBIKIRP4g3aE8qTvOo1A4uHljQa4Mw+r1x9oe4A+bvuNn NSSA== X-Gm-Message-State: ALoCoQk/Ff95TQ3H2Fav0KeG0BqXLz+lEcUUl5xVELlsgkApoto6N1Cz+25jBtVUHBEyAZe+JHUK X-Received: by 10.49.71.239 with SMTP id y15mr31341314qeu.14.1381081589538; Sun, 06 Oct 2013 10:46:29 -0700 (PDT) Original-Received: by 10.49.38.162 with HTTP; Sun, 6 Oct 2013 10:45:59 -0700 (PDT) In-Reply-To: <20131005165034.GA2943@acm.acm> X-Google-Sender-Auth: YnU6W4cirDN4ikBPEXBHFkcvmYw 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:78958 Archived-At: --047d7b5d237c8cf49404e8161d7a Content-Type: text/plain; charset=ISO-8859-1 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 > > 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': > I'd say it's moderately close rather than very close. At the moment CC > Mode does its own electric indentation entirely, and I'd like things to > stay that way, so as to minimise incompatibility between versions, to > avoid breaking existing users' setups and so on. Sorry, I don't follow. Why "moderately close" instead of "very close"? The docstring of `electric-indent-functions' suggests that its members are called after the insertion of every character. 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? 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. > > 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? > 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. The fact that you say it would be a lot of work to rearrange things leads me to believe that my supposition may have been incorrect, though that does not affect my view that global electricity settings should govern electricity behavior globally. > > 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. > CC Mode already does electric actions by other means, and users setups > depend on these. I don't want to break these existing setups. > Integrating CC Mode's ways with these new mechanisms is a challenge. Since you didn't point out any shortcomings of these mechanisms or describe these "other means" or why it would be so difficult to integrate them with global electricity settings, I see no way to continue this line of discussion. > > 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. 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) with a corresponding (defcustom c-force-electric-flag nil "*If non-nil, force electric indentation and newline insertion enablement. Otherwise, the default state of this behavior is to be enabled if either `electric-layout-mode' or `electric-indent-mode' are enabled. Note: regardless of any of the above settings, `c-toggle-electric-state' can toggle enablement of this feature on a buffer-granular basis." :type 'boolean :group 'c) though this is imperfect since it loses information when the two global configuration values differ. Even so, it would be a vast improvement for newbies who do not want this behavior. Another possible flaw with this approach is that runtime changes to global electricity enablement would not affect CC Mode's behavior, which doesn't matter to me but might to others. > > I read the electric-*-mode docstrings describing the exact behavior in > > question and I disabled it. That should be the end of the story. > Yes. But there's a difference between you disabling it and merely using > the default value. Since the current default is already nil, it's not > clear what you mean by "disabling" it. You're right; I should have said, "I ensured that it was disabled." I meant that I had read the relevant documentation and verified that the all of the related configuration reflected my wishes. In this case because the defaults already did so I did not have to change anything. > 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. > It's also still up for discussion how > you {en,dis}able electric-indent-mode buffer locally, which is a sensible > thing to want to do. I believe even the stopgap measure I suggested would permit changing that behavior buffer-locally. --047d7b5d237c8cf49404e8161d7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 5, 2013 at 9:50 AM, Alan Mackenzie <acm@muc.de> wrote:
> On Fri, Oct 04, 20= 13 at 02:21:22PM -0700, Josh wrote:
> > On Thu, Oct 3, 2013 at 7:3= 2 AM, Stefan Monnier <monnie= r@iro.umontreal.ca>
> > wrote:
> > > > What I'm suggesting is some sor= t of hook so that
> > > > electric-indent-mode (and electric= -layout-mode, too, I suppose)
> > > > invokes the "elec= tric engine" in CC Mode rather than trying to do
> > > > the electric indentation itself.
> > > Soun= ds OK.
>
> > Unless I'm misunderstanding, the indentatio= n hook you're describing
> > seems very close to `electric-ind= ent-functions':
> I'd say it's moderately close rather than very close.=A0 At th= e moment CC
> Mode does its own electric indentation entirely, and I&= #39;d like things to
> stay that way, so as to minimise incompatibili= ty between versions, to
> avoid breaking existing users' setups and so on.

Sorry, I d= on't follow.=A0 Why "moderately close" instead of "very<= br>close"?=A0 The docstring of `electric-indent-functions' suggest= s that
its members are called after the insertion of every character.

If CC= Mode performs indentation only after character insertion,
why couldn= 9;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?

If CC Mode reindentation is additionally or on= ly triggered by events
other than character insertion, what are those ev= ents?=A0 Timers?
Hooks?=A0 This is what I was getting at when I asked ho= w the existing
delegation mechanisms fall short.

> >=A0=A0=A0=A0 electric-ind= ent-functions is a variable defined in `electric.el'.
> >=A0= =A0=A0=A0 Its value is nil
> >=A0=A0=A0=A0=A0=A0 This variable may= be risky if used as a file-local variable.
> >=A0=A0=A0=A0 Documentation:
> >=A0=A0=A0=A0 Special hook = run to decide whether to auto-indent.
> >=A0=A0=A0=A0 Each functio= n is called with one argument (the inserted char), with
> >=A0=A0= =A0=A0 point right after that char, and it should return t to cause
> > indentation,
> >=A0=A0=A0=A0 `no-indent' to prevent = indentation or nil to let other functions decide.
>
> > Is t= here 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 ques= tion was based on a supposition (perhaps naive, as I'm
not at all familiar with the CC Mode code) that its indentation
function= ality was either already centralized into a some "indent this
line = properly" function or that it would be desirable and feasible to
make it so.=A0 If that were so, it seemed to me that such a function
cou= ld be pressed into service as an electric-indent-function without
too mu= ch trouble.=A0 The fact that you say it would be a lot of work to
rearra= nge things leads me to believe that my supposition may have been
incorrect, though that does not affect my view that global electricity
s= ettings should govern electricity behavior globally.

> > Deleg= ation of newline insertion decisions is similarly already supported
> > via `electric-layout-rules':
>
> >=A0=A0=A0=A0= electric-layout-rules
> >=A0=A0=A0=A0 electric-layout-rules is a = variable defined in `electric.el'.
> >=A0=A0=A0=A0 Its value i= s nil
> >=A0=A0=A0=A0 Documentation:
> >=A0=A0=A0=A0 List of rules saying where to automatically insert ne= wlines.
> >=A0=A0=A0=A0 Each rule has the form (CHAR . WHERE) wher= e CHAR is the char
> >=A0=A0=A0=A0 that was just inserted and WHER= E specifies where to insert newlines
> >=A0=A0=A0=A0 and can be: nil, `before', `after', `around&#= 39;, or a function of no
> >=A0=A0=A0=A0 arguments that returns on= e of those symbols.
>
> > If either or both of these delegat= ion mechanisms are insufficient to
> > satisfy CC Mode's requirements, it would be interesting to he= ar how they
> > fall short.
> CC Mode already does electric = actions by other means, and users setups
> depend on these.=A0 I don&= #39;t want to break these existing setups.
> Integrating CC Mode's ways with these new mechanisms is a challeng= e.

Since you didn't point out any shortcomings of these mechanis= ms or
describe these "other means" or why it would be so diffi= cult to
integrate them with global electricity settings, I see no way to
continu= e this line of discussion.

> > Although I agree with your earl= ier point that major modes are best
> > suited to make decisions a= bout /how/ to perform electric behavior for
> > their specific domains, which also seems to be borne out by the e= xisting
> > delegation support, I've seen no justification for= a major mode deciding
> > to disregard (!) my configuration of /w= hether/ 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.=A0 `electric-indent-mode'= ; is the new
> kid on the block.=A0 Concrete suggestions for integrat= ing `c-electric-flag'
> and `electric-indent-mode' haven't been copious up till now.= =A0 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
configurat= ion specifying default behavior at odds with that of
existing mode-granu= lar configuration, but that's water under the
bridge.=A0 As for thei= r integration, I have already confessed to being
unfamiliar with CC Mode code, but perhaps until a better long-term
solut= ion has been specified and implemented a reasonable stopgap
measure woul= d be to set the default value of c-electric-flag to

=A0 (or c-force-= electric-flag electric-layout-mode electric-indent-mode)

with a corresponding

=A0 (defcustom c-force-electric-flag nil=A0=A0=A0 "*If non-nil, force electric indentation and newline insert= ion enablement.

=A0 Otherwise, the default state of this behavior is= to be enabled if either
=A0 `electric-layout-mode' or `electric-indent-mode' are enabled.
=A0 Note: regardless of any of the above settings, `c-toggle-electric= -state'
=A0 can toggle enablement of this feature on a buffer-granul= ar basis."
=A0=A0=A0 :type 'boolean
=A0=A0=A0 :group 'c)

though this= is imperfect since it loses information when the two
global configurati= on values differ.=A0 Even so, it would be a vast
improvement for newbies= who do not want this behavior.=A0 Another
possible flaw with this approach is that runtime changes to global
elect= ricity enablement would not affect CC Mode's behavior, which
doesn&#= 39;t matter to me but might to others.

> > I read the electric= -*-mode docstrings describing the exact behavior in
> > question and I disabled it.=A0 That should be the end of the stor= y.
> Yes.=A0 But there's a difference between you disabling it an= d merely using
> the default value.=A0 Since the current default is a= lready nil, it's not
> clear what you mean by "disabling" it.

You're rig= ht; I should have said, "I ensured that it was disabled."=A0 Imeant that I had read the relevant documentation and verified that the
all of the related configuration reflected my wishes.=A0 In this case
be= cause the defaults already did so I did not have to change anything.
> Perhaps there need to be three
> values here, 'default, t a= nd nil.

Perhaps so, but until that time I expect my global configuration
set= tings to be observed regardless of whether they remain at the
default va= lues or whether the developers of some mode or library
I'm using thi= nk those defaults are sensible.

> It's also still up for discussion how
> you {en,dis}able= electric-indent-mode buffer locally, which is a sensible
> thing to = want to do.

I believe even the stopgap measure I suggested would per= mit changing
that behavior buffer-locally.

--047d7b5d237c8cf49404e8161d7a--