emacs-devel
[Top][All Lists]
Advanced

[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: Sat, 23 Sep 2006 19:29:49 -0400

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 <address@hidden> wrote:
On 9/7/06, Richard Stallman <address@hidden> 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
address@hidden
http://myriadicity.net



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

Attachment: linefield-example.el
Description: Binary data


reply via email to

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