C-j considered harmful (not really)

C-j considered harmful (not really)

[Per Starbäck]

2009/11/16 Per Starbäck <per@starback.se>:
> 2009/11/16 David De La Harpe Golden <david@harpegolden.net>:

>> So, ^I for TAB, ^H for backspace, ^[ for escape etc.
>
> Sure, but I don't like that to be prerequisite knowledge for using Emacs.

Which brings me to another point. There is at least one such
correspondence that Emacs
users are supposed to know about, that I think is unnecessary, and
that is C-j = LF = \n.
That is used for example in I-search and in arguments to query-replace etc.

I would like some alternative way to enter newline in arguments,
something having to
do with <return> since that's the key actually associated with "new
line" for all
those you don't know their ASCII.

That key should be used in I-search with the same meaning as C-j has
now, and should
be possible to use instead of C-q C-j to enter a newline in minibuffer
input. Maybe
<C-return> could be used for this?

Then this would be an alternative just for people with window systems,
but I think people
who would benefit from this almost always have a window system anyway.

Re: C-j considered harmful (not really)

[Deniz Dogan]

2009/11/16 Per Starbäck <per@starback.se>:
> 2009/11/16 Per Starbäck <per@starback.se>:
>> 2009/11/16 David De La Harpe Golden <david@harpegolden.net>:
>
>>> So, ^I for TAB, ^H for backspace, ^[ for escape etc.
>>
>> Sure, but I don't like that to be prerequisite knowledge for using Emacs.
>
> Which brings me to another point. There is at least one such
> correspondence that Emacs
> users are supposed to know about, that I think is unnecessary, and
> that is C-j = LF = \n.
> That is used for example in I-search and in arguments to query-replace etc.
>
> I would like some alternative way to enter newline in arguments,
> something having to
> do with <return> since that's the key actually associated with "new
> line" for all
> those you don't know their ASCII.
>
> That key should be used in I-search with the same meaning as C-j has
> now, and should
> be possible to use instead of C-q C-j to enter a newline in minibuffer
> input. Maybe
> <C-return> could be used for this?
>
> Then this would be an alternative just for people with window systems,
> but I think people
> who would benefit from this almost always have a window system anyway.
>
>
>

How about M-RET instead? That works in non-windowed Emacs as well and
seems to be unbound by default.

-- 
Deniz Dogan

Re: C-j considered harmful (not really)

[Juri Linkov]

>> That key should be used in I-search with the same meaning as C-j has
>> now, and should
>> be possible to use instead of C-q C-j to enter a newline in minibuffer
>> input. Maybe
>> <C-return> could be used for this?
>
> How about M-RET instead? That works in non-windowed Emacs as well and
> seems to be unbound by default.

In IM clients, S-RET inserts newline, and RET accepts input.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-j considered harmful (not really)

[Xavier Maillard]

   >> That key should be used in I-search with the same meaning as C-j has
   >> now, and should
   >> be possible to use instead of C-q C-j to enter a newline in minibuffer
   >> input. Maybe
   >> <C-return> could be used for this?
   >
   > How about M-RET instead? That works in non-windowed Emacs as well and
   > seems to be unbound by default.

   In IM clients, S-RET inserts newline, and RET accepts input.

Does it work in -nw environment ? Here S-RET is not recognized in
my session (GNU Emacs running in the linux console).

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: C-j considered harmful (not really)

[Juri Linkov]

>    >> That key should be used in I-search with the same meaning as C-j has
>    >> now, and should
>    >> be possible to use instead of C-q C-j to enter a newline in minibuffer
>    >> input. Maybe
>    >> <C-return> could be used for this?
>    >
>    > How about M-RET instead? That works in non-windowed Emacs as well and
>    > seems to be unbound by default.
>
>    In IM clients, S-RET inserts newline, and RET accepts input.
>
> Does it work in -nw environment ? Here S-RET is not recognized in
> my session (GNU Emacs running in the linux console).

I think most users including newbies that are unaware of `C-q C-j'
use Emacs on a window system anyway, so they would benefit from S-RET
that is a standard key to insert newline instead of accepting input
in other programs.

We have the same duality with the S-TAB key.  On a terminal, we provide
an alternative `ESC TAB'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-j considered harmful (not really)

[Per Starbäck]

2009/11/17 Juri Linkov <juri@jurta.org>:
>>> That key should be used in I-search with the same meaning as C-j has
>>> now, and should
>>> be possible to use instead of C-q C-j to enter a newline in minibuffer
>>> input. Maybe
>>> <C-return> could be used for this?

> In IM clients, S-RET inserts newline, and RET accepts input.

Evidently <S-return> is used to insert newlines in lots of programs.
I've just searched
for "shift-return" and "shift-enter" on the web and seen many examples.

After reconsidering this I then suggest just that <S-return> should be
usable as an alternative to C-j.

* nice for those who are used to that from other programs
* easier to remember for most new users
* I realize now I would like it personally as well. I used the
linefeed key a lot back when I used a vt100,
but nowadays I have keyboards without a linefeed key, like most of
them are. I could use C-j but I find
myself typing RET TAB far more often. I think it would be easier to
learn to linefeed-deprived fingers to
sneak in a shift with the RET.
* Since <S-return> isn't always available it should probably not be
used for some new command anyway,
so this is as good a use of it as there is.

Re: C-j considered harmful (not really)

[Deniz Dogan]

2009/11/22 Per Starbäck <per@starback.se>:
> 2009/11/17 Juri Linkov <juri@jurta.org>:
>>>> That key should be used in I-search with the same meaning as C-j has
>>>> now, and should
>>>> be possible to use instead of C-q C-j to enter a newline in minibuffer
>>>> input. Maybe
>>>> <C-return> could be used for this?
>
>> In IM clients, S-RET inserts newline, and RET accepts input.
>
> Evidently <S-return> is used to insert newlines in lots of programs.
> I've just searched
> for "shift-return" and "shift-enter" on the web and seen many examples.
>
> After reconsidering this I then suggest just that <S-return> should be
> usable as an alternative to C-j.
>
> * nice for those who are used to that from other programs
> * easier to remember for most new users
> * I realize now I would like it personally as well. I used the
> linefeed key a lot back when I used a vt100,
> but nowadays I have keyboards without a linefeed key, like most of
> them are. I could use C-j but I find
> myself typing RET TAB far more often. I think it would be easier to
> learn to linefeed-deprived fingers to
> sneak in a shift with the RET.
> * Since <S-return> isn't always available it should probably not be
> used for some new command anyway,
> so this is as good a use of it as there is.
>

I still think we should have an alternative to C-j which works in -nw
as well, which is not the case with S-RET.

-- 
Deniz Dogan

Re: C-j considered harmful (not really)

[Stefan Monnier]

> Evidently <S-return> is used to insert newlines in lots of programs.
> I've just searched for "shift-return" and "shift-enter" on the web and
> seen many examples.

> After reconsidering this I then suggest just that <S-return> should be
> usable as an alternative to C-j.

So you suggest

  (define-key function-key-map [S-return] [?\C-j])

?

I guess I could live with that.  But you'd still need to prefix it with
C-q in minibuffer prompts, wouldn't you?  So we'd need more changes,
e.g. making LF in minibuffer input not exit the minibuffer.  I've never
used an LF key, so I could live with that, but I don't know what other
people think about it.


        Stefan

Re: C-j considered harmful (not really)

[Juri Linkov]

> > Evidently <S-return> is used to insert newlines in lots of programs.
> > I've just searched for "shift-return" and "shift-enter" on the web and
> > seen many examples.
> >
> > After reconsidering this I then suggest just that <S-return> should be
> > usable as an alternative to C-j.
>
> So you suggest
>
>   (define-key function-key-map [S-return] [?\C-j])
>
> ?

I guess the initial suggestion was rather:

  (define-key minibuffer-local-map [S-return] 'newline)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-j considered harmful (not really)

[Per Starbäck]

2009/11/23 Juri Linkov <juri@jurta.org>:
>> > Evidently <S-return> is used to insert newlines in lots of programs.
>> > I've just searched for "shift-return" and "shift-enter" on the web and
>> > seen many examples.
>> >
>> > After reconsidering this I then suggest just that <S-return> should be
>> > usable as an alternative to C-j.
>>
>> So you suggest
>>
>>   (define-key function-key-map [S-return] [?\C-j])
>>
>> ?
>
> I guess the initial suggestion was rather:
>
>  (define-key minibuffer-local-map [S-return] 'newline)

I changed my mind, so my current suggestion is the function-key-map
thing. I realized that
this alternative to a real linefeed key would be useful elsewhere too, for
newline-and-indent and other functions that are "natural" for a linefeed key.
Also I think it makes sense in general to have
keys-that-can't-be-typed-everywhere
be aliases for something that can be typed everywhere instead of doing
their own thing.

> I guess I could live with that.  But you'd still need to prefix it with
> C-q in minibuffer prompts, wouldn't you?  So we'd need more changes,
> e.g. making LF in minibuffer input not exit the minibuffer.  I've never
> used an LF key, so I could live with that, but I don't know what other
> people think about it.

Right. I'd like to see that as another question (regardless of whether
S-return = C-j or not),
that it's unnecessary to have both RET and C-j for
minibuffer-complete-and-exit, so it would
be better to have C-j do newline there. Probably some people are used to using
C-j there? So then I suggest an option for that, with the default
being that C-j does newline,
to make it easier for new users.

I think this would be useful even for very casual new users, at least
with replace-string.
And I think it would be useful for all current users who only use RET
for minibuffer-complete-and-exit
(like myself).

RE: C-j considered harmful (not really)

[Drew Adams]

> Right. I'd like to see that as another question (regardless of whether
> S-return = C-j or not), that it's unnecessary to have both RET and
> C-j for minibuffer-complete-and-exit, so it would be better to have
> C-j do newline there.
>
> Probably some people are used to using C-j there?

Yes, in Icicles, `C-j' is self-inserting in the minibuffer. Likewise `SPC' and
`?'. Why? Because in Icicles it is not rare for completions or input text to
contain such chars.

RE: C-j considered harmful (not really)

[Drew Adams]

> I guess the initial suggestion was rather:
>   (define-key minibuffer-local-map [S-return] 'newline)

1. I hope you won't do that. It's best to reserve modifiers for similar meanings
as the base key they modify, other things being equal. IOW, S-RET, M-RET,
C-M-RET, C-S-RET, etc. should be reserved for things akin to what RET does.

(In Icicles, for instance, S-RET in the minibuffer overrides the REQUIRE-MATCH
arg to completing-read, so it acts like RET + confirmation. Just an example.)


I wasn't going to speak to the general question about `S-RET' as a binding for
newline, but since I've started...

2. I don't like the idea of binding `S-RET' to newline. The argument is
apparently that some users will be used to that and thus expect it. So what?
There are so many more things to learn about Emacs that might not be what
someone is used to. This is truly not a big deal, and it doesn't warrant
sacrificing a good key such as `S-RET'. That key is naturally associated with
RET, which is used often and has specific meanings in different contexts, so
`S-RET' can be used for a variant of what RET does in any given context (see #1
wrt the minibuffer's RET).

`C-j' _IS_ newline. OK, some people don't know that. But most programmers of
UNIX, Linux, C, etc. do know it, and others can surely learn it - no biggee. It
is elegant to use the key to self-insert, the same way it is elegant to use the
key `a' to insert an `a' character.

Just one opinion.

Re: C-j considered harmful (not really)

[Per Starbäck]

> I wasn't going to speak to the general question about `S-RET' as a binding for
> newline, but since I've started...
>
> 2. I don't like the idea of binding `S-RET' to newline. The argument is
> apparently that some users will be used to that and thus expect it. So what?
> There are so many more things to learn about Emacs that might not be what
> someone is used to. This is truly not a big deal, and it doesn't warrant
> sacrificing a good key such as `S-RET'. That key is naturally associated with

In some ways S-RET is *not* a "good key", since it's not available in
all platforms.
I see that as one of the reasons why the proposed binding is so good
as a standard binding.
Since Emacs normally avoids using keys not available everywhere for
important stuff, nothing
much is really sacrificed. It is only a win (even though maybe it's
not big a win).
(And of course a library like icicles could change that for those who
want that.)

> RET, which is used often and has specific meanings in different contexts, so
> `S-RET' can be used for a variant of what RET does in any given context (see #1
> wrt the minibuffer's RET).

> `C-j' _IS_ newline. OK, some people don't know that. But most programmers of
> UNIX, Linux, C, etc. do know it, and others can surely learn it - no biggee. It

(Well, C-j is linefeed, and linefeed is newline in Unix, and thus in
GNU, and thus in Emacs
buffers.) I agree that's it's not a biggie and that others *can* learn
it. But I prefer
if they don't have to, since they have lots of other stuff to learn as
well. Every good step
is a good step, even the small ones.

> is elegant to use the key to self-insert, the same way it is elegant to use the
> key `a' to insert an `a' character.

Absolutely. Even though the non-paren part of my subject line might
indicate otherwise I only
want an alternative. (And I would like C-j to self-insert in minibuffers.)

Re: C-j considered harmful (not really)

[Juri Linkov]

> 2. I don't like the idea of binding `S-RET' to newline. The argument is
> apparently that some users will be used to that and thus expect it. So what?
> There are so many more things to learn about Emacs that might not be what
> someone is used to. This is truly not a big deal, and it doesn't warrant
> sacrificing a good key such as `S-RET'. That key is naturally associated with
> RET, which is used often and has specific meanings in different contexts, so
> `S-RET' can be used for a variant of what RET does in any given context (see #1
> wrt the minibuffer's RET).
>
> `C-j' _IS_ newline. OK, some people don't know that. But most programmers of
> UNIX, Linux, C, etc. do know it, and others can surely learn it - no biggee. It
> is elegant to use the key to self-insert, the same way it is elegant to use the
> key `a' to insert an `a' character.

Fine, but note that `C-j' already has different non-self-insert-newline
semantics in other modes:

In Emacs-Lisp mode, C-j runs the command newline-and-indent.
In Lisp Interaction mode, C-j runs the command eval-print-last-sexp.
In Editable Wdired mode, C-j runs the command ignore.

BTW, see how users expect `C-q RET' to insert a newline in the minibuffer:
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4956

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: C-j considered harmful (not really)

[Drew Adams]

> > `C-j' _IS_ newline. OK, some people don't know that. But 
> > most programmers of UNIX, Linux, C, etc. do know it, and
> > others can surely learn it - no biggee. It
> > is elegant to use the key to self-insert, the same way it 
> > is elegant to use the key `a' to insert an `a' character.
> 
> Fine, but note that `C-j' already has different 
> non-self-insert-newline semantics in other modes:

I did not say that `C-j' should _always_ be self-inserting.

The same is true for `a' or `A' and so on - such keys are often bound to other
commands in various modes.