From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Default behaviour of RET. Date: Mon, 21 Oct 2013 16:09:56 -0700 (PDT) Message-ID: <7e015aeb-d6da-4085-89bd-57bdfb5bc7a0@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1382397045 12421 80.91.229.3 (21 Oct 2013 23:10:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2013 23:10:45 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at, monnier@iro.umontreal.ca, acm@muc.de, Eli Zaretskii , stephen@xemacs.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 22 01:10:48 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VYOcW-0006w6-Po for ged-emacs-devel@m.gmane.org; Tue, 22 Oct 2013 01:10:45 +0200 Original-Received: from localhost ([::1]:42187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYOcW-0000iK-1n for ged-emacs-devel@m.gmane.org; Mon, 21 Oct 2013 19:10:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYOcH-0000iF-Ff for emacs-devel@gnu.org; Mon, 21 Oct 2013 19:10:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYOc9-0002Hu-KJ for emacs-devel@gnu.org; Mon, 21 Oct 2013 19:10:29 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:31230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYOc1-0002GJ-IU; Mon, 21 Oct 2013 19:10:13 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LNA8wA026508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 23:10:09 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LNA7F9005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 23:10:07 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LNA7l7005908; Mon, 21 Oct 2013 23:10:07 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164444 Archived-At: > >> 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. >=20 > 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. >=20 > 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. >=20 > 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." >=20 > 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. >=20 > It's not the greatest of problems one might find with Emacs, true. >=20 > > 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. >=20 > 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.