Re: comint read-only prompt

[JD Smith]

On Mon, 2002-08-19 at 08:40, Stefan Monnier wrote:
> > "Marshall, Simon" <address@hidden> 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 <=>