unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: JD Smith <jdsmith@as.arizona.edu>
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
Subject: Re: comint read-only prompt
Date: 21 Aug 2002 19:21:55 -0700	[thread overview]
Message-ID: <1029982915.1242.163.camel@turtle.as.arizona.edu> (raw)
In-Reply-To: <200208220157.g7M1vaN10501@wijiji.santafe.edu>

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

  reply	other threads:[~2002-08-22  2:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-19  8:24 comint read-only prompt Marshall, Simon
2002-08-19 10:59 ` Miles Bader
2002-08-19 15:40   ` Stefan Monnier
2002-08-19 15:57     ` JD Smith
2002-08-19 23:45       ` Miles Bader
2002-08-20 16:14         ` Stefan Monnier
2002-08-21  0:12           ` Richard Stallman
2002-08-21 15:06             ` Stefan Monnier
2002-08-21  0:11         ` Richard Stallman
2002-08-20 17:21       ` Richard Stallman
2002-08-20 18:03         ` JD Smith
2002-08-20 21:17           ` Miles Bader
2002-08-20 22:01             ` JD Smith
2002-08-21  0:18               ` Miles Bader
2002-08-21  1:24                 ` JD Smith
2002-08-21  1:36                   ` Miles Bader
2002-08-21 15:28                     ` Stefan Monnier
2002-08-20 18:36         ` Luc Teirlinck
2002-08-20 21:12         ` Miles Bader
2002-08-20 23:23           ` Kim F. Storm
2002-08-21 11:05         ` Kai Großjohann
2002-08-22  1:57           ` Richard Stallman
2002-08-22  2:21             ` JD Smith [this message]
2002-08-22  2:35             ` Miles Bader
2002-08-24  2:33               ` Richard Stallman
2002-08-19 23:41     ` Miles Bader
2002-08-19 20:46 ` Richard Stallman
2002-08-21  0:23   ` Noah Friedman
2002-08-21  1:21     ` Miles Bader
2002-08-21  1:38       ` Miles Bader
2002-08-21  1:32     ` JD Smith
2002-08-21 15:23       ` Stefan Monnier
2002-08-22  1:21         ` Miles Bader
2002-08-22  7:57         ` Eli Zaretskii
2002-08-24  2:32           ` Richard Stallman
2002-08-21  0:23   ` Noah Friedman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1029982915.1242.163.camel@turtle.as.arizona.edu \
    --to=jdsmith@as.arizona.edu \
    --cc=Kai.Grossjohann@CS.Uni-Dortmund.DE \
    --cc=emacs-devel@gnu.org \
    --cc=miles@lsi.nec.co.jp \
    --cc=monnier+gnu/emacs@rum.cs.yale.edu \
    --cc=simon.marshall@misys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).