From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: need option so line-move-to-column ignores fields, plus patch Date: Wed, 6 Sep 2006 12:52:39 -0400 Message-ID: <2cd46e7f0609060952m54601787x8c91412af7fbf69f@mail.gmail.com> References: <2cd46e7f0608310848l743430e9ia7a1d45e22428083@mail.gmail.com> <2cd46e7f0608312339s16a2a101p8c30840bbdeb0d22@mail.gmail.com> <2cd46e7f0609032143v311b670dra2d2ef679dd936@mail.gmail.com> <2cd46e7f0609041256q73c0c0d3s7631a964ae9a8367@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1157561598 19615 80.91.229.2 (6 Sep 2006 16:53:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Sep 2006 16:53:18 +0000 (UTC) Cc: emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 06 18:53:16 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GL0e0-0008Hc-DZ for ged-emacs-devel@m.gmane.org; Wed, 06 Sep 2006 18:52:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GL0e0-0000nd-2h for ged-emacs-devel@m.gmane.org; Wed, 06 Sep 2006 12:52:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GL0dl-0000gr-Vk for emacs-devel@gnu.org; Wed, 06 Sep 2006 12:52:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GL0dl-0000dg-3G for emacs-devel@gnu.org; Wed, 06 Sep 2006 12:52:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GL0dk-0000d7-V9 for emacs-devel@gnu.org; Wed, 06 Sep 2006 12:52:41 -0400 Original-Received: from [64.233.184.230] (helo=wr-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GL0dw-0005xM-3G for emacs-devel@gnu.org; Wed, 06 Sep 2006 12:52:52 -0400 Original-Received: by wr-out-0506.google.com with SMTP id 71so861639wra for ; Wed, 06 Sep 2006 09:52:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cqGc91UaZM0wqbwOIL9zO8JaAD0VyIZ6JQyrHPfU74B3EtUjCIGPllyVcXDGSaN70mqOeytmaaK97PmubWKrt+9FeX7Nr7/H0flTS5GekQ481t/SLO0NhzDwcATPgTQJrryiwppxPyl7zaSvMe9WFJJi+WNdCfng6fS/WuNG0eM= Original-Received: by 10.90.78.9 with SMTP id a9mr670731agb; Wed, 06 Sep 2006 09:52:39 -0700 (PDT) Original-Received: by 10.90.105.4 with HTTP; Wed, 6 Sep 2006 09:52:39 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59455 Archived-At: On 9/6/06, Richard Stallman 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- 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