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

[Ken Manheimer]

On 9/1/06, Miles Bader <address@hidden> wrote:
> Richard Stallman <address@hidden> 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?

i don't understand what you're suggesting in that paragraph.

i can say that i noticed that line-move-finish duplicates the
line-move column positioning according to fields (mixed together with
the provision for line moves into intangibility), and the second
version of  my patch addresses that.

> 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.

so the environment for that sort of editing should leave the default
value for line-move-ignore-fields, to retain the current behavior.
line-move-ignore-fields should be set when you don't want that
behavior.  i don't see how that is incorrect.

> 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'.

none of the newlines in the buffers where i'm having the problem have
any 'field property set.  ie, the following lisp expression:

 (while (and (re-search-forward "\n" nil t) (not (get-char-property
(1- (point)) 'field))))

advances from the beginning to the end of the buffers without stopping.

(out of curiousity, i tried setting the field 'boundary on the
newlines. the column was retained in the left part of the line - ie,
having characters that have the field 'boundary set.  to the right of
that, with characters that lack any 'field setting, the column is not
retained - the cursor moves to the left-most non-fielded character of
the next line, just to the right of the rightmost 'boundary char.
that is in the content part of the line, and distinctly is not
desired.)

> Perhaps I misunderstand his problem though.

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.

i'm open to solutions using only fields as they currently are
implemented, but i haven't found any that avoid sacrificing either the
intra-line or line-motion behavior.

--
ken
address@hidden
http://myriadicity.net