unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: rms@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at,
	monnier@iro.umontreal.ca, acm@muc.de,
	Eli Zaretskii <eliz@gnu.org>,
	stephen@xemacs.org
Subject: RE: Default behaviour of RET.
Date: Mon, 21 Oct 2013 16:09:56 -0700 (PDT)	[thread overview]
Message-ID: <7e015aeb-d6da-4085-89bd-57bdfb5bc7a0@default> (raw)

> >> The question is what would be the sane default.
> >
> > The default Emacs behavior for this is quite sane, and has been so
> > for almost 40 years now.
> 
> It is sane because it is old? That's a bad argument.

That's not the argument.  I gave my opinion that the Emacs behavior
is sane.  And that it has been so for 40 years.  No one said that
_because_ the behavior is old it must be sane.  The behavior is sane,
_and_ it is longstanding behavior, used by thousands for a long time.

But yes, one could make the argument that that longevity provides
_some_ measure of support for an assertion that the behavior is not
insane.  Some measure of support does not mean old-therefore-sane.

> > That it is not the same as the default behavior of this or that
> > other application does not make the Emacs default behavior insane.
> 
> The Emacs default settings are considered outdated by many of its
> users (here's one tiny example:
> https://github.com/technomancy/better-defaults). So discussing
> changes in long-established behaviors can be useful.

Of course it can be useful.  And change is sometimes good.  That
doesn't mean that all change is good.  It doesn't mean that this
particular change would be the right thing to do.

You are making sweeping generalizations that do not help advance
reasons why this change should be made.

Yes, long-established behaviors can always be questioned.  And the
questions and answers _here_ are?  So far, we have as arguments only
that (a) IDEs use RET instead of C-j, and (b) RET is, in some minds,
more convenient than C-j.

Emacs offers both keys/behaviors, which is good (IMHO).  Perhaps your
argument should be that the keys should be reversed?  That would be
a more reasonable request (IMO) than just making RET also do what C-j
does.

> >> You seem to be under impression that Eli is somehow new to using
> >> Emacs.
> >
> > You seem to be fantasizing.  The "foreign vantage point" is an
> > outside view, nothing more.
> 
> Yeah, and who's outside? One of the most prolific Emacs contributors?

No one is outside.  You keep repeating that strawman.  RET does outside
what C-j does inside.  From the point of view outside, RET is the right
key and C-j is the wrong key.  For Emacs, the opposite is the case -
so far.

> > That is the argument, no?  "All the other guys are doing it another
> > way."
> 
> Read it this way: "won't somebody think of the poor new users?"

We all are doing so, no?  It's not like someone is forcing a contorted
key combination here.  C-j is a simple key sequence, as simple as C-f.

Or else it's not.  Either it is convenient, as has apparently been
thought for a long time by many users, or it is not and this is finally
being realized.

And inherently not, not just because someone might have a habit
developed elsewhere - that is a separate argument from the relative
difficulty of typing C-j.

IOW, there are two separate arguments that those proposing to make
RET do what C-j does have advanced:

1. C-j is "much less convenient" to type than RET.
2. RET is what the "poor new users" are used to using.

I've argued against #1 - I'm not convinced that C-j is "much less
convenient".

But especially, I am in favor of keeping _both_ behaviors.  The keys
could be swapped, if people think that is the way to go.

Against #2 I have less to say.  I've argued that if "others are doing
it" is the _only_ argument then that is pretty lame.  If that is it,
then we are essentially back to the discussion about turning on CUA
mode by default: same argument exactly.  I would hope for a better
argument.

> And: "quite often standard behavior emerges for a reason".

Yet another platitude - yap, yap.  (And what/whom are you quoting?)

> > There is nothing new that makes the difference in convenience
> > between `C-j' and `RET' any greater now than it has been at any
> > point in the past.  Exactly the same difference: same mole hill.
> 
> It's not the greatest of problems one might find with Emacs, true.
> 
> > For Emacs, `C-j' has been considered convenient for this behavior
> > for a very long time.  And I, for one, still find it convenient.
> > It doesn't get much more convenient than `C-j'.  Circulez ; il
> > n'y a rien a voir.
> 
> You still haven't answered why you want RET to be bound to
> `newline'.

I like having both keys, for the two different behaviors.  I use both.
I can't tell you just when I use RET, but I do.

I don't really care much which key provides which behavior.  I don't
mind using either - I already use both.

I would put it exactly the way Richard put it: (a) "I don't think the
default behavior of RET should be changed" and (b) "We have two
commands, RET and C-j", with two different behaviors.

For me, (b) is more important: keep the two behaviors.  For (a), I'm
adding my voice to agree that "I don't think the default behavior of
RET should be changed."  That's all.



             reply	other threads:[~2013-10-21 23:09 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 23:09 Drew Adams [this message]
2013-10-22  0:37 ` Default behaviour of RET Dmitry Gutov
     [not found] <<febb6245-ceda-4c33-a220-b0f24a1c34d2@default>
     [not found] ` <<8361sqli02.fsf@gnu.org>
2013-10-21 17:01   ` Drew Adams
2013-10-21 20:04     ` Dmitry Gutov
2013-10-21 20:53       ` Drew Adams
2013-10-21 21:15         ` Dmitry Gutov
2013-10-21 22:03         ` chad
2013-10-21 22:12           ` Daniel Colascione
2013-10-21 23:10             ` Drew Adams
2013-10-22  6:49             ` Lars Brinkhoff
2013-10-23 20:23             ` Alan Mackenzie
2013-10-21 22:13           ` Davis Herring
2013-10-21 23:12             ` Drew Adams
2013-10-21 22:59           ` Jorgen Schaefer
2013-10-22 14:02             ` Stefan Monnier
2013-10-23  0:10               ` Richard Stallman
2013-10-23  4:36               ` Josh
2013-10-23 12:29                 ` Stefan Monnier
2013-10-23 18:15                   ` Josh
2013-10-24 13:35                     ` Stefan Monnier
2013-10-21 23:10           ` Drew Adams
2013-10-22  7:45             ` Jarek Czekalski
2013-10-22 12:03               ` Rustom Mody
2013-10-23 20:18       ` Alan Mackenzie
2013-10-23 23:43         ` Stephen J. Turnbull
2013-10-24  1:53         ` Dmitry Gutov
2013-10-21 22:59     ` Xue Fuqiao
     [not found] <<525EDC50.8010401@gmx.at>
     [not found] ` <<20131016192642.GD3125@acm.acm>
     [not found]   ` <<87mwm8g61e.fsf@uwakimon.sk.tsukuba.ac.jp>
     [not found]     ` <<jwv4n8globm.fsf-monnier+emacs@gnu.org>
     [not found]       ` <<20131018170320.GC2569@acm.acm>
     [not found]         ` <<jwvzjq6pdek.fsf-monnier+emacs@gnu.org>
     [not found]           ` <<20131018204551.GC3012@acm.acm>
     [not found]             ` <<jwvzjq6c9da.fsf-monnier+emacs@gnu.org>
     [not found]               ` <<20131019105836.GA2991@acm.acm>
     [not found]                 ` <<762fa4a6-1a42-48b2-97ba-0f3ab7ef7ba5@default>
     [not found]                   ` <<20131020145513.GC3484@acm.acm>
     [not found]                     ` <<E1VY1SB-0006V5-EH@fencepost.gnu.org>
     [not found]                       ` <<83a9i3l554.fsf@gnu.org>
2013-10-21  3:26                         ` Drew Adams
2013-10-21 12:12                           ` Rustom Mody
2013-10-22  1:25                             ` Richard Stallman
2013-10-23  1:20                               ` Stephen J. Turnbull
2013-10-22 13:53                             ` Kenichi Handa
2013-10-21 16:13                           ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2013-10-13 10:13 electric-indent-mode: abolition of `newline' function is not the Right Thing Alan Mackenzie
2013-10-13 13:23 ` Stefan Monnier
2013-10-13 14:09   ` Alan Mackenzie
2013-10-13 16:22     ` Stefan Monnier
2013-10-13 17:28       ` Alan Mackenzie
2013-10-15 18:28         ` martin rudalics
2013-10-16 17:12           ` Alan Mackenzie
2013-10-16 18:34             ` martin rudalics
2013-10-16 19:26               ` Default behaviour of RET Alan Mackenzie
2013-10-16 19:47                 ` Eli Zaretskii
2013-10-16 23:17                 ` Stephen J. Turnbull
2013-10-17  0:47                   ` Stefan Monnier
2013-10-18 17:03                     ` Alan Mackenzie
2013-10-18 19:52                       ` Stefan Monnier
2013-10-18 20:45                         ` Alan Mackenzie
2013-10-19  1:59                           ` Stefan Monnier
2013-10-19 10:58                             ` Alan Mackenzie
2013-10-19 15:07                               ` Drew Adams
2013-10-20 14:55                                 ` Alan Mackenzie
2013-10-20 22:26                                   ` Richard Stallman
2013-10-21  2:38                                     ` Eli Zaretskii
2013-10-19 22:20                               ` Stefan Monnier
2013-10-20 15:00                                 ` Alan Mackenzie
2013-10-18 16:57                   ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7e015aeb-d6da-4085-89bd-57bdfb5bc7a0@default \
    --to=drew.adams@oracle.com \
    --cc=acm@muc.de \
    --cc=dgutov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    --cc=rudalics@gmx.at \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).