Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!husc6!yale!Ram-Ashwin
From: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Newsgroups: comp.emacs
Subject: Re: Bugs or features?
Message-ID: <49157@yale-celray.yale.UUCP>
Date: 30 Jan 89 20:23:02 GMT
Sender: root@yale.UUCP
Reply-To: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 63
In-Reply-To: tale's message <8901272259.AA01939@pawlsub.rpi.edu> of Fri, 27 Jan 89 17:59:33 EST

>   From: tale@pawl.rpi.edu
>
>   GNU Emacs 18.50.2 of Sun Oct 30 1988 on imagine.pawl.rpi.edu (berkeley-unix)
>   
>   What happens is that when I resume emacs, the string to display
>   free space has mutated from a nice "97%" to
>   "97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J"
>   (ad nauseum)
>   
>   Now it might eventually wind itself all the way back down, but it
>   hasn't in my experience.  Then again, I don't sit around waiting for
>   it to happen.

Ok, I tried it on a Unix machine which supports suspend-emacs (18.52.22,
berkeley-unix).  When I fg the job again, I do get "97%^J97%^J97%^J97%^J..."
in the mode-line (actually, in my case it's "55%^J55%^J55%^J55%^J..."
instead, thankfully :-)).  However, this does not happen with the
display-time string.  The free-space-checker-string corrects itself when it
is next updated (see free-space-checker-interval).

Now, free-space-checker is modelled after display-time, so I don't understand
why this should happen with one and not the other.  However, looking at the
code for the display-time-filter, I notice the curious comment:

  ;; Desired data can't need more than the last 30 chars,
  ;; so save time by flushing the rest.
  ;; This way, if we have many different times all collected at once,
  ;; we can discard all but the last few very fast.
  (if (> (length string) 30)
      (setq string (substring string -30)))
  ...
  (setq display-time-string string)

I suspect what is happening is that while Emacs is suspended, the output from
the process is collected up into one large string, to be processed when Emacs
resumes as if the output was that one string (instead of several individual
strings, each waiting to be processed).  This looks like an Emacs bug to me.

A workaround for this would be to change free-space-checker-filter to nullify
the free-space-checker-string if its length is > 9 (thus producing no output
in the mode line).  The correct free space will be displayed when the
free-space-checker-string is next updated.

(defun free-space-checker-filter (proc string)
   "Filter for free-space-checker-process.
Removes trailing newline, if any, and puts the string into the modeline."
   (setq free-space-checker-string
         (if (> (length string) 9)
             ""
             (concat " " (if (char-equal (string-to-char (substring string -1 nil)) ?\^J)
                             (substring string 0 -1)
                             string))))             
   (force-mode-line-update))

One could use a trick like display-time-filter uses to search down the string
for the last piece of output, but it doesn't seem like it's worth the effort
unless you really need to know the free space right that instant.

-- Ashwin.

ARPA:    Ram-Ashwin@cs.yale.edu
UUCP:    {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin
BITNET:  Ram@yalecs