From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: no-spam@cua.dk (Kim F. Storm) 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 17:59:07 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5x8z8pak2s.fsf@kfs2.cua.dk> References: <200201210941.g0L9f9s14343@aztec.santafe.edu> <5xd6y1aorh.fsf@kfs2.cua.dk> <873cyxanrn.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016470844 17956 127.0.0.1 (18 Mar 2002 17:00:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Mar 2002 17:00:44 +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 16n0V2-0004fW-00 for ; Mon, 18 Mar 2002 18:00:44 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16n0a1-0002LW-00 for ; Mon, 18 Mar 2002 18:05:53 +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 16n0Ua-0005vw-00; Mon, 18 Mar 2002 12:00:16 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16n0SY-0005Xs-00; Mon, 18 Mar 2002 11:58:10 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 9B17C7C035; Mon, 18 Mar 2002 16:58:08 +0000 (GMT) Original-To: Miles Bader In-Reply-To: <873cyxanrn.fsf@tc-1-100.kawasaki.gol.ne.jp> Original-Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:2010 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2010 Miles Bader writes: > storm@cua.dk (Kim F. Storm) writes: > > What happens if you have two fields next to each other -- in that > > case, the inside of one field is the outside the other field - and > > vice versa. > > This is not a problem. The only important case is where one of these > commands would from `outside' to `inside' in a way that's counter-intuitive. I don't understand. How does emacs know when it's currently in an important case... > > > > 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). > > > > Which indicates to me that your proposed solutions isn't the right one. > > Why? I said 'indicates' -- as the major example of using this feature doesn't work, and need to be reworked using more machinery (rather than less). > > > But we already handle the minibuffer correctly, so this > > will continue to work > > No, the minibuffer suffers from the same `problem' that comint does. > It's just not commonly enountered by users, because they usually don't > move into the prompt. Ok, but it sometimes does make sense to navigate inside the prompt. C-e -> goto end of prompt (= start of input), another C-e -> go to end of input. Isn't that how it's working now? > > > if we don't start messing up the existing movement & killing > > functions!!! > > What are you talking about? I thought you were proposing to change, end-of-line and other commands to behave differently if point is "inside" a field. I referred to that as "messy" (compared to doing it through command remapping). -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel