[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10805: 24.0.93; edebug-trace t may cause stuff being inserted into c
bug#10805: 24.0.93; edebug-trace t may cause stuff being inserted into current buffer
Wed, 15 Feb 2012 10:56:29 +0100
> Maybe. But please keep in mind that `edebug-trace-display' is about
> _displaying_ a buffer. We don't want the user to edit the trace buffer,
> so calling `select-window' is in fact not necessary in this case. The
> former window is instantly re-selected by `edebug-trace-display'.
IIUC edebug conflates the concepts of displaying and popping to buffers.
;; If the buffer's currently displayed, avoid set-window-configuration.
---> Since `save-window-excursion' calls `set-window-configuration'
we don't "avoid" anything here.
---> Here the `select-window' problem might strike as well. But
why should the window be selected? To make `goto-char',
`current-buffer' and `point' work?
(message "Current buffer: %s Point: %s Mark: %s"
(if (marker-buffer (edebug-mark-marker))
(marker-position (edebug-mark-marker)) "<not set>"))
---> Popping back to the original window as the _last_ action of
a `save-window-excursion' doesn't make any sense.
(edebug-pop-to-buffer edebug-buffer (car edebug-window-data)))))
This may select a window up to three times for the apparent single
purpose to display the context of a position in some buffer.
> Please also note (another issue, but related) that if the trace buffer
> is already visible in another (visible) frame, a new window pops up in
> the current frame nevertheless, which is kind of annoying if source
> files are spread over multiple frames.
Probably because `edebug-get-buffer-window' (aliased to
`get-buffer-window') is called with a nil ALL-FRAMES argument. Try to
use another argument (you probably have to raise frames to make this