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: Multi-line input Date: Fri, 5 Dec 2014 19:20:09 -0800 (PST) Message-ID: <901a3a0c-f29d-4977-843b-5b303f8a6a3a@default> References: <87fvds2r5i.fsf@mail.jurta.org> <87zjbokx0t.fsf@mail.linkov.net> <546E1845.2010301@dancol.org> <87oarjklgc.fsf_-_@mail.linkov.net> <871todslvt.fsf@mail.linkov.net> 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 1417836059 29924 80.91.229.3 (6 Dec 2014 03:20:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 03:20:59 +0000 (UTC) Cc: Daniel Colascione , emacs-devel@gnu.org To: Juri Linkov , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 06 04:20:52 2014 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 1Xx5vP-0003JM-VB for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 04:20:52 +0100 Original-Received: from localhost ([::1]:53240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xx5vP-00070o-BL for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2014 22:20:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xx5v3-00070d-6x for emacs-devel@gnu.org; Fri, 05 Dec 2014 22:20:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xx5uu-0003Qw-DM for emacs-devel@gnu.org; Fri, 05 Dec 2014 22:20:29 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:32765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xx5uu-0003Qr-6x for emacs-devel@gnu.org; Fri, 05 Dec 2014 22:20:20 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB63KBpq011812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 03:20:12 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB63KAaP017645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 03:20:10 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB63KApU003559; Sat, 6 Dec 2014 03:20:10 GMT In-Reply-To: <871todslvt.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:179081 Archived-At: > The only downside of S-RET is that it's not available on a tty. > But on a graphical display S-RET is a common key to insert a > newline. Nope. As I mentioned in thread "Losing minibuffer input", Emacs should not sacrifice `S-RET' to just inserting a newline char, as some other, lesser programs do. Emacs should reserve `S-RET' for behavior similar to Emacs `RET' behavior. And depending on the context that can mean things like choosing a completion candidate. Like `TAB', `RET' does more in Emacs than it does in other programs. As I said: Modifiers used with RET and TAB should be reserved for actions similar or analogous to what RET and TAB are used for without modifiers (as we have done with M-TAB, for instance). In particular, in the minibuffer they should be reserved for actions similar to what RET and TAB do in the minibuffer. Besides which, Emacs already has a perfectly good, canonical way to insert a newline char: `C-j'. Make `C-j' self-inserting in more keymaps and you will not need to waste `S-RET' for that, nor will you need a `C-q C-j' workaround. You are making things complicated for nothing. > *** `electric-indent-mode' is now enabled by default. > Typing RET reindents the current line and indents the new > line. `C-j' inserts a newline but does not indent. >=20 > But e.g. in *scratch* typing `C-j' evaluates the last expression. > S-RET could help here as well, after agreeing on its universal > meaning of inserting a newline. There is no such "universal meaning". For Emacs use, this is backward. `C-j' in *scratch* should self-insert (newline char). If anything should, it is `S-RET' that should have a special behavior here, such as evaluating. Are you going to be consistent, and swap `C-j' with `S-RET' for specifying a newline char everywhere? Will users who want to search for a newline char now need to use `S-RET' during Isearch? [*] No? So users will sometimes use `C-j' to insert a newline, and sometimes use `S-RET'? So much for "universal" consistency. What would be gained by that, besides a supposed consistency with a few simplistic text-editing contexts? Why not keep Emacs consistent with itself instead - and with UNIX, GNU/Linux,... Let newline (`C-j') be newline - across Emacs, by default. Save `S-RET' for more complex behavior, just as we do (but other, simpler edit contexts do not) for `RET' and `TAB'. [*] Yes, FWIW, I would be in favor of having `C-j' self-insert in Isearch also, instead of needing to use `C-q C-j'. Just as for a character such as `b' or `?', `C-j' would behave the same within search and outside search: it would self-insert. But `C-q C-j' is anyway better than `S-RET' during search - it makes clear that you are, well, inserting a `C-j' (newline) character.