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

["Ken Manheimer" <ken.manheimer@gmail.com>]

On 9/3/06, Richard Stallman <rms@gnu.org> wrote:
>     i want fields respected for motion within a line - specifically, when
>     moving from the right of the boundary towards the boundary - without
>     sacrificing retention of the column when moving between lines.  that's
>     the level of control that line-move-ignore-fields provides.
>
> That is clear enough.
>
> So, can we find specific cases where some other incompatible behavior
> is positively desirable?  It would be useful for people to look
> for the other facilities that use fields, to see what cases there are
> where we would not want this behavior.

i don't expect line-move-ignore-fields to be used everywhere, or even
as the default.  i expect that my desire to have fielded behavior for
within line motion but not when moving across lines is the exception,
not the rule.

> Miles found one:
>
>     The current interaction between line-movement and fields is intentional,
>     so that "column" preservation does not cause, for instance, the cursor
>     to move into the prompt in the minibuffer when you're editing a multline
>     minibuffer entry.
>
> In that case, we don't want point to move vertically upward into the field
> at the start of the line.
>
> However, the current behavior in that case is not good.
> When I use M-: to make a minibuffer, and then enter
>
> This is a test
> of multiple lines
>
> I find that C-p from the second line always puts point right after the
> prompt, regardless of where point was in the second line.
>
> I think the behavior we want in the minibuffer is that point should
> move vertically up _unless_ that would leave it inside the prompt,
> in which case it goes to the end of the prompt.
>
> Ken, would that behavior be good for allout?

the difference in allout is that one headline with structure can
follow another.  i would want motion from the structure (left-hand)
side of a line (corresponding to the minibuffer's prompt), to another
line with structure, to remain in the structure side if the columns
line up.

it's conceivable that motion could be sticky within either side of the
line.  ie, when moving within the structure (guide lines and bullet)
on the left-hand side, the cursor retains its column or sticks at the
right edge, and vice versa when moving between lines in the content
portion of the headlines.   the user then has to deliberately cross
the boundary to reach the other side.

with that policy in effect, moving from a content-only to a
structure+content line would stick to the content area.

(i have no idea how all this would be implemented, or even if it's all
feasible.  fielded text motion seems low level to me, and i don't
understand what all the contingencies are or how it provides for
them.)

offhand, that policy is not what i prefer, however.  i do not see it
necessary to retain the cursor within the structure area or the
content area when moving between lines.  i wouldn't mind it as an
alternative, and ideally both pure cursor-column retention (a la
line-move-ignore-fields) and structure vs content side stickiness
would be possible, with a customization option controlling which
policy obtains.
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net