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

[Ken Manheimer]

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
> 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
address@hidden
http://myriadicity.net