unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: JD Smith <jdsmith@as.arizona.edu>
Cc: Miles Bader <miles@lsi.nec.co.jp>,
	"Marshall, Simon" <simon.marshall@misys.com>,
	"'Emacs Developers'" <emacs-devel@gnu.org>
Subject: Re: comint read-only prompt
Date: 19 Aug 2002 08:57:59 -0700	[thread overview]
Message-ID: <1029772679.16562.13.camel@turtle.as.arizona.edu> (raw)
In-Reply-To: <200208191540.g7JFemV13663@rum.cs.yale.edu>

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

  reply	other threads:[~2002-08-19 15:57 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 [this message]
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
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=1029772679.16562.13.camel@turtle.as.arizona.edu \
    --to=jdsmith@as.arizona.edu \
    --cc=emacs-devel@gnu.org \
    --cc=miles@lsi.nec.co.jp \
    --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).