[Top][All Lists]

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

Re: Default behaviour of RET.

From: Davis Herring
Subject: Re: Default behaviour of RET.
Date: Mon, 21 Oct 2013 16:13:47 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110717 Lanikai/3.1.11

> If there's a vote to be made, I have helped hundreds of users (mostly
> MIT students) who wanted RET to do newline-and-indent by default
> in programming modes. It's easy enough to change if it's not the
> default, but I certainly think it's a better default.

The question of RET's default behavior is not independent of the
question of that of C-j.  It is manifestly more useful to expose
different functionality on different keys.  (Even though users can
customize one of them away, the defaults have their usual importance
when you're not at your home machine/account/whatever.)

Is the proposal to make RET and C-j synonymous despite this?  In the
abstract, it would actually make sense to interchange them: then C-j
could just be a self-inserting character.  It would even make sense for
lisp-interaction-mode's current binding: you rarely would want to eval
the preceding sexp and add its value into an enclosing sexp (i.e., where
indentation would make a difference).

For my own use case, which involves a lot of Python, I like having a
non-indenting newline available because it saves having to dedent
manually with DEL (or M-\) when I know I want to return to top-level.
(This detail is of course not important in {} or () languages, where a
trailing ) can be considered or an electric } can dedent for you.)


This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during

reply via email to

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