bug#10805: 24.0.93; edebug-trace t may cause stuff being inserted into current buffer

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> IIUC edebug conflates the concepts of displaying and popping to buffers.
> Take `edebug-bounce-point':
>
>   (save-excursion
>     ;; If the buffer's currently displayed, avoid set-window-configuration.
>     ---> Since `save-window-excursion' calls `set-window-configuration'
>          we don't "avoid" anything here.
>     (save-window-excursion
>       (edebug-pop-to-buffer edebug-outside-buffer)
>       ---> 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?
>       (goto-char edebug-outside-point)
>       (message "Current buffer: %s Point: %s Mark: %s"
>              (current-buffer) (point)
>              (if (marker-buffer (edebug-mark-marker))
>                  (marker-position (edebug-mark-marker)) "<not set>"))
>       (edebug-sit-for arg)
>       ---> 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.

I agree, I see no reason for doing this.

> > 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
> useful).

Yes, of course, that works.  The same applies to the source code
buffers.  Maybe we could introduce a user option specifying if windows
in other (visible) frames should be considered or not.  Dunno if that
would be appropriate, I didn't use edebug much before.  Currently,
edebug never considers other frames (most of the code seems to have been
written at a time when Emacs did not yet have frames).  Some users might
find it handy if they could use source buffers spread over several
frames, and edebug would work with them.


Michael