[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Manheimer
Subject: Re: need option so line-move-to-column ignores fields, plus patch
Date: Mon, 4 Sep 2006 00:43:16 -0400

On 9/3/06, Richard Stallman <address@hidden> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]