bug#17074: 24.4.50; C-j is undefined in Emacs Lisp mode (and RET doesn't indent either)

bug#17074: 24.4.50; C-j is undefined in Emacs Lisp mode (and RET doesn't indent either)

[Drew Adams]

Up until recently, it was bad enough that you, in effect, swapped C-j
and RET behaviors.  Bad enough, meaning that I needed to use different
keys for different Emacs versions, by default.  But at least I could do
that.

In this version, you've gone a step further and eliminated any
newline-and-indent binding by default (AFAICT).

C-j used to do that.  And recently RET had that effect.  Now neither key
does it.  And C-j isn't even bound by default!

Please stop this madness.  Could you please return to the behavior that
Emacs has always had in this regard: C-j to insert a newline and indent,
RET to just insert a newline?

Or if that's too much to ask, could you please revert to what you had
recently, so I can at least get newline-and-indent by hitting RET
instead of C-j?

Yes, I can customize things, once you stop changing things and I figure
out what the right way to customize things is.

FWIW, NEWS is no help in this regard.  You've introduced a regression in
longstanding behavior (you will call it an improvement, no doubt),
apparently without telling users how to simply get back the previous
behavior.  Shame.

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-21 on ODIEONE
Bzr revision: 116829 dancol@dancol.org-20140321121023-5tjxtiws6qa4qyod
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3' 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include' LDFLAGS=-Lc:/Devel/emacs/lib'

bug#17074: 24.4.50; C-j is undefined in Emacs Lisp mode (and RET doesn't indent either)

[Stefan]

Drew,

please get to the point: what is the bug you're reporting?
Your subject says C-j is unbound in elisp-mode, but the body is just
a long rambling about C-j and RET and how the world will soon end
because of all that madness.

The trunk code has had C-j unbound (globally, not just in elisp-mode) for
a few days right when I forked emacs-24 but that's been fixed.  So if
C-j is unbound globally for you, you're probably just using a revision
from that unfortunate period.


        Stefan

bug#17074: 24.4.50; C-j is undefined in Emacs Lisp mode (and RET doesn't indent either)

[Drew Adams]

> The trunk code has had C-j unbound (globally, not just in elisp-mode) for
> a few days right when I forked emacs-24 but that's been fixed.  So if
> C-j is unbound globally for you, you're probably just using a revision
> from that unfortunate period.

You tell me.  Does the time of the build I reported fall during
that (vaguely expressed) "unfortunate period"?  The bug report is
quite specific about the build.  Why beat around the bush?

It's always next to impossible to know whether or not a change
such as C-j being undefined is by design.  There is in general a
lack of proposals followed by discussion, and a lack of help from
NEWS (until very near the end).  We come across a change and try
to guess whether it is intentional.

From my point of view this is a regression.  Glad to hear you
apparently think so too.  But until hearing that, it is not obvious
that this is not some new design brainchild.

bug#17074: 24.4.50; C-j is undefined in Emacs Lisp mode (and RET doesn't indent either)

[Stefan Monnier]

> You tell me.

No, you do, I have better things to do with my time.


        Stefan