From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: need option so line-move-to-column ignores fields, plus patch Date: Mon, 25 Sep 2006 17:43:51 -0400 Message-ID: <8764fbhbag.fsf@stupidchicken.com> References: <2cd46e7f0608310848l743430e9ia7a1d45e22428083@mail.gmail.com> <2cd46e7f0608312339s16a2a101p8c30840bbdeb0d22@mail.gmail.com> <2cd46e7f0609032143v311b670dra2d2ef679dd936@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=us-ascii X-Trace: sea.gmane.org 1159220619 10600 80.91.229.2 (25 Sep 2006 21:43:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Sep 2006 21:43:39 +0000 (UTC) Cc: ken.manheimer@gmail.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 25 23:43:37 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 1GRyES-0005KD-NK for ged-emacs-devel@m.gmane.org; Mon, 25 Sep 2006 23:43:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRyES-00034v-AK for ged-emacs-devel@m.gmane.org; Mon, 25 Sep 2006 17:43:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRyCs-0002Ax-Qk for emacs-devel@gnu.org; Mon, 25 Sep 2006 17:41:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRyCs-00029b-3K for emacs-devel@gnu.org; Mon, 25 Sep 2006 17:41:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRyCr-00029T-NU for emacs-devel@gnu.org; Mon, 25 Sep 2006 17:41:41 -0400 Original-Received: from [18.19.1.138] (helo=cyd) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GRyHK-0000TN-Pl; Mon, 25 Sep 2006 17:46:18 -0400 Original-Received: by cyd (Postfix, from userid 1000) id D72BD4E3E1; Mon, 25 Sep 2006 17:43:51 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Mon\, 25 Sep 2006 16\:48\:53 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:60216 Archived-At: 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. > > It can go to after the bar. That's where it should go. This logic is wrong. Consider the case where there is a field' in the region denoted XXXXXX; everywhere else, the `field' property is null. Point is initially located at the position indicated by `|'. | XXXXXXXXX Clearly, pressing C-n should move point to the start of the field. The trouble is that the example given by Ken is a particular case where it *looks* as though the behavior you describe makes sense; but in the more general case, it is wrong. > 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)." > > I'm saying we need to change that logic, so that the results > will be good. > > I think we need a concept of temporary goal fields to go with the > temporary goal column. When you type the first line-move command > it should record some info about the field you're in when you start. > Then if a field with the same property appears on the line you move to, > it should be handled as if it were -- in some sense -- "the same". This is a feature, not a bug. But if this behavior (i.e., treating non-contiguous fields as identical for the purpose of line-motion) is really the behavior you want, and we agree that it will close this bug, I can implement this even more simply than that, by comparing `field' properties at the relevant places inside line-move-finish.