I stripped [Unicode-2] from the subject line because I realized
now the problem is also in Emacs 22. It is due to the --with-gtk
build option and probably to the Fecora Core 6 Linux which runs
the metacity window manager. Anyway I must apologize for having
reported it vaguely.
In article <address@hidden>, Katsumi Yamaoka <address@hidden> writes:
--8<---------------cut here---------------start------------->8---
(defun test ()
(interactive)
(let ((frame (make-frame)))
(select-frame frame)
(select-window (frame-first-window frame)))
(switch-to-buffer "*foo*"))
(local-set-key [f1] 'test)
--8<---------------cut here---------------end--------------->8---
To reproduce the problem, select the frame by clicking the mouse
on the rim (not on an Emacs buffer) of the frame after selecting
another X-frame, and type the [f1] key (not `M-x test RET').
In my case, the new frame is neither selected nor focused.
Let me correct it; the problem happens with Emacs 22 and 23
built with the --with-gtk option and run in the Fedora Core 6
Linux (which I update every day).
In <address@hidden> Kenichi Handa wrote:
That's very strange because Emacs 22 and 23 should not be
different in the codes handling that kind of thing.
Handa-san, thank you for the comment. The reason I misunderstood
that it occurs only with Emacs 23 is that I only tested it with
Emacs 23 built with GTK and Emacs 22 built with LUCID then (I
usually use Emacs 22 LUCID).
A solution is to use `select-frame-set-input-focus' instead of
`select-frame'. So, I'd like to modify gnus-win.el so as to use
`select-frame-set-input-focus'[1] if it is not a bug of Emacs 23.
It will arise to all those who use GTK Emacs and at least the
Fedora Core Linux, so such a workaround is quite insufficient.
While I don't have a skill to fix this unfortunately, I hope it
is solved before releasing.
Regards,
_______________________________________________
emacs-pretest-bug mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug