Re: Default behaviour of RET.

[Josh]

On Wed, Oct 23, 2013 at 5:29 AM, Stefan Monnier
<address@hidden> wrote:
>>>> If the default binding of RET changes, please do make sure that there
>>>> is a simple and easily accessible way of toggling this, to enable
>>>> correct pasting of multi-line text in tty versions of Emacs.
>>> Indeed, very good point.
>>> So we have the following issues if we want to enable electric-indent-mode:
>>> - C-j's default binding becomes useless.
>>> - need for a new tty-paste command.
>> I'm not sure that follows.
>
> I can't see the relation between what you say and what you quoted.

Sorry if I was unclear; I'll try again.  Several[0][1][2][3] people here have
expressed their preference for the continued availability of distinct
newline and newline-and-indent commands.  This distinction is lost
under the current electric-mode implementation, which effectively
merges the two.  This is presumably why you believe that C-j's default
binding of newline-and-indent would become useless, but it seems to me
that a keymap-based electric-mode implementation could remap those
commands such that hitting return (->newline-and-indent) would trigger
reindentation while keeping non-indenting newline functionality available
on C-j (->newline).

Secondly, this discussion was launched by a complaint[4] about
electric-mode's effect on newline's behavior when called
programmatically.  As Alan mentioned[5], there are hundreds of
existing calls to newline and such a change to its behavior would have
ripple effects on and perhaps breakage of an unknown number of those
callers.  In contrast to the present electric-mode implementation, a
keymap-based approach would leave newline's behavior in those
contexts unchanged.

[0] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00552.html
[1] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00685.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00639.html
[3] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00690.html
[4] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00407.html
[5] http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00413.html