From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: comint read-only prompt Date: 20 Aug 2002 18:24:33 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: <1029893073.20783.290.camel@turtle.as.arizona.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1029893122 27476 127.0.0.1 (21 Aug 2002 01:25:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 21 Aug 2002 01:25:22 +0000 (UTC) Cc: rms@gnu.org, monnier+gnu/emacs@rum.cs.yale.edu, miles@lsi.nec.co.jp, simon.marshall@misys.com, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17hKFN-000793-00 for ; Wed, 21 Aug 2002 03:25:21 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17hKhY-0003uV-00 for ; Wed, 21 Aug 2002 03:54:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hKGW-0000jw-00; Tue, 20 Aug 2002 21:26:32 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hKEj-0000hB-00 for emacs-devel@gnu.org; Tue, 20 Aug 2002 21:24:41 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hKEh-0000gy-00 for emacs-devel@gnu.org; Tue, 20 Aug 2002 21:24:41 -0400 Original-Received: from turtle.as.arizona.edu ([128.196.208.207]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hKEe-0000gU-00; Tue, 20 Aug 2002 21:24:36 -0400 Original-Received: (from jdsmith@localhost) by turtle.as.arizona.edu (8.11.6/8.11.6) id g7L1OXS22158; Tue, 20 Aug 2002 18:24:33 -0700 Original-To: Miles Bader In-Reply-To: <20020821001812.GA23832@gnu.org> X-Mailer: Ximian Evolution 1.0.5 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6706 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6706 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 University of Arizona <=> 520-621-1532 Tucson, Arizona 85721 <=>