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: Sun, 24 Sep 2006 21:31:05 -0400 Message-ID: <2cd46e7f0609241831r19a5ff89p220980398ebb7156@mail.gmail.com> References: <2cd46e7f0608310848l743430e9ia7a1d45e22428083@mail.gmail.com> <2cd46e7f0609041256q73c0c0d3s7631a964ae9a8367@mail.gmail.com> <2cd46e7f0609060952m54601787x8c91412af7fbf69f@mail.gmail.com> <2cd46e7f0609070747o5028d2bewd5a9e79a5afd4a46@mail.gmail.com> <2cd46e7f0609231629hf2187cbl7e46507ee6070422@mail.gmail.com> <87zmcokjjs.fsf@stupidchicken.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 1159147884 1560 80.91.229.2 (25 Sep 2006 01:31:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Sep 2006 01:31:24 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 25 03:31:21 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 1GRfJX-0007j6-7W for ged-emacs-devel@m.gmane.org; Mon, 25 Sep 2006 03:31:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRfJW-0001gX-OD for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 21:31:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRfJN-0001gS-0y for emacs-devel@gnu.org; Sun, 24 Sep 2006 21:31:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRfJL-0001gG-Hg for emacs-devel@gnu.org; Sun, 24 Sep 2006 21:31:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRfJL-0001gD-9Y for emacs-devel@gnu.org; Sun, 24 Sep 2006 21:31:07 -0400 Original-Received: from [66.249.82.232] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GRfNe-00015g-7S for emacs-devel@gnu.org; Sun, 24 Sep 2006 21:35:34 -0400 Original-Received: by wx-out-0506.google.com with SMTP id i26so1879191wxd for ; Sun, 24 Sep 2006 18:31:06 -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=TBxyfdOo3hqgXf8pIRT2JYN6zGzksrcI8NtbQyjSuaGbZc4HF/XFAymmAUpWwYw/bbmSYN/TGT9RjndbIJF3Ws5kwEaRQlKnjPty340AYEPLd9eRscjahgbiQ4F4peTyQhMKjv6HI+r/7ufEWFWLcszE2a0Pu6SIhE7mV1hqDLc= Original-Received: by 10.90.115.9 with SMTP id n9mr1128568agc; Sun, 24 Sep 2006 18:31:05 -0700 (PDT) Original-Received: by 10.90.105.4 with HTTP; Sun, 24 Sep 2006 18:31:05 -0700 (PDT) Original-To: "Chong Yidong" In-Reply-To: <87zmcokjjs.fsf@stupidchicken.com> 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:60183 Archived-At: On 9/24/06, Chong Yidong wrote: > Richard Stallman writes: > > > | 1. With the cursor adjacent to the right of any bar, > > | if you move forwards a line (^N), the cursor slips to column 0. > > | 2. Moving backwards (^P) with the cursor in the same place, however, > > | doesn't have this problem - it sticks near the boundary. > > > > #1 is clearly a bug. C-n should be symmetrical with C-p. > > I don't see where else the cursor can possibly go in #1. The logic of > line-move is like this: "Try to naively move the cursor vertically > down. If this moves us into a new field, go instead to the beginning > of the field (if going forward) or the end of the field (if going > backward)." this definitely warrants documentation. currently line-move has no docstring. i don't remember whether i've seen anything as simple salient as this description in the elisp info, and the connection to the info for constrain-to-field is obscure, at best, and this is not really covered there, as well. (there's a misspelling there - search in lispref/text.texti for "argumemt", should be "argument".) > In #1, the "naive" motion moves the cursor into a new field, so it > shouldn't move to the old column; instead, it moves into the beginning > of the field. > > The C-p behavior is also correct. The situation actually is > symmetric, but subtle. When the cursor moves backwards, and finds > itself in a new field, it moves to the *end* of that field. When the > field boundaries are arranged as > > | > | > | > > the logical behavior implies that the cursor should stick near the > boundary. Spontaneous symmetry breaking! > > > | 4. Forwards with the cursor on or to the bar's left leaves it in column 0. > > > > That is a bug. It should be sticky except staying to the left of the bar. > > Same here---the cursor is moving into a new field. > > I have checked in a fix to improve column motion in certain other > situations. i think i'm in a bind. fields are suitable for the ^A behavior - when starting in the content portion of an item's header line, i want ^A to take the cursor to the beginning of the content portion. seems like fields give me exactly that. (i see now that it need not be the field 'boundary, but that's another story.) when moving between lines, i often see the screen split into two irregularly-bounded portions - the structure part on the left and the content part on the right. (this presumes all the items have their bodies collapsed, a common situation.) i would like for line motion within each portion to have regular column stickiness, except that i'd like for the cursor to go to the same kind of portion (content or structure) of the next line as the portion it came from, if possible. this is evidently not what fields are designed to do. ? if that's so, then the line-motion-ignore-fields, which i originally proposed, is what i need. i'd prefer the column stickiness within structure/content segregation, but lacking that the regular field model (moving to the end or the beginning of the new field, depending on direction) is not at all suitable - as bad or worse than jumping to the beginning or end of line, depending on direction. is this making sense? -- ken ken.manheimer@gmail.com http://myriadicity.net