From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 13273@debbugs.gnu.org
Subject: bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements
Date: Tue, 25 Dec 2012 22:32:26 -0800 [thread overview]
Message-ID: <6A3A32185AC5419EB8F0550D57356710@us.oracle.com> (raw)
In-Reply-To:
> > > * `home' - `beginning-of-line'
> > > * `end' - `end-of-line'
> > > * `C-a' - `beginning-of-visual-line'
> > > * `C-e' - `end-of-visual-line'
> >
> > I think it would be better the other way around: leave C-a and C-e
> > move by physical lines, and make Home and End move by visual lines,
> > which I think is consistent with other applications.
>
> OK, go for it, please. Doesn't matter to me either way. I
> was thinking of `home' and `end' as being the stronger, more
> distant movements, based on their names and based on (I guess
> misunderstanding) some of the discussion in emacs-devel. I
> am certainly no expert on what the "standard"/"conventional"
> meanings are.
However, I wonder what most Emacs users would really prefer.
To be clear, I don't use visual line mode, and I have no preference regarding
it.
But I would imagine that:
1. It is more common in visual line mode to want to move incrementally up/down
visual line bols/eols than it is to move incrementatlly up/down logical line
bols/eols.
2. Emacs users, who are used to `C-a' and `C-e', would generally prefer to use
`C-a' and `C-e' for this repeat-movement, rather than `home' and `end'.
If #1 and #2 are true, then which is more important: (a) to preserve the same
bindings as externally, for those who are used to using `home' & `end' for this
or (b) to provide Emacs-traditional keys, `C-a' & `C-e' for this more common
bol/eol movement (visual)?
IOW, I would think that for Emacs users used to `C-a' & `C-e' what I sent in the
patch is preferable, but for users used to other apps what you suggest is
preferable.
Again, it does not really matter to me. Someone else might have stronger
arguments that what I see, and someone else would anyway need to decide. I only
hope that the two functionalities do get installed, so users of visual-line mode
get repeatable bol/eol movements.
---
Outside of visual line mode, I think that `C-a' and `C-e' (and maybe `home' and
`end'?) should also be repeatable, in the same way. (But here there is no
difference between visual and logical bol/eol.)
In my own use I bind the same redefined commands `beginning-of-line' and
`end-of-line' to `C-a' and `C-e' globally. Well, actually I do not redefine
those commands for my use. Instead, I name the repeatable commands I wrote
`beginning-of-line+' and `end-of-line+', and I bind those to `C-a' and `C-e'.
But they are the same definitions that I called `beginning-of-line' and
`end-of-line' in the patch.
However, I am totally unclear about what `move-beginning-of-line' and
`move-end-of-line' are for and how they differ from `beginning-of-line' and
`end-of-line'. What's that all about?
I cannot understand the doc well enough to figure out what the differences are
or why these new commands were added (and why they replace the older commands
only as bindings, instead of just redefining the older commands, IOW, why have
two sets of commands).
My real request is, I guess, that users get repeatable bol/eol movement commands
for both non visual line mode and visual line mode. And preferably the same
keys. For v-m mode there can be two different behaviors - the ones I defined,
for logical and visual line bol/eol. For non v-m mode (globally) there is only
one behavior: logical (= visual).
I would like to see `C-a' & `C-e' kept for non v-m mode, at least. Perhaps I
sent the wrong patch for that, thinking that my redefinition of
`beginning-of-line' and `end-of-line' would be bound to `C-a' and `C-e' globally
(and perhaps also to `home' and `end' globally).
But maybe it is `move-beginning-of-line' & `move-end-of-line', instead, that
should be patched to be repeatable? In any case, the aim was to have `C-a' and
`C-e' be repeatable (globally as well as in v-m mode).
What is the reason for `move-beginning-of-line' & `move-end-of-line' as separate
commands from `beginning-of-line' and `end-of-line', and why did the latter pair
lose the key bindings?
next prev parent reply other threads:[~2012-12-26 6:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-24 22:27 bug#13273: 24.3.50; [PATCH] enhancement request: repeatable `visual-line-mode' line movements Drew Adams
2012-12-25 17:41 ` Eli Zaretskii
2012-12-26 5:59 ` Drew Adams
2012-12-26 6:32 ` Drew Adams [this message]
2012-12-27 10:08 ` Vitalie Spinu
2012-12-27 16:16 ` Drew Adams
2012-12-27 19:13 ` Vitalie Spinu
2012-12-27 19:35 ` Drew Adams
2012-12-28 18:06 ` Vitalie Spinu
2012-12-28 18:51 ` Drew Adams
2012-12-28 19:22 ` Vitalie Spinu
2012-12-28 19:36 ` Eli Zaretskii
2012-12-28 19:55 ` Vitalie Spinu
2012-12-28 20:13 ` Eli Zaretskii
2012-12-28 20:04 ` Drew Adams
2012-12-28 20:33 ` Vitalie Spinu
2012-12-28 21:05 ` Drew Adams
2019-06-27 12:04 ` Lars Ingebrigtsen
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=6A3A32185AC5419EB8F0550D57356710@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=13273@debbugs.gnu.org \
--cc=eliz@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.