Re: need option so line-move-to-column ignores fields, plus patch

[Ken Manheimer]

On 9/24/06, Chong Yidong <address@hidden> wrote:
> Richard Stallman <address@hidden> 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
address@hidden
http://myriadicity.net