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: Fri, 1 Sep 2006 02:39:15 -0400 Message-ID: <2cd46e7f0608312339s16a2a101p8c30840bbdeb0d22@mail.gmail.com> References: <2cd46e7f0608310848l743430e9ia7a1d45e22428083@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 1157092780 18275 80.91.229.2 (1 Sep 2006 06:39:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2006 06:39:40 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 01 08:39:39 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 1GJ2gc-0006xq-QL for ged-emacs-devel@m.gmane.org; Fri, 01 Sep 2006 08:39:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJ2gc-0004rn-6b for ged-emacs-devel@m.gmane.org; Fri, 01 Sep 2006 02:39:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJ2gP-0004qF-TB for emacs-devel@gnu.org; Fri, 01 Sep 2006 02:39:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJ2gP-0004p1-5F for emacs-devel@gnu.org; Fri, 01 Sep 2006 02:39:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJ2gO-0004oq-RW for emacs-devel@gnu.org; Fri, 01 Sep 2006 02:39:16 -0400 Original-Received: from [66.249.82.224] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GJ2qB-0007px-Hl for emacs-devel@gnu.org; Fri, 01 Sep 2006 02:49:23 -0400 Original-Received: by wx-out-0506.google.com with SMTP id i26so1137296wxd for ; Thu, 31 Aug 2006 23:39:16 -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=JZqq7svTtHQIP90pxAS6TEcsCdHGNClilSofBtWsIflA0YaOYMEsIwr1T11drn71WQNIEXL7jdLto+5riYu6cNXH6yd81/HcRwGOko6XS7ZcFt8QrJN+V7qT3PufiLkXNXAcZDOXi2/qX/rxBFFkXZR76yex6yNRu3b8rpZnSJg= Original-Received: by 10.90.25.9 with SMTP id 9mr386078agy; Thu, 31 Aug 2006 23:39:15 -0700 (PDT) Original-Received: by 10.90.105.4 with HTTP; Thu, 31 Aug 2006 23:39:15 -0700 (PDT) Original-To: "Miles Bader" 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:59207 Archived-At: On 9/1/06, Miles Bader wrote: > Richard Stallman writes: > > the bug is that i can't use text fields this way without sacrificing > > column retention on line moves, as far as i can tell. > > line-move-to-column is hard-wired to respect fields when seeking the > > prior positions column, so that moving the cursor between topics > > usually leaves the cursor at column 0, which is almost always not what > > the user wants. > > > > Creating a new variable can enable allout to get what it wants. > > But that is a sort of a cop-out, because users might want the same > > thing in other modes that use fields, sometimes. > > I'm not sure Ken's change is correct anyway -- line-move-to-column is > what line-move _usually_ ends up using, right, to preserve the current > column? i don't understand what you're suggesting in that paragraph. i can say that i noticed that line-move-finish duplicates the line-move column positioning according to fields (mixed together with the provision for line moves into intangibility), and the second version of my patch addresses that. > The current interaction between line-movement and fields is intentional, > so that "column" preservation does not cause, for instance, the cursor > to move into the prompt in the minibuffer when you're editing a multline > minibuffer entry. so the environment for that sort of editing should leave the default value for line-move-ignore-fields, to retain the current behavior. line-move-ignore-fields should be set when you don't want that behavior. i don't see how that is incorrect. > When I've noticed the sort of problem Ken's complaining about in the > past, it's always been due to the fact that the newline character on a > line is in a field; there is already a sort of mechanism to try and deal with > this (used for instance, by comint), which is to put newline characters > in a special field with the value `boundary'. none of the newlines in the buffers where i'm having the problem have any 'field property set. ie, the following lisp expression: (while (and (re-search-forward "\n" nil t) (not (get-char-property (1- (point)) 'field)))) advances from the beginning to the end of the buffers without stopping. (out of curiousity, i tried setting the field 'boundary on the newlines. the column was retained in the left part of the line - ie, having characters that have the field 'boundary set. to the right of that, with characters that lack any 'field setting, the column is not retained - the cursor moves to the left-most non-fielded character of the next line, just to the right of the rightmost 'boundary char. that is in the content part of the line, and distinctly is not desired.) > Perhaps I misunderstand his problem though. i want fields respected for motion within a line - specifically, when moving from the right of the boundary towards the boundary - without sacrificing retention of the column when moving between lines. that's the level of control that line-move-ignore-fields provides. i'm open to solutions using only fields as they currently are implemented, but i haven't found any that avoid sacrificing either the intra-line or line-motion behavior. -- ken ken.manheimer@gmail.com http://myriadicity.net