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: Losing minibuffer input Date: Thu, 20 Nov 2014 16:24:26 -0800 (PST) Message-ID: <52b231e3-f2a2-4d92-91e9-da3c625b1b9f@default> References: <87fvds2r5i.fsf@mail.jurta.org> <87zjbokx0t.fsf@mail.linkov.net> <87zjbll9ao.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 1416529504 28831 80.91.229.3 (21 Nov 2014 00:25:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2014 00:25:04 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 21 01:24:56 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 1Xrc1v-0003h8-7E for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2014 01:24:55 +0100 Original-Received: from localhost ([::1]:37937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrc1u-0001v8-I9 for ged-emacs-devel@m.gmane.org; Thu, 20 Nov 2014 19:24:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrc1i-0001rQ-HZ for emacs-devel@gnu.org; Thu, 20 Nov 2014 19:24:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xrc1Z-0007oi-LB for emacs-devel@gnu.org; Thu, 20 Nov 2014 19:24:42 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:34036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xrc1Z-0007oc-FG for emacs-devel@gnu.org; Thu, 20 Nov 2014 19:24:33 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAL0OVMX023630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Nov 2014 00:24:32 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 sAL0ORqM003297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Nov 2014 00:24:29 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAL0ORMS003292; Fri, 21 Nov 2014 00:24:27 GMT In-Reply-To: <87zjbll9ao.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: 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:177901 Archived-At: > > [FWIW, S-RET is used in at least one 3rd-party library for > > an alternative (to RET) action on the input.] >=20 > There is no conflict since a 3rd-party library can freely override > any default keybinding. Sure, but users sooner or later start to complain about interference with "standard" vanilla bindings, even if it is Emacs itself that has come late to the game. RET in Emacs, especially during completion, is not just like RET in most applications. Like TAB. They both do so much more in Emacs. 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. And this, whether it is vanilla Emacs (now or in the future) or users or a 3rd-party library that binds RET or TAB + modifier keys in minibuffer maps. We should not be jumping at the chance to copy other programs, which do not have such sophisticated (minibuffer, completion etc.) interactions (if they have any such at all), in their simple use of S-RET as a way to simply insert a hard return. That is leveling toward the bottom (most rudimentary) editing behavior instead of reaching toward the top (the rest of Emacs). Especially since in the Emacs (and UNIX and GNU/Linux and ASCII...) world, we **already have a way of inserting a newline char**: just type it (`C-j'). That's what we use for searching, and that is what we should use to insert a newline char in the minibuffer also. Use `C-j' to insert a newline char. Simple. Emacsy. Unixy. This is *already* a useful Emacs idiom. There is no good reason=20 to use up a powerfully mnemonic key like S-RET, to simply insert a newline. Make S-RET, M-RET, C-M-RET, C-S-RET, M-S-RET, C-M-S-RET, if we use them, do things that are Emacs-analogous to things that Emacs does for RET. Similarly, make S-TAB, M-TAB, C-M-TAB, C-S-TAB, M-S-TAB, C-M-S-TAB, if we use them, do things that are Emacs-analogous to things that Emacs does for TAB. It just does not always make sense to copy what is done in other programs that cannot take advantage of all that Emacs has to offer. They have no advantage in fitting in with other, existing Emacs keys, habits, features and ways of use. Too bad for them. You don't need to waste S-RET on inserting a C-j char. So don't bother. I guarantee that you will find better, more minibuffer-oriented things to do with such a key.