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

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

On 9/4/06, Richard Stallman <rms@gnu.org> wrote:
>     > 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 am looking for a way to avoid the need for such an option,
> a way to make the command DTRT for everyone without need for
> parameters.  And I think I have found one.
>
> I would like people to help me check whether this solution really works.
>
>       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.
>
> Since the minibuffer has only one prompt, this case cannot occur
> in the minibuffer.  Therefore, if we make C-n and C-p do this,
> the change need not have any effect on the minibuffer.
>
> So far I see no problem with my proposal as modified by your request.
> But what about comint?  It uses fields for the prompts, right?
> Would this behavior be right for comint?
>
>     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.
>
> In that case, what behavior WOULD you prefer?

the one i've been suggesting - retention of the column on line-move
regardless of fields.

there are subtle pluses and minuses to sticking within the
structure/content field areas.  the boundary between the two wavers
with outline depth, so that the cursor may be bumping against it
repeatedly as you traverse lines.  having the cursor column varying
with the boundary could be just right, or it could be distracting and
even annoying.  i just don't know, and would have to try it to find
out.  i do know that just retaining the column works well.

further, allout already offers retention of the cursor on the item
bullet position when doing hot-spot navigation (where allout commands
are available as shortcut keys, without the prefix or
control-qualification, when the cursor is situated on the bullet
character).  that makes structure/content-area segregated line-moves
somewhat redundant.  pure line-move column retention are
complementary, however.  that is why i would like to have the latter
at least as an option.

-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net