From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman 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: Mon, 18 Mar 2002 13:07:31 -0700 (MST) Sender: emacs-devel-admin@gnu.org Message-ID: <200203182007.g2IK7VK08811@wijiji.santafe.edu> References: <200201210941.g0L9f9s14343@aztec.santafe.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1016482181 28837 127.0.0.1 (18 Mar 2002 20:09:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Mar 2002 20:09:41 +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 16n3Rs-0007V1-00 for ; Mon, 18 Mar 2002 21:09:40 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16n3Ww-0003jI-00 for ; Mon, 18 Mar 2002 21:14:54 +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 16n3Rl-0008Nu-00; Mon, 18 Mar 2002 15:09:33 -0500 Original-Received: from pele.santafe.edu ([192.12.12.119]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16n3Po-0008C8-00; Mon, 18 Mar 2002 15:07:32 -0500 Original-Received: from wijiji.santafe.edu (wijiji [192.12.12.5]) by pele.santafe.edu (8.11.6+Sun/8.9.3) with ESMTP id g2IK7Ya22188; Mon, 18 Mar 2002 13:07:34 -0700 (MST) Original-Received: (from rms@localhost) by wijiji.santafe.edu (8.11.6+Sun/8.9.3) id g2IK7VK08811; Mon, 18 Mar 2002 13:07:31 -0700 (MST) X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@wijiji using -f Original-To: miles@gnu.org In-Reply-To: (message from Miles Bader on 18 Mar 2002 11:39:35 +0900) 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:2013 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2013 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. That part bothers me. Can we assign a coherent meaning to a field property on an empty overlay? _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel