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