Re: comint read-only prompt

[JD Smith <jdsmith@as.arizona.edu>]

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