From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line] Date: 18 Mar 2002 11:39:35 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200201210941.g0L9f9s14343@aztec.santafe.edu> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016419536 18868 127.0.0.1 (18 Mar 2002 02:45:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Mar 2002 02:45:36 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16mn9T-0004uE-00 for ; Mon, 18 Mar 2002 03:45:35 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16mnEC-0004f3-00 for ; Mon, 18 Mar 2002 03:50:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16mn99-0005Wg-00; Sun, 17 Mar 2002 21:45:15 -0500 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16mn7K-0005Pc-00; Sun, 17 Mar 2002 21:43:22 -0500 Original-Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g2I2hGd28792; Mon, 18 Mar 2002 11:43:16 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g2I2h9d10202; Mon, 18 Mar 2002 11:43:12 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g2I2daB20243; Mon, 18 Mar 2002 11:42:22 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g2I2dag11378; Mon, 18 Mar 2002 11:39:36 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id C721C3725; Mon, 18 Mar 2002 11:39:35 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200201210941.g0L9f9s14343@aztec.santafe.edu> Original-Lines: 56 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:1997 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1997 [ This is in reply to an old message complainging that commands like C-e or C-k, when invoked inside a comint prompt, would jump-to/kill-to the end of the prompt, instead of the end of the line. ] It seems to me that the right answer to this problem is to augment the field handling to distinguish between the `inside' and the `outside' of a field (currently there is no such distinction). Then some commands (such as `end-of-line' or `kill-line') would only use the field- sensitive behavior when invoked inside a field, and would act normally when invoked outside a field. [ There is one twist, which I'm not sure the right answer too (but which doesn't effect the comint case). If there's a field inside a line, like this ([ and ] demark the field): 1xxxxxxxxxxx[FFFFFFFFFFFFFFFFFFFF]yyyyyyyyyyyyyyyyy2 Currently, if you type `C-e' while point is at position `1' in such a line, it will jump to the beginning of the field, at `[', which is clearly wrong (though I find that it's sometimes convenient :-). However, is the right behavior for C-e at position `1' to jump to (a) the real end of the line (position `2'), or the end of the field at position `]'? Both behaviors seem fairly sane, and both would be useful in some cases. ] The question is, what's a good interface to distinguish the inside of a field from the outside? I suggest saying that a field property of `nil' is always `outside', and any non-nil value is `inside'. This is very easy to understand and implement, and would be convenient for most user code (since the bulk of text would automatically be considered `outside'). Unfortunately, the most common use of fields currently is in the minibuffer, and it uses a `nil' field property as the `inside' (and puts a non-nil field property on the prompt, to distinguish it). The reason it does this is because the minibuffer input field is at the end of the buffer, and can have a size of zero. Thus any inserted characters will have nil values for their properties, including the `field' property. Also, it's important that the field code recognize that there's an empty field there, so that commands such as C-a don't act wierdly when nothing's been typed into the minibuffer. However, I think this can be handled by making the minibuffer input use an overlay for the input field, instead of relying on the nil-properties inserted at the end of the buffer. [The field code doesn't seem to always handle this properly, but I think that's an implementation bug.] So, that's what I propose to do. Any objections, or better ideas? Thanks, -Miles -- 80% of success is just showing up. --Woody Allen _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel