Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> +  ;; In Emacs 24.4 onwards, prevent Emacs's built in electric indentation from
> +  ;; messing up CC Mode's, and set `c-electric-flag' if `electric-indent-mode'
> +  ;; has been called by the user.
> +  (when (boundp 'electric-indent-inhibit) (setq electric-indent-inhibit t))
> +  (when (and (boundp 'electric-indent-mode-has-been-called)
> +	     (> electric-indent-mode-has-been-called 1))
> +    (setq c-electric-flag electric-indent-mode))

Could you explain what problem this is trying to avoid?

> +  ;; Emacs has en/disabled `electric-indent-mode'.  Propagate this through to
> +  ;; each CC Mode buffer.
> +  (when (and (boundp 'electric-indent-mode-has-been-called)
> +	     (> electric-indent-mode-has-been-called 1))
> +    (mapc (lambda (buf)
> +	    (with-current-buffer buf
> +	      (when c-buffer-is-cc-mode
> +		;; Don't use `c-toggle-electric-state' here due to recursion.
> +		(setq c-electric-flag electric-indent-mode)
> +		(c-update-modeline))))
> +	  (buffer-list))))

And could you also explain what this one is trying to avoid?


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hi, Stefan.

On Mon, Feb 17, 2014 at 07:11:18PM -0500, Stefan Monnier wrote:
> > +  ;; In Emacs 24.4 onwards, prevent Emacs's built in electric indentation from
> > +  ;; messing up CC Mode's, and set `c-electric-flag' if `electric-indent-mode'
> > +  ;; has been called by the user.
> > +  (when (boundp 'electric-indent-inhibit) (setq electric-indent-inhibit t))
> > +  (when (and (boundp 'electric-indent-mode-has-been-called)
> > +	     (> electric-indent-mode-has-been-called 1))
> > +    (setq c-electric-flag electric-indent-mode))

> Could you explain what problem this is trying to avoid?

Setting electric-indent-inhibit is intended to protect CC Mode from the
dangers of CC Mode's electricity clashing with electric.el's.  The other
bit takes over the value of c-electric-indent-mode into CC Mode only
when it has been set by the user, thus preventing electric.el's default
overriding CC Mode's.  (As we've already discussed, CC Mode's indentation
doesn't work properly with electric indentation disabled.)

> > +  ;; Emacs has en/disabled `electric-indent-mode'.  Propagate this through to
> > +  ;; each CC Mode buffer.
> > +  (when (and (boundp 'electric-indent-mode-has-been-called)
> > +	     (> electric-indent-mode-has-been-called 1))
> > +    (mapc (lambda (buf)
> > +	    (with-current-buffer buf
> > +	      (when c-buffer-is-cc-mode
> > +		;; Don't use `c-toggle-electric-state' here due to recursion.
> > +		(setq c-electric-flag electric-indent-mode)
> > +		(c-update-modeline))))
> > +	  (buffer-list))))

> And could you also explain what this one is trying to avoid?

Basically the same thing.  It's preventing an inopportune default (as
contrasted with an explicit user setting) overriding CC Mode's default.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> The other bit takes over the value of c-electric-indent-mode into CC
> Mode only when it has been set by the user, thus preventing
> electric.el's default overriding CC Mode's.

For that I think it's better to only obey electric-indent-mode if
Emacs>24.3 rather than use the electric-indent-mode-has-been-called crutch.

>> > +  ;; Emacs has en/disabled `electric-indent-mode'.  Propagate this through to
>> > +  ;; each CC Mode buffer.
>> > +  (when (and (boundp 'electric-indent-mode-has-been-called)
>> > +	     (> electric-indent-mode-has-been-called 1))
>> > +    (mapc (lambda (buf)
>> > +	    (with-current-buffer buf
>> > +	      (when c-buffer-is-cc-mode
>> > +		;; Don't use `c-toggle-electric-state' here due to recursion.
>> > +		(setq c-electric-flag electric-indent-mode)
>> > +		(c-update-modeline))))
>> > +	  (buffer-list))))
>> And could you also explain what this one is trying to avoid?
> Basically the same thing.  It's preventing an inopportune default (as
> contrasted with an explicit user setting) overriding CC Mode's default.

Looks quite different since it checks (>
electric-indent-mode-has-been-called 1), but if you say it's the same,
then I'll remove electric-indent-mode-has-been-called and let you check
Emacs's version instead.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hi, Stefan.

On Mon, Feb 24, 2014 at 10:24:23PM -0500, Stefan Monnier wrote:
> > The other bit takes over the value of c-electric-indent-mode into CC
> > Mode only when it has been set by the user, thus preventing
> > electric.el's default overriding CC Mode's.

> For that I think it's better to only obey electric-indent-mode if
> Emacs>24.3 rather than use the electric-indent-mode-has-been-called crutch.

That does not achieve the same effect.

> >> > +  ;; Emacs has en/disabled `electric-indent-mode'.  Propagate this through to
> >> > +  ;; each CC Mode buffer.
> >> > +  (when (and (boundp 'electric-indent-mode-has-been-called)
> >> > +	     (> electric-indent-mode-has-been-called 1))
> >> > +    (mapc (lambda (buf)
> >> > +	    (with-current-buffer buf
> >> > +	      (when c-buffer-is-cc-mode
> >> > +		;; Don't use `c-toggle-electric-state' here due to recursion.
> >> > +		(setq c-electric-flag electric-indent-mode)
> >> > +		(c-update-modeline))))
> >> > +	  (buffer-list))))
> >> And could you also explain what this one is trying to avoid?
> > Basically the same thing.  It's preventing an inopportune default (as
> > contrasted with an explicit user setting) overriding CC Mode's default.

> Looks quite different since it checks (>
> electric-indent-mode-has-been-called 1), ....

Both bits of code check (> electric-indent-mode-has-been-called 1), hence
they are very similar, not quite different.

> .... but if you say it's the same, then I'll remove
> electric-indent-mode-has-been-called and let you check Emacs's version
> instead.

Please don't do this.  I meant literally what I wrote.

A better solution would be to provide a less ugly way of checking whether
a user has called electric-indent-mode - possibly some enhancement of
define-minor-mode.  I can't think of any at the moment.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

>> > The other bit takes over the value of c-electric-indent-mode into CC
>> > Mode only when it has been set by the user, thus preventing
>> > electric.el's default overriding CC Mode's.
>> For that I think it's better to only obey electric-indent-mode if
>> Emacs>24.3 rather than use the electric-indent-mode-has-been-called crutch.
> That does not achieve the same effect.

Can you give a scenario where the result is different?

> Please don't do this.  I meant literally what I wrote.

Yes, but I hate this electric-indent-mode-has-been-called crutch, so we
need a different solution.

> A better solution would be to provide a less ugly way of checking whether
> a user has called electric-indent-mode

A different way would still be ugly, because this requirement is itself ugly.
We need to find a solution that does not depend on *how* we got to this state.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Sat, Mar 01, 2014 at 10:57:34AM -0500, Stefan Monnier wrote:
> >> > The other bit takes over the value of c-electric-indent-mode into CC
> >> > Mode only when it has been set by the user, thus preventing
> >> > electric.el's default overriding CC Mode's.
> >> For that I think it's better to only obey electric-indent-mode if
> >> Emacs>24.3 rather than use the electric-indent-mode-has-been-called crutch.

Using version numbers to check for features is not exactly clean coding.

> > That does not achieve the same effect.

> Can you give a scenario where the result is different?

The default for electric-indent-mode is changed in a future Emacs
version.

> > Please don't do this.  I meant literally what I wrote.

> Yes, but I hate this electric-indent-mode-has-been-called crutch, so we
> need a different solution.

> > A better solution would be to provide a less ugly way of checking whether
> > a user has called electric-indent-mode

> A different way would still be ugly, because this requirement is itself
> ugly.  We need to find a solution that does not depend on *how* we got
> to this state.

By "this state" you mean what?  The minor mode electric-indent-mode can
be in any of three states: (i) left at its default, (ii) set (or toggled)
to t, (iii) set (or toggled) to nil.

The challenge is to distinguish between (i) and ((ii) or (iii)).

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> Using version numbers to check for features is not exactly clean coding.

Much less hideous than checking how many times a function was called.

> The default for electric-indent-mode is changed in a future Emacs
> version.

So it's hypothetical.  We'll cross this bridge if/when we get there.

> The challenge is to distinguish between (i) and ((ii) or (iii)).

No, we should only care about "enabled" and "disabled".


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Mar 03, 2014 at 10:48:50PM -0500, Stefan Monnier wrote:
> > Using version numbers to check for features is not exactly clean coding.

> Much less hideous than checking how many times a function was called.

Uh??  Why are you comparing the checking of Emacs's version number with
testing whether a function has been called?

There lacks a clean way of determining if a minor-mode function has been
called.  There is a clear need for such a facility.

> > The default for electric-indent-mode is changed in a future Emacs
> > version.

> So it's hypothetical.  We'll cross this bridge if/when we get there.

> > The challenge is to distinguish between (i) and ((ii) or (iii)).

What exactly do (i), (ii), and (iii) mean?  You have cut so much out of
my post that the meaning has been lost.  This is extremely annoyinng, and
you do this frequently.  Could you be less severe with your cutting in
the future, please.

> No, we should only care about "enabled" and "disabled".

That's a fairly contentious opinion, not backed up by any reasoning.
Would you care to give your reasons why "default state" is not to be
cared about?

As we have discussed before, it is essential that c-electric-flag be
enabled by default for CC Mode buffers.  Without it, indentation would
need to be done manually, e.g. by continual use of the tab key.  Yet
c-electric-flag, a buffer local flag, is now inextricably coupled to
electric-indent-mode, a crude global flag.  A user wishing to disable
electric-indent-mode for some random buffer will find automatic
indentation broken in her C Mode buffers.

There is no mechanism provided to users by electric-indent-mode to enable
it selectively in a buffer.  Even the undocumented
electric-indent-local-mode doesn't work properly, as you admitted
recently.

In the massive confusion and possible protest that will follow in the
wake of the release of electric-indent-mode, one of your options will be
to disable the mode by default.  Would you please give your word, as a
gentleman, that whatever transpires, after the sequence emacs -Q, C-x C-f
foo.c, foo.c's copy of c-electric-flag will always be t.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> There lacks a clean way of determining if a minor-mode function has been
> called.  There is a clear need for such a facility.

I don't see what's clear about this supposed need.

> As we have discussed before, it is essential that c-electric-flag be
> enabled by default for CC Mode buffers.

And as you probably remember, I disagree.  What is essential for me is
that C-mode have the same behavior as other modes.  I.e. obey
electric-indent-mode.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

Thanks for ignoring practically all of my last email.  That really made
my day.

On Sat, Mar 08, 2014 at 08:57:57PM -0500, Stefan Monnier wrote:
> > There lacks a clean way of determining if a minor-mode function has been
> > called.  There is a clear need for such a facility.

> I don't see what's clear about this supposed need.

So it would seem.

> > As we have discussed before, it is essential that c-electric-flag be
> > enabled by default for CC Mode buffers.

> And as you probably remember, I disagree.

Yes, I remember well.  Your disagreement consisted of noting that you
personally like typing tab all the time, rather than having lines of code
indent automatically.

> What is essential for me is that C-mode have the same behavior as other
> modes.  I.e. obey electric-indent-mode.

Major modes provide different behaviours, behaviours appropriate to the
type of text being edited.  That's why we have major modes.

Electric indentation in CC Mode is not broken.  You're determined,
nevertheless, to fix it.  The consequences for Emacs cannot be good.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> Thanks for ignoring practically all of my last email.
> That really made my day.

OK, since you insist, see detailed answers below.

>> And as you probably remember, I disagree.
> Yes, I remember well.  Your disagreement consisted of noting that you
> personally like typing tab all the time, rather than having lines of code
> indent automatically.

No, my personal preference has nothing to do with it.  That would affect
my ~/.emacs, not Emacs's own defaults.

>> What is essential for me is that C-mode have the same behavior as other
>> modes.  I.e. obey electric-indent-mode.
> Major modes provide different behaviours, behaviours appropriate to the
> type of text being edited.  That's why we have major modes.

Right.  But I don't see what is so special about the C language that
makes c-electric-flag (aka electric-indent-mode) indispensable in c-mode.

Better don't bother answering: electric-indent-mode is enabled by
default anyway, so there's really no problem here.

The question is really: why do you need to know if electric-indent-mode
was called (and even how many times)?  From what I understand of your
previous answers it is because you want to only obey
electric-indent-mode if the user changed the default.  If so, what is
wrong about testing Emacs's version instead?

AFAIK your only worry is when electric-indent-mode is nil to make sure
that the user really meant it.  But if you test Emacs's version to make
sure it's >24.3, then electric-indent-mode can only be nil if the user
decided so.  So you don't need to know if electric-indent-mode has been
called nor how many times.


        Stefan


> > No, we should only care about "enabled" and "disabled".
> That's a fairly contentious opinion, not backed up by any reasoning.
> Would you care to give your reasons why "default state" is not to be
> cared about?

You know very well:
some major modes have historically setup some keys to electrically
reindent the current line.  And some haven't.  This just reflects
the personal preference of the major mode's author(s).  It also means
that a user who doesn't like this behavior needs to disable it
separately for each and every such major mode (which includes figuring
out how to disable it, which is not standardized either).  And it also
means that a user who does like this behavior will have to tweak the
other major modes.

Hence my introducing electric-indent-mode to standardize the behavior
across modes.  As is too often the case, CC-mode is the only one that
doesn't want to get in line.

> As we have discussed before, it is essential that c-electric-flag be
> enabled by default for CC Mode buffers.  Without it, indentation would
> need to be done manually, e.g. by continual use of the tab key.

Right: when electric-indent-mode is nil, it means that the user wants to
have control over when auto-indentation is performed.  That's not a bug.

On the contrary: it is crucial to stay sane when you're editing code
using an indentation convention that's different from the one supported
by the major mode.

But indeed, electric-indent-mode is enabled by default, because we
recognize that it is overall better to try and maintain indentation
without forcing the user to constantly use TAB.

> Yet c-electric-flag, a buffer local flag, is now inextricably coupled
> to electric-indent-mode, a crude global flag.  A user wishing to
> disable electric-indent-mode for some random buffer will find
> automatic indentation broken in her C Mode buffers.

No, she will find it correctly disabled, according to her wish expressed
by the fact that she disabled electric-indent-mode.

> There is no mechanism provided to users by electric-indent-mode to enable
> it selectively in a buffer.

Alan, please be constructive: you know full well this is untrue.

> Even the undocumented electric-indent-local-mode

The fact that it's not yet documented is irrelevant, since that's
a problem that needs to be addressed anyway (and rather sooner than
later since it's one of the hurdles remaining for the trunk to re-open).

> doesn't work properly, as you admitted recently.

Right, it has some bugs open, and we'll have to fix them for 24.4.

> In the massive confusion and possible protest that will follow in the
> wake of the release of electric-indent-mode, one of your options will be
> to disable the mode by default.

Come on, Alan.  You know me better than that.

And FWIW you've been the strongest voice *against* enabling
electric-indent-mode, oddly enough.

> Would you please give your word, as a gentleman, that whatever
> transpires, after the sequence emacs -Q, C-x C-f foo.c, foo.c's copy
> of c-electric-flag will always be t.

No, I can't, sorry: if it were up to me, c-electric-flag would not even
exist any more.

But I can give you my word that "automatic indentation as a side effect
of normal editing" will be enabled by default in programming modes,
including C-like modes, yes.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Glenn Morris]

Stefan Monnier wrote:

>> Even the undocumented electric-indent-local-mode
>
> The fact that it's not yet documented is irrelevant, since that's
> a problem that needs to be addressed anyway (and rather sooner than
> later since it's one of the hurdles remaining for the trunk to re-open).

Since it doesn't even have a NEWS entry, don't hold your breath.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> No, I can't, sorry: if it were up to me, c-electric-flag would not even
> exist any more.

FWIW, I've just noticed that when `electric-pair-mode' is enabled in
c-mode, it's `electric-pair-backward-delete-char' command it not
working, since c-mode rebinds it to `c-electric-backspace'.

It works when I unbind `c-electric-backspace' from
`c-mode-base-map'. All other autopairing/autoskipping works well.

Perhaps a lesser problem since `electric-pair-mode' is not enabled by
default.

There might also be non-intrusive solutions on elec-pair.el's
side. Other modes like python-mode also like to redefine the backspace
key. They all seem to call backward-delete-char-untabify eventually, so
maybe somehow transferring `electric-pair-mode's behaviour there is a
good idea.

Should I open a bug report?

João

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> Should I open a bug report?

Yes.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hi, Stefan.

On Sun, Mar 09, 2014 at 11:37:36PM -0400, Stefan Monnier wrote:

> >> What is essential for me is that C-mode have the same behavior as other
> >> modes.  I.e. obey electric-indent-mode.
> > Major modes provide different behaviours, behaviours appropriate to the
> > type of text being edited.  That's why we have major modes.

> Right.  But I don't see what is so special about the C language that
> makes c-electric-flag (aka electric-indent-mode) indispensable in c-mode.

CC Mode modes don't indent correctly automatically without electric
indentation.  This is in the typical case where lines of code are being
typed in, line by line.

> Better don't bother answering: electric-indent-mode is enabled by
> default anyway, so there's really no problem here.

Good!

> The question is really: why do you need to know if electric-indent-mode
> was called (and even how many times)?  From what I understand of your
> previous answers it is because you want to only obey
> electric-indent-mode if the user changed the default.

Not quite.  I want the default for CC Mode modes to be t, regardless of
any system wide default.  I think it likely there will be other major
modes which need a default of nil.  Once a user has positively indicated
which way she wants the setting, then that is fine.

> If so, what is wrong about testing Emacs's version instead?

????

> AFAIK your only worry is when electric-indent-mode is nil to make sure
> that the user really meant it.  But if you test Emacs's version to make
> sure it's >24.3, then electric-indent-mode can only be nil if the user
> decided so.

electric-indent-mode is, essentially, new code, and its default doesn't
appear yet to have stabilised.  As I've already said, I anticipate a
storm of protest and a sea of confusion over this new default.  In order
to quell the protest, there will be the option of making the default nil
in future versions.  It would be good to have CC Mode decoupled from
this.

> So you don't need to know if electric-indent-mode has been called nor
> how many times.


>         Stefan


> > > No, we should only care about "enabled" and "disabled".
> > That's a fairly contentious opinion, not backed up by any reasoning.
> > Would you care to give your reasons why "default state" is not to be
> > cared about?

> You know very well:
> some major modes have historically setup some keys to electrically
> reindent the current line.  And some haven't.  This just reflects
> the personal preference of the major mode's author(s).

No.  It reflects the intrinsic needs of the major mode.  CC Mode needs
it, Emacs Lisp Mode is never going to have a use for it, Text Mode needs
it nil, and in some modes, electric indentation plain doesn't work
(python, for example).

> It also means that a user who doesn't like this behavior needs to
> disable it separately for each and every such major mode (which
> includes figuring out how to disable it, which is not standardized
> either).  And it also means that a user who does like this behavior
> will have to tweak the other major modes.

I think you are wrong in your tacit assumption that liking of e-i-m is
person dependent rather than major mode dependent.

> Hence my introducing electric-indent-mode to standardize the behavior
> across modes.  As is too often the case, CC-mode is the only one that
> doesn't want to get in line.

The way electric-indent-mode was implemented seems optimised to maximise
the difficulty of integrating CC Mode with it.  My main concern over this
integration has been avoiding loss of or damage to functionality.  CC
Mode's electric indentation is essentially 100% perfect, all the rough
edges and conflicts having been debated and settled in long forgotten 20
year old exchanges.  Have you ever wondered why RET and C-j aren't
electric keys in CC Mode?

Compatibility with stand-alone CC Mode has also been of some concern.

> > As we have discussed before, it is essential that c-electric-flag be
> > enabled by default for CC Mode buffers.  Without it, indentation would
> > need to be done manually, e.g. by continual use of the tab key.

> Right: when electric-indent-mode is nil, it means that the user wants to
> have control over when auto-indentation is performed.  That's not a bug.

This is the case after e-i-m has been SET to nil.  What is a bug (IMNSHO)
is that this selection is not buffer local.  Other similar features are
implemented as buffer local with a "global-*" variant: font-lock-mode,
hi-lock-mode, .....  There are at least 17 such minor modes with a global
variant.  electric-indent-mode is going to be inconsistent with these
other modes.  Why couldn't we have had electric-indent-mode and
global-electric-indent-mode?

> On the contrary: it is crucial to stay sane when you're editing code
> using an indentation convention that's different from the one supported
> by the major mode.

That is indeed the use case for no electric indentation (with the lesser
one of newbies who can't yet cope with it).

> But indeed, electric-indent-mode is enabled by default, because we
> recognize that it is overall better to try and maintain indentation
> without forcing the user to constantly use TAB.

Yes.

> > Yet c-electric-flag, a buffer local flag, is now inextricably coupled
> > to electric-indent-mode, a crude global flag.  A user wishing to
> > disable electric-indent-mode for some random buffer will find
> > automatic indentation broken in her C Mode buffers.

> No, she will find it correctly disabled, according to her wish expressed
> by the fact that she disabled electric-indent-mode.

You're assuming here that she will be disabling e-i-m due to a general
dislike of electricity, rather than having an isolated chaotically indented
buffer.

> > There is no mechanism provided to users by electric-indent-mode to enable
> > it selectively in a buffer.

> Alan, please be constructive: you know full well this is untrue.

> > Even the undocumented electric-indent-local-mode

> The fact that it's not yet documented is irrelevant, since that's
> a problem that needs to be addressed anyway (and rather sooner than
> later since it's one of the hurdles remaining for the trunk to re-open).

:-)

> > doesn't work properly, as you admitted recently.

> Right, it has some bugs open, and we'll have to fix them for 24.4.

Double :-).  On 2014-02-18 you opined "I don't think it's worth the
trouble" to fix.  I feel relieved it will be getting fixed now.

> > In the massive confusion and possible protest that will follow in the
> > wake of the release of electric-indent-mode, one of your options will be
> > to disable the mode by default.

> Come on, Alan.  You know me better than that.

> And FWIW you've been the strongest voice *against* enabling
> electric-indent-mode, oddly enough.

I don't think so.  I have strongly objected to the design features of
electric-indent-mode and protested against the collateral effects they
have on the rest of Emacs.

> > Would you please give your word, as a gentleman, that whatever
> > transpires, after the sequence emacs -Q, C-x C-f foo.c, foo.c's copy
> > of c-electric-flag will always be t.

> No, I can't, sorry: if it were up to me, c-electric-flag would not even
> exist any more.

Yes, I'm sure.  The flag is needed for all Emacsen which aren't GNU Emacs
24.4+.  It is well tested, works, seems to be used, and has never
elicited complaints from users.

> But I can give you my word that "automatic indentation as a side effect
> of normal editing" will be enabled by default in programming modes,
> including C-like modes, yes.

Thanks.  That will do.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

>> Right.  But I don't see what is so special about the C language that
>> makes c-electric-flag (aka electric-indent-mode) indispensable in c-mode.
> CC Mode modes don't indent correctly automatically without electric
> indentation.

And the same holds true for all other programming modes.
Nothing special here.

For some major modes (like Lisp), using newline-and-indent is sufficient
to indent code as you type it.  For most others,
reindent-then-newline-and-indent is needed instead.

I don't know of any mode where electric behavior of something else than
the newline character is needed for the "typical case where lines of
code are being typed in, line by line".  But since this "typical case"
is not that typical, several major modes elect to make a few other keys
electric so as to try and maintain indentation even when code is being
modified rather than just being written linearly.

Maybe the special part of c-mode is that you used a set of electric
chars which is sufficient and yet does not include newline.

> Not quite.  I want the default for CC Mode modes to be t, regardless of
> any system wide default.

I know you steadfastly refuse to recognize that this is your personal
preference rather than a requirement of the languages you support.

> I think you are wrong in your tacit assumption that liking of e-i-m is
> person dependent rather than major mode dependent.

There are details about *how* e-i-m works which depend on the mode.
Yes.  That's why e-i-m has mode-local settings (e.g. which keys are
electric, or whether the indentation algorithm can reliably reindent).

But the global e-i-m setting is about deciding whether the user wants
his code to be automatically indented as he types (to the extent
possible).  It is *defined* as a person-dependent preference.

> The way electric-indent-mode was implemented seems optimised to maximise
> the difficulty of integrating CC Mode with it.

Of course, my main objective was to piss you off and make your
life miserable.  It hasn't worked as well as planned, but this is not
quite over yet ;-)


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Mar 17, 2014 at 11:48:16AM -0400, Stefan wrote:
> >> Right.  But I don't see what is so special about the C language that
> >> makes c-electric-flag (aka electric-indent-mode) indispensable in c-mode.
> > CC Mode modes don't indent correctly automatically without electric
> > indentation.

> And the same holds true for all other programming modes.

No it doesn't.  We both agree that Emacs Lisp Mode has no use whatsoever
for electric indentation.  Clearly, only languages where a line's
indentation is dependent on the contents of that line can benefit from
electric indentation.

> Nothing special here.

> I don't know of any mode where electric behavior of something else than
> the newline character is needed for the "typical case where lines of
> code are being typed in, line by line".

Then I suggest you think hard about the disadvantages of RET as an
electric indentation key.  If there weren't such disadvantages, CC Mode
would have been using it for 20 years.

> But since this "typical case" is not that typical, several major modes
> elect to make a few other keys electric so as to try and maintain
> indentation even when code is being modified rather than just being
> written linearly.

Yes.

> Maybe the special part of c-mode is that you used a set of electric
> chars which is sufficient and yet does not include newline.

Newline is a poor choice for an electric indentation key.

> > Not quite.  I want the default for CC Mode modes to be t, regardless of
> > any system wide default.

> I know you steadfastly refuse to recognize that this is your personal
> preference rather than a requirement of the languages you support.

You're not going to accept reasoned argument here, so I think there's no
point continuing this line of discussion.

> > I think you are wrong in your tacit assumption that liking of e-i-m is
> > person dependent rather than major mode dependent.

> There are details about *how* e-i-m works which depend on the mode.
> Yes.  That's why e-i-m has mode-local settings (e.g. which keys are
> electric, or whether the indentation algorithm can reliably reindent).

Any "indentation algorithm" can reliably reindent.  It is the context in
which the algorithm is used which is important, not the algorithm itself.

> But the global e-i-m setting is about deciding whether the user wants
> his code to be automatically indented as he types (to the extent
> possible).  It is *defined* as a person-dependent preference.

Clearly.  I am pointing out that this definition is perhaps a suboptimal
one.  Your scheme makes it difficult for a user to set up a major mode as
being non e-i-m, or even an individual buffer.

> > The way electric-indent-mode was implemented seems optimised to maximise
> > the difficulty of integrating CC Mode with it.

> Of course, my main objective was to piss you off and make your
> life miserable.  It hasn't worked as well as planned, but this is not
> quite over yet ;-)

Not even that.  You were in so much of a hurry to reinvent the wheel,
that you were oblivious of perfectly round wheels with smooth bearings
which had been in existence for ~20 years.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

>> And the same holds true for all other programming modes.
> No it doesn't.  We both agree that Emacs Lisp Mode has no use whatsoever
> for electric indentation.

No, I don't agree.  First because most people don't use C-j but use
RET instead, and second because typing text linearly is far from being
the only important editing pattern.

> Then I suggest you think hard about the disadvantages of RET as an
> electric indentation key.  If there weren't such disadvantages, CC Mode
> would have been using it for 20 years.

I need your help here, I'm afraid.  And I'm obviously not the only,
because it's very common for text editors to "auto-indent on RET"
(either by default, or via a config setting).

>> There are details about *how* e-i-m works which depend on the mode.
>> Yes.  That's why e-i-m has mode-local settings (e.g. which keys are
>> electric, or whether the indentation algorithm can reliably reindent).
> Any "indentation algorithm" can reliably reindent.

No: python-mode, haskell-mode, and coffeescript-mode can't.

> Clearly.  I am pointing out that this definition is perhaps a suboptimal
> one.

I don't see what you mean by "definition" not "suboptimal".

> Your scheme makes it difficult for a user to set up a major mode as
> being non e-i-m, or even an individual buffer.

How so?

> Not even that.  You were in so much of a hurry to reinvent the wheel,
> that you were oblivious of perfectly round wheels with smooth bearings
> which had been in existence for ~20 years.

No, I know those wheels very well, because I suffered through many of
them.  The problem is they're not modular: your rebinding of ?{ to make
it auto-indent means that my global binding of ?{ to make it auto-pair
doesn't work in c-mode.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

() Stefan <monnier@iro.umontreal.ca>
() Wed, 19 Mar 2014 21:46:03 -0400

   [...] because most people don't use C-j but use RET instead

Drat, another case where i am revealed to be not like Most People.  :-/

Seriously, typing RET often is a good way to twist the wrist and inflame
the nerves therein.  Personally, i avoid it as much as possible; when i
need to invoke the ‘newline’ command, i type ‘C-m’.

(end random data point)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[João Távora]

Thien-Thi Nguyen <ttn@gnu.org> writes:

>    [...] because most people don't use C-j but use RET instead
>
> Drat, another case where i am revealed to be not like Most People.
> :-/
> [...]
> need to invoke the ‘newline’ command, i type ‘C-m’.

But you are like most people, C-m *is* RET. By default I think.

J

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Wed, Mar 19, 2014 at 09:46:03PM -0400, Stefan wrote:
> >> And the same holds true for all other programming modes.
> > No it doesn't.  We both agree that Emacs Lisp Mode has no use whatsoever
> > for electric indentation.

> No, I don't agree.  First because most people don't use C-j but use
> RET instead, and second because typing text linearly is far from being
> the only important editing pattern.

????  That's a non-sequitur.  The indentation of an elisp line of code is
solely dependent on the the lines before it - its indentation is
completely determined before any of its contents are typed in.  Therefore
there is nothing to be gained by reindenting this line at any subsequent
time, i.e. electric indentation.

Whether a user uses C-j or RET to terminate this line is irrelevant.

> > Then I suggest you think hard about the disadvantages of RET as an
> > electric indentation key.  If there weren't such disadvantages, CC Mode
> > would have been using it for 20 years.

> I need your help here, I'm afraid.  And I'm obviously not the only,
> because it's very common for text editors to "auto-indent on RET"
> (either by default, or via a config setting).

You're being vague, here.  By "auto-indent on RET" you could mean indent
the existing line ("electric indentation") or the new line created
("newline-and-indent").  The newline-and-indent behaviour is common in
other editors, electric indentation is not.  (I'm not aware of another
editor which does it, but I'm willing to be informed of any.)

Using electric indentation on RET is poor, because it only works when you
actually type a RET (or a C-j).  This is often not the case, e.g. when
you open up a line (e.g. with C-M-o) then type in a new line of code.

If you are typing in comments at the end of code lines, you won't want
electric indentation messing up their alignment.  You also want to know
how much space you've got between the comment opener and "column 80", for
whatever value of column 80 you use.  You will want electric indentation
to have done its thing _before_ you start typing the comment.  Thus
electric indentation is needed on keys other than RET; when that is the
case, e-i on RET is superfluous.

> >> There are details about *how* e-i-m works which depend on the mode.
> >> Yes.  That's why e-i-m has mode-local settings (e.g. which keys are
> >> electric, or whether the indentation algorithm can reliably reindent).
> > Any "indentation algorithm" can reliably reindent.  It is the context
> > in which the algorithm is used which is important, not the algorithm
> > itself.

> No: python-mode, haskell-mode, and coffeescript-mode can't.

We're in violent agreement, here.  It is the context (i.e. the major
mode) these indentation algorithms are used in, not the algorithms
themselves.  The algorithms themselves are perfectly capable of
reindentation.

> > Clearly.  I am pointing out that this definition is perhaps a suboptimal
> > one.

> I don't see what you mean by "definition" not "suboptimal".

You've cut out the necessary context again, and put me to unnecessary
work to restore it.  This makes it look like you want to evade answering
the point, without being obvious that this is what you are doing.  This
is one of the most irritating tactics that can be used on a mailing list,
short of out and out trolling.  PLEASE STOP DOING THIS!!!!

Here is that context, restored:
>>> But the global e-i-m setting is about deciding whether the user wants
>>> his code to be automatically indented as he types (to the extent
>>> possible).  It is *defined* as a person-dependent preference.

>>Clearly.  I am pointing out that this definition is perhaps a suboptimal
>>one.

> I don't see what you mean by "definition" not "suboptimal"

I think it's now clear which definition, your definition, we're talking
about.  I put it to you, once more, that this "person-dependent"
preference, as contrasted with a major-mode or buffer dependent one, is
suboptimal. 

> > Not even that.  You were in so much of a hurry to reinvent the wheel,
> > that you were oblivious of perfectly round wheels with smooth bearings
> > which had been in existence for ~20 years.

> No, I know those wheels very well, because I suffered through many of
> them.

Your "suffering", outlined below, concerned a peripheral annoyance, not
the basic design.  If that suffering was so great, how come you never
sent a report to bug-cc-mode about it?

The point is, that you could easily have taken over the design features
of CC Mode's electric indentation, which would likely have gone through
all sorts of false starts and design mistakes 20 years ago before
emerging with its well considered, slick design.  Instead, you started
from scratch, repeating history instead of learning from it.

> The problem is they're not modular: your rebinding of ?{ to make it
> auto-indent means that my global binding of ?{ to make it auto-pair
> doesn't work in c-mode.

You're saying it's OK for a _MINOR_ mode to bind "{" ???  This is crazy.
Supposing another minor mode also wanted to bind "{" for its purposes?
Which one wins?  This is clearly unsustainable.

Minor modes which want to hook up their functionality to a key like "{"
should do just that, not attempt to supersede other functionality.
Mechanisms for this exist - electric-indent-mode uses one of these, for
example.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

>> No, I don't agree.  First because most people don't use C-j but use
>> RET instead, and second because typing text linearly is far from being
>> the only important editing pattern.

> ????  That's a non-sequitur.  The indentation of an elisp line of code is
> solely dependent on the the lines before it - its indentation is
> completely determined before any of its contents are typed in.  Therefore
> there is nothing to be gained by reindenting this line at any subsequent
> time, i.e. electric indentation.
> Whether a user uses C-j or RET to terminate this line is irrelevant.

Then I have no idea what you're talking about.  "electric-indent" to me
means "try to keep code indented without having to hit TAB".  In Elisp,
without electric-indent you have to use C-j or TAB if you want your
code indented.  So whether the user hits C-j or RET is relevant.

> Using electric indentation on RET is poor, because it only works when you
> actually type a RET (or a C-j).

That doesn't mean it's poor.  Just that it's not sufficient.
And I fully agree on this, which is why we have electric-indent-chars.

> This is often not the case, e.g. when you open up a line (e.g. with
> C-M-o) then type in a new line of code.

Last I checked, RET is used more commonly than C-M-o.

> If you are typing in comments at the end of code lines, you won't want
> electric indentation messing up their alignment.

If auto-indentation gets it wrong, then indeed electric-indent will get
in the way.  That's true whether RET is electric or not.

> electric indentation is needed on keys other than RET; when that is the
> case, e-i on RET is superfluous.

Having RET in electric-indent-chars is not always indispensable, indeed.
But that doesn't make it harmful.  And of course, if you want, you can
remove it from electric-indent-chars either in your .emacs or in c-mode.

>> >> There are details about *how* e-i-m works which depend on the mode.
>> >> Yes.  That's why e-i-m has mode-local settings (e.g. which keys are
>> >> electric, or whether the indentation algorithm can reliably reindent).
>> > Any "indentation algorithm" can reliably reindent.  It is the context
>> > in which the algorithm is used which is important, not the algorithm
>> > itself.
>> No: python-mode, haskell-mode, and coffeescript-mode can't.
> We're in violent agreement, here.  It is the context (i.e. the major
> mode) these indentation algorithms are used in, not the algorithms
> themselves.  The algorithms themselves are perfectly capable of
> reindentation.

To me, the algorithm used by haskell-mode could not be used in
another context, so this distinction makes no sense.

> You've cut out the necessary context again, and put me to unnecessary
> work to restore it.

No, it's because the context did not manage to explain to me the text
that I quoted.  I stripped this context because it was not useful for me
to explain precisely which part I failed to understand.

> Here is that context, restored:
>>>> But the global e-i-m setting is about deciding whether the user wants
>>>> his code to be automatically indented as he types (to the extent
>>>> possible).  It is *defined* as a person-dependent preference.
>>> Clearly.  I am pointing out that this definition is perhaps a suboptimal
>>> one.
>> I don't see what you mean by "definition" not "suboptimal"
> I think it's now clear which definition, your definition, we're talking
> about.

Thanks, yes, that makes sense.

> I put it to you, once more, that this "person-dependent" preference,
> as contrasted with a major-mode or buffer dependent one,
> is suboptimal.

What would be more optimal?

Clearly, having the major mode decide for the user is not better because
I can assure you that there are users who want electric indentation in
C-mode and there are others who don't.

> Minor modes which want to hook up their functionality to a key like "{"
> should do just that, not attempt to supersede other functionality.
> Mechanisms for this exist - electric-indent-mode uses one of these, for
> example.

Well, mechanisms to do that were added at the same time as
electric-indent-mode.

But so it seems the part of the design you dislike in
electric-indent-mode is not the use of post-self-insert-hook (as
I assumed) but something else.  What is it?

It seems now that your main (only?) objection is having RET do
reindent-then-newline-and-indent instead of having it only do
newline-and-indent.  If that's the case, then let's focus on this.
In what scenario is it a problem?


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On 3/22/14, 9:14 AM, Stefan wrote:
> It seems now that your main (only?) objection is having RET do
> reindent-then-newline-and-indent instead of having it only do
> newline-and-indent.  If that's the case, then let's focus on this.
> In what scenario is it a problem?

Let me ask this, in what scenario does it actually do anything useful?

All the cases I can think of it's a nop, except when the indent guessing
is flat out wrong, and then it's just annoying (Grrrr, M-_ C-q RET TAB).

-David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[David Kastrup]

David Caldwell <david@porkrind.org> writes:

> On 3/22/14, 9:14 AM, Stefan wrote:
>> It seems now that your main (only?) objection is having RET do
>> reindent-then-newline-and-indent instead of having it only do
>> newline-and-indent.  If that's the case, then let's focus on this.
>> In what scenario is it a problem?
>
> Let me ask this, in what scenario does it actually do anything useful?

   }
   ^

When pressing RET now, the result should be

   }

   ^

with the added empty line being _empty_ rather than containing two
spaces.

> All the cases I can think of it's a nop, except when the indent
> guessing is flat out wrong, and then it's just annoying (Grrrr, M-_
> C-q RET TAB).

Yup.  The current behavior makes editing flex or bison files (a mixture
of patterns and/or rules and C code) a lot more annoying than it was a
year ago since at points of "bad indentation" (when in the pattern/rule
part or on its boundary to C code), RET does a lot more damage than
previously.

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On 3/22/14, 3:05 PM, David Kastrup wrote:
> David Caldwell <david@porkrind.org> writes:
> 
>> On 3/22/14, 9:14 AM, Stefan wrote:
>>> It seems now that your main (only?) objection is having RET do
>>> reindent-then-newline-and-indent instead of having it only do
>>> newline-and-indent.  If that's the case, then let's focus on this.
>>> In what scenario is it a problem?
>>
>> Let me ask this, in what scenario does it actually do anything useful?
> 
>    }
>    ^
> 
> When pressing RET now, the result should be
> 
>    }
> 
>    ^
> 
> with the added empty line being _empty_ rather than containing two
> spaces.

Then perhaps it shouldn't act like "TAB RET TAB" but instead like "M-\
RET TAB". Or even "s/^\s +$// RET TAB" (in case preserving trailing
whitespace on a non-blank line is somehow better—though I think it would
not be).

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

>> It seems now that your main (only?) objection is having RET do
>> reindent-then-newline-and-indent instead of having it only do
>> newline-and-indent.  If that's the case, then let's focus on this.
>> In what scenario is it a problem?
> Let me ask this, in what scenario does it actually do anything useful?

When you edit a line in such as way that this line's indentation is not
correct any more and then you hit RET.  E.g. start from

       foo();

put point right before "f" and type: "end RET".
Of course, in a language that uses "begin ... end" or something like that.

> All the cases I can think of it's a nop, except when the indent guessing
> is flat out wrong, and then it's just annoying (Grrrr, M-_ C-q RET TAB).

Yes, electric-indent is a pain when the indent guessing is wrong.
But that holds for all electric-indent-chars.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Sat, Mar 22, 2014 at 12:14:54PM -0400, Stefan wrote:
> > The indentation of an elisp line of code is solely dependent on the
> > the lines before it - its indentation is completely determined before
> > any of its contents are typed in.  Therefore there is nothing to be
> > gained by reindenting this line at any subsequent time, i.e. electric
> > indentation.  Whether a user uses C-j or RET to terminate this line
> > is irrelevant.

> Then I have no idea what you're talking about.  "electric-indent" to me
> means "try to keep code indented without having to hit TAB".

The actual definition of "electricity" is found in the Emacs manual, page
"Electric C", where it has been for a very long time indeed.  It runs as
follows:

    In C mode and related modes, certain printing characters are
    "electric"--in addition to inserting themselves, they also reindent
    the current line, and optionally also insert newlines.

.  If you redefine the "electric" in "electric-indent" as you have done,
you conflate unrelated topics, and both your thought patterns and the
code end up a mess.  It is not helpful to construe `newline-and-indent'
as somehow being "electric".

> In Elisp, without electric-indent you have to use C-j or TAB if you
> want your code indented.  So whether the user hits C-j or RET is
> relevant.

No.  To keep Elisp properly indented, you merely have to depress
whichever key is bound to `newline-and-indent', whether that be RET, or
C-j, or whatever.  Electric indentation doesn't come into it.

> > Using electric indentation on RET is poor, because it only works when you
> > actually type a RET (or a C-j).

> That doesn't mean it's poor.  Just that it's not sufficient.
> And I fully agree on this, which is why we have electric-indent-chars.

> > This is often not the case, e.g. when you open up a line (e.g. with
> > C-M-o) then type in a new line of code.

> Last I checked, RET is used more commonly than C-M-o.

Yes, but the point still stands.  You open up a fresh line, by RET, and
type code into it, but don't want to type RET/C-j at the end of it.
You'll want electric indentation on some other character you've just
typed.

> > If you are typing in comments at the end of code lines, you won't want
> > electric indentation messing up their alignment.

> If auto-indentation gets it wrong, then indeed electric-indent will get
> in the way.  That's true whether RET is electric or not.

No.  If electric indentation has already happened after typing the
semicolon/comma/brace, the alignment of the subsequent comment will
remain undisturbed.  If RET puts the alignment out, you're cursing it.

> > electric indentation is needed on keys other than RET; when that is the
> > case, e-i on RET is superfluous.

> Having RET in electric-indent-chars is not always indispensable, indeed.
> But that doesn't make it harmful.  And of course, if you want, you can
> remove it from electric-indent-chars either in your .emacs or in c-mode.

> >>>> But the global e-i-m setting is about deciding whether the user wants
> >>>> his code to be automatically indented as he types (to the extent
> >>>> possible).  It is *defined* as a person-dependent preference.
> >>> Clearly.  I am pointing out that this definition is perhaps a suboptimal
> >>> one.
> >> I don't see what you mean by "definition" not "suboptimal"
> > I think it's now clear which definition, your definition, we're talking
> > about.

> Thanks, yes, that makes sense.

> > I put it to you, once more, that this "person-dependent" preference,
> > as contrasted with a major-mode or buffer dependent one,
> > is suboptimal.

> What would be more optimal?

A mode-dependent or buffer-local dependent setting, as well as, rather
than instead of.

> Clearly, having the major mode decide for the user is not better because
> I can assure you that there are users who want electric indentation in
> C-mode and there are others who don't.

C Mode users who don't want electric indentation have been remarkably
quiet about it on bug-cc-mode, at least since `c-toggle-electric-state'
was introduced.

Each major mode should be able to decide on its own default, which the
user should be able to override easily.

> > Minor modes which want to hook up their functionality to a key like "{"
> > should do just that, not attempt to supersede other functionality.
> > Mechanisms for this exist - electric-indent-mode uses one of these, for
> > example.

> Well, mechanisms to do that were added at the same time as
> electric-indent-mode.

Yes.

> But so it seems the part of the design you dislike in
> electric-indent-mode is not the use of post-self-insert-hook (as
> I assumed) but something else.  What is it?

It is the conflation of electric indentation with the "-and-indent" part
of `newline-and-indent', and the poor quality code this has led to.  For
example, `newline' and `newline-and-indent', strong, well understood,
well coded functions have been superseeded by new `newline' and
`electric-newline-and-maybe-indent', both vague functions which sometimes
indent the new line, sometimes don't.  Another example: `newline' has
been sullied with a grotesque new parameter "interactive" whose meaning
can not be reconciled with `newline''s functionality, but can only be
described by a flowchart of new `newline''s internal workings.

Having a minor mode tweek the global keymap on being enabled was
grotesque, but that has, thankfully, now been fixed.  The wierd
implementation of `electric-indent-local-mode', which didn't work
properly, is also getting fixed, though it is still needlessly
complicated.

I strongly dislike, even despise, the conflation of electric indentation
with the way (RET C-j) are bound to (`newline' `newline-and-indent').
The bindings of these keys has nothing to do with electric indentation,
and swapping their functionalities on {en,dis}abling e-i-m is bizarre.
There was no discussion of this on emacs-devel, and no consensus for this
change.  What _was_ discussed was the swapping of the two bindings in
programming modes, and it was coincidental that this discussion happened
in an offshoot of a thread discussing electric indentation mode.  Why
can't we simply have RET bound to `newline-and-indent' and C-j bound to
`newline' in programming modes, as discussed and, pretty much agreed on,
in emacs-devel last autumn?

Given that electric-indent-mode could have been implemented with the same
functionality in a clear, straightforward fashion, it is galling to see
the "clever", fragile, difficult to maintain code which we now have.

None of this am I saying here for the first time.

I object to the documentation of e-i-m on the info page "Convenience
Functions", as though it were some minor convenience function rather than
the essential component of automatic indentation it actually is.  But I
think we would agree this documentation needs amending anyway.

> It seems now that your main (only?) objection is having RET do
> reindent-then-newline-and-indent instead of having it only do
> newline-and-indent.

See above.  ;-)

> If that's the case, then let's focus on this.  In what scenario is it a
> problem?

I suppose it's not really a big problem.  Having RET/C-j as electric keys
in CC Mode just isn't needed.  _Any_ line of code in a real C/C++/...
program is going to contain some other electric character.  Other major
modes would likely also benefit from having characters other than RET
electric.

Incidentally, in Emacs -Q, Text Mode and Fundamental Mode have gone back
to the unwanted state of RET doing `newline-and-indent'.  Should I raise
another bug report?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

> The actual definition of "electricity" is found in the Emacs manual, page

Use in other packages shows that people have understood the notion of
"electric" to mean many other things beside the very restricted
semantics you point to.

>> In Elisp, without electric-indent you have to use C-j or TAB if you
>> want your code indented.  So whether the user hits C-j or RET is
>> relevant.
> No.  To keep Elisp properly indented, you merely have to depress
> whichever key is bound to `newline-and-indent', whether that be RET, or
> C-j, or whatever.

"whichever key is bound to `newline-and-indent'" would be C-j and not
RET in all Emacsen released so far, so I see we violently agree.

> Electric indentation doesn't come into it.

Of course it does because electric-indent changes the behavior such that
RET can be (or has to be in 24.4) used instead of C-j.  But you knew
that, obviously.

> Yes, but the point still stands.  You open up a fresh line, by RET, and
> type code into it, but don't want to type RET/C-j at the end of it.

Fine.  Feel free to provide a patch to make split-line auto-indent when
electric-indent is enabled.

> You'll want electric indentation on some other character you've just
> typed.

Indeed that's also good.  But I don't know of any such character we
could use globally in electric-indent-chars, so it's up to each major
mode to specify which chars to use.

> No.  If electric indentation has already happened after typing the
> semicolon/comma/brace, the alignment of the subsequent comment will
> remain undisturbed.  If RET puts the alignment out, you're cursing it.

Then I misunderstood and don't know what you're talking about.  Can you
give a scenario?

>> What would be more optimal?
> A mode-dependent or buffer-local dependent setting, as well as, rather
> than instead of.

We have that: electric-indent-local-mode and electric-indent-inhibit.

> Why can't we simply have RET bound to `newline-and-indent' and C-j
> bound to `newline' in programming modes, as discussed and, pretty much
> agreed on, in emacs-devel last autumn?

Lack of patch implementing this (supposed) simple change?

> Incidentally, in Emacs -Q, Text Mode and Fundamental Mode have gone back
> to the unwanted state of RET doing `newline-and-indent'.  Should I raise
> another bug report?

You can, but it's not a bug.  It's a feature (not sure what you mean by
"back" since it's been this way ever since I enabled
electric-indent-mode by default, AFAIK).
So make this bug report specific about a particular circumstance where
the behavior is undesirable, or about how hard it is to disable it.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 23, 2014 at 09:37:09PM -0400, Stefan wrote:
> > The actual definition of "electricity" is found in the Emacs manual, page

> Use in other packages shows that people have understood the notion of
> "electric" to mean many other things beside the very restricted
> semantics you point to.

Yes, but as used in "electric indentation", I think the terminology, and
the methodology, has been as in C Mode's definition up until very
recently.

> > No.  To keep Elisp properly indented, you merely have to depress
> > whichever key is bound to `newline-and-indent', whether that be RET, or
> > C-j, or whatever.

> "whichever key is bound to `newline-and-indent'" would be C-j and not
> RET in all Emacsen released so far, so I see we violently agree.

> > Electric indentation doesn't come into it.

> Of course it does because electric-indent changes the behavior such that
> RET can be (or has to be in 24.4) used instead of C-j.  But you knew
> that, obviously.

OK, I meant "electric indentation" as defined in the manual page -
"reindenting the current line".  This has nothing to do with which way
round C-j and RET are bound.

> > You'll want electric indentation on some other character you've just
> > typed.

> Indeed that's also good.  But I don't know of any such character we
> could use globally in electric-indent-chars, so it's up to each major
> mode to specify which chars to use.

Yes.

> > No.  If electric indentation has already happened after typing the
> > semicolon/comma/brace, the alignment of the subsequent comment will
> > remain undisturbed.  If RET puts the alignment out, you're cursing it.

> Then I misunderstood and don't know what you're talking about.  Can you
> give a scenario?

Assume that electric indentation happens on \n, and not on {.  You type
in a { (which is intrinsically 4 characters too indented, for some value
of 4) then do M-; to insert a comment at comment-column.  You fill in the
comment, do C-e then RET.  The ensuing electric indentation on RET puts
out the alignment of the comment:

                            if (foo)       /* aligned comment */
			    {          /* coment misaligned by e-i-m */

> >> What would be more optimal?
> > A mode-dependent or buffer-local dependent setting, as well as, rather
> > than instead of.

> We have that: electric-indent-local-mode and electric-indent-inhibit.

OK, for electric-indent-local-mode, which is gradually becoming
prominent.  But I though electric-indent-inhibit was a variable for major
modes, not users - a mode initialisation thing, rather than a user
configuration variable.

> > Why can't we simply have RET bound to `newline-and-indent' and C-j
> > bound to `newline' in programming modes, as discussed and, pretty much
> > agreed on, in emacs-devel last autumn?

> Lack of patch implementing this (supposed) simple change?

Here is what I propose, and am willing to do:
1. For electric indentation:
  a - Restore `newline' and `newline-and-indent' to their traditional
    functionality, and remove `electric-newline-and-maybe-indent'.
  b - Simplify `electric-indent-post-self-insert-function' such that it
    reindents only the line on which the self-inserting character is
    typed.
  c - Reform `electric-indent-local-mode' as a first-class minor mode and
    `electric-indent-mode' as a global version of it.
2. For making RET indent the new line in programming modes:
  a - Bind RET to `newline-and-indent' and C-j to `newline' in
    `prog-mode-map' and possibly in certain other major mode maps (to be
    discussed).
  b - (Maybe) create a minor mode to restore RET and C-j to traditional
    bindings.

The above will leave electric-indent-mode functioning pretty much as it
currently does.  What do you say?

> > Incidentally, in Emacs -Q, Text Mode and Fundamental Mode have gone back
> > to the unwanted state of RET doing `newline-and-indent'.  Should I raise
> > another bug report?

> You can, but it's not a bug.  It's a feature (not sure what you mean by
> "back" since it's been this way ever since I enabled
> electric-indent-mode by default, AFAIK).

Apologies: I thought Text Mode had been restored to the traditional
bindings in the last few months.

> So make this bug report specific about a particular circumstance where
> the behavior is undesirable, or about how hard it is to disable it.

I think RMS's bug #16156, reproduced and being discussed on a parallel
thread, is a good enough example, so there's not much point in me opening
a new one.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

Alan Mackenzie <acm@muc.de> writes:

>> > A mode-dependent or buffer-local dependent setting, as well as, rather
>> > than instead of.
>
>> We have that: electric-indent-local-mode and electric-indent-inhibit.
>
> OK, for electric-indent-local-mode, which is gradually becoming
> prominent.  But I though electric-indent-inhibit was a variable for major
> modes, not users - a mode initialisation thing, rather than a user
> configuration variable.

This is usually the case with buffer-local dependent settings. They're
impossible to set via Customize (I think), so one doesn't usually think
of them as user options, but a user can modify such var in a hook, too.

>  b - Simplify `electric-indent-post-self-insert-function' such that it
>    reindents only the line on which the self-inserting character is
>    typed.

It would still need to handle presence of ?\n in `electric-indent-chars'
when that's the case.  This value is somewhat special since the
line-to-be reindented would be the previous, not the current one.

> 2. For making RET indent the new line in programming modes:
>   a - Bind RET to `newline-and-indent' and C-j to `newline' in
>     `prog-mode-map' and possibly in certain other major mode maps (to be
>     discussed).

I believe there's something to be said for consistency: having RET
indent line in some modes, but not others doesn't make much sense to me.

There's a certain class of users who've been binding RET to
`newline-and-indent' for a long time (myself included), and I haven't
seen anyone mention only doing that in prog-mode, instead of globally.

>   b - (Maybe) create a minor mode to restore RET and C-j to traditional
>     bindings.

How hard can it be for a user to change the key bindings without a mode?

>> So make this bug report specific about a particular circumstance where
>> the behavior is undesirable, or about how hard it is to disable it.
>
> I think RMS's bug #16156, reproduced and being discussed on a parallel
> thread, is a good enough example, so there's not much point in me opening
> a new one.

This behavior, as described in the bug above, makes sense to me, so it's
clearly a personal preference.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Dmitry.

On Tue, Mar 25, 2014 at 03:37:15AM +0200, Dmitry Gutov wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> > A mode-dependent or buffer-local dependent setting, as well as, rather
> >> > than instead of.

> >> We have that: electric-indent-local-mode and electric-indent-inhibit.

> > OK, for electric-indent-local-mode, which is gradually becoming
> > prominent.  But I though electric-indent-inhibit was a variable for major
> > modes, not users - a mode initialisation thing, rather than a user
> > configuration variable.

> This is usually the case with buffer-local dependent settings. They're
> impossible to set via Customize (I think), so one doesn't usually think
> of them as user options, but a user can modify such var in a hook, too.

That's not what I meant.  I meant something more like
electric-indent-inhibit being a setting which defines a major mode rather
than being a way of configuring it.

> >  b - Simplify `electric-indent-post-self-insert-function' such that it
> >    reindents only the line on which the self-inserting character is
> >    typed.

> It would still need to handle presence of ?\n in `electric-indent-chars'
> when that's the case.  This value is somewhat special since the
> line-to-be reindented would be the previous, not the current one.

Yes to all of that.  But I expressed myself precisely, and meant what I
wrote.

> > 2. For making RET indent the new line in programming modes:
> >   a - Bind RET to `newline-and-indent' and C-j to `newline' in
> >     `prog-mode-map' and possibly in certain other major mode maps (to be
> >     discussed).

> I believe there's something to be said for consistency: having RET
> indent line in some modes, but not others doesn't make much sense to me.

Indentation (in the sense of what `indent-line-function' does) only makes
sense in programming (etc.) modes.  In text modes, and the like,
indentation is, in practice, done with adaptive fill prefices.

Having RET do `newline-and-indent' in Emacs Lisp Mode while doing
`newline' in Text Mode makes a lot of sense to me.  A trickier question
is to identify which of the non-programming modes really want this sort
of indentation.

> There's a certain class of users who've been binding RET to
> `newline-and-indent' for a long time (myself included), and I haven't
> seen anyone mention only doing that in prog-mode, instead of globally.

That was what we collectively decided last Autumn when the topic came up.

You've seen me mention it.  ;-)

Richard Stallman alluded to it in his disgust at bug #16156, when what
was bound to RET at the time zapped his indentation.

I personally would not be unhappy at leaving the traditional binding in
place for RET and C-j, but wouldn't mind them swapping in "indenting"
modes.  I'd object strongly to RET in text mode messing around with
indentation.

> >   b - (Maybe) create a minor mode to restore RET and C-j to traditional
> >     bindings.

> How hard can it be for a user to change the key bindings without a mode?

Middling, not very.  Such a minor mode might serve to damp down the
inevitable complaints the change in defaults will provoke.

> >> So make this bug report specific about a particular circumstance where
> >> the behavior is undesirable, or about how hard it is to disable it.

> > I think RMS's bug #16156, reproduced and being discussed on a parallel
> > thread, is a good enough example, so there's not much point in me opening
> > a new one.

> This behavior, as described in the bug above, makes sense to me, so it's
> clearly a personal preference.

By "makes sense" I think you mean "seems a sensible thing to do".  I take
issue with you here and say that, in Text Mode, it's a bizarre thing to
do.  I can't think of any normal circumstances where this behaviour would
be commonly desired; just how often in Text Mode do you not want RET just
to insert a new line when you type it at the beginning of a line?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

Hi Alan,

On 26.03.2014 22:53, Alan Mackenzie wrote:

> Indentation (in the sense of what `indent-line-function' does) only makes
> sense in programming (etc.) modes.  In text modes, and the like,
> indentation is, in practice, done with adaptive fill prefices.

This could be considered a reason to improve the indent-line-function in 
text-mode. `indent-relative' offers behavior that's pretty close. Maybe 
it could be made to follow the behavior of auto-fill even closer.

> Having RET do `newline-and-indent' in Emacs Lisp Mode while doing
> `newline' in Text Mode makes a lot of sense to me.  A trickier question
> is to identify which of the non-programming modes really want this sort
> of indentation.

I'd rather make exceptions for specific "non-programming modes", where 
indentation of the next line is really hard to guess.

Many modes that don't inherit from prog-mode have something to do with 
structured content, and often define their own specific indentation 
functions (sgml-mode, markdown-mode inherit from text-mode, css-mode and 
yaml-mode inherit from fundamental-mode).

I'd really expect typing <div> and pressing RET in html-mode to offer 
hard +2 indentation on the next line, but I wouldn't call it a 
programming mode.

In Markdown, I'm often typing code blocks, and I expect RET to bring me 
to the column which the previous line was indented to, so I don't have 
to press TAB each time. And if I'm outside of a code block, the lines 
usually either have no indentation (then indent-relative indents to the 
0th column as well), or they serve as continuation of a paragraph, and I 
want each next line to have the same extra indentation until the 
paragraph ends (and indent-relative does that well enough).

The last time I used text-mode, it was for a similar purpose (a couple 
of code blocks, and the rest of the text is indented to column 0).

`M-x fill-paragraph' would slaughter the code blocks, and it wouldn't 
improve the indentation anywhere else.

It also eats line breaks that were put in manually. A good example is 
ChangeLog files: we often see cleanup commits in Emacs that change the 
places where the lines are broken, for better readability, in ways that 
fill-paragraph is unable to do automatically.

And if ChangeLog files didn't always magically have the right 
indentation (one tab), and one had to fix it with `fill-paragraph', all 
the manual line breaks would be mangled, each time. It still happens 
when I fix lines that are too long this way.

>> There's a certain class of users who've been binding RET to
>> `newline-and-indent' for a long time (myself included), and I haven't
>> seen anyone mention only doing that in prog-mode, instead of globally.
>
> That was what we collectively decided last Autumn when the topic came up.

Okay: I haven't seen anyone mention doing it outside of emacs-devel.

> Richard Stallman alluded to it in his disgust at bug #16156, when what
> was bound to RET at the time zapped his indentation.
>
> I personally would not be unhappy at leaving the traditional binding in
> place for RET and C-j, but wouldn't mind them swapping in "indenting"
> modes.  I'd object strongly to RET in text mode messing around with
> indentation.

Maybe text-mode by itself should be a special case. I don't use it often 
enough to have a strong opinion.

>> How hard can it be for a user to change the key bindings without a mode?
>
> Middling, not very.  Such a minor mode might serve to damp down the
> inevitable complaints the change in defaults will provoke.

As long as this new mode is divorced from electric-indent-mode, I'd be 
happy.

> By "makes sense" I think you mean "seems a sensible thing to do".  I take
> issue with you here and say that, in Text Mode, it's a bizarre thing to
> do.  I can't think of any normal circumstances where this behaviour would
> be commonly desired; just how often in Text Mode do you not want RET just
> to insert a new line when you type it at the beginning of a line?

This specific behavior is a consequence of using `newline-and-indent'. 
One answer may be "Don't want that? Use `open-line'", which I sometimes 
do, but special-casing indent-line-function in text-mode not to reindent 
on the first invocation (when point is at bol followed by whitespace and 
then non-whitespace on the same line) could well be another option.

What makes sense to me, is using `newline-and-indent' itself. Richard 
doesn't like

foo
|  bar

turning into

foo

|bar

I can understand that, but I don't like

foo
   bar|baz

turning into

foo
   bar
|baz  (note the missing indentation)

Which situation do you think occurs more frequently?

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Dmitry.

On Thu, Mar 27, 2014 at 10:02:49AM +0200, Dmitry Gutov wrote:
> On 26.03.2014 22:53, Alan Mackenzie wrote:

> > Indentation (in the sense of what `indent-line-function' does) only makes
> > sense in programming (etc.) modes.  In text modes, and the like,
> > indentation is, in practice, done with adaptive fill prefices.

> This could be considered a reason to improve the indent-line-function in 
> text-mode. `indent-relative' offers behavior that's pretty close. Maybe 
> it could be made to follow the behavior of auto-fill even closer.

Notice, here, how we're no longer talking about electric indentation, but
rather about newline-and-indent.  The two topics are distinct.

> > Having RET do `newline-and-indent' in Emacs Lisp Mode while doing
> > `newline' in Text Mode makes a lot of sense to me.  A trickier question
> > is to identify which of the non-programming modes really want this sort
> > of indentation.

> I'd rather make exceptions for specific "non-programming modes", where 
> indentation of the next line is really hard to guess.

Yes, but how?  fundamental-mode is a non-programming mode, so the global
key map needs RET set up for newline, C-j for newline-and-indent.  That
leaves lots of mode key maps to be set up.  At this point, your
suggestion and mine become the same.

> Many modes that don't inherit from prog-mode have something to do with 
> structured content, and often define their own specific indentation 
> functions (sgml-mode, markdown-mode inherit from text-mode, css-mode and 
> yaml-mode inherit from fundamental-mode).

> I'd really expect typing <div> and pressing RET in html-mode to offer 
> hard +2 indentation on the next line, but I wouldn't call it a 
> programming mode.

Yes.

> In Markdown, I'm often typing code blocks, and I expect RET to bring me 
> to the column which the previous line was indented to, so I don't have 
> to press TAB each time. And if I'm outside of a code block, the lines 
> usually either have no indentation (then indent-relative indents to the 
> 0th column as well), or they serve as continuation of a paragraph, and I 
> want each next line to have the same extra indentation until the 
> paragraph ends (and indent-relative does that well enough).

I usually think of html, markdown, and such like, as the "etc." in
"programming modes (etc.)".

> The last time I used text-mode, it was for a similar purpose (a couple 
> of code blocks, and the rest of the text is indented to column 0).

> `M-x fill-paragraph' would slaughter the code blocks, and it wouldn't 
> improve the indentation anywhere else.

If you edit the non-code blocks a lot in text mode, `fill-paragraph' is
_exactly_ what's wanted to restore the filling.  I think, in text mode,
M-q preserves existing indentation.

> >> There's a certain class of users who've been binding RET to
> >> `newline-and-indent' for a long time (myself included), and I
> >> haven't seen anyone mention only doing that in prog-mode, instead of
> >> globally.

> > That was what we collectively decided last Autumn when the topic came up.

> Okay: I haven't seen anyone mention doing it outside of emacs-devel.

> > Richard Stallman alluded to it in his disgust at bug #16156, when what
> > was bound to RET at the time zapped his indentation.

> > I personally would not be unhappy at leaving the traditional binding in
> > place for RET and C-j, but wouldn't mind them swapping in "indenting"
> > modes.  I'd object strongly to RET in text mode messing around with
> > indentation.

> Maybe text-mode by itself should be a special case. I don't use it often 
> enough to have a strong opinion.

I think RET should do the most natural sort of newline, and C-j the
subsidiary one, whatever they may happen to be for a particular mode.

> >> How hard can it be for a user to change the key bindings without a
> >> mode?

> > Middling, not very.  Such a minor mode might serve to damp down the
> > inevitable complaints the change in defaults will provoke.

> As long as this new mode is divorced from electric-indent-mode, I'd be 
> happy.

This is a key point.

> > By "makes sense" I think you mean "seems a sensible thing to do".  I take
> > issue with you here and say that, in Text Mode, it's a bizarre thing to
> > do.  I can't think of any normal circumstances where this behaviour would
> > be commonly desired; just how often in Text Mode do you not want RET just
> > to insert a new line when you type it at the beginning of a line?

> This specific behavior is a consequence of using `newline-and-indent'. 

No, not at all.  It's a consequence of electric behaviour getting
entangled with newline-and-indent.  Electric indentation doesn't belong
in Text Mode.  It's useful only where the indentation of a line of code
can be changed by what's in the line.

> One answer may be "Don't want that? Use `open-line'", which I sometimes 
> do, but special-casing indent-line-function in text-mode not to reindent 
> on the first invocation (when point is at bol followed by whitespace and 
> then non-whitespace on the same line) could well be another option.

;-)  That would be papering over the cracks.  Banishing electric
indentation from major modes where it's silly is what we really want.

> What makes sense to me, is using `newline-and-indent' itself. Richard 
> doesn't like

> foo
> |  bar

> turning into

> foo

> |bar

> I can understand that, but I don't like

> foo
>    bar|baz

> turning into

> foo
>    bar
> |baz  (note the missing indentation)

> Which situation do you think occurs more frequently?

The two are completely non-competing situations.  RMS's happened because
electric indentation was active where it shouldn't be.  Your situation is
a matter of binding (RET C-j) to ('newline 'newline-and-indent) the
appropriate way round.  Don't confuse these.

I think Text Mode is about typing natural language text in paragraphs.
The "indentation" will be the adaptive fill prefix inserted by
auto-fill-mode.  Normally, you'll be typing RET to start a new paragraph,
and this will either be at column 0, or at some column not dependent on
the previous text.  newline-and-indent isn't the Right Thing here.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

On 30.03.2014 17:57, Alan Mackenzie wrote:

>> This could be considered a reason to improve the indent-line-function in
>> text-mode. `indent-relative' offers behavior that's pretty close. Maybe
>> it could be made to follow the behavior of auto-fill even closer.
>
> Notice, here, how we're no longer talking about electric indentation, but
> rather about newline-and-indent.  The two topics are distinct.

Yes, but I think we're discussing both in this thread. FWIW, I think 
we're in agreement about electric indentation on RET. See my message 
here, and also Stefan's reply:

http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00936.html
http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00957.html

> Yes, but how?  fundamental-mode is a non-programming mode, so the global
> key map needs RET set up for newline, C-j for newline-and-indent.  That
> leaves lots of mode key maps to be set up.  At this point, your
> suggestion and mine become the same.

Maybe.

> I usually think of html, markdown, and such like, as the "etc." in
> "programming modes (etc.)".

Yeah, okay. Which other modes exactly need newline-and-indent on RET 
could be a matter of debate, but one possible criteria is "mode has a 
meaningful/specialized indentation function".

> If you edit the non-code blocks a lot in text mode, `fill-paragraph' is
> _exactly_ what's wanted to restore the filling.

If the filling algorithm is perfect, then yes, it could be what's wanted.

> I think RET should do the most natural sort of newline, and C-j the
> subsidiary one, whatever they may happen to be for a particular mode.

Sounds okay, I guess.

>> As long as this new mode is divorced from electric-indent-mode, I'd be
>> happy.
>
> This is a key point.

It could be something called like `old-newline-keys-mode'. Appropriate 
major modes would swap RET and C-j bindings, and the above minor mode 
would force them all back to (RET C-j) -> (newline newline-and-indent).

>> This specific behavior is a consequence of using `newline-and-indent'.
>
> No, not at all.  It's a consequence of electric behaviour getting
> entangled with newline-and-indent.

It's the same if I disable `electric-indent-mode' but bind RET to 
`newline-and-indent'.

And if `electric-indent-mode' didn't do `-and-indent' but retained the 
electric indent on RET, a similar example is easy to demonstrate:

foo
   bar|

Press RET, see the same result.

IOW, text-mode could be considered in trouble if RET triggers call to 
indentation at any line.

> The two are completely non-competing situations.  RMS's happened because
> electric indentation was active where it shouldn't be.

AFAICT it's the opposite, but see the scenario above.

To quote the bug report: "and point is at the start of the second line"

> Your situation is
> a matter of binding (RET C-j) to ('newline 'newline-and-indent) the
> appropriate way round.  Don't confuse these.

Indeed, for my usage the above binding is sufficient.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Mar 31, 2014 at 08:11:58PM +0300, Dmitry Gutov wrote:
> On 30.03.2014 17:57, Alan Mackenzie wrote:

> >> This could be considered a reason to improve the
> >> indent-line-function in text-mode. `indent-relative' offers behavior
> >> that's pretty close. Maybe it could be made to follow the behavior
> >> of auto-fill even closer.

> > Notice, here, how we're no longer talking about electric indentation, but
> > rather about newline-and-indent.  The two topics are distinct.

> Yes, but I think we're discussing both in this thread. FWIW, I think 
> we're in agreement about electric indentation on RET. See my message 
> here, and also Stefan's reply:

> http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00936.html
> http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00957.html

Yes, I think we're in agreement with eachother, but not with Stefan.  He
has decided to conflate the RET/C-j bindings and electric-indent-mode,
and to have these bindings apparently flip each time e-i-m is called.
He's also decided to do this although there's never been any meaningful
discussion of it here, and there isn't going to be any.

> > I usually think of html, markdown, and such like, as the "etc." in
> > "programming modes (etc.)".

> Yeah, okay. Which other modes exactly need newline-and-indent on RET 
> could be a matter of debate, but one possible criteria is "mode has a 
> meaningful/specialized indentation function".

Hmm.  I'm not sure that gets us very far, in practice.  What does
"meaningful/specialized" mean?  I'll be more specific: programming modes
which use syntactic indentation (i.e. most of them) and the various
markup-like modes which are "like" programming languages.

> > I think RET should do the most natural sort of newline, and C-j the
> > subsidiary one, whatever they may happen to be for a particular mode.

> Sounds okay, I guess.

> >> As long as this new mode is divorced from electric-indent-mode, I'd be
> >> happy.

> > This is a key point.

> It could be something called like `old-newline-keys-mode'. Appropriate 
> major modes would swap RET and C-j bindings, and the above minor mode 
> would force them all back to (RET C-j) -> (newline newline-and-indent).

Again, Stefan has decided there will be no such new mode, and that its
functionality is going to be twisted up with electric-indent-mode, rather
than being independent of it.  It now seems us discussing this further
would just be a waste of time.


> >> This specific behavior is a consequence of using `newline-and-indent'.

> > No, not at all.  It's a consequence of electric behaviour getting
> > entangled with newline-and-indent.

> It's the same if I disable `electric-indent-mode' but bind RET to 
> `newline-and-indent'.

> And if `electric-indent-mode' didn't do `-and-indent' but retained the 
> electric indent on RET, a similar example is easy to demonstrate:

> foo
>    bar|

> Press RET, see the same result.

Yes.  Again, if we're in a programming mode that's what we want nearly
all the time - it's what electric indentation is for (despite all the
disadvantages of doing it on \n).  In non-programming modes it's what we
don't want.  It now seems Somebody (tm) is going to have to trawl through
all major modes disabling electric indentation for lots of them.

> IOW, text-mode could be considered in trouble if RET triggers call to 
> indentation at any line.

Yes indeed.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

> Assume that electric indentation happens on \n, and not on {.  You type
> in a { (which is intrinsically 4 characters too indented, for some value
> of 4) then do M-; to insert a comment at comment-column.  You fill in the
> comment, do C-e then RET.  The ensuing electric indentation on RET puts
> out the alignment of the comment:
>                             if (foo)       /* aligned comment */
> 			    {          /* coment misaligned by e-i-m */

Ah, you're again pointing out the benefit of adding more chars to
electric-indent-chars.  Fine.  We've already been in violent agreement
on this time for a long time.

>> >> What would be more optimal?
>> > A mode-dependent or buffer-local dependent setting, as well as, rather
>> > than instead of.
>> We have that: electric-indent-local-mode and electric-indent-inhibit.
> OK, for electric-indent-local-mode, which is gradually becoming
> prominent.  But I thought electric-indent-inhibit was a variable for major
> modes, not users - a mode initialisation thing, rather than a user
> configuration variable.

Indeed electric-indent-inhibit is not meant as a user-config.
And electric-indent-mode is not meant as a buffer-local config.
So what?  There is electric-indent-local-mode which is meant as
a buffer-local user-config.

So what is the problem?  Please tell precisely what feature you miss
rather than just criticize the existing ones.

>> Lack of patch implementing this (supposed) simple change?
> Here is what I propose, and am willing to do:
> 1. For electric indentation:
>   a - Restore `newline' and `newline-and-indent' to their traditional
>     functionality, and remove `electric-newline-and-maybe-indent'.
>   b - Simplify `electric-indent-post-self-insert-function' such that it
>     reindents only the line on which the self-inserting character is
>     typed.
>   c - Reform `electric-indent-local-mode' as a first-class minor mode and
>     `electric-indent-mode' as a global version of it.
> 2. For making RET indent the new line in programming modes:
>   a - Bind RET to `newline-and-indent' and C-j to `newline' in
>     `prog-mode-map' and possibly in certain other major mode maps (to be
>     discussed).
>   b - (Maybe) create a minor mode to restore RET and C-j to traditional
>     bindings.
> The above will leave electric-indent-mode functioning pretty much as it
> currently does.  What do you say?

I want to keep electric-indent-mode as a global mode that determines
whether certain self-inserting keys (such as RET and others) auto-indent.

>> So make this bug report specific about a particular circumstance where
>> the behavior is undesirable, or about how hard it is to disable it.
> I think RMS's bug #16156, reproduced and being discussed on a parallel
> thread, is a good enough example, so there's not much point in me opening
> a new one.

Then post in that bug explaining why the behavior is undesirable or how
hard it is to disable it.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Mar 24, 2014 at 09:54:40PM -0400, Stefan wrote:

> >> > A mode-dependent or buffer-local dependent setting, as well as, rather
> >> > than instead of.
> >> We have that: electric-indent-local-mode and electric-indent-inhibit.
> > OK, for electric-indent-local-mode, which is gradually becoming
> > prominent.  But I thought electric-indent-inhibit was a variable for major
> > modes, not users - a mode initialisation thing, rather than a user
> > configuration variable.

> Indeed electric-indent-inhibit is not meant as a user-config.
> And electric-indent-mode is not meant as a buffer-local config.
> So what?  There is electric-indent-local-mode which is meant as
> a buffer-local user-config.

> So what is the problem?  Please tell precisely what feature you miss
> rather than just criticize the existing ones.

I seem to have lost the thread here.  Maybe there aren't any.

> >> Lack of patch implementing this (supposed) simple change?
> > Here is what I propose, and am willing to do:
> > 1. For electric indentation:
> >   a - Restore `newline' and `newline-and-indent' to their traditional
> >     functionality, and remove `electric-newline-and-maybe-indent'.
> >   b - Simplify `electric-indent-post-self-insert-function' such that it
> >     reindents only the line on which the self-inserting character is
> >     typed.
> >   c - Reform `electric-indent-local-mode' as a first-class minor mode and
> >     `electric-indent-mode' as a global version of it.
> > 2. For making RET indent the new line in programming modes:
> >   a - Bind RET to `newline-and-indent' and C-j to `newline' in
> >     `prog-mode-map' and possibly in certain other major mode maps (to be
> >     discussed).
> >   b - (Maybe) create a minor mode to restore RET and C-j to traditional
> >     bindings.
> > The above will leave electric-indent-mode functioning pretty much as it
> > currently does.  What do you say?

> I want to keep electric-indent-mode as a global mode that determines
> whether certain self-inserting keys (such as RET and others) auto-indent.

How is this not satisfied by e-i-m being a define-globalized-minor-mode?
With the current setup, we have a rather contorted relationship between
e-i-m and e-i-local-m, with buffer local copies of electric-indent-mode
popping into and out of existence.

What about the rest of my suggestion?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

>> I want to keep electric-indent-mode as a global mode that determines
>> whether certain self-inserting keys (such as RET and others) auto-indent.
> How is this not satisfied by e-i-m being a define-globalized-minor-mode?

AFAICT your suggestion would not swap RET/C-j depending on e-i-m.

> With the current setup, we have a rather contorted relationship between
> e-i-m and e-i-local-m, with buffer local copies of electric-indent-mode
> popping into and out of existence.

For a setting which is mostly global by nature (it reflects on the
user's general preference), I'm not worried and generally prefer this
over using define-globalized-minor-mode which is a fine hack, but
a hack nevertheless.

> What about the rest of my suggestion?

I'm worried about the possible consequences: e-i-m has been around for
a little while now and we're somewhat familiar with its problems.
Your approach might solve some problems (tho I haven't seen a clear
statement of what those problems are, in terms of *behavior*), but will
inevitably come with its own set of consequences.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stefan.

On Thu, Mar 27, 2014 at 10:49:06AM -0400, Stefan Monnier wrote:
> >> I want to keep electric-indent-mode as a global mode that determines
> >> whether certain self-inserting keys (such as RET and others) auto-indent.
> > How is this not satisfied by e-i-m being a define-globalized-minor-mode?

> AFAICT your suggestion would not swap RET/C-j depending on e-i-m.

It would most emphatically not do so.  That is something which was never
discussed on emacs-devel before it was implemented, and it is wrong.
Unrelated things should not be bound together into a single action.

> > With the current setup, we have a rather contorted relationship between
> > e-i-m and e-i-local-m, with buffer local copies of electric-indent-mode
> > popping into and out of existence.

> For a setting which is mostly global by nature (it reflects on the
> user's general preference), I'm not worried and generally prefer this
> over using define-globalized-minor-mode which is a fine hack, but
> a hack nevertheless.

Eh?  How does global-font-lock-mode, for example, not work 100%?  It is
also "mostly global by nature".  What might not work properly if e-i-m
was made into a globalized minor mode?

With a globalized-minor-mode, it is predictable which buffers are
affected when the global command is given, namely all of them.  With
e-i-m, only some buffers are affected, and there is currently no
rationale behind which ones are, which ones aren't.  You need to read the
source code to work this out, and that is bad.

> > What about the rest of my suggestion?

> I'm worried about the possible consequences: e-i-m has been around for
> a little while now and we're somewhat familiar with its problems.

The changes I'm proposing, with the exception already noted, are not
changes in functionality.  e-i-m is essentially still fresh code - one or
two enthusiasts used it in 24.3, but it hasn't really hit big time yet.
Now is the right time to sort out its problems.  Besides, we're hackers,
and we're competent.  :-)

> Your approach might solve some problems (tho I haven't seen a clear
> statement of what those problems are, in terms of *behavior*), ...

e-i-m also toggling RET/C-j is a behaviour problem, as noted above.

But the other problems are those of bad design and bad coding, not bad
behaviour.  They are all the the consequence of a single design mistake,
namely that e-i-post-self-insert-function tries to handle the indentation
of a new line.  This has led to difficult to understand overcomplicated
coding, functional duplication, disassociation of functionality from
defuns, damaged backward compatibility, ....

These problems should be _fixed_.  To fix them is not difficult.  I'm
willing to do this.

> .... but will inevitably come with its own set of consequences.

Inevitably?  How so?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

>> >> I want to keep electric-indent-mode as a global mode that determines
>> >> whether certain self-inserting keys (such as RET and others) auto-indent.
>> > How is this not satisfied by e-i-m being a define-globalized-minor-mode?
>> AFAICT your suggestion would not swap RET/C-j depending on e-i-m.
> It would most emphatically not do so.

This is a non-starter: cutting the link between the two is not really up
for negotiation, it's an important part of keeping the interface simple.

That is: it's OK to have a custom var deciding whether e-i-m swaps RET
and LF, but by default that custom var should be enabled.

> Eh?  How does global-font-lock-mode, for example, not work 100%?

Analyze the code from a suspicious point of view, like you do for e-i-m,
and you'll soon find ways.  Or use your memory of problems we've had.

>> I'm worried about the possible consequences: e-i-m has been around for
>> a little while now and we're somewhat familiar with its problems.
> The changes I'm proposing, with the exception already noted, are not
> changes in functionality.

I'd be very surprised if it doesn't change functionality: saying it
doesn't is not sufficient.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hi, Stefan.

Another point:

On Sat, Mar 22, 2014 at 12:14:54PM -0400, Stefan wrote:

> Having RET in electric-indent-chars is not always indispensable, indeed.
> But that doesn't make it harmful.

See bug #16156 from Richard, which is still open:
"
In text mode, if the buffer contains
-----------------------------------------
foo
   bar
-----------------------------------------

and point is at the start of the second line, and I type RET,
it gives

-----------------------------------------
foo

bar
-----------------------------------------

This is clearly wrong.
"

This is caused by RET being in electric-indent-chars.  Here, it _is_
harmful.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

> In text mode, if the buffer contains
> -----------------------------------------
> foo
>    bar
> -----------------------------------------

> and point is at the start of the second line, and I type RET, it gives

> -----------------------------------------
> foo
>
> bar
> -----------------------------------------

> This is clearly wrong.

I don't see what is "clear" about it being wrong, sorry.
I see you don't like it (and Richard apparently doesn't like it either),
but that's a different problem.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stephen J. Turnbull]

Stefan writes:

 > > In text mode, if the buffer contains
 > > -----------------------------------------
 > > foo
 > >    bar
 > > -----------------------------------------
 > 
 > > and point is at the start of the second line, and I type RET, it gives
 > 
 > > -----------------------------------------
 > > foo
 > >
 > > bar
 > > -----------------------------------------
 > 
 > > This is clearly wrong.
 > 
 > I don't see what is "clear" about it being wrong, sorry.
 > I see you don't like it (and Richard apparently doesn't like it either),
 > but that's a different problem.

It would be nice if you guys would avoid using keystrokes instead of
commands in this discussion.  I think it's perfectly reasonable to
swap the usage of CR and LF from `newline' and `newline-and-indent' to
`newline-and-indent' and `newline', respectively.  That may disconcert
us oldtimers, but I suspect it's what newcomers to Emacs will expect.[1]
And it's easy enough to "fix" if you don't like it.  But I hope that's
not what Alan's talking about, although it's entirely unclear to me if
that's what Stefan's talking about.

That is, if what Alan means by "type RET" is "type a keystroke bound
to `newline'", then my preference accords with his.  For my usage that
behavior is *clearly* *wrong*, as in text modes when there's leading
whitespace on a line, either *I* put it there, or some electrically-
crapified command that I just disabled the electricity on did (and it
won't happen again, so there's no reason not to fix it by hand this
time).

Footnotes: 
[1]  I got used to it in Python-mode quite readily, despite continuing
to use the traditional bindings for RET and C-j in other modes.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> That is, if what Alan means by "type RET" is "type a keystroke bound
> to `newline'", then my preference accords with his.  For my usage that
> behavior is *clearly* *wrong*, as in text modes when there's leading
> whitespace on a line, either *I* put it there, or some electrically-
> crapified command that I just disabled the electricity on did (and it
> won't happen again, so there's no reason not to fix it by hand this
> time).

FWIW, effectively doing `reindent-then-newline-and-indent' on RET also
seems gratuitous to me. When I reach the end of a line, usually text on
that line is already indented correctly (automatically, or through me
typing TAB manually), so the first `reindent' does nothing, unless the
indentation function was wrong about the current line in the first
place, and I had to adjust it manually.

The modes where reindenting the current line on RET is beneficial often,
can add `?\n' to electric-indent-chars themselves. For most, the
benefits are marginal and they are offset by having to tweak
`electric-indent-inhibit' or
`electric-indent-functions-without-reindent' for existing text-based
modes.

For all others, just swapping C-j and RET bindings would've worked just
as well, and I think it would result in simpler code.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 24 Mar 2014 11:08:43 +0200
> Cc: Alan Mackenzie <acm@muc.de>, Stefan <monnier@IRO.UMontreal.CA>,
> 	emacs-devel@gnu.org
> 
> FWIW, effectively doing `reindent-then-newline-and-indent' on RET also
> seems gratuitous to me. When I reach the end of a line, usually text on
> that line is already indented correctly (automatically, or through me
> typing TAB manually), so the first `reindent' does nothing, unless the
> indentation function was wrong about the current line in the first
> place, and I had to adjust it manually.

This might be mostly true, but not always.  E.g., what if you delete a
character whose electricity caused the line to be indented in some
special way, when that character was inserted earlier?  After deleting
that character, the line might no longer be indented correctly.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Mon, 24 Mar 2014 11:08:43 +0200
>> Cc: Alan Mackenzie <acm@muc.de>, Stefan <monnier@IRO.UMontreal.CA>,
>> 	emacs-devel@gnu.org
>> 
>> FWIW, effectively doing `reindent-then-newline-and-indent' on RET also
>> seems gratuitous to me. When I reach the end of a line, usually text on
>> that line is already indented correctly (automatically, or through me
>> typing TAB manually), so the first `reindent' does nothing, unless the
>> indentation function was wrong about the current line in the first
>> place, and I had to adjust it manually.
>
> This might be mostly true, but not always.  E.g., what if you delete a
> character whose electricity caused the line to be indented in some
> special way, when that character was inserted earlier?

I _expect_ to have to type TAB when deleting electric characters.

> After deleting that character, the line might no longer be indented
> correctly.

Really, the only actually valid argument so far is Stefan's of typing

end M-x newline-and-indent RET

when in pascal and on

   a := 7.0
  ^

since it is

   end a:= 7.0

but

end
a := 7.0

except, of course, that it is actually

end;
a := 7.0

after all even in Pascal.  And pressing TAB on

   end;a := 7.0

still will do the right thing.  So I don't really think the "inserting
newline will actually cause a different indentation for the line above"
case is relevant enough to fall over backwards for it.

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Really, the only actually valid argument so far is Stefan's of typing
>
> end M-x newline-and-indent RET
>
> after all even in Pascal.  And pressing TAB on
>
>    end;a := 7.0
>
> still will do the right thing.  So I don't really think the "inserting
> newline will actually cause a different indentation for the line above"
> case is relevant enough to fall over backwards for it.

Here are cases where it makes a difference: when pressing RET in the
middle of endend or enduntil or similar joined block-ending reserved
words.  But then typing SPC TAB Left RET is reasonably workable.  Or C-o
TAB C-n TAB or a number of other ways.

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

On 24.03.2014 19:19, Eli Zaretskii wrote:

> This might be mostly true, but not always.  E.g., what if you delete a
> character whose electricity caused the line to be indented in some
> special way, when that character was inserted earlier?  After deleting
> that character, the line might no longer be indented correctly.

This is covered by "through me typing TAB manually".

If I delete a char or a keyword making the line indented incorrectly, 
the next thing I do is type TAB. And `reindent-' on RET would still be a 
no-op.

This could be just me, but I somehow doubt that.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Eli Zaretskii]

> Date: Mon, 24 Mar 2014 19:38:44 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: stephen@xemacs.org, acm@muc.de, monnier@IRO.UMontreal.CA, 
>  emacs-devel@gnu.org
> 
> On 24.03.2014 19:19, Eli Zaretskii wrote:
> 
> > This might be mostly true, but not always.  E.g., what if you delete a
> > character whose electricity caused the line to be indented in some
> > special way, when that character was inserted earlier?  After deleting
> > that character, the line might no longer be indented correctly.
> 
> This is covered by "through me typing TAB manually".

It's a nuisance for me to have to type TAB every time.  Long time ago,
I switched to Emacs because it didn't require that to keep the source
nicely formatted, while other IDEs did.

> If I delete a char or a keyword making the line indented incorrectly, 
> the next thing I do is type TAB. And `reindent-' on RET would still be a 
> no-op.
> 
> This could be just me, but I somehow doubt that.

Not just you, but not me, either ;-)

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

>> > This might be mostly true, but not always.  E.g., what if you delete a
>> > character whose electricity caused the line to be indented in some
>> > special way, when that character was inserted earlier?  After deleting
>> > that character, the line might no longer be indented correctly.
>> 
>> This is covered by "through me typing TAB manually".
>
> It's a nuisance for me to have to type TAB every time.

"every time" sounds much more annoying than "every time I perform some
improbable operation". ;)

> I switched to Emacs because it didn't require that to keep the source
> nicely formatted, while other IDEs did.

I mostly like the fact that `indent-for-tab-command' is idempotent in
most modes.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: acm@muc.de,  stephen@xemacs.org,  monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Tue, 25 Mar 2014 03:53:35 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > This might be mostly true, but not always.  E.g., what if you delete a
> >> > character whose electricity caused the line to be indented in some
> >> > special way, when that character was inserted earlier?  After deleting
> >> > that character, the line might no longer be indented correctly.
> >> 
> >> This is covered by "through me typing TAB manually".
> >
> > It's a nuisance for me to have to type TAB every time.
> 
> "every time" sounds much more annoying than "every time I perform some
> improbable operation". ;)

When I edit source code, I don't think in terms of whether I've just
performed some improbable operation.  I just edit, and expect Emacs to
do the rest.  Typing RET is a natural part of editing; typing TAB is
not.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan]

> FWIW, effectively doing `reindent-then-newline-and-indent' on RET also
> seems gratuitous to me. When I reach the end of a line, usually text on
> that line is already indented correctly (automatically, or through me
> typing TAB manually),

You might get used to "RET reindents" and stop hitting TAB that often ;-)
For me one of the reasons why it's not gratuitous is because of things like:

       begin
         blabla
         blibli
       end

Go to just before "blibli" and type "end RET": notice that hitting TAB
just before RET won't help you, because you need to reindent the line
after the newline is inserted.

This is admittedly less serious for interactive editing than for
keyboard macros (and templates/skeletons/snippets), but I find the
behavior to be handy.

> The modes where reindenting the current line on RET is beneficial often,
> can add `?\n' to electric-indent-chars themselves.

Indeed, we could do that.

> For most, the benefits are marginal and they are offset by having to
> tweak `electric-indent-inhibit' or
> `electric-indent-functions-without-reindent' for existing
> text-based modes.

Good point.

> For all others, just swapping C-j and RET bindings would've worked just
> as well, and I think it would result in simpler code.

Again "just swapping" sounds simple, but I'm not sure what patch you
have in mind.  I think it's important for the user to be able to easily
say something like (electric-indent-mode -1) (and/or its buffer-local
equivalent) to recover the Emacs-23 behavior.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

Stefan <monnier@IRO.UMontreal.CA> writes:

> You might get used to "RET reindents" and stop hitting TAB that often
> ;-)

Maybe. :) But if I'm going to type anything else at all on the given
line before typing RET, the hand is itching to reindent before that, to
make text look ordered.

> For me one of the reasons why it's not gratuitous is because of things like:
>
>        begin
>          blabla
>          blibli
>        end
>
> Go to just before "blibli" and type "end RET": notice that hitting TAB
> just before RET won't help you, because you need to reindent the line
> after the newline is inserted.

I can see how this could be handy, but it's not an example I see
frequently. In part because I use `ruby-end', which inserts `end' after
one types a block beginner and SPC or RET. So one's inclined to produce
all `end' keywords that way, to keep them paired.

In any case, this seems to depend on the language having
keyword-delimited blocks and no semicolons.  This does not characterize
the majority of the languages Emacs supports, I think.

>> For all others, just swapping C-j and RET bindings would've worked just
>> as well, and I think it would result in simpler code.
>
> Again "just swapping" sounds simple, but I'm not sure what patch you
> have in mind.

I've commented on Alan's proposed plan of action.

> I think it's important for the user to be able to easily
> say something like (electric-indent-mode -1) (and/or its buffer-local
> equivalent) to recover the Emacs-23 behavior.

The importance of this is not clear to me, but I guess it wouldn't hurt
to have this, either way.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stephen J. Turnbull]

Stefan writes:

 > > FWIW, effectively doing `reindent-then-newline-and-indent' on RET also
 > > seems gratuitous to me. When I reach the end of a line, usually text on
 > > that line is already indented correctly (automatically, or through me
 > > typing TAB manually),
 > 
 > You might get used to "RET reindents" and stop hitting TAB that often ;-)

I'm very unlikely to get used to it.  Specifically, in the very
annoying case where unconventional indentation gets blown away by it
(TAB won't fix that!)

 > For me one of the reasons why it's not gratuitous is because of things like:
 > 
 >        begin
 >          blabla
 >          blibli
 >        end
 > 
 > Go to just before "blibli" and type "end RET": notice that hitting TAB
 > just before RET won't help you, because you need to reindent the line
 > after the newline is inserted.

I wouldn't do that, because the right indentation for "blibli" depends
on intended semantics.  That is, if I started from syntactically valid
code, after inserting "end" I now have invalid code ("end without
begin").  Non-trivial edits are required to return the buffer to
"well-formed" state, and I personally prefer the now-orphaned fragment
to retain its indentation, indicating its previous semantics.

Therefore I would go to the end of "blabla", and hit RET.  Why would I
care about the "no-op" reindent?  Because it might not be a no-op.
("blabla" might not be conventionally indented.)

 > This is admittedly less serious for interactive editing than for
 > keyboard macros (and templates/skeletons/snippets), but I find the
 > behavior to be handy.

In case of such things, I'd want to do

    C-x ( C-SPC ... macro keys ... C-x C-x M-x indent-region C-x )

(except in Python, where you're screwed because block structure is
determined by indentation, so situations where determining the
appropriate number of dedents requires knowing the intended semantics
are common).

 > > For all others, just swapping C-j and RET bindings would've worked just
 > > as well, and I think it would result in simpler code.
 > 
 > Again "just swapping" sounds simple, but I'm not sure what patch you
 > have in mind.  I think it's important for the user to be able to easily
 > say something like (electric-indent-mode -1) (and/or its buffer-local
 > equivalent) to recover the Emacs-23 behavior.

"Just swapping" is entirely independent of electric-indent-mode.  It
wouldn't change the Emacs-23 behavior, just have it on different keys.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

>> You might get used to "RET reindents" and stop hitting TAB that often ;-)

> I'm very unlikely to get used to it.  Specifically, in the very
> annoying case where unconventional indentation gets blown away by it
> (TAB won't fix that!)

I've been C-j'ing to get return and indent, since I first startet using
emacs, back in 1987 or 1988 or thereabouts.

Works for me.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stephen J. Turnbull]

Steinar Bang writes:
 > >>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:
 > 
 > >> You might get used to "RET reindents" and stop hitting TAB that often ;-)
 > 
 > > I'm very unlikely to get used to it.  Specifically, in the very
 > > annoying case where unconventional indentation gets blown away by it
 > > (TAB won't fix that!)
 > 
 > I've been C-j'ing to get return and indent, since I first startet using
 > emacs, back in 1987 or 1988 or thereabouts.
 > 
 > Works for me.

*sigh* That is simply not the point, it has worked forever (I started
using Emacs in 1979, don't remember if `newline-and-indent' was
implemented in pre-GNU Emacsen) and I don't expect it to stop working.

There are two problems with binding `reindent-then-newline-and-indent'
(RTNAT) and `newline-and-indent' (NAT) but not `newline'.  The first
is that the simple, reliable "newline" behavior is not easily available
in macros and the like.

The second is that for many users RTNAT is going to be identical to
NAT 95% of the time, or perhaps more, depending on how often they edit
code such that the changed syntax requires changed indentation.  This
makes one simply an unreliable version of the other, ISTM.  If a user
likes RTNAT behavior, they probably are willing to put up with the
occasional spurious indentation change -- and won't use the NAT
binding.  If they don't like that behavior, they won't use the RTNAT
binding anyway.

I don't think this is good UI.  Keystrokes are scarce in Emacs.  They
shouldn't be spent on keeping users of different preferences happy,
that's the job of minor modes.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Steinar Bang]

>>>>> "Stephen J. Turnbull" <stephen@xemacs.org>:

> *sigh* That is simply not the point, it has worked forever (I started
> using Emacs in 1979, don't remember if `newline-and-indent' was
> implemented in pre-GNU Emacsen) and I don't expect it to stop working.

Well, actually my message was meant to be that I agree with you.

What I tried to say was "that the functionality already exists, has
existed for a long time, and my fingers know how to find it, so please
don't touch the existing binding of RET!"

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

Steinar Bang <sb@dod.no> writes:

> What I tried to say was "that the functionality already exists, has
> existed for a long time, and my fingers know how to find it, so please
> don't touch the existing binding of RET!"

Seriously, that's a weak argument: changing the binding back is a
one-off operation.

It has been well-established that many existing and most new users
expect RET to perform indentation.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Steinar Bang]

>>>>> Dmitry Gutov <dgutov@yandex.ru>:

> It has been well-established that many existing and most new users
> expect RET to perform indentation.

If they wish to, they can change the keybinding.

It's a one-time operation.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[David Kastrup]

Steinar Bang <sb@dod.no> writes:

>>>>>> Dmitry Gutov <dgutov@yandex.ru>:
>
>> It has been well-established that many existing and most new users
>> expect RET to perform indentation.
>
> If they wish to, they can change the keybinding.
>
> It's a one-time operation.

Ah, but will it be easier for the new users or the old hands to do that
one-time operation?

Actually, that question may be harder to answer than it looks like,
considering that the old hands consider things like customization menus
the spawn of vi and have probably disabled menus so long ago that they
don't even remember their existence any more.

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Dmitry Gutov]

David Kastrup <dak@gnu.org> writes:

> Ah, but will it be easier for the new users or the old hands to do that
> one-time operation?
>
> Actually, that question may be harder to answer than it looks like,
> considering that the old hands consider things like customization menus
> the spawn of vi and have probably disabled menus so long ago that they
> don't even remember their existence any more.

I'm pretty sure the old users are all familiar with `define-key' (among
other functions). Anyone who doesn't is insufficiently old.

The set of old users is limited, and it's bound to decline over time.

The set of new users is essentially unlimited, and we better hope it'll
exceed the amount of the current old users many times over.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stefan Monnier]

> I'm very unlikely to get used to it.  Specifically, in the very
> annoying case where unconventional indentation gets blown away by it
> (TAB won't fix that!)

Of course, in that case you simply want to disable electric-indent-mode.


        Stefan

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > I'm very unlikely to get used to it.  Specifically, in the very
 > > annoying case where unconventional indentation gets blown away by it
 > > (TAB won't fix that!)
 > 
 > Of course, in that case you simply want to disable electric-indent-mode.

Doesn't that turn off *all* the electric characters?  Or are you
saying it's possible to turn of electric indent mode for a particular
line?

Also, the usual electric characters don't usually figure in the
affected lines.  It's only RET that I'd like to be able to use.

Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478.

[Alan Mackenzie]

Hello, Stephen.

On Mon, Mar 24, 2014 at 03:59:09PM +0900, Stephen J. Turnbull wrote:
> Stefan writes:

>  > > In text mode, if the buffer contains
>  > > -----------------------------------------
>  > > foo
>  > >    bar
>  > > -----------------------------------------

>  > > and point is at the start of the second line, and I type RET, it gives

>  > > -----------------------------------------
>  > > foo

>  > > bar
>  > > -----------------------------------------

>  > > This is clearly wrong.

>  > I don't see what is "clear" about it being wrong, sorry.
>  > I see you don't like it (and Richard apparently doesn't like it either),
>  > but that's a different problem.

> It would be nice if you guys would avoid using keystrokes instead of
> commands in this discussion.  I think it's perfectly reasonable to
> swap the usage of CR and LF from `newline' and `newline-and-indent' to
> `newline-and-indent' and `newline', respectively.

That's the consensus that was reached here last autumn, at least for
programming modes.  There was surprisingly little objection, not even
from me.  I think Drew is the only main objector.  For other modes, I
don't think such a consensus was reached at all.

> That may disconcert us oldtimers, but I suspect it's what newcomers to
> Emacs will expect.[1] And it's easy enough to "fix" if you don't like
> it.  But I hope that's not what Alan's talking about, although it's
> entirely unclear to me if that's what Stefan's talking about.

The entire section was a bug report by RMS, as was made clear in my post
before the attribution was removed by an overenthusiasticly cutting
reply, as so often happens in this group.

I think Richard was partly taking the role of a new user, and was partly
bewildered, possibly put out, himself.

> That is, if what Alan means by "type RET" is "type a keystroke bound
> to `newline'", then my preference accords with his.

I don't think that was what Richard (not me) meant - I think he meant
literally and spritiually what he wrote.

> For my usage that behavior is *clearly* *wrong*, as in text modes when
> there's leading whitespace on a line, either *I* put it there, or some
> electrically- crapified command that I just disabled the electricity on
> did (and it won't happen again, so there's no reason not to fix it by
> hand this time).

Yes.  I don't think this electric behaviour should be present in Text
Mode (and similar) either.

-- 
Alan Mackenzie (Nuremberg, Germany).