From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs 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 Message-ID: <878vk2kxsf.fsf@web.de> References: <87y5s6l63w.fsf@web.de> <4F3A3D3C.8020002@gmx.at> <87vcn97z07.fsf@web.de> <4F3B814D.3060607@gmx.at> Reply-To: michael_heerdegen@web.de NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1329445097 11699 80.91.229.3 (17 Feb 2012 02:18:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Feb 2012 02:18:17 +0000 (UTC) Cc: 10805@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 17 03:18:16 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RyDOq-0002QF-8V for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Feb 2012 03:18:16 +0100 Original-Received: from localhost ([::1]:36084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyDOp-000061-MT for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Feb 2012 21:18:15 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:48049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyDOm-00005w-VJ for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2012 21:18:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RyDOl-000568-N7 for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2012 21:18:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyDOl-000564-KB for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2012 21:18:11 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RyDQX-00034k-KD for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2012 21:20:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2012 02:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10805 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10805-submit@debbugs.gnu.org id=B10805.132944514811749 (code B ref 10805); Fri, 17 Feb 2012 02:20:01 +0000 Original-Received: (at 10805) by debbugs.gnu.org; 17 Feb 2012 02:19:08 +0000 Original-Received: from localhost ([127.0.0.1]:43104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RyDPf-00033R-S7 for submit@debbugs.gnu.org; Thu, 16 Feb 2012 21:19:08 -0500 Original-Received: from fmmailgate02.web.de ([217.72.192.227]:40381) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RyDPZ-00032t-Im for 10805@debbugs.gnu.org; Thu, 16 Feb 2012 21:19:06 -0500 Original-Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id 902AD1C25099B for <10805@debbugs.gnu.org>; Fri, 17 Feb 2012 03:17:04 +0100 (CET) Original-Received: from snow.dragon ([89.204.139.100]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0MEmKo-1RjJ923VFq-00Fj9D; Fri, 17 Feb 2012 03:17:04 +0100 In-Reply-To: <4F3B814D.3060607@gmx.at> (martin rudalics's message of "Wed, 15 Feb 2012 10:56:29 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) X-Provags-ID: V02:K0:3/jcdJG3o7YDfoVETtBdo3l4hvA6Qp+Axir4j2mh9PQ cAUkd3Gb3v1ykUes1SexmvJb/kg15BQQ0hw3meCgdiI3O3Ixzz kQQSf/kHGtVmDKIkZT/xNTM3kSOjZ09tXkP0Xk2Zkw4p49gD/m aArFs6jIRA3WUrUefHAtrpJzqW4ICa2idUYHsW/a6OgcOP8o2z pv1nP6dzkU0hbwk6sVfBPpfPbX5qFZ/73OkkNAufIQ= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:56949 Archived-At: martin rudalics 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)) "")) > (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