From: "Ken Manheimer" <ken.manheimer@gmail.com>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: need option so line-move-to-column ignores fields, plus patch
Date: Sun, 24 Sep 2006 21:31:05 -0400 [thread overview]
Message-ID: <2cd46e7f0609241831r19a5ff89p220980398ebb7156@mail.gmail.com> (raw)
In-Reply-To: <87zmcokjjs.fsf@stupidchicken.com>
On 9/24/06, Chong Yidong <cyd@stupidchicken.com> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
> > | 1. With the cursor adjacent to the right of any bar,
> > | if you move forwards a line (^N), the cursor slips to column 0.
> > | 2. Moving backwards (^P) with the cursor in the same place, however,
> > | doesn't have this problem - it sticks near the boundary.
> >
> > #1 is clearly a bug. C-n should be symmetrical with C-p.
>
> I don't see where else the cursor can possibly go in #1. The logic of
> line-move is like this: "Try to naively move the cursor vertically
> down. If this moves us into a new field, go instead to the beginning
> of the field (if going forward) or the end of the field (if going
> backward)."
this definitely warrants documentation. currently line-move has no
docstring. i don't remember whether i've seen anything as simple
salient as this description in the elisp info, and the connection to
the info for constrain-to-field is obscure, at best, and this is not
really covered there, as well. (there's a misspelling there - search
in lispref/text.texti for "argumemt", should be "argument".)
> In #1, the "naive" motion moves the cursor into a new field, so it
> shouldn't move to the old column; instead, it moves into the beginning
> of the field.
>
> The C-p behavior is also correct. The situation actually is
> symmetric, but subtle. When the cursor moves backwards, and finds
> itself in a new field, it moves to the *end* of that field. When the
> field boundaries are arranged as
>
> |
> |
> |
>
> the logical behavior implies that the cursor should stick near the
> boundary. Spontaneous symmetry breaking!
>
> > | 4. Forwards with the cursor on or to the bar's left leaves it in column 0.
> >
> > That is a bug. It should be sticky except staying to the left of the bar.
>
> Same here---the cursor is moving into a new field.
>
> I have checked in a fix to improve column motion in certain other
> situations.
i think i'm in a bind.
fields are suitable for the ^A behavior - when starting in the content
portion of an item's header line, i want ^A to take the cursor to the
beginning of the content portion. seems like fields give me exactly
that. (i see now that it need not be the field 'boundary, but that's
another story.)
when moving between lines, i often see the screen split into two
irregularly-bounded portions - the structure part on the left and the
content part on the right. (this presumes all the items have their
bodies collapsed, a common situation.) i would like for line motion
within each portion to have regular column stickiness, except that i'd
like for the cursor to go to the same kind of portion (content or
structure) of the next line as the portion it came from, if possible.
this is evidently not what fields are designed to do. ?
if that's so, then the line-motion-ignore-fields, which i originally
proposed, is what i need. i'd prefer the column stickiness within
structure/content segregation, but lacking that the regular field
model (moving to the end or the beginning of the new field, depending
on direction) is not at all suitable - as bad or worse than jumping to
the beginning or end of line, depending on direction.
is this making sense?
--
ken
ken.manheimer@gmail.com
http://myriadicity.net
next prev parent reply other threads:[~2006-09-25 1:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-31 15:48 need option so line-move-to-column ignores fields, plus patch Ken Manheimer
2006-08-31 16:25 ` Ken Manheimer
2006-08-31 17:11 ` David Kastrup
2006-08-31 22:57 ` Richard Stallman
2006-09-01 4:17 ` Miles Bader
2006-09-01 6:39 ` Ken Manheimer
2006-09-03 15:17 ` Richard Stallman
2006-09-04 4:43 ` Ken Manheimer
2006-09-04 17:18 ` Richard Stallman
2006-09-04 19:56 ` Ken Manheimer
2006-09-06 8:49 ` Richard Stallman
2006-09-06 16:52 ` Ken Manheimer
2006-09-07 6:54 ` Richard Stallman
2006-09-07 14:47 ` Ken Manheimer
2006-09-23 23:29 ` Ken Manheimer
2006-09-24 16:28 ` Richard Stallman
2006-09-24 20:17 ` Ken Manheimer
2006-09-25 20:48 ` Richard Stallman
2006-09-24 22:04 ` Chong Yidong
2006-09-24 22:10 ` Chong Yidong
2006-09-25 1:53 ` Ken Manheimer
2006-10-11 4:13 ` Ken Manheimer
2006-10-11 18:50 ` Richard Stallman
2006-10-11 19:19 ` Ken Manheimer
2006-10-12 22:37 ` Richard Stallman
2006-09-25 1:31 ` Ken Manheimer [this message]
2006-09-25 8:36 ` Slawomir Nowaczyk
2006-09-25 20:48 ` Richard Stallman
2006-09-25 21:43 ` Chong Yidong
2006-09-27 17:18 ` Ken Manheimer
2006-09-29 16:32 ` Richard Stallman
2006-09-29 18:21 ` Chong Yidong
2006-09-07 6:54 ` Richard Stallman
2006-09-07 14:27 ` Ken Manheimer
2006-09-05 4:48 ` Miles Bader
2006-09-01 6:30 ` Ken Manheimer
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cd46e7f0609241831r19a5ff89p220980398ebb7156@mail.gmail.com \
--to=ken.manheimer@gmail.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).