Post by Stefan KangasSee the FIXME in the source code. My setup is too involved to present
here. Suffice it to say that the `Info-bookark-jump' code messes with
the frame that was selected before popping up the Info frame (for
`Info-find-node'). (I get a separate frame for the Info buffer because
`special-display-regexps' is `("[ ]?[*][^*]+[*]")'.)
I don't understand the problem here. I set the following, according to
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
And I've experimented a bit with jumping to info bookmarks without
seeing anything unusual.
Sorry, but a year later I don't recall the details.
The "FIXME" is maybe self-explanatory:
`save-window-excursion' can't restore the window config
of the frame that was selected before, if a different
frame is selected afterward. It does this:
(let ((,c (current-window-configuration)))
(unwind-protect (progn ,@body)
(set-window-configuration ,c)))
If BODY selects a different frame then the
`set-window-configuration' is evaluated there,
which can't be right.
I don't know now whether the report was just
to point out the FIXME or whether it affected me.
I do get a separate frame for Info buffers, but
I don't know what to do to check whether the
window config in the original buffer doesn't
get restored correctly (I don't see how it could)
or whether trying to restore it in the newly
selected frame is problematic (I don't notice that
it is, but I don't fiddle with window configs, so
I don't think I'd notice, if it did).
I think a proper test would need to involve doing
something additional to the handler, to first
modify the original window config, then let the
new frame get selected, and see that the original
window config didn't get restored (it couldn't,
AFAICT).
I think the point of the bug report was probably
just to point to the FIXME. Sorry I've forgotten.