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: Minor feature idea Date: Thu, 22 Jan 2015 14:42:04 -0800 (PST) Message-ID: References: <> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1421966552 313 80.91.229.3 (22 Jan 2015 22:42:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2015 22:42:32 +0000 (UTC) To: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 22 23:42:28 2015 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 1YEQSI-0003X7-Iw for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 23:42:26 +0100 Original-Received: from localhost ([::1]:56365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEQSH-0007TU-PM for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 17:42:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEQS4-0007TP-FP for emacs-devel@gnu.org; Thu, 22 Jan 2015 17:42:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEQRz-0004ru-EO for emacs-devel@gnu.org; Thu, 22 Jan 2015 17:42:12 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:45931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEQRz-0004rl-8C; Thu, 22 Jan 2015 17:42:07 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0MMg55E017458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2015 22:42:06 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0MMg47s001921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 22:42:05 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t0MMg47m009614; Thu, 22 Jan 2015 22:42:04 GMT In-Reply-To: <> 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: 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: 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:181635 Archived-At: > In the minibuffer reading a file name, C-a typed within the last > component could move to the start of that component. The next time, > it could move to the beginning of the line. >=20 > If people think it is a good idea, I will write it if no one else > does. >=20 > Alternatively, C-M-b and C-M-f could move by filename component. > That is cleaner and does more, but those chars are harder to type > and users won't come across it in their editing. It's certainly possible to do such things. 2 cents: 1. The minibuffer is an editing buffer. The usual commands for doing things like this (moving over filename components) should apply there as well. If there is a lack of such features in general then they can be added for the general case, and they would then automatically apply to the minibuffer case as well. 2. It should not be assumed that minibuffer input is a single line. In my use, for example, there are lots of cases where I yank or otherwise retrieve and edit multiple-line text in the minibuffer. Doing this is easier in my context, perhaps (Icicles), but it can and should be just as possible in Emacs. For my use, both in the minibuffer and outside of it, I bind `C-a' and `C-e' to repeatable commands that move to the start and end of the previous or next line. E.g., `C-e' moves to the end of the line, repeating it moves to the end of the next line, etc. This helps for multiple-line editing, IMO. I would prefer that `C-a' and `C-e' remain based on line limits and not try to move to other-thing limits based on the context. If they were to be changed to do that, I would prefer that they at least do so for things that are similar to or analogous to lines. Similar arguments apply to `C-M-b'/`C-M-f'. But there I think you might have a point, in that input that involves filenames is often distinct from input that involves symbols, and even when they are both present (e.g. for Lisp sexp input) it is generally not a problem to use the same keys for both symbols and filename components. To repeat what I said in #1: let's add commands/keys that move forward/backward over filename components, if that is deemed not easy enough currently. Let's not co-opt `C-a'/`C-e' for that. I might not object to `C-M-b'/`C-M-f', but again, why make the behavior different for the minibuffer? IOW, maybe they should handle filename components the same way they handle symbols (?). On the other hand, it can be handy to use these keys to move past a whole file name. [I assume that by "component" you mean whatever is between (unescaped) `/' chars, or something similar. I don't know of a command that does that, but it could be useful. (`forward-same-syntax' comes close, but it requires repetition to get across each `/'.)] Just one opinion, and liable to change.