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: Mon, 4 Sep 2006 15:56:58 -0400 Message-ID: <2cd46e7f0609041256q73c0c0d3s7631a964ae9a8367@mail.gmail.com> References: <2cd46e7f0608310848l743430e9ia7a1d45e22428083@mail.gmail.com> <2cd46e7f0608312339s16a2a101p8c30840bbdeb0d22@mail.gmail.com> <2cd46e7f0609032143v311b670dra2d2ef679dd936@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 1157399848 7275 80.91.229.2 (4 Sep 2006 19:57:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 4 Sep 2006 19:57:28 +0000 (UTC) Cc: emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 04 21:57:26 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 1GKKZN-0006tP-4C for ged-emacs-devel@m.gmane.org; Mon, 04 Sep 2006 21:57:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKKZM-0004YS-Nx for ged-emacs-devel@m.gmane.org; Mon, 04 Sep 2006 15:57:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GKKZ7-0004Vw-CK for emacs-devel@gnu.org; Mon, 04 Sep 2006 15:57:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GKKZ1-0004Hb-J2 for emacs-devel@gnu.org; Mon, 04 Sep 2006 15:57:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKKZ1-0004HE-Bw for emacs-devel@gnu.org; Mon, 04 Sep 2006 15:56:59 -0400 Original-Received: from [64.233.184.237] (helo=wr-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GKKjb-0005pE-GV for emacs-devel@gnu.org; Mon, 04 Sep 2006 16:07:55 -0400 Original-Received: by wr-out-0506.google.com with SMTP id 71so535742wra for ; Mon, 04 Sep 2006 12:56:58 -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=nrAf8hb6XBOO67z+nW+otIWUzKzA8r3ghGMvKJgeysIRtVVDKlOuyW3Rr5feA6ZqNT6cpTVp0MtCLeR8kOPWkOM0lh5q8XPZEch674H5l8qG8Mm/cIstd4lEWcDrm9tAeM3EUbAokLW8GyM2wMagfuM9H7Ffch04zK4QyUI+2fM= Original-Received: by 10.90.117.11 with SMTP id p11mr1164329agc; Mon, 04 Sep 2006 12:56:58 -0700 (PDT) Original-Received: by 10.90.105.4 with HTTP; Mon, 4 Sep 2006 12:56:58 -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:59333 Archived-At: On 9/4/06, Richard Stallman wrote: > > So, can we find specific cases where some other incompatible behavior > > is positively desirable? It would be useful for people to look > > for the other facilities that use fields, to see what cases there are > > where we would not want this behavior. > > i don't expect line-move-ignore-fields to be used everywhere, or even > as the default. > > I am looking for a way to avoid the need for such an option, > a way to make the command DTRT for everyone without need for > parameters. And I think I have found one. > > I would like people to help me check whether this solution really works. > > i would want motion from the structure (left-hand) > side of a line (corresponding to the minibuffer's prompt), to another > line with structure, to remain in the structure side if the columns > line up. > > Since the minibuffer has only one prompt, this case cannot occur > in the minibuffer. Therefore, if we make C-n and C-p do this, > the change need not have any effect on the minibuffer. > > So far I see no problem with my proposal as modified by your request. > But what about comint? It uses fields for the prompts, right? > Would this behavior be right for comint? > > offhand, that policy is not what i prefer, however. i do not see it > necessary to retain the cursor within the structure area or the > content area when moving between lines. > > In that case, what behavior WOULD you prefer? the one i've been suggesting - retention of the column on line-move regardless of fields. there are subtle pluses and minuses to sticking within the structure/content field areas. the boundary between the two wavers with outline depth, so that the cursor may be bumping against it repeatedly as you traverse lines. having the cursor column varying with the boundary could be just right, or it could be distracting and even annoying. i just don't know, and would have to try it to find out. i do know that just retaining the column works well. further, allout already offers retention of the cursor on the item 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 somewhat redundant. pure line-move column retention are complementary, however. that is why i would like to have the latter at least as an option. -- ken ken.manheimer@gmail.com http://myriadicity.net