[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: Fri, 1 Sep 2006 02:39:15 -0400

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

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

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.


reply via email to

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