The below issue is reproducible in a plain GNU Emacs (Carbon). Note
that the X11 version is reported to work fine, but not Carbon Emacs.
This might not be considered a bug by some of you (for example
because the window manager selects the new frame), but I still think
synchronizing the behavior of the X11 version and the Carbon
implementation could be advantageous.
Begin forwarded message:
From: Mark Russell [EMAIL PROTECTED]
Date: 9 December 2005 18:48:52 GMT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] display-buffer can leave wrong frame with
input focus
display-buffer leaves the wrong frame selected in the following
situation:
- You have a frame selected
- You call display-buffer on a buffer which is listed in
special-display-buffer-names
(and not displayed in the frame you currently have selected)
This creates a new frame to display the buffer (if it is not
displayed already)
and leaves that frame selected. Any subsequent input goes to the
buffer in that frame, but the documentation for display-buffer says
that it does not select the buffer.
To reproduce the bug, load the following code:
(setq special-display-buffer-names '(*test-buffer*))
(defun test-display-buffer ()
Test frame focus by visiting a buffer in an unsplittable
window
(interactive)
(display-buffer (get-buffer-create *test-buffer*)))
In one frame say M-x test-display-buffer. A new frame will appear
displaying *test-buffer* and the input focus will be left there.
This also happens in Carbon emacs, but under X11 emacs the new
frame is created, but the input focus remains in the original
frame, which I believe is the correct behavior).
I tripped over this using the compile library, where the call of
display-buffer in compilation-goto-locus causes the input focus to
alternate between the compilation error messages window and the
source file window each time you use next-error (I have
*compilation* listed in special-display-buffer-names). This
makes stepping through a stack trace almost unusable for me. As a
workaround I replaced the display-buffer call in compilation-goto-
locus with get-buffer-window, but I think the display-buffer
behavior is the actual bug.
Mark Russell
In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
of 2005-12-02 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.7
Distributor `Apple Computers', version 10.4.3
configured using `configure '--without-x' '--prefix=/usr/local''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: CPerl
Minor modes in effect:
smart-frame-positioning-mode: t
recentf-mode: t
encoded-kbd-mode: t
osx-key-mode: t
show-paren-mode: t
delete-selection-mode: t
pc-selection-mode: t
cua-mode: t
tooltip-mode: t
auto-compression-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Auto-saving...
Mark saved where search started
Quit [2 times]
ad-Orig-error: Moved back before first error
Undo...
Undo!
Undo...
Undo!
Loading browse-url...done
Auto-saving...
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
