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

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

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