From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@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 16:17:54 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xd6y1aorh.fsf@kfs2.cua.dk> References: <200201210941.g0L9f9s14343@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016464699 12129 127.0.0.1 (18 Mar 2002 15:18:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Mar 2002 15:18:19 +0000 (UTC) Cc: rms@gnu.org, 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 16mytu-00039U-00 for ; Mon, 18 Mar 2002 16:18:18 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16myys-0001Z5-00 for ; Mon, 18 Mar 2002 16:23:26 +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 16mytl-0004UR-00; Mon, 18 Mar 2002 10:18:09 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16mysd-0004TO-00; Mon, 18 Mar 2002 10:16:59 -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 D2E057C035; Mon, 18 Mar 2002 15:16:55 +0000 (GMT) Original-To: Miles Bader In-Reply-To: Original-Lines: 67 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:2007 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2007 Miles Bader writes: > [ 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. I think the proper way to achieve this is by using different keymap text properties on input fields and prompt fields. Of course, that will not happen "automatically", but it avoids "cluttering" all the standard (and non-standard) movement and killing commands with such "field aware" exceptions. As a service to the lisp programmers, we could define new `standard' functions like end-of-input-field, end-of-prompt-field, etc. for this and add keymaps input-field-keymap and prompt-field-keymap utilizing the "command remap" feature to remap end-of-line, beginning-of-line and other relevant commands to those commands. Then it would be easy (but tedious?) to put the proper keymap property on the fields and prompts... > 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'). > 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. > The question is, what's a good interface to distinguish the inside of a > field from the 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). Which indicates to me that your proposed solutions isn't the right one. > 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.] If there is a problem with inheriting the field/text properties at the end of the buffer (notably the minibuffer), we need to look at that as a separate issue. IMO, a right-sticky property should be honoured also at the end of the buffer, so if that doesn't happen, it's sounds like a bug. Hm, the problem is that the input field is initially zero-length, so maybe there isn't anywhere to define those properties in the first place... But we already handle the minibuffer correctly, so this will continue to work if we don't start messing up the existing movement & killing functions!!! -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel