[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Default behaviour of RET.

From: Dmitry Gutov
Subject: Re: Default behaviour of RET.
Date: Thu, 24 Oct 2013 05:53:41 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

Hi Alan,

On 24.10.2013 00:18, Alan Mackenzie wrote:
I really have to wonder when anyone would wish to use RET bound to
newline. Why? Does some popular major mode provide inadequate
indentation function, so that you have to pick whether to indent the
next line automatically or not?

`newline' is the Right Thing to do in non-programming modes like Text
Mode, at least a lot of the time.

For example, it is if you have paragraphs indented like this one, where
     you use auto-fill-mode to calculate a non-null fill prefix to indent
     subsequent lines of the paragraph and RET to start a new paragraph at
     column zero.

Even in programming modes, you might want to start a whole-line comment
at column zero, even where (or especially where) the code is deeply

I see your point.

My personal position is that I'm quite happy with RET doing `newline' and
C-j doing `newline-and-indent', but (despite being a traditionalist) I
wouldn't be that bothered if those bindings were exchanged.  I would be
most unhappy if the `newline' functionality were to be obliterated, even
in restricted circumstances like `electric-indent-mode' being enabled and
\n being in `electric-indent-chars'.

This seems like the best solution to me: either just a change of default bindings, or a new by-default-on minor mode.
And removal of `\n' from `electric-indent-chars' everywhere.

The alternative approach of remapping `C-j' to `newline' when `electric-indent-mode' is on seems less consistent to me, because there's no hard guarantee, AFAICT, that `electric-indent-chars' will include \n in all situations (modes and user configurations).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]