From: "Ken Manheimer" <ken.manheimer@gmail.com>
Cc: emacs-devel@gnu.org, miles@gnu.org
Subject: Re: need option so line-move-to-column ignores fields, plus patch
Date: Wed, 6 Sep 2006 12:52:39 -0400 [thread overview]
Message-ID: <2cd46e7f0609060952m54601787x8c91412af7fbf69f@mail.gmail.com> (raw)
In-Reply-To: <E1GKt5y-0005LL-Eo@fencepost.gnu.org>
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
next prev parent reply other threads:[~2006-09-06 16:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-31 15:48 need option so line-move-to-column ignores fields, plus patch Ken Manheimer
2006-08-31 16:25 ` Ken Manheimer
2006-08-31 17:11 ` David Kastrup
2006-08-31 22:57 ` Richard Stallman
2006-09-01 4:17 ` Miles Bader
2006-09-01 6:39 ` Ken Manheimer
2006-09-03 15:17 ` Richard Stallman
2006-09-04 4:43 ` Ken Manheimer
2006-09-04 17:18 ` Richard Stallman
2006-09-04 19:56 ` Ken Manheimer
2006-09-06 8:49 ` Richard Stallman
2006-09-06 16:52 ` Ken Manheimer [this message]
2006-09-07 6:54 ` Richard Stallman
2006-09-07 14:47 ` Ken Manheimer
2006-09-23 23:29 ` Ken Manheimer
2006-09-24 16:28 ` Richard Stallman
2006-09-24 20:17 ` Ken Manheimer
2006-09-25 20:48 ` Richard Stallman
2006-09-24 22:04 ` Chong Yidong
2006-09-24 22:10 ` Chong Yidong
2006-09-25 1:53 ` Ken Manheimer
2006-10-11 4:13 ` Ken Manheimer
2006-10-11 18:50 ` Richard Stallman
2006-10-11 19:19 ` Ken Manheimer
2006-10-12 22:37 ` Richard Stallman
2006-09-25 1:31 ` Ken Manheimer
2006-09-25 8:36 ` Slawomir Nowaczyk
2006-09-25 20:48 ` Richard Stallman
2006-09-25 21:43 ` Chong Yidong
2006-09-27 17:18 ` Ken Manheimer
2006-09-29 16:32 ` Richard Stallman
2006-09-29 18:21 ` Chong Yidong
2006-09-07 6:54 ` Richard Stallman
2006-09-07 14:27 ` Ken Manheimer
2006-09-05 4:48 ` Miles Bader
2006-09-01 6:30 ` Ken Manheimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cd46e7f0609060952m54601787x8c91412af7fbf69f@mail.gmail.com \
--to=ken.manheimer@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).