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

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

[Ken Manheimer]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

i propose a change to the way line-move-to-column to enable
insensitivity to fields.  without this change, modes that make certain
uses of fields sacrifice column retention in line motion.  i consider
that a bug, and this a bug fix.

in my under-development allout extensions, i'm using field boundaries
to distinguish between an outline item's structural elements (the
guide lines and topic bullet area) and the item's content,
specifically the content on the item's head line:

| | | > here's the content.  the stuff before "here's" is the bullet
and guidelines.

this is working exactly as i need - cursor motion from within the
headline content stops when it first hits the start of the content,
yet will move into the structure area (for hot-spot navigation) with a
subsequent ^A.

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.

my patch introduces a new lisp-level variable,
`line-move-ignore-fields', and a condition in line-move-to-column to
obey that variable.  the default setting of line-move-ignore-fields is
nil, so the current behavior remains.  my allout extension sets it to
get the behavior it needs.

(i made it a lisp-level rather than customization variable because i
expect that it's a modal, not user policy.  i feel the same way about
line-move-ignore-invisible, though, so i'm breaking with that
precedent, and could be persuaded to have the variable i'm introducing
be customizable.)

i would be interested to hear if i missed some better way to achieve
either the cursor motion i want in the headline, without using fields,
or have column retention without adding the field sensitivity
inhibition, as i'm doing.  barring that, i think this is a necessary
bug fix.

the patch is attached, and here's the ChangeLog entry:

2006-08-22  Ken Manheimer  <ken.manheimer@gmail.com>

	* simple.el (line-move-ignore-fields): New lisp-level variable for
	overriding line-move-to-column's sensitivity to fields when doing
	column positioning.
	(line-move-to-column): Respect line-move-ignore-fields.

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

[-- Attachment #2: line-move-patch.txt --]
[-- Type: text/plain, Size: 790 bytes --]

--- simple.el	22 Aug 2006 17:54:52 -0400	1.812
+++ simple.el	31 Aug 2006 11:43:52 -0400	
@@ -3466,6 +3466,9 @@
   :type 'boolean
   :group 'editing-basics)
 
+(defvar line-move-ignore-fields nil
+  "*Non-nil means \\[next-line] and \\[previous-line] ignore fields.")
+
 (defun line-move-invisible-p (pos)
   "Return non-nil if the character after POS is currently invisible."
   (let ((prop
@@ -3702,7 +3705,8 @@
     (let ((opoint (point)))
       (move-to-column col)
       ;; move-to-column doesn't respect field boundaries.
-      (goto-char (constrain-to-field (point) opoint))))
+      (if (not line-move-ignore-fields)
+          (goto-char (constrain-to-field (point) opoint)))))
 
   (when (and line-move-ignore-invisible
 	     (not (bolp)) (line-move-invisible-p (1- (point))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Ken Manheimer]

[-- Attachment #1: Type: text/plain, Size: 3794 bytes --]

dang, my fix is not as simple or straight forwards as i hoped.

line-move-finish duplicates some of the provision for fields.  i don't
understand why, but  it only changes the resulting column
occasionally, but then in the same way as before.  the upshot is that,
without an additional change, the cursor winds up in column 0
occasionally.

my additional change accounts for that without preventing proper
handling of intangible text, which is mixed together with the
inter-line fielded text provision in line-move-finish.  i've tested it
and established that the intangible provision still works regardless,
and the field-insensitivity is complete when line-move-ignore-fields
is t.

i also made line-move-ignore-fields buffer-local, in keeping with the
judgement that this is a provision for modes, not users.

here's the new version of the ChangeLog entry, and the new version of
the patch is attached:

2006-08-22  Ken Manheimer  <ken.manheimer@gmail.com>

	* simple.el (line-move-ignore-fields): New internal variable for
	overriding line-move-finish and line-move-to-column' sensitivity
	to fields when doing column positioning.
	(line-move-finish): Respect line-move-ignore-fields.
	(line-move-to-column): Respect line-move-ignore-fields.

On 8/31/06, Ken Manheimer <ken.manheimer@gmail.com> wrote:
> i propose a change to the way line-move-to-column to enable
> insensitivity to fields.  without this change, modes that make certain
> uses of fields sacrifice column retention in line motion.  i consider
> that a bug, and this a bug fix.
>
> in my under-development allout extensions, i'm using field boundaries
> to distinguish between an outline item's structural elements (the
> guide lines and topic bullet area) and the item's content,
> specifically the content on the item's head line:
>
> | | | > here's the content.  the stuff before "here's" is the bullet
> and guidelines.
>
> this is working exactly as i need - cursor motion from within the
> headline content stops when it first hits the start of the content,
> yet will move into the structure area (for hot-spot navigation) with a
> subsequent ^A.
>
> 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.
>
> my patch introduces a new lisp-level variable,
> `line-move-ignore-fields', and a condition in line-move-to-column to
> obey that variable.  the default setting of line-move-ignore-fields is
> nil, so the current behavior remains.  my allout extension sets it to
> get the behavior it needs.
>
> (i made it a lisp-level rather than customization variable because i
> expect that it's a modal, not user policy.  i feel the same way about
> line-move-ignore-invisible, though, so i'm breaking with that
> precedent, and could be persuaded to have the variable i'm introducing
> be customizable.)
>
> i would be interested to hear if i missed some better way to achieve
> either the cursor motion i want in the headline, without using fields,
> or have column retention without adding the field sensitivity
> inhibition, as i'm doing.  barring that, i think this is a necessary
> bug fix.
>
> the patch is attached, and here's the ChangeLog entry:
>
> 2006-08-22  Ken Manheimer  <ken.manheimer@gmail.com>
>
>         * simple.el (line-move-ignore-fields): New lisp-level variable for
>         overriding line-move-to-column's sensitivity to fields when doing
>         column positioning.
>         (line-move-to-column): Respect line-move-ignore-fields.

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

[-- Attachment #2: line-move-patch.txt --]
[-- Type: text/plain, Size: 1170 bytes --]

--- simple.el	22 Aug 2006 17:54:52 -0400	1.812
+++ simple.el	31 Aug 2006 12:21:47 -0400	
@@ -3466,6 +3466,10 @@
   :type 'boolean
   :group 'editing-basics)
 
+(defvar line-move-ignore-fields nil
+  "*Non-nil means \\[next-line] and \\[previous-line] ignore fields.")
+(make-variable-buffer-local 'line-move-ignore-fields)
+
 (defun line-move-invisible-p (pos)
   "Return non-nil if the character after POS is currently invisible."
   (let ((prop
@@ -3683,7 +3687,8 @@
 	(goto-char opoint)
 	(let ((inhibit-point-motion-hooks nil))
 	  (goto-char
-	   (constrain-to-field new opoint nil t
+	   (constrain-to-field new (if line-move-ignore-fields new opoint)
+			       nil t
 			       'inhibit-line-move-field-capture)))
 
 	;; If all this moved us to a different line,
@@ -3702,7 +3707,8 @@
     (let ((opoint (point)))
       (move-to-column col)
       ;; move-to-column doesn't respect field boundaries.
-      (goto-char (constrain-to-field (point) opoint))))
+      (if (not line-move-ignore-fields)
+          (goto-char (constrain-to-field (point) opoint)))))
 
   (when (and line-move-ignore-invisible
 	     (not (bolp)) (line-move-invisible-p (1- (point))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[David Kastrup]

"Ken Manheimer" <ken.manheimer@gmail.com> writes:

> my patch introduces a new lisp-level variable,
> `line-move-ignore-fields',

How is this different from `inhibit-field-text-motion'?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

    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.

So I wonder: can you identify something about the pattern of use of
the fields which makes this result desirable?  Then
line-move-to-column could detect that usage.

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

[Miles Bader]

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

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

[Ken Manheimer]

On 8/31/06, Richard Stallman <rms@gnu.org> wrote:
>     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.
>
> So I wonder: can you identify something about the pattern of use of
> the fields which makes this result desirable?  Then
> line-move-to-column could detect that usage.

that's a good question.  i don't see a pattern justifiable with some
principle better than what line-move-ignore-fields expresses, however:

i want fields respected when moving within a line - specifically, when
moving from the right of the boundary towards the boundary.  on the
other hand, i want the column retained, whatever the column, when
moving between lines.  (hot-spot navigation, which uses shortcut
versions of outline navigation keys, automatically leaves the cursor
on the bullet, so it's not necessary for next-line/previous-line
navigation to do so.)

(currently, i have everything in the outline-structure side of the
headline, from the left margin to a space to the right of the topic
bullet, being 'field 'boundary.  it works to have them other fields,
except for the right-most one just before the content being 'boundary,
but not as well.  all the headline content, to the right of that, has
no field.  that gets the behavior i described previously, where the
cursor stays within the content on the first ^A, and then moves into
the structure area the next time.  i've tried some other combinations
of field settings, but this works exactly as i want for inter-line
motion, and none of the alternatives which provide the desired in-line
motion have any advantages for cross-line motion, and most are worse.)

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

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

[Ken Manheimer]

On 9/1/06, Miles Bader <miles.bader@necel.com> wrote:
> 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?

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
ken.manheimer@gmail.com
http://myriadicity.net

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

[Richard Stallman]

    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.

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?

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

[Ken Manheimer]

On 9/3/06, Richard Stallman <rms@gnu.org> 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
them.)

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.
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

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

[Richard Stallman]

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

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

[Ken Manheimer]

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

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

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> 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.

Yeah... that's how it's _supposed_ to work ... I guess something broke
it.  I'll look and see if I see something...

As far as Ken's change, maybe it's the right thing for his use, I don't
know (most of the existing field behavior is oriented towards making
the "prompt: input" case like the minibuffer or comint works correctly).
It wouldn't be enabled by default, and it does have the advantage of
being very simple to understand.

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

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

[Richard Stallman]

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

I see.

Since that would definitely be bad for the minibuffer, that could only
be an option.  You'd like to make this an option, but I think that
approach has a serious drawback -- namely, presenting a choice between
two alternatives, each of which is flawed for some cases.

Meanwhile, the current code is broken for the minibuffer too.
We need to fix it.  I am hoping that, once it is fixed right for
the minibuffer, it will be ok for allout as well -- thus eliminating
the need for an ugly option.

    further, allout already offers retention of the cursor on the item
    bullet position when doing hot-spot navigation

I don't know what "hot-spot navigation" means, so you've lost me
completely.

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

[Ken Manheimer]

On 9/6/06, Richard Stallman <rms@gnu.org> wrote:
>     the one i've been suggesting - retention of the column on line-move
>     regardless of fields.
>
> I see.
>
> Since that would definitely be bad for the minibuffer, that could only
> be an option.  You'd like to make this an option, but I think that
> approach has a serious drawback -- namely, presenting a choice between
> two alternatives, each of which is flawed for some cases.
>
> Meanwhile, the current code is broken for the minibuffer too.
> We need to fix it.  I am hoping that, once it is fixed right for
> the minibuffer, it will be ok for allout as well -- thus eliminating
> the need for an ugly option.
>
>     further, allout already offers retention of the cursor on the item
>     bullet position when doing hot-spot navigation
>
> I don't know what "hot-spot navigation" means, so you've lost me
> completely.

i tried to anticipate that with the description in the parenthetic
comment you elided:

< 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

i wasn't sure this was sufficient to convey the gist: when the cursor
is positioned on allout-mode item bullet characters, unqualified
keystrokes are mapped onto the corresponding allout commands, and the
cursor is left positioned on the destination item's bullet character,
for further "hotspot" navigation.  ie, "n" (instead of "\C-<space> n")
advances to the bullet character of the next topic, "f" advances to
the next sibling topic, "h" hides the topic's contents, "i" shows its
offspring, and so on.

this is relevant in that it provides a favorable cursor behavior for
structure navigation.  hence, the bigger problem is the loss of the
current column when traversing in the content portion.  the fix you're
suggesting will reduce that problem.  i don't know whether it will
solve it, however.

i would still be worried that the cursor will annoyingly get pushed
rightwards when moving across content lines, due to traversing
headlines of deep topics, where the structure portion of the line
extends further to the right.  this would be mitigated by preserving
and restoring the displaced leftwards placements, but the behavior i'm
concerned with doesn't obtain for the cases you're considering, so i
doubt it would be provided for.  (i kinda doubt that my description of
the concern is readily understandable, sigh).

the option simplifies this concern.  fielded constraints are employed
where useful, and disregarded where not.  it supports the general
virtues of allout outlines, which have both regular and structured
text qualities, as suits the user's purpose.

i agree that adding the option is ugly from the user perspective, and
that each option is an additional nuance to occupy the programmer's
landscape.  once the programmer knows how it suits their needs,
however, it is not a problem from the perspective of an application
like allout, where the mode sets the option and the user isn't
bothered with it.  maybe the behavior you're suggesting will mitigate
most of my need for it.
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

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

[Richard Stallman]

    i would still be worried that the cursor will annoyingly get pushed
    rightwards when moving across content lines, due to traversing
    headlines of deep topics, where the structure portion of the line
    extends further to the right.

That could certainly happen, but why would it be annoying?
The cursor would come back towards the original column as you move
onward into lines whose structure portion is shorter.

This is like what happens when you start at a high-numbered column
and move through lines that are too short to reach that column.

      this would be mitigated by preserving
    and restoring the displaced leftwards placements,

I don't understand those words.

						      but the behavior i'm
    concerned with doesn't obtain for the cases you're considering, so i
    doubt it would be provided for.

Which cases do you mean by "the cases [I'm] considering"?
I am considering the allout cases you describe.

      (i kinda doubt that my description of
    the concern is readily understandable, sigh).

If the "description of the concern" refers to the words I cited
at the top of this message, I think I understand the behavior,
but I don't understand why you see it as a problem.

    the option simplifies this concern.

That's not enough to make the option _necessary_.
Remember I want to avoid options when possible.
If we can get good enough behavior without one,
then the option isn't needed.

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

[Richard Stallman]

Does allout bind C-SPC with a special meaning?
That would seem to be very painful, since C-SPC is the normal
way to set the mark.

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

[Ken Manheimer]

On 9/7/06, Richard Stallman <rms@gnu.org> wrote:
> Does allout bind C-SPC with a special meaning?
> That would seem to be very painful, since C-SPC is the normal
> way to set the mark.

my mistake!  it's "C-c <space> <char>", not "C-<space>"!

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

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

[Ken Manheimer]

On 9/7/06, Richard Stallman <rms@gnu.org> wrote:
>     i would still be worried that the cursor will annoyingly get pushed
>     rightwards when moving across content lines, due to traversing
>     headlines of deep topics, where the structure portion of the line
>     extends further to the right.
>
> That could certainly happen, but why would it be annoying?
> The cursor would come back towards the original column as you move
> onward into lines whose structure portion is shorter.

that would be good - it's actually the behavior i was hoping but
wasn't expecting would be the case.  that would satisfy me.

> This is like what happens when you start at a high-numbered column
> and move through lines that are too short to reach that column.
>
>       this would be mitigated by preserving
>     and restoring the displaced leftwards placements,
>
> I don't understand those words.

i was trying to describe the cursor coming back to the high-numbered
column, exactly as you mentioned above.

>                                                       but the behavior i'm
>     concerned with doesn't obtain for the cases you're considering, so i
>     doubt it would be provided for.
>
> Which cases do you mean by "the cases [I'm] considering"?
> I am considering the allout cases you describe.

the high-column.

>       (i kinda doubt that my description of
>     the concern is readily understandable, sigh).

which it wasn't - sorry.  :-)

> If the "description of the concern" refers to the words I cited
> at the top of this message, I think I understand the behavior,
> but I don't understand why you see it as a problem.
>
>     the option simplifies this concern.
>
> That's not enough to make the option _necessary_.
> Remember I want to avoid options when possible.
> If we can get good enough behavior without one,
> then the option isn't needed.

i think what you're proposing will work for allout mode.
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

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

[Ken Manheimer]

[-- Attachment #1.1: Type: text/plain, Size: 2888 bytes --]

i'm still having serious problems with the behavior of line motion vis a vis
field boundaries, as of today's CVS.  i've created a script that
demonstrates the behavior problems and describes as clearly as i can the
behaviors i would like.

it may be that those behaviors are not generally suitable, in which case
the line-move-ignore-fields variable i was initially proposing would
be a workable (but
a lot less desirable) compromise.

i don't think the behaviors i'm seeking are suited uniquely to my outliner
situation, but i'm not sure about that one way or the other.  i'm hoping
that this explicit example will provide a clear template which would help to
verify the solution.

ken

On 9/7/06, Ken Manheimer <ken.manheimer@gmail.com> wrote:
>
> On 9/7/06, Richard Stallman <rms@gnu.org> wrote:
> >     i would still be worried that the cursor will annoyingly get pushed
> >     rightwards when moving across content lines, due to traversing
> >     headlines of deep topics, where the structure portion of the line
> >     extends further to the right.
> >
> > That could certainly happen, but why would it be annoying?
> > The cursor would come back towards the original column as you move
> > onward into lines whose structure portion is shorter.
>
> that would be good - it's actually the behavior i was hoping but
> wasn't expecting would be the case.  that would satisfy me.
>
> > This is like what happens when you start at a high-numbered column
> > and move through lines that are too short to reach that column.
> >
> >       this would be mitigated by preserving
> >     and restoring the displaced leftwards placements,
> >
> > I don't understand those words.
>
> i was trying to describe the cursor coming back to the high-numbered
> column, exactly as you mentioned above.
>
> >                                                       but the behavior
> i'm
> >     concerned with doesn't obtain for the cases you're considering, so i
> >     doubt it would be provided for.
> >
> > Which cases do you mean by "the cases [I'm] considering"?
> > I am considering the allout cases you describe.
>
> the high-column.
>
> >       (i kinda doubt that my description of
> >     the concern is readily understandable, sigh).
>
> which it wasn't - sorry.  :-)
>
> > If the "description of the concern" refers to the words I cited
> > at the top of this message, I think I understand the behavior,
> > but I don't understand why you see it as a problem.
> >
> >     the option simplifies this concern.
> >
> > That's not enough to make the option _necessary_.
> > Remember I want to avoid options when possible.
> > If we can get good enough behavior without one,
> > then the option isn't needed.
>
> i think what you're proposing will work for allout mode.
> --
> ken
> ken.manheimer@gmail.com
> http://myriadicity.net
>



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

[-- Attachment #1.2: Type: text/html, Size: 4343 bytes --]

[-- Attachment #2: linefield-example.el --]
[-- Type: application/octet-stream, Size: 2962 bytes --]

;; Eval or load this script and execute the `linefield-example' command
;; for demonstration of the field boundary misbehaviors in an emacs 22 cvs
;; checkout as of mid-day, September 23, 2006, and description of the
;; behaviors i would like to see.

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

(defvar linefield-text
  "The lines with a '|' bar as their first non-whitespace
character are decorated with 'field 'boundary and 'face
'highlight text properties from the left margin until and
including the bar.

 |   
  | 1. With the cursor adjacent to the right of any bar,
   |   if you move forwards a line (^N), the cursor slips to column 0.
    | 2. Moving backwards (^P) with the cursor in the same place, however,
     |   doesn't have this problem - it sticks near the boundary.
    | 3. Moving forwards or backwards with the cursor to the right of the
   |     boundary *not* adjacent does regular sticky-column behavior.
  | 4. Forwards with the cursor on or to the bar's left leaves it in column 0.
 | 5. Backwards in the same situation moves it to the right of the bar.
6. ^A from anywhere beyond the immediate right of the boundary moves to
   the immediate right, and subsequently advances to the far left.

#2, #3, and #6 are near what i want.  the rest are not.

#2 is actually inconsistent - sometimes the cursor is kept
adjacent to the boundary, sometimes (if right-hand part is only
whitespace, like the very first decorated line, and then it
depends on how you started!) there's a column left in between.
the inconsistencies here make me worried that the behaviors are
not converging to something regular.

#1 should work like #2, instead of slipping to column 0.  i doubt
what's happening now is the intended behavior.

#5 treats stuff to the left of the boundary as forbidden, always
promoting the cursor to the right, which is not what i want.
instead, motion to the left of the boundary line should be the
mirror image of #2 and #3 behaviors, on the left instead of the
right.

#4 is broken like #1.

it may be that there's a different way to paint the properties
that gets the behaviors i want - but #6 is important, it's the
reason i'm mucking with the field stuff in the first place.  the
behavior in #2 would be good, if it were consistently there,
forward and backwards, and symmetric across the boundary.
"

  "Text for demonstrating linefield staircase.")

(defun linefield-example ()
  "Demonstrate fieldtext boundary misbehavior."
  (interactive)
  (let* ((buffer (get-buffer-create "fieldtext-example"))
         first second)
    (pop-to-buffer buffer)
    (erase-buffer)
    (insert linefield-text)
    (goto-char (point-min))
    (while (re-search-forward "^ +|" nil t)
      (cond ((not first) (setq first (point)))
            ((not second) (setq second (point))))
      (set-text-properties (match-beginning 0) (point)
                           '(field boundary face highlight)))
    (goto-char second)))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

      | 1. With the cursor adjacent to the right of any bar,
       |   if you move forwards a line (^N), the cursor slips to column 0.
	| 2. Moving backwards (^P) with the cursor in the same place, however,
	 |   doesn't have this problem - it sticks near the boundary.

#1 is clearly a bug.  C-n should be symmetrical with C-p.

	| 3. Moving forwards or backwards with the cursor to the right of the
       |     boundary *not* adjacent does regular sticky-column behavior.

That is correct.

      | 4. Forwards with the cursor on or to the bar's left leaves it in column 0.

That is a bug.  It should be sticky except staying to the left of the bar.

     | 5. Backwards in the same situation moves it to the right of the bar.

That is correct behavior.

    6. ^A from anywhere beyond the immediate right of the boundary moves to
       the immediate right, and subsequently advances to the far left.

That is correct behavior.

So it looks like C-p works but C-n doesn't.

Yidong, would you like to fix this, then ack?

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

[Ken Manheimer]

we agree on every behavior except for one, and that disagreement may
be due to a misunderstanding.

On 9/24/06, Richard Stallman <rms@gnu.org> wrote:
>       | 1. With the cursor adjacent to the right of any bar,
>        |   if you move forwards a line (^N), the cursor slips to column 0.
>         | 2. Moving backwards (^P) with the cursor in the same place, however,
>          |   doesn't have this problem - it sticks near the boundary.
>
> #1 is clearly a bug.  C-n should be symmetrical with C-p.
>
>         | 3. Moving forwards or backwards with the cursor to the right of the
>        |     boundary *not* adjacent does regular sticky-column behavior.
>
> That is correct.
>
>       | 4. Forwards with the cursor on or to the bar's left leaves it in column 0.
>
> That is a bug.  It should be sticky except staying to the left of the bar.
>
>      | 5. Backwards in the same situation moves it to the right of the bar.
>
> That is correct behavior.

that is not the behavior i need, and don't see why it is desirable -
particularly since it's the opposite of the behavior you agreed to
when advancing - ie, #4, just above.

by #5, i am saying that when the cursor is between the left margin and
the bar (so the cursor is within the characters with the 'field
'boundary text property), moving back a line moves the cursor to the
*right* side of the bar, outside of the 'field 'boundary characters.
i don't want the system moving the cursor out of the field type i
started from.  you agreed that it shouldn't do so when moving forwards
(#4), do you really mean that it should do so when moving backwards?

>     6. ^A from anywhere beyond the immediate right of the boundary moves to
>        the immediate right, and subsequently advances to the far left.
>
> That is correct behavior.
>
> So it looks like C-p works but C-n doesn't.

C-p mostly works, except for #5.  it may be that #5 is deliberate and
suitable for some situations, but it's "helping" me in a way that's
counterproductive for my purposes.

> Yidong, would you like to fix this, then ack?

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

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

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> | 1. With the cursor adjacent to the right of any bar,
>  |   if you move forwards a line (^N), the cursor slips to column 0.
>   | 2. Moving backwards (^P) with the cursor in the same place, however,
>    |   doesn't have this problem - it sticks near the boundary.
>
> #1 is clearly a bug.  C-n should be symmetrical with C-p.

I don't see where else the cursor can possibly go in #1.  The logic of
line-move is like this: "Try to naively move the cursor vertically
down.  If this moves us into a new field, go instead to the beginning
of the field (if going forward) or the end of the field (if going
backward)."

In #1, the "naive" motion moves the cursor into a new field, so it
shouldn't move to the old column; instead, it moves into the beginning
of the field.

The C-p behavior is also correct.  The situation actually is
symmetric, but subtle.  When the cursor moves backwards, and finds
itself in a new field, it moves to the *end* of that field.  When the
field boundaries are arranged as

   |
  |
 |

the logical behavior implies that the cursor should stick near the
boundary.  Spontaneous symmetry breaking!

> | 4. Forwards with the cursor on or to the bar's left leaves it in column 0.
>
> That is a bug.  It should be sticky except staying to the left of the bar.

Same here---the cursor is moving into a new field.

I have checked in a fix to improve column motion in certain other
situations.

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

[Chong Yidong]

By the way, the `linefield-example' command you provided assigns a
field with a `boundary' value.  Such fields are treated specially; see
the docstring of `constrain-to-field'.  Is this deliberate?

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

[Ken Manheimer]

On 9/24/06, Chong Yidong <cyd@stupidchicken.com> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
> > | 1. With the cursor adjacent to the right of any bar,
> >  |   if you move forwards a line (^N), the cursor slips to column 0.
> >   | 2. Moving backwards (^P) with the cursor in the same place, however,
> >    |   doesn't have this problem - it sticks near the boundary.
> >
> > #1 is clearly a bug.  C-n should be symmetrical with C-p.
>
> I don't see where else the cursor can possibly go in #1.  The logic of
> line-move is like this: "Try to naively move the cursor vertically
> down.  If this moves us into a new field, go instead to the beginning
> of the field (if going forward) or the end of the field (if going
> backward)."

this definitely warrants documentation.  currently line-move has no
docstring.  i don't remember whether i've seen anything as simple
salient as this description in the elisp info, and the connection to
the info for constrain-to-field is obscure, at best, and this is not
really covered there, as well.  (there's a misspelling there - search
in lispref/text.texti for "argumemt", should be "argument".)

> In #1, the "naive" motion moves the cursor into a new field, so it
> shouldn't move to the old column; instead, it moves into the beginning
> of the field.
>
> The C-p behavior is also correct.  The situation actually is
> symmetric, but subtle.  When the cursor moves backwards, and finds
> itself in a new field, it moves to the *end* of that field.  When the
> field boundaries are arranged as
>
>    |
>   |
>  |
>
> the logical behavior implies that the cursor should stick near the
> boundary.  Spontaneous symmetry breaking!
>
> > | 4. Forwards with the cursor on or to the bar's left leaves it in column 0.
> >
> > That is a bug.  It should be sticky except staying to the left of the bar.
>
> Same here---the cursor is moving into a new field.
>
> I have checked in a fix to improve column motion in certain other
> situations.

i think i'm in a bind.

fields are suitable for the ^A behavior - when starting in the content
portion of an item's header line, i want  ^A to take the cursor to the
beginning of the content portion.  seems like fields give me exactly
that.  (i see now that it need not be the field 'boundary, but that's
another story.)

when moving between lines, i often see the screen split into two
irregularly-bounded portions - the structure part on the left and the
content part on the right.  (this presumes all the items have their
bodies collapsed, a common situation.)  i would like for line motion
within each portion to have regular column stickiness, except that i'd
like for the cursor to go to the same kind of portion (content or
structure) of the next line as the portion it came from, if possible.
this is evidently not what fields are designed to do.  ?

if that's so, then the line-motion-ignore-fields, which i originally
proposed, is what i need.  i'd prefer the column stickiness within
structure/content segregation, but lacking that the regular field
model (moving to the end or the beginning of the new field, depending
on direction) is not at all suitable - as bad or worse than jumping to
the beginning or end of line, depending on direction.

is this making sense?

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

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

[Ken Manheimer]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On 9/24/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> By the way, the `linefield-example' command you provided assigns a
> field with a `boundary' value.  Such fields are treated specially; see
> the docstring of `constrain-to-field'.  Is this deliberate?

it had to do with the special treatment that widget-field-at provides
for fields named 'boundary.  however, i think i no longer need that
provision, so can use any field name.

i see different behavior when i use an arbitrarily named field in my
example.  it's closer to what i need, as long as i don't put the
cursor near the border between the fields or in the structure side,
but there are still some problematic behaviors.  i'm attaching a new
version of the script which describes exactly what's going on.

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

[-- Attachment #2: linefield-example.el --]
[-- Type: application/octet-stream, Size: 2341 bytes --]

;; Eval or load this script and execute the `linefield-example' command
;; for demonstration of the field boundary misbehaviors in an emacs 22 cvs
;; checkout as of mid-day, September 23, 2006, and description of the
;; behaviors i would like to see.

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

(defvar linefield-text
  "The lines with a '|' bar as their first non-whitespace
character are decorated with 'field 'boundary and 'face
'highlight text properties from the left margin until and
including the bar.

 |   
  | 1. With the cursor adjacent to the right of any bar, if you move forwards
   |   a line (^N), the cursor slips to column 0 the first time and then gets
    |  pushed over by the bars, but doesn't stick to them when they recede.
    | 2. Moving backwards (^P) with the cursor in the same place, however, it
     |   just acts column sticky, regardless of fields.
    | 3. Moving forwards or backwards with the cursor to the right of the
   |     bar and *not* adjacent, it does regular sticky-column behavior.
  | 4. Forwards with the cursor on or to the bar's left moves it to the bar.
 | 5. Backwards in the same situation stays column sticky.
6. Starting with the cursor on the number six and going backwards makes the
   cursor alternate between the bar and column 0.

7. ^A from anywhere beyond the immediate right of the boundary moves to
   the immediate right, and subsequently advances to the far left.

#1 and #6 are not ok, because of visiting column 0.

i would prefer to have right-of-the-bar/left-of-the-bar stickiness in both
directions, but can live without that.  but #1's first jump to column 0 and
then sticking to the bar is not good.
"

  "Text for demonstrating linefield staircase.")

(defun linefield-example ()
  "Demonstrate fieldtext boundary misbehavior."
  (interactive)
  (let* ((buffer (get-buffer-create "fieldtext-example"))
         first second
         (i 0))
    (pop-to-buffer buffer)
    (erase-buffer)
    (insert linefield-text)
    (goto-char (point-min))
    (while (re-search-forward "^ +|" nil t)
      (cond ((not first) (setq first (point)))
            ((not second) (setq second (point))))
      (setq i (1+ i))
      (set-text-properties (match-beginning 0) (point)
                           '(field structure face highlight)))
    (goto-char second)))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Slawomir Nowaczyk]

On Sun, 24 Sep 2006 18:04:55 -0400
Chong Yidong <cyd@stupidchicken.com> wrote:

#> > #1 is clearly a bug.  C-n should be symmetrical with C-p.
#> 
#> I don't see where else the cursor can possibly go in #1. The logic of
#> line-move is like this: "Try to naively move the cursor vertically
#> down. If this moves us into a new field, go instead to the beginning
#> of the field (if going forward) or the end of the field (if going
#> backward)."

Is it? Just curious, what's the rationale for that? I know almost
nothing about fields, but to me, the logical behaviour would be
something like "... go instead to the *nearest* end of this field, i.e.
either to the beginning or to the end (both when going forward and when
going backward)"

This would at least make C-n and C-p symmetric.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

To a man standing on the sun, everything looks like a conic section.

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

[Richard Stallman]

    >      | 5. Backwards in the same situation moves it to the right of the bar.
    >
    > That is correct behavior.

    that is not the behavior i need, and don't see why it is desirable -
    particularly since it's the opposite of the behavior you agreed to
    when advancing - ie, #4, just above.

Sorry, I misread it before.  You are right: when point starts in the
field, it should move up into the previous line's field.

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

[Richard Stallman]

    > | 1. With the cursor adjacent to the right of any bar,
    >  |   if you move forwards a line (^N), the cursor slips to column 0.
    >   | 2. Moving backwards (^P) with the cursor in the same place, however,
    >    |   doesn't have this problem - it sticks near the boundary.
    >
    > #1 is clearly a bug.  C-n should be symmetrical with C-p.

    I don't see where else the cursor can possibly go in #1.

It can go to after the bar.  That's where it should go.

      The logic of
    line-move is like this: "Try to naively move the cursor vertically
    down.  If this moves us into a new field, go instead to the beginning
    of the field (if going forward) or the end of the field (if going
    backward)."

I'm saying we need to change that logic, so that the results
will be good.

I think we need a concept of temporary goal fields to go with the
temporary goal column.  When you type the first line-move command
it should record some info about the field you're in when you start.
Then if a field with the same property appears on the line you move to,
it should be handled as if it were -- in some sense -- "the same".

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

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > | 1. With the cursor adjacent to the right of any bar,
>     >  |   if you move forwards a line (^N), the cursor slips to column 0.
>     >   | 2. Moving backwards (^P) with the cursor in the same place, however,
>     >    |   doesn't have this problem - it sticks near the boundary.
>     >
>     > #1 is clearly a bug.  C-n should be symmetrical with C-p.
>
>     I don't see where else the cursor can possibly go in #1.
>
> It can go to after the bar.  That's where it should go.

This logic is wrong.  Consider the case where there is a field' in the
region denoted XXXXXX; everywhere else, the `field' property is null.
Point is initially located at the position indicated by `|'.

  |
XXXXXXXXX

Clearly, pressing C-n should move point to the start of the field.
The trouble is that the example given by Ken is a particular case
where it *looks* as though the behavior you describe makes sense; but
in the more general case, it is wrong.

>       The logic of
>     line-move is like this: "Try to naively move the cursor vertically
>     down.  If this moves us into a new field, go instead to the beginning
>     of the field (if going forward) or the end of the field (if going
>     backward)."
>
> I'm saying we need to change that logic, so that the results
> will be good.
>
> I think we need a concept of temporary goal fields to go with the
> temporary goal column.  When you type the first line-move command
> it should record some info about the field you're in when you start.
> Then if a field with the same property appears on the line you move to,
> it should be handled as if it were -- in some sense -- "the same".

This is a feature, not a bug.

But if this behavior (i.e., treating non-contiguous fields as
identical for the purpose of line-motion) is really the behavior you
want, and we agree that it will close this bug, I can implement this
even more simply than that, by comparing `field' properties at the
relevant places inside line-move-finish.

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

[Ken Manheimer]

On 9/25/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> >     > | 1. With the cursor adjacent to the right of any bar,
> >     >  |   if you move forwards a line (^N), the cursor slips to column 0.
> >     >   | 2. Moving backwards (^P) with the cursor in the same place, however,
> >     >    |   doesn't have this problem - it sticks near the boundary.
> >     >
> >     > #1 is clearly a bug.  C-n should be symmetrical with C-p.
> >
> >     I don't see where else the cursor can possibly go in #1.
> >
> > It can go to after the bar.  That's where it should go.
>
> This logic is wrong.  Consider the case where there is a field' in the
> region denoted XXXXXX; everywhere else, the `field' property is null.
> Point is initially located at the position indicated by `|'.
>
>   |
> XXXXXXXXX
>
> Clearly, pressing C-n should move point to the start of the field.
> The trouble is that the example given by Ken is a particular case
> where it *looks* as though the behavior you describe makes sense; but
> in the more general case, it is wrong.

the difference here is that, in my model for #1, above, the "|" cursor
is starting from within a field marked XXXXXX.  if you implement what
you describe below, column-sticky would be provided, as i wish.

> >       The logic of
> >     line-move is like this: "Try to naively move the cursor vertically
> >     down.  If this moves us into a new field, go instead to the beginning
> >     of the field (if going forward) or the end of the field (if going
> >     backward)."
> >
> > I'm saying we need to change that logic, so that the results
> > will be good.
> >
> > I think we need a concept of temporary goal fields to go with the
> > temporary goal column.  When you type the first line-move command
> > it should record some info about the field you're in when you start.
> > Then if a field with the same property appears on the line you move to,
> > it should be handled as if it were -- in some sense -- "the same".
>
> This is a feature, not a bug.

in the situation as it's been, i was in a bind.  i wanted to use
fields to get ^A to respect the boundary between the content and
structure parts of the item head lines.  i didn't want to sacrifice
column-stickiness when moving between successive head lines.  as far
as i can see, by calling this a feature, you're suggesting that i
should either give up on the ^A functionality or column-stickiness.

i originally suggested a setting that would stop this misbehavior, and
give me both.  it's not an ideal solution, but it stops line moves
from being disruptive without sacrificing the ^A respect for the
boundary.  richard suggested instead seeking refinements to the
fields/line-move model that would extend it to accomodate my concerns.
 i think the model extension that he suggested (and that you are
accepting, below) does that.  moreover, i think this extension fixes a
deficiency in the model.

to me, the bug or feature question is, is my content/structure
demarcation for ^A a misuse of fields?  if so, then i'm asking for a
new fields feature.  if not (and i think not), then i'm asking for a
fix in the fields model.

> But if this behavior (i.e., treating non-contiguous fields as
> identical for the purpose of line-motion) is really the behavior you
> want, and we agree that it will close this bug, I can implement this
> even more simply than that, by comparing `field' properties at the
> relevant places inside line-move-finish.

thanks - i think this will work well for my purposes.

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

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

[Richard Stallman]

    >     > | 1. With the cursor adjacent to the right of any bar,
    >     >  |   if you move forwards a line (^N), the cursor slips to column 0.
    >
    >     I don't see where else the cursor can possibly go in #1.
    >
    > It can go to after the bar.  That's where it should go.

    This logic is wrong.  Consider the case where there is a field' in the
    region denoted XXXXXX; everywhere else, the `field' property is null.
    Point is initially located at the position indicated by `|'.

      |
    XXXXXXXXX

    Clearly, pressing C-n should move point to the start of the field.

I don't see why that would be right.  Moving to the end of the field
seems just as plausible to me.  But it might depend on the intended
semantics of the field.

    > I think we need a concept of temporary goal fields to go with the
    > temporary goal column.  When you type the first line-move command
    > it should record some info about the field you're in when you start.
    > Then if a field with the same property appears on the line you move to,
    > it should be handled as if it were -- in some sense -- "the same".

    This is a feature, not a bug.

Does C-n do the right thing in the modes that use fields?
If not, then I think this is a bug fix.  If so, maybe this is
a new feature.

    But if this behavior (i.e., treating non-contiguous fields as
    identical for the purpose of line-motion) is really the behavior you
    want, and we agree that it will close this bug, I can implement this
    even more simply than that, by comparing `field' properties at the
    relevant places inside line-move-finish.

Please give it a try.

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

[Chong Yidong]

>     But if this behavior (i.e., treating non-contiguous fields as
>     identical for the purpose of line-motion) is really the behavior you
>     want, and we agree that it will close this bug, I can implement this
>     even more simply than that, by comparing `field' properties at the
>     relevant places inside line-move-finish.
>
> Please give it a try.

OK; I've checked in the change.

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

[Ken Manheimer]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On 9/24/06, Ken Manheimer <ken.manheimer@gmail.com> wrote:

> i see different behavior when i use an arbitrarily named field in my
> example.  it's closer to what i need, as long as i don't put the
> cursor near the border between the fields or in the structure side,
> but there are still some problematic behaviors.  i'm attaching a new
> version of the script which describes exactly what's going on.

i'm still having some problems with the behavior.  when moving
downwards, the cursor jumps to column 1 for one line when it would
wind up shifting to a new field.  it then resumes column-sticky
behavior from the column on which it started, until the next field
change.

the same thing happens when moving upwards, except to the end-of-line
instead of column 1, iff the content side has a field qualifier.  the
example i'm posting can be used to show both situations, by leaving or
removing the comment chars eliding a few of the lines.

i would like to see the behavior richard describes, but would be ok
with plain column-sticky behavior.

i'm sorry i've taken a while to post this, and i'm going to be away
for several days starting tomorrow, so wanted to put this out there.

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

[-- Attachment #2: linefield-example.el --]
[-- Type: application/octet-stream, Size: 1734 bytes --]

;; Eval or load this script and execute the `linefield-example' command
;; for demonstration of the field boundary misbehaviors in an emacs 22 cvs
;; checkout as of mid-day (EST), October 9, 2006.

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

(defvar linefield-text
  "The lines with a '|' bar as their first non-whitespace
character are decorated with 'field 'boundary and 'face
'highlight text properties from the left margin until and
including the bar.

 | I've lost track of what the correct behavior is supposed to be.
  | When the cursor first changes fields while moving downwards,
   | it jumps to the first column.
    | It moves back to its original column for subsequent moves.
   | If the content side has its own field setting
   | (see the commented out code), then the cursor shifts
  |  to the last column when moviing upwards
 | and hitting a field shift.

The jumps to the first or last column seem undesirable to me."

  "Text for demonstrating linefield staircase.")

(defun linefield-example ()
  "Demonstrate fieldtext boundary misbehavior."
  (interactive)
  (let* ((buffer (get-buffer-create "linefield-example"))
         first second
         (inhibit-field-text-motion t))
    (pop-to-buffer buffer)
    (erase-buffer)
    (insert linefield-text)
    (goto-char (point-min))
    (while (re-search-forward "^ +|" nil t)
      (cond ((not first) (setq first (point)))
            ((not second) (setq second (point))))
      (set-text-properties (match-beginning 0) (point)
                           '(field structure face highlight))
;;      (set-text-properties (point) (progn (end-of-line) (point))
;;                           '(field content face bold))
      )
    (goto-char second)))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

    i'm still having some problems with the behavior.  when moving
    downwards, the cursor jumps to column 1 for one line when it would
    wind up shifting to a new field.  it then resumes column-sticky
    behavior from the column on which it started, until the next field
    change.

That sounds like exactly what it is supposed to do.
Could you explain what you see as a problem?

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

[Ken Manheimer]

On 10/11/06, Richard Stallman <rms@gnu.org> wrote:
>     i'm still having some problems with the behavior.  when moving
>     downwards, the cursor jumps to column 1 for one line when it would
>     wind up shifting to a new field.  it then resumes column-sticky
>     behavior from the column on which it started, until the next field
>     change.
>
> That sounds like exactly what it is supposed to do.
> Could you explain what you see as a problem?

darting over to column 1 or the end of line when the line move brings
it into a different field is entirely spurious for my purposes.  just
sticky column, regardless of fields, is much preferable.

it would also be fine to have the cursor stick to the boundary, on the
side of the field that the same as the field it came from, which is
what i thought you were suggesting.

i'm ok with just sticky column behavior, which is what my original
patch did, and having the cursor dart to beginning or end of line and
then recover the sticky column is better than the original behavior
(where it would get stuck to beginning or end of line), so i can live
with it, but it doesn't make sense in this context (ie,  line motion
between outline headlines).
-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

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

[Richard Stallman]

    darting over to column 1 or the end of line when the line move brings
    it into a different field is entirely spurious for my purposes.

Would you please show me a scenario and explain why you think this
behavior is wrong?

    it would also be fine to have the cursor stick to the boundary, on the
    side of the field that the same as the field it came from, which is
    what i thought you were suggesting.

How is that different from the behavior you are describing?
Your description sounds like a description of exactly this.