all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: rms@gnu.org, emacs-devel@gnu.org
Subject: RE: Minor feature idea
Date: Thu, 22 Jan 2015 14:42:04 -0800 (PST)	[thread overview]
Message-ID: <d5e817a0-9677-4ad6-90de-a5c5739114dd@default> (raw)
In-Reply-To: <<E1YEPwm-0004PK-Aw@fencepost.gnu.org>>

> 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.
> 
> If people think it is a good idea, I will write it if no one else
> does.
> 
> 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.



       reply	other threads:[~2015-01-22 22:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<E1YEPwm-0004PK-Aw@fencepost.gnu.org>
2015-01-22 22:42 ` Drew Adams [this message]
2015-01-22 22:09 Minor feature idea Richard Stallman
2015-01-22 22:56 ` Daniel Colascione
2015-01-22 23:07   ` Drew Adams
2015-01-23  3:43   ` Richard Stallman
2015-01-23  3:49   ` Stefan Monnier
2015-01-23  9:37     ` David Kastrup
2015-01-23 20:17       ` Stefan Monnier
2015-01-23 16:41     ` Karl Fogel
2015-01-23 17:45     ` Wolfgang Jenkner
2015-01-22 23:12 ` Dmitry Gutov
2015-01-23  3:44   ` Richard Stallman
2015-01-23 13:38     ` Andreas Schwab
2015-01-24  1:10       ` Richard Stallman
2015-01-25  6:45         ` Thierry Volpiatto
2015-01-26  3:42           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5e817a0-9677-4ad6-90de-a5c5739114dd@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.