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

[Miles Bader <miles.bader@necel.com>]

Richard Stallman <rms@gnu.org> writes:
>     the bug is that i can't use text fields this way without sacrificing
>     column retention on line moves, as far as i can tell.
>     line-move-to-column is hard-wired to respect fields when seeking the
>     prior positions column, so that moving the cursor between topics
>     usually leaves the cursor at column 0, which is almost always not what
>     the user wants.
>
> Creating a new variable can enable allout to get what it wants.
> But that is a sort of a cop-out, because users might want the same
> thing in other modes that use fields, sometimes.

I'm not sure Ken's change is correct anyway -- line-move-to-column is
what line-move _usually_ ends up using, right, to preserve the current
column?

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.

When I've noticed the sort of  problem Ken's complaining about in the
past, it's always been due to  the fact that the newline character on a
line is in a field; there is already a sort of mechanism to try and deal with
this (used for instance, by comint), which is to put newline characters
in a special field with the value `boundary'.

Perhaps I misunderstand his problem though.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin