[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 ()
(interactive)
(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
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
- --=-=-=--
------- End of forwarded message -------