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:12:13 -0700 (PDT) Message-ID: <86bc54a4-767f-4930-9b08-8dea6058b4a3@default> References: > <8361sqli02.fsf@gnu.org>> <1730ebf3-db44-498c-b2a9-4d288d83a946@default> <87k3h6xuen.fsf@yandex.ru> <1878e4fa-50f2-4655-a4ff-30d1db708ee8@default> <5D2595BD-AC11-4FB6-B363-31EBE28A0AE0@mit.edu> <5265A71B.6050501@lanl.gov> 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 1382397176 14111 80.91.229.3 (21 Oct 2013 23:12:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2013 23:12:56 +0000 (UTC) Cc: rms@gnu.org, "emacs-devel@gnu.org devel" , monnier@iro.umontreal.ca, Dmitry Gutov , acm@muc.de, Eli Zaretskii To: Davis Herring , chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 22 01:12:58 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 1VYOeg-00084a-7g for ged-emacs-devel@m.gmane.org; Tue, 22 Oct 2013 01:12:58 +0200 Original-Received: from localhost ([::1]:42197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYOef-00027Z-PT for ged-emacs-devel@m.gmane.org; Mon, 21 Oct 2013 19:12:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYOeT-00027A-0b for emacs-devel@gnu.org; Mon, 21 Oct 2013 19:12:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYOeK-000355-F3 for emacs-devel@gnu.org; Mon, 21 Oct 2013 19:12:44 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:31761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYOeB-000337-7o; Mon, 21 Oct 2013 19:12:27 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LNCPBo028347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 23:12:26 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LNCODl020710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 23:12:24 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 r9LNCO4N010315; Mon, 21 Oct 2013 23:12:24 GMT In-Reply-To: <5265A71B.6050501@lanl.gov> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:164447 Archived-At: > 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.) Exactly. And that's the main point Richard was making, IMO. The only other thing he said was that he personally did not think that the default behavior of RET should be changed. The more important point is to keep two behaviors easily accessible. =20 > Is the proposal to make RET and C-j synonymous despite this? That is unclear to me too, but I too got that impression, and that's why I responded. We should keep both behaviors, IMO. > In the abstract, it would actually make sense to interchange them: > then C-j could just be a self-inserting character. FWIW, that works for me. (I already have C-j self-insert elsewhere,=20 including in the minibuffer.) > 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). There too, I'm with you. (In fact, I put *scratch* into Emacs-Lisp mode because I hate having RET evaluate a sexp.) > 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. I too use RET sometimes, but I can't say offhand when it is that I do.