unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: martin rudalics <rudalics@gmx.at>
Cc: 10805@debbugs.gnu.org
Subject: bug#10805: 24.0.93; edebug-trace t may cause stuff being inserted into current buffer
Date: Fri, 17 Feb 2012 03:18:24 +0100	[thread overview]
Message-ID: <878vk2kxsf.fsf@web.de> (raw)
In-Reply-To: <4F3B814D.3060607@gmx.at> (martin rudalics's message of "Wed, 15 Feb 2012 10:56:29 +0100")

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





  reply	other threads:[~2012-02-17  2:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-13 22:29 bug#10805: 24.0.93; edebug-trace t may cause stuff being inserted into current buffer Michael Heerdegen
2012-02-14 10:53 ` martin rudalics
2012-02-14 23:53   ` Michael Heerdegen
2012-02-15  9:56     ` martin rudalics
2012-02-17  2:18       ` Michael Heerdegen [this message]
2012-02-17  9:58         ` martin rudalics
2012-02-17 15:12           ` Stefan Monnier
2012-02-18 17:04             ` martin rudalics
2012-10-04 13:17 ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878vk2kxsf.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=10805@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).