comint read-only prompt

comint read-only prompt

[Marshall, Simon]

Hi guys, this one is for you...

-----Original Message-----
From: JD Smith [mailto:jdsmith@as.arizona.edu] 
Sent: 09 August 2002 00:30
To: shivers@cs.cmu.edu; simon@gnu.org
Subject: comint read-only prompt




I'm the maintainer of the IDLWAVE programming mode, which uses comint to
run the language IDL interactively (see idlw-shell.el if you're
interested).  Without comint, programming the shell would have been far
more cumbersome.   

One missing feature of comint that I'd always pined for was the ability
to make the most recent prompt (IDL> in my case) read-only.  Right now,
the delete key just runs right over it.  As I looked into it further, I
realized the problem was that an overlay is (usually) used to highlight
this prompt, and that overlays (for whatever reason) do not honor the
'read-only property, as text properties do.  I had hoped Emacs 21 would
address this shortcoming, but it did not.

However, I learned by example in cpp-mode (cpp.el), the overlay
properties `modification-hooks' and `insert-in-front-hooks' can be used
to effect a read-only equivalency, by signaling an error if the user
attempts to modify or pre-pend text in the overlay.

I tried this out on the comint.el which shipped with Emacs 21.2.1, and
it works marvelously.  I used 'intangible in addition so left arrow
would skip right over the prompt (and C-a, etc., would stop before the
prompt).  Would you guys be interested in this type of functionality? 
If so, I could redo the mods against CVS comint, and send them your way
for a look (the major relevant change between 21.2.1 and CVS is in
comint-snapshot-last-prompt, where I need to remove hooks to prevent
older prompts from being read-only, in case you want to delete them). 
Otherwise, I might implement them as advice from within idlw-shell, but
I'd prefer the more robust solution.

Thanks,

JD

-- 
 J.D. Smith            <=> 
 Steward Observatory   <=> 520-621-9532 <W>
 University of Arizona <=> 520-621-1532 <F>
 Tucson, Arizona 85721 <=> 

Re: comint read-only prompt

[Miles Bader]

"Marshall, Simon" <simon.marshall@misys.com> writes:
> One missing feature of comint that I'd always pined for was the ability
> to make the most recent prompt (IDL> in my case) read-only.
>
>  Would you guys be interested in this type of functionality? 

Yup.  I was planning to do something like this, but forgot about it.

It's a shame that `read-only' on an overlay doesn't work, though; that
would have made a very nice tidy solution.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: comint read-only prompt

[Stefan Monnier]

> "Marshall, Simon" <simon.marshall@misys.com> writes:
> > One missing feature of comint that I'd always pined for was the ability
> > to make the most recent prompt (IDL> in my case) read-only.
> >
> >  Would you guys be interested in this type of functionality? 
> 
> Yup.  I was planning to do something like this, but forgot about it.
> 
> It's a shame that `read-only' on an overlay doesn't work, though; that
> would have made a very nice tidy solution.

Doesn't the latest trunk code of comint use text-properties now ?


	Stefan

Re: comint read-only prompt

[JD Smith]

On Mon, 2002-08-19 at 08:40, Stefan Monnier wrote:
> > "Marshall, Simon" <simon.marshall@misys.com> writes:
> > > One missing feature of comint that I'd always pined for was the ability
> > > to make the most recent prompt (IDL> in my case) read-only.
> > >
> > >  Would you guys be interested in this type of functionality? 
> > 
> > Yup.  I was planning to do something like this, but forgot about it.
> > 
> > It's a shame that `read-only' on an overlay doesn't work, though; that
> > would have made a very nice tidy solution.
> 
> Doesn't the latest trunk code of comint use text-properties now ?

Thanks for the response guys.

I think the trunk version differs from the released version in the way
it "snapshots" older prompts.  Formerly, new overlays were created for
each prompt.  Now, overlay properties are converted to text properties
for old prompts.  Unfortunately, this "snapshotting" occurs all over the
place, even before a new prompt arrives.  One feature I wanted was for
older prompts *not* to be read-only.  Here's the advice I used to get it
to work (not released, just for play):

  (defvar idlwave-shell-save-comint-last-prompt-overlay nil)
  (defun idlwave-shell-comint-signal-read-only (overlay after start end 
                                                        &optional len)
    (if (and (not after)
             (or (< (overlay-start overlay) start)
                 (> (overlay-end overlay) end)))
        (error "")))

  (defadvice comint-output-filter (around swap-read-only activate)
    "Add a read-only equivalency to the last prompt overlay."
    ;; Caution: in Emacs <~21.2, a new overlay gets created for each
    ;; prompt... in later versions, text-properties for old prompts
    ;; are used instead, and the original overlay is recycled.  In
    ;; this case, we can advise snapshot-last-prompt to remove the
    ;; read-only *text properties* (not the overlay properties).
    ;; Here we test to ensure the prompt isn't in the same position as
    ;; the process-mark before removing the read-only overlay stuff.
    (when (and idlwave-shell-save-comint-last-prompt-overlay 
               (not (equal
                     (marker-position (process-mark (get-buffer-process 
                                                     (current-buffer))))
                     (overlay-end 
                      idlwave-shell-save-comint-last-prompt-overlay))))
      (overlay-put idlwave-shell-save-comint-last-prompt-overlay 
                   'modification-hooks nil)
      (overlay-put idlwave-shell-save-comint-last-prompt-overlay 
                   'insert-in-front-hooks' nil))
    ad-do-it
    (when comint-last-prompt-overlay
      (setq idlwave-shell-save-comint-last-prompt-overlay 
            comint-last-prompt-overlay)
      (overlay-put comint-last-prompt-overlay 'intangible t)
      (overlay-put comint-last-prompt-overlay 'modification-hooks 
                   '(idlwave-shell-comint-signal-read-only))
      (overlay-put comint-last-prompt-overlay 'insert-in-front-hooks 
                   '(idlwave-shell-comint-signal-read-only))))
  
  (defadvice comint-snapshot-last-prompt (after remove-text-read-only activate)
    "Remove the read-only text properties potentially set by snapshot"
    (when comint-last-prompt-overlay
      (remove-text-properties 
       (overlay-start comint-last-prompt-overlay)
       (overlay-end comint-last-prompt-overlay)
       '(modification-hooks nil insert-in-front-hooks nil))))

I've attempted to deal with both cases: a new overlay for each prompt,
and the same overlay getting moved, with text properties set in their
stead for older prompts.  Since "snapshotting" can happen at any time
(even before a prompt becomes an old prompt, but is still at the current
process-mark), I found it necessary to save the last prompt, and remove
the "read-only" properties just before the filter.  In any case, you
obviously wouldn't have to support both forms yourself.  

Another option I tried is adding, at the time of overlay move, a
read-only text property (and don't forget rear-nonsticky).  I reasoned
that this is perfectly acceptable given the new use of text properties
in CVS comint.  I didn't like the error message as much.

Let me know if it's unclear.

Thanks,

JD

-- 
 J.D. Smith            <=> 
 Steward Observatory   <=> 520-621-9532 <W>
 University of Arizona <=> 520-621-1532 <F>
 Tucson, Arizona 85721 <=> 

Re: comint read-only prompt

[Miles Bader]

On Mon, Aug 19, 2002 at 08:57:59AM -0700, JD Smith wrote:
> Another option I tried is adding, at the time of overlay move, a
> read-only text property (and don't forget rear-nonsticky).  I reasoned
> that this is perfectly acceptable given the new use of text properties
> in CVS comint.  I didn't like the error message as much.

Given how often this sort of complaint turns up (that a read-only property is
a good solution except for the error message), how about this idea: If a
signalling an error due to a read-only property, if the property's value is a
string, use that as the error message rather than the default.

[I'm guessing this wouldn't cause compatibility problems becuase people
usually don't use a string just to indicate non-nil]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: comint read-only prompt

[Stefan Monnier]

> On Mon, Aug 19, 2002 at 08:57:59AM -0700, JD Smith wrote:
> > Another option I tried is adding, at the time of overlay move, a
> > read-only text property (and don't forget rear-nonsticky).  I reasoned
> > that this is perfectly acceptable given the new use of text properties
> > in CVS comint.  I didn't like the error message as much.
> 
> Given how often this sort of complaint turns up (that a read-only property is
> a good solution except for the error message), how about this idea: If a
> signalling an error due to a read-only property, if the property's value is a
> string, use that as the error message rather than the default.

I can only agree given that I've thought about the same thing a few
months back and even did some attempt at coding; see patch below.
The print_error_message needs to be updated as well, but I didn't
go that far.


	Stefan


Index: textprop.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/textprop.c,v
retrieving revision 1.132
diff -u -r1.132 textprop.c
--- textprop.c	16 Jul 2002 17:37:14 -0000	1.132
+++ textprop.c	20 Aug 2002 16:10:19 -0000
@@ -83,9 +83,10 @@
    to capture that error in GDB by putting a breakpoint on it.  */
 
 static void
-text_read_only ()
+text_read_only (propval)
+     Lisp_Object propval;
 {
-  Fsignal (Qtext_read_only, Qnil);
+  Fsignal (Qtext_read_only, STRINGP (propval) ? Fcons (propval, Qnil) : Qnil);
 }
 
 
@@ -2051,7 +2052,7 @@
 		      if (TMEM (Qread_only, tem)
 			  || (NILP (Fplist_get (i->plist, Qread_only))
 			      && TMEM (Qcategory, tem)))
-			text_read_only ();
+			text_read_only (after);
 		    }
 		}
 
@@ -2071,7 +2072,7 @@
 		      if (! TMEM (Qread_only, tem)
 			  && (! NILP (Fplist_get (prev->plist,Qread_only))
 			      || ! TMEM (Qcategory, tem)))
-			text_read_only ();
+			text_read_only (before);
 		    }
 		}
 	    }
@@ -2090,13 +2091,13 @@
 		  if (TMEM (Qread_only, tem)
 		      || (NILP (Fplist_get (i->plist, Qread_only))
 			  && TMEM (Qcategory, tem)))
-		    text_read_only ();
+		    text_read_only (after);
 
 		  tem = textget (prev->plist, Qrear_nonsticky);
 		  if (! TMEM (Qread_only, tem)
 		      && (! NILP (Fplist_get (prev->plist, Qread_only))
 			  || ! TMEM (Qcategory, tem)))
-		    text_read_only ();
+		    text_read_only (after);
 		}
 	    }
 	}
@@ -2118,7 +2119,7 @@
       do
 	{
 	  if (! INTERVAL_WRITABLE_P (i))
-	    text_read_only ();
+	    text_read_only (textget (i->plist, Qread_only));
 
 	  if (!inhibit_modification_hooks)
 	    {

Re: comint read-only prompt

[Richard Stallman]

    I can only agree given that I've thought about the same thing a few
    months back and even did some attempt at coding; see patch below.

This seems reasonable.

    The print_error_message needs to be updated as well, but I didn't
    go that far.

What updating does it need?

Re: comint read-only prompt

[Stefan Monnier]

>     I can only agree given that I've thought about the same thing a few
>     months back and even did some attempt at coding; see patch below.
> 
> This seems reasonable.
> 
>     The print_error_message needs to be updated as well, but I didn't
>     go that far.
> 
> What updating does it need?

I can't remember exactly, but I think that as it is, the error message
looks too much like an "internal error" (it uses the usual syntax
used for "uncaught exceptions").


	Stefan

Re: comint read-only prompt

[Richard Stallman]

    Given how often this sort of complaint turns up (that a read-only property is
    a good solution except for the error message), how about this idea: If a
    signalling an error due to a read-only property, if the property's value is a
    string, use that as the error message rather than the default.

Some such festure seems like a good idea.
The basic handling of error message strings in Emacs is
rather inflexible, so there is no existing feature we
can use to do this.  Doing it with a special-case kludge
might be the best way, since it is easy.

Re: comint read-only prompt

[Richard Stallman]

      One feature I wanted was for
    older prompts *not* to be read-only.

It seems rather inconsistent to me to make the newest prompt read-only
and not the other prompts.

Re: comint read-only prompt

[JD Smith]

On Tue, 2002-08-20 at 10:21, Richard Stallman wrote:
>       One feature I wanted was for
>     older prompts *not* to be read-only.
> 
> It seems rather inconsistent to me to make the newest prompt read-only
> and not the other prompts.
> 

My thinking is this:  one of the major advantages of comint over a
traditional terminal is the ability to edit freely past input and
output.  If, suddenly, certain edit operations on older entries elicited
errors, it might be jarring.  Imagine marking out a region of old
input/output to kill and yank into a journal buffer, only to be met with
"Attempt to modify read-only text". 

One more difference, aside from the error message, between using
modification-hooks + insert-in-front-hooks vs. read-only +
rear-nonsticky pertains to killing regions.  With the former method, the
prompt cannot be modified or prepended to, but can be killed as part of
a larger region.  With the latter method, any attempt to remove the text
is met with an error message.  You'd need to bind inhibit-read-only in
all commands which alter prior text.  So there are three options for old
prompts:

        1. Leave them read-only by virtue of a read-only text-property. 
           Any attempt to kill or delete any part of the entirety of
           older prompts generates an error.
        2. Leave them read-only by virtue of modification and
           insert-in-front-hooks.  Attempts to delete any part of the
           prompts signals an error, but the entire prompt can be killed
           without complaint.
        3. Leave them read-write.

Option 1 is probably the easiest to implement (simply add all
text-properties, including read-only, at the time of overlay move...
eliminating the vestigial overlay and snapshot-last-prompt altogether). 
My preference would be Option 2 or 3.

Thanks,

JD

-- 
 J.D. Smith            <=> 
 Steward Observatory   <=> 520-621-9532 <W>
 University of Arizona <=> 520-621-1532 <F>
 Tucson, Arizona 85721 <=> 

Re: comint read-only prompt

[Miles Bader]

On Tue, Aug 20, 2002 at 11:03:04AM -0700, JD Smith wrote:
> Option 1 is probably the easiest to implement (simply add all
> text-properties, including read-only, at the time of overlay move...
> eliminating the vestigial overlay and snapshot-last-prompt altogether). 

You can argue whether the use of an overlay (and snapshot-last-prompt) is the
best solution or not, but it's is _not_ `vestigial', it's quite intentional.

[note that the last prompt can change quite often; you can't simply plop down
text properties and leave them there -- you have to be prepared to remove
them later if what you thought was a prompt turns out not to be]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: comint read-only prompt

[JD Smith]

On Tue, 2002-08-20 at 14:17, Miles Bader wrote:
> On Tue, Aug 20, 2002 at 11:03:04AM -0700, JD Smith wrote:
> > Option 1 is probably the easiest to implement (simply add all
> > text-properties, including read-only, at the time of overlay move...
> > eliminating the vestigial overlay and snapshot-last-prompt altogether). 
> 
> You can argue whether the use of an overlay (and snapshot-last-prompt) is the
> best solution or not, but it's is _not_ `vestigial', it's quite intentional.
> 
> [note that the last prompt can change quite often; you can't simply plop down
> text properties and leave them there -- you have to be prepared to remove
> them later if what you thought was a prompt turns out not to be]
> 

Sorry, poor choice of words.  I did notice that snapshot-last-prompt, in
the CVS version, now adds text properties as opposed to "freeing" the
overlay, and that it gets called not just when a new prompt is created,
but *many* times, e.g. every time a command is sent (which occurs in the
background all the time in IDLWAVE).

So, in the present scheme, the current prompt has either
overlay-properties, or redundant overlay+text-properties.  All old
prompts have just text-properties.  In this context, I can't see how
overlays are uniquely needed, since they aren't predictably present by
themselves... but maybe it's just the time between when they are created
or first moved and when they are snapshotted that their presence is
important.  I had assumed you could just "plop down" text properties and
leave them, since that's effectively what happens as soon as snapshot is
called.  

Thanks,

JD

-- 
 J.D. Smith            <=> 
 Steward Observatory   <=> 520-621-9532 <W>
 University of Arizona <=> 520-621-1532 <F>
 Tucson, Arizona 85721 <=> 

Re: comint read-only prompt

[Miles Bader]

On Tue, Aug 20, 2002 at 03:01:32PM -0700, JD Smith wrote:
> Sorry, poor choice of words.  I did notice that snapshot-last-prompt, in
> the CVS version, now adds text properties as opposed to "freeing" the
> overlay, and that it gets called not just when a new prompt is created,
> but *many* times, e.g. every time a command is sent (which occurs in the
> background all the time in IDLWAVE).

I'm confused by what you mean -- that's when snapshot-last-prompt has
_always_ been called, when input is sent (and it's not called at all when `a
new prompt is created').  It should be called exactly the same number of
times now as it was before.

> So, in the present scheme, the current prompt has either
> overlay-properties, or redundant overlay+text-properties.  All old prompts
> have just text-properties.  In this context, I can't see how overlays are
> uniquely needed, since they aren't predictably present by themselves...

That simply isn't true; the _majority_ of the time, in a normal shell
session, the overlay alone is responsible for the last prompt (there may be a
brief instant after you've send a command, and before the process has sent
any output, when they may overlap, but that's harmless).  As the process
sends output after a command, the overlay is moved so that it covers anything
that `looks like a prompt', which may happen many times.  [and
snapshot-last-prompt is never called _at all_]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: comint read-only prompt

[JD Smith]

On Tue, 2002-08-20 at 17:18, Miles Bader wrote:
> On Tue, Aug 20, 2002 at 03:01:32PM -0700, JD Smith wrote:
> > Sorry, poor choice of words.  I did notice that snapshot-last-prompt, in
> > the CVS version, now adds text properties as opposed to "freeing" the
> > overlay, and that it gets called not just when a new prompt is created,
> > but *many* times, e.g. every time a command is sent (which occurs in the
> > background all the time in IDLWAVE).
> 
> I'm confused by what you mean -- that's when snapshot-last-prompt has
> _always_ been called, when input is sent (and it's not called at all when `a
> new prompt is created').  It should be called exactly the same number of
> times now as it was before.

Sorry if I wasn't clear.  This is certainly true.  In the past, however,
snapshot was emptying out an overlay variable and then a new overlay was
being created in the filter.  Now it assigns text properties over the
top of the overlay, in anticipation of the overlay getting moved.

> > So, in the present scheme, the current prompt has either
> > overlay-properties, or redundant overlay+text-properties.  All old prompts
> > have just text-properties.  In this context, I can't see how overlays are
> > uniquely needed, since they aren't predictably present by themselves...
> 
> That simply isn't true; the _majority_ of the time, in a normal shell
> session, the overlay alone is responsible for the last prompt (there may be a
> brief instant after you've send a command, and before the process has sent
> any output, when they may overlap, but that's harmless).  As the process
> sends output after a command, the overlay is moved so that it covers anything
> that `looks like a prompt', which may happen many times.  [and
> snapshot-last-prompt is never called _at all_]
> 

I just realized the source of the confusion; I forgot to mention that
IDLWAVE uses comint in a potentially unusual mode: 

	(set-process-filter process 'idlwave-shell-filter)

In idlwave-shell-filter, output can be *hidden* (i.e. sent to a hidden
buffer, in which case the prompt overlay stays put), otherwise it is
just passed on to comint-output-filter and shows up in the shell buffer
like normal.  However, every time you send a command, whether hidden or
not, the prompt is snapshotted.  The problem is in assuming every
send-input will automatically be followed by a call to the
output-filter.  I'm not familiar with how other modes use comint, but
I'd bet setting your own process-filter (e.g. to send hidden commands)
is not too uncommon.

In any case, the CVS comint's method don't really hurt IDLWAVE: it's
just that you often have both overlay and text properties  on the same
piece of text at the same time (thanks to the zealous snapshotting). 
If, however, read-only properties were added and removed relying on the
"one send-input, one output-filter" assumption, then that could cause
problems.

A proposed solution: if snapshot were moved to the beginning of the
output-filter, these problems would disappear.  Something roughly like:

(defun comint-output-filter (process string)
  ...
  (comint-snapshot-last-prompt)
  ;;fiddle with overlays to ensure the right placement
  ...
  ;; move the overlay
  (move-overlay comint-last-prompt-overlay ...) 
  ...
  ;; or maybe make a new one
  (setq comint-last-prompt-overlay
	(make-overlay prompt-start (point)))
  (overlay-put comint-last-prompt-overlay
	       'font-lock-face 'comint-highlight-prompt)
  ...
  ;; add the read-only text properties
  (add-text-properties (overlay-start comint-last-prompt-overlay)
		       (overlay-end comint-last-prompt-overlay)
		       '(read-only t rear-nonsticky t))

(defun comint-snapshot-last-prompt ()
  (when comint-last-prompt-overlay
    (let ((inhibit-read-only t))
      (add-text-properties (overlay-start comint-last-prompt-overlay)
                           (overlay-end comint-last-prompt-overlay)
                           (nconc
			    (overlay-properties comint-last-prompt-overlay)
			    '(read-only nil))))))


That way, the read-only properties are removed and other text properties
(highlight, etc.) are applied to the soon-to-be-old prompt only just
before text (containing a new prompt, presumably) arrives.  Probably I'm
missing something simple, but it seems to me that would do it.

Thanks,

JD

-- 
 J.D. Smith            <=> 
 Steward Observatory   <=> 520-621-9532 <W>
 University of Arizona <=> 520-621-1532 <F>
 Tucson, Arizona 85721 <=> 

Re: comint read-only prompt

[Miles Bader]

JD Smith <jdsmith@as.arizona.edu> writes:
> The problem is in assuming every send-input will automatically be
> followed by a call to the output-filter.  I'm not familiar with how
> other modes use comint, but I'd bet setting your own process-filter
> (e.g. to send hidden commands) is not too uncommon.

If you don't expect any output following the input you send, you can
call `process-send-string' instead of `comint-send-string'.  That will
avoid the snapshotting.

> A proposed solution: if snapshot were moved to the beginning of the
> output-filter, these problems would disappear.

That would be completely wrong.  The reason why `prompt snapshotting'
is done when the user sends input is because that's the only time you
can be pretty sure that what the overlay covers is _actually_ a prompt.

[Normal shell output contains lots of things that appear to be prompts,
but in fact are not; they are briefly displayed as if they were prompts,
but when more output arrives, the overlay is moved, and so the incorrect
display is removed.]

-Miles
-- 
97% of everything is grunge

Re: comint read-only prompt

[Stefan Monnier]

> > A proposed solution: if snapshot were moved to the beginning of the
> > output-filter, these problems would disappear.
> 
> That would be completely wrong.  The reason why `prompt snapshotting'
> is done when the user sends input is because that's the only time you
> can be pretty sure that what the overlay covers is _actually_ a prompt.

I think what he was suggesting is:

- comint-send-string sets the overlay's `snapshot' property.
- comint's output filter checks the `snapshot' property to determine
  whether to call comint-snapshot-last-prompt or to just move
  the overlay.

But it seems that it's much simpler to just use process-send-string.
Maybe comint-send-string's docstring could be a bit more forthcoming about
what it means by "extra bookkeeping" so that authors can make a better
informed choice between the two functions.


	Stefan

Re: comint read-only prompt

[Luc Teirlinck]

Richard Stallman wrote:

   It seems rather inconsistent to me to make the newest prompt read-only
   and not the other prompts.

JD Smith wrote:

   So there are three options for old prompts:

	   1. Leave them read-only by virtue of a read-only text-property. 
	      Any attempt to kill or delete any part of the entirety of
	      older prompts generates an error.
	   2. Leave them read-only by virtue of modification and
	      insert-in-front-hooks.  Attempts to delete any part of the
	      prompts signals an error, but the entire prompt can be killed
	      without complaint.
	   3. Leave them read-write.


I believe there is one single important reason to make the latest
prompt read-only: it corresponds to the current command line.  This
reason does not apply to old prompts.

I quite often want to edit or "clean up" comint application buffers.
Option 1 forces one to play around with inhibit-read-only to
accomplish this.  Option 1 is currently implemented in ielm.  It is
extremely inconvenient.

I prefer option 3.  Option 2 might work too.

Sincerely,

Luc.

Re: comint read-only prompt

[Miles Bader]

On Tue, Aug 20, 2002 at 11:21:38AM -0600, Richard Stallman wrote:
>     One feature I wanted was for
>     older prompts *not* to be read-only.
> 
> It seems rather inconsistent to me to make the newest prompt read-only
> and not the other prompts.

It's an inconistency that probably doesn't matter to users.

The `current' prompt is clearly different than others, and far, far, more
likely to be inadvertently modified.  Given the annoyance that read-only past
prompts could cause, and the fact that they are very unlikely to need
protection, I think this split is a good one.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: comint read-only prompt

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Tue, Aug 20, 2002 at 11:21:38AM -0600, Richard Stallman wrote:
> > It seems rather inconsistent to me to make the newest prompt read-only
> > and not the other prompts.
> 
> Given the annoyance that read-only past
> prompts could cause, and the fact that they are very unlikely to need
> protection, I think this split is a good one.

I agree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: comint read-only prompt

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>       One feature I wanted was for
>     older prompts *not* to be read-only.
>
> 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.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: comint read-only prompt

[Richard Stallman]

    > 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.

Re: comint read-only prompt

[JD Smith]

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

Re: comint read-only prompt

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> 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.

If just rebinding DEL to abort when it hits the prompt would be enough,
then that seems like it might be a good idea (and could even be turned
on by default, probably).  But I don't think this particular case
warrants any more effort than that, if making the current prompt
read-only would be simpler.

[People already think of the current prompt as something special (`it's
the current prompt!'), but tend to think of old prompts as simply being
part of the text of the session, not as something special.]

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: comint read-only prompt

[Richard Stallman]

    If just rebinding DEL to abort when it hits the prompt would be enough,
    then that seems like it might be a good idea (and could even be turned
    on by default, probably).

That too might be a good solution.

Re: comint read-only prompt

[Miles Bader]

On Mon, Aug 19, 2002 at 11:40:48AM -0400, Stefan Monnier wrote:
> > It's a shame that `read-only' on an overlay doesn't work, though; that
> > would have made a very nice tidy solution.
> 
> Doesn't the latest trunk code of comint use text-properties now ?

Yeah, for everything _except_ the `current' prompt (because it is updated
constantly, it's much easier to keep a single overlay and just change the
position).  I suppose that could be changed to use text-properties too, but I
think it would be more messy.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: comint read-only prompt

[Richard Stallman]

    I tried this out on the comint.el which shipped with Emacs 21.2.1, and
    it works marvelously.  I used 'intangible in addition so left arrow
    would skip right over the prompt (and C-a, etc., would stop before the
    prompt).  Would you guys be interested in this type of functionality? 

It is certainly worth trying out.

Re: comint read-only prompt

[Noah Friedman]

>There is already a perfectly good method for avoiding accidentally backing
>into the prompt while editing, and that is binding C-cC-a to
>comint-bol-or-process-mark (which is what it used to be bound to, years
>ago),

Sorry, I meant binding C-a to comint-bol.  Sometime in the past few years
someone changed it to just be beginning-of-line.

Re: comint read-only prompt

[Noah Friedman]

I fail to understand why you want to mess with read-only properties in
comint buffers at all, especially with regard to the prompt.

There is already a perfectly good method for avoiding accidentally backing
into the prompt while editing, and that is binding C-cC-a to
comint-bol-or-process-mark (which is what it used to be bound to, years
ago), and if you are so inclined you can bind a function to
pre-command-hook to move point past the prompt (or even past the process
mark) if you try to edit a prompt.  But really, if you mess up the prompt,
so what?  In the decade+ that I've been using shell mode, this has never
once been an issue.  But I do find excessive use of read-only properties on
regular text immensely frustrating when I am trying to do something out of
the ordinary.

Re: comint read-only prompt

[Miles Bader]

Noah Friedman <friedman@splode.com> writes:
> I fail to understand why you want to mess with read-only properties in
> comint buffers at all, especially with regard to the prompt.

I suspect it would be turned off by default.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: comint read-only prompt

[Miles Bader]

p.s.:  You forgot to add `Dag nabit!' to the end of your message.

-miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: comint read-only prompt

[JD Smith]

On Tue, 2002-08-20 at 17:23, Noah Friedman wrote:
> I fail to understand why you want to mess with read-only properties in
> comint buffers at all, especially with regard to the prompt.
> 

There are two types of people in the world:  ones who use C-a C-k when
they change their mind at a prompt, and ones who wail on the Delete
key.  I'm usually one of the former, and did in fact bind C-a to
comint-bol.  However, I've had many users complain that they can delete
right over the prompt and into the previous line, when they delete with
abandon.  For small (few character) deletes, I'd probably prefer the
delete-with-abandon method myself, but I've trained myself not to use
it.  Anyway, it's a small but noticeable usability deficiency on the
command line compared to a traditional terminal.

JD

Re: comint read-only prompt

[Stefan Monnier]

> > I fail to understand why you want to mess with read-only properties in
> > comint buffers at all, especially with regard to the prompt.

I don't feel very strongly about it, but I tend to agree with Noah on
this one: read-only properties are often annoying and should be used
*very* sparingly.  It's better to make sure people don't end up erasing
the text by mistake, then let them try to do it and then burp.

> There are two types of people in the world:  ones who use C-a C-k when
> they change their mind at a prompt, and ones who wail on the Delete key.

I don't know about you, but when I do C-a C-k in Emacs-21's *shell*
buffer, I don't end up erasing the prompt.  Maybe you haven't
noticed the `field' property introduced with Emacs-21 because
you have C-a set to comint-bol ?


	Stefan

Re: comint read-only prompt

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > There are two types of people in the world:  ones who use C-a C-k when
> > they change their mind at a prompt, and ones who wail on the Delete key.
> 
> I don't know about you, but when I do C-a C-k in Emacs-21's *shell*
> buffer, I don't end up erasing the prompt.

I think his point was that the `wail on the Delete key' people do it
because that's what they're used to, and they're likely to continue
doing so, even if there are `better' methods available.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: comint read-only prompt

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Wed, 21 Aug 2002 11:23:28 -0400
> 
> I don't feel very strongly about it, but I tend to agree with Noah on
> this one: read-only properties are often annoying and should be used
> *very* sparingly.

Perhaps this should be told in the ELisp manual.

Re: comint read-only prompt

[Richard Stallman]

    > I don't feel very strongly about it, but I tend to agree with Noah on
    > this one: read-only properties are often annoying and should be used
    > *very* sparingly.

    Perhaps this should be told in the ELisp manual.

I think so.  But can we make the advice any more specific than just
"very sparingly"?

It seems to me that read-only properties are useful for creating a
structure within which there are editable fields.  For instance,
Custom, and the minibuffer, and maybe forms.el (if it uses them).

Are there any other types of situation where they are useful?