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: Sun, 9 Nov 2014 10:52:41 -0800 (PST) Message-ID: References: <87fvds2r5i.fsf@mail.jurta.org> 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 1415559208 30837 80.91.229.3 (9 Nov 2014 18:53:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Nov 2014 18:53:28 +0000 (UTC) To: Juri Linkov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 09 19:53:18 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 1XnXby-0003kA-Jc for ged-emacs-devel@m.gmane.org; Sun, 09 Nov 2014 19:53:18 +0100 Original-Received: from localhost ([::1]:39700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnXbx-0005td-VZ for ged-emacs-devel@m.gmane.org; Sun, 09 Nov 2014 13:53:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnXbc-0005qX-3N for emacs-devel@gnu.org; Sun, 09 Nov 2014 13:53:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnXbQ-0001MQ-Du for emacs-devel@gnu.org; Sun, 09 Nov 2014 13:52:56 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:45716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnXbQ-0001MD-7R for emacs-devel@gnu.org; Sun, 09 Nov 2014 13:52:44 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sA9IqeT4026945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Nov 2014 18:52:41 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA9IqeYu023665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Nov 2014 18:52:40 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA9Iqdjn015577; Sun, 9 Nov 2014 18:52:39 GMT In-Reply-To: <87fvds2r5i.fsf@mail.jurta.org> 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: 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:176634 Archived-At: > when editing multi-line text in the minibuffer: it's too easy to lose > edited text by pressing an up-down arrow key with the intention to go > to the next/previous line like in a normal buffer. The changes are > lost because the up-down key has a special meaning in the minibuffer > to go to the next/previous history item. So just don't do that. Use `C-n' & `C-p' to move to a different line. And you can always use `undo' to undo any such boo-boo and get back what (you think) you lost. You can _edit_ text in the minibuffer. In particular, `undo' works fine. But if the vanilla Emacs behavior really bothers you, then customize bindings in your `minibuffer-local-map' - for your own use. Trivial to do. > The fix is simple: It ain't broke; don't fix it. > allow up-down arrow keys to have their usual behavior and only on > hitting the beginning/end of the minibuffer move to the next > or previous history item, thus making navigation more smooth and > continuous. So now users will need to move point to the beginning or end of the minibuffer, just to get `up' and `down' to navigate the history list? No thanks. >(define-key map [down] 'next-line-or-history-element) >(define-key map [up] 'previous-line-or-history-element) >=20 > (defun next-line-or-history-element (&optional arg) > "Move cursor vertically down ARG lines, or to the next history element. > When point is at the bottom line of multi-line minibuffer, puts ARGth > next element of the minibuffer history in the minibuffer." The language here even underlines how much of a mishmash this is. Move _the cursor_ to the next history element? I don't think so. This behavior is not only not handy; it is also confusing.