From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: comint read-only prompt Date: 21 Aug 2002 19:21:55 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: <1029982915.1242.163.camel@turtle.as.arizona.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1029982999 12260 127.0.0.1 (22 Aug 2002 02:23:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 22 Aug 2002 02:23:19 +0000 (UTC) Cc: Kai.Grossjohann@CS.Uni-Dortmund.DE, monnier+gnu/emacs@rum.cs.yale.edu, miles@lsi.nec.co.jp, simon.marshall@misys.com, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17hhcz-0003Bd-00 for ; Thu, 22 Aug 2002 04:23:17 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17hi5f-0004up-00 for ; Thu, 22 Aug 2002 04:52:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hhe9-0004x5-00; Wed, 21 Aug 2002 22:24:29 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hhbn-0004rl-00 for emacs-devel@gnu.org; Wed, 21 Aug 2002 22:22:03 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hhbk-0004rL-00 for emacs-devel@gnu.org; Wed, 21 Aug 2002 22:22:03 -0400 Original-Received: from turtle.as.arizona.edu ([128.196.208.207]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hhbk-0004rF-00; Wed, 21 Aug 2002 22:22:00 -0400 Original-Received: (from jdsmith@localhost) by turtle.as.arizona.edu (8.11.6/8.11.6) id g7M2Lta05387; Wed, 21 Aug 2002 19:21:55 -0700 Original-To: rms@gnu.org In-Reply-To: <200208220157.g7M1vaN10501@wijiji.santafe.edu> X-Mailer: Ximian Evolution 1.0.5 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6749 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6749 On Wed, 2002-08-21 at 18:57, Richard Stallman wrote: > > It seems rather inconsistent to me to make the newest prompt read-only > > and not the other prompts. > > People might want to trim the *shell* buffer, for example to > eliminate spurious commands. Then the modified *shell* buffer can be > sent via email to illustrate some point. > > Yes, I agree. In some cases people might want to edit the last > prompt, too. Yet there are also cases (as has been said) where they > would tend to do so by mistake and it would be useful to prevent them. > > Perhaps instead of trying to distinguish these cases based on which > prompt is being edited, we should try to distinguish between different > commands. For instance, maybe the case that should get an error > is when point is after the last prompt and you're deleting a region > that runs back into the last prompt. That sounds very sensible to me. The modification-hooks + insert-in-front-hooks method I originally introduced approximates this. If you drop insert-in-front, the user could annotate the beginning of the line with the last prompt, remove the entire prompt without complaint, but still be prevented from "backing over" it. He also couldn't place the point in the middle of the prompt and edit from there, but I'm not sure how useful that would be anyway. If I needed to edit the last prompt in situ (for instance to remove my hostname), I'd simply hit return to make it no longer the last line, and edit away. I could always C-k the empty prompt line at the end. Since I'm saved from accidentally erasing the prompt many many more times than I'm slightly inconvenienced when I intentionally want to edit it, I think it's a good trade. This has the advantage of being held in the overlay, and thus side-stepping the whole snapshotting dilemma (so long as you ensure that modification-hooks stays an overlay and does not become a text-property). I think 'intangible makes sense here too, to avoid leaving point inside the prompt. Is there anyone with more experience with the comint code who'd like to try implementing this? Thanks, JD