[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comint read-only prompt
From: |
JD Smith |
Subject: |
Re: comint read-only prompt |
Date: |
20 Aug 2002 18:24:33 -0700 |
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 <=>
- comint read-only prompt, Marshall, Simon, 2002/08/19
- Re: comint read-only prompt, Richard Stallman, 2002/08/20
- Re: comint read-only prompt, JD Smith, 2002/08/20
- Message not available
- Re: comint read-only prompt, JD Smith, 2002/08/20
- Message not available
- Re: comint read-only prompt,
JD Smith <=
- Re: comint read-only prompt, Miles Bader, 2002/08/20
- Re: comint read-only prompt, Stefan Monnier, 2002/08/21
- Re: comint read-only prompt, Luc Teirlinck, 2002/08/20
- Message not available
- Re: comint read-only prompt, Kim F. Storm, 2002/08/20
- Re: comint read-only prompt, Kai Großjohann, 2002/08/21
- Re: comint read-only prompt, Richard Stallman, 2002/08/21
- Re: comint read-only prompt, JD Smith, 2002/08/21
- Re: comint read-only prompt, Miles Bader, 2002/08/21
- Re: comint read-only prompt, Richard Stallman, 2002/08/23
- Message not available
- Re: comint read-only prompt, Richard Stallman, 2002/08/20