[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: Wed, 6 Sep 2006 12:52:39 -0400

On 9/6/06, Richard Stallman <address@hidden> 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

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.

reply via email to

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