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:02:27 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <87y9gp8lws.fsf@tc-1-100.kawasaki.gol.ne.jp> References: <200201210941.g0L9f9s14343@aztec.santafe.edu> <5xd6y1aorh.fsf@kfs2.cua.dk> <873cyxanrn.fsf@tc-1-100.kawasaki.gol.ne.jp> <5x8z8pak2s.fsf@kfs2.cua.dk> 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 1016506095 11045 127.0.0.1 (19 Mar 2002 02:48:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Mar 2002 02:48:15 +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-0002s3-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 16n9kg-0000wd-01 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 16n7NG-0008NT-00; Mon, 18 Mar 2002 19:21:10 -0500 Original-Received: from smtp02.fields.gol.com ([203.216.5.132]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16n7Mi-0008Jz-00; Mon, 18 Mar 2002 19:20:36 -0500 Original-Received: from tc-2-215.kawasaki.gol.ne.jp ([203.216.25.215] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 16n7Mc-00061U-00; Tue, 19 Mar 2002 09:20:33 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id C81A63013; Tue, 19 Mar 2002 09:02:27 +0900 (JST) Original-To: no-spam@cua.dk (Kim F. Storm) System-Type: i686-pc-linux-gnu In-Reply-To: <5x8z8pak2s.fsf@kfs2.cua.dk> Original-Lines: 45 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:2019 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2019 no-spam@cua.dk (Kim F. Storm) writes: > I don't understand. How does emacs know when it's currently in an important > case... What are you talking about? I mean _I've_ thought about how things work, and considered the important cases when the current mechanism is confusing in this way, and decided that this is a good solution. > 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). Of course it works. The reason why it's a bit wierd is because the input field is at the of the buffer, and _everything_ involving text properties works a bit oddly at the end of the buffer. [your proposed `solution' would have exactly the same problem!] > 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? Yes, but people apparently don't like it (I don't really care). They want C-e to go to the `end of something', not `the beginning'. Even though the `background' is a field too by definition, people think of the input field as being distinguished from the background, and I suppose emacs ought to respect that. > I thought you were proposing to change, end-of-line and other > commands to behave differently if point is "inside" a field. I'm proposing changing the way the field-restriction functions work (which are called by anyone that cares about a field) to not act like it's a field when the field property is nil. > I referred to that as "messy" (compared to doing it through command > remapping). I suspect trying to do it through command remapping would actually be a lot messier -- because you're only changing things at a surface level, you have a lot more special cases to worry about. [and in any case, the current mechanism (1) exists, and (2) works quite well] -Miles -- I'd rather be consing. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel