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: 19 Mar 2002 09:18:16 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <87u1rd8l6f.fsf@tc-1-100.kawasaki.gol.ne.jp> References: <200201210941.g0L9f9s14343@aztec.santafe.edu> <200203182007.g2IK7VK08811@wijiji.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 1016506096 11054 127.0.0.1 (19 Mar 2002 02:48:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Mar 2002 02:48:16 +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 16n9fb-0002sC-00 for ; Tue, 19 Mar 2002 03:48:15 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16n9kh-0000wd-00 for ; Tue, 19 Mar 2002 03:53:31 +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 16n7NN-0008Py-00; Mon, 18 Mar 2002 19:21:17 -0500 Original-Received: from smtp01.fields.gol.com ([203.216.5.131]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16n7Mh-0008Jm-00; Mon, 18 Mar 2002 19:20:35 -0500 Original-Received: from tc-2-215.kawasaki.gol.ne.jp ([203.216.25.215] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp01.fields.gol.com with esmtp (Magnetic Fields) id 16n7Mc-0007qu-00; Tue, 19 Mar 2002 09:20:33 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id B19613015; Tue, 19 Mar 2002 09:18:16 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu In-Reply-To: <200203182007.g2IK7VK08811@wijiji.santafe.edu> Original-Lines: 23 X-Abuse-Complaints: abuse@gol.com 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:2020 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2020 Richard Stallman writes: > 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? Well, input fields can be zero-width, so it sems like emacs has to be able to do _something_ for that case. It could do so using the same rules it uses for field boundaries (which are also ambiguous, because you have to decide whether a movement should be treated as being at the end of the first field or at the beginning of the second field), by looking at the stickyness of any overlay. If you don't like this, then the only thing I can think of is that you have to say `empty fields can only exist at the end of the buffer.' [Then, of course, some other way has to be found to distinguish `inside' from `outside'.] -Miles -- Would you like fries with that? _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel