[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

address@hidden: Re: mode-line redisplay bug]

From: Richard M. Stallman
Subject: address@hidden: Re: mode-line redisplay bug]
Date: Fri, 12 Aug 2005 10:59:21 -0400

His test case is very clear, but it does not fail when I try it.
Can anyone else observe this failure?

------- Start of forwarded message -------
To: address@hidden
From: Edward O'Connor <address@hidden>
Date: Thu, 11 Aug 2005 09:17:55 -0700
Organization: Church of Emacs
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Subject: Re: mode-line redisplay bug
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

- --=-=-=

Several months ago, I wrote:

> Every so often for a while I've occasionally seen this odd redisplay
> bug, and I now think I know about it to report it. Anyway, here's what
> happens: I set `mode-line-format' to nil in my eshell buffers. I
> switch to an ERC buffer with the command `erc-track-switch-buffer'
> (which is just a cute wrapper around `switch-to-buffer'). My mode-line
> in the ERC buffer upon such a buffer switch will often be garbled,
> with only part of it appearing, as you can see in this screenshot:
> http://edward.oconnor.cx/tmp/emacs/bug1.png
> I thought that the bug might have something to do with my custom
> `mode-line' face, but as you can see in this other screenshot, it
> occurs with default Emacs faces as well:
> http://edward.oconnor.cx/tmp/emacs/bug2.png
> (For completeness sake, here's what a normal ERC buffer looks like:
> http://edward.oconnor.cx/tmp/emacs/normal.png)
> I imagine the redisplay code is trying to only redraw those parts of the
> mode-line that have changed, or something like that. Nevertheless, it
> does seem that the redisplay engine doesn't realize that, when switching
> from a buffer without a mode-line, *everything in the mode-line* needs
> to be redisplayed.

(For the record, I've seen this bug under X11, Mac OS X, and w32.)

Richard Stallman replied:

> Can you please send a precise self-contained test case for this bug?

And I've finally written a self-contained test case (attached):

- --=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: inline; filename=redisplay-bug.el
Content-Description: test case for redisplay bug

;; Step 0: Launch an Emacs on some variety of window-system.

;; Step 1: Ensure that there's something in the mode-line that changes
;;         periodically.

(defvar frob " hello")

(add-to-list 'minor-mode-alist '(t frob))

(defun frob-it ()
  "Change `frob' to a random string, and force a mode-line update."
  (setq frob (concat " " (make-string (+ 2 (random 6))
                                      (+ 97 (random 26)))))
  (force-mode-line-update t))

(run-with-timer 5 5 'frob-it)

;; Step 2: Ensure that there's a buffer with no mode-line.

(with-current-buffer (get-buffer "*scratch*")
  (setq header-line-format mode-line-format
        mode-line-format   nil))

;; Step 3: Make a key binding for switching between the buffer with no
;;         mode-line and a buffer with a mode-line which uses
;;         `switch-to-buffer'.

(global-set-key (kbd "C-c c")
                (lambda ()
                  (if (eq (current-buffer) (get-buffer "*Messages*"))
                      (switch-to-buffer (get-buffer "*scratch*"))
                    (switch-to-buffer (get-buffer "*Messages*")))))

;; Step 4: To observe the bug, switch to *scratch*, wait for the
;;         header-line to change, and hit C-c c. More often than not,
;;         the mode-line in *Messages* will be only partially
;;         displayed. (Try this several times, by repeated use of the
;;         C-c c key binding, if you don't observe the effect right
;;         away.) Typing C-l (unsurprisingly) fixes the display.

- --=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Emacs-pretest-bug mailing list

- --=-=-=--
------- End of forwarded message -------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]