From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Claus Fischer Newsgroups: gmane.emacs.bugs Subject: bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem Date: Wed, 10 Jan 2018 12:19:45 +0100 Message-ID: <20180110111945.fugo7cknqysarnny@clausfischer.com> References: <20180109123311.klciuvflkdgm23pf@clausfischer.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4d7iyx3oys3pwisv" X-Trace: blaine.gmane.org 1515583100 2607 195.159.176.226 (10 Jan 2018 11:18:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Jan 2018 11:18:20 +0000 (UTC) User-Agent: NeoMutt/20170113 (1.7.2) Cc: 30044@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 10 12:18:16 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZEOX-0008Iq-Uc for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jan 2018 12:18:10 +0100 Original-Received: from localhost ([::1]:34189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZEQW-000302-0h for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jan 2018 06:20:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZEQP-0002zl-T2 for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2018 06:20:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZEQM-0005YY-Nr for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2018 06:20:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42419) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eZEQM-0005YD-Jb for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2018 06:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eZEQM-0001GS-7L for bug-gnu-emacs@gnu.org; Wed, 10 Jan 2018 06:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Claus Fischer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jan 2018 11:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30044 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30044-submit@debbugs.gnu.org id=B30044.15155831904835 (code B ref 30044); Wed, 10 Jan 2018 11:20:02 +0000 Original-Received: (at 30044) by debbugs.gnu.org; 10 Jan 2018 11:19:50 +0000 Original-Received: from localhost ([127.0.0.1]:50316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZEQA-0001Fv-0G for submit@debbugs.gnu.org; Wed, 10 Jan 2018 06:19:50 -0500 Original-Received: from clausfischer.com ([78.46.66.52]:33472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZEQ7-0001Fm-Ac for 30044@debbugs.gnu.org; Wed, 10 Jan 2018 06:19:47 -0500 Original-Received: from boltzmann.clausfischer.com (localhost.localdomain [127.0.0.1]) by clausfischer.com (Postfix) with ESMTP id B5D378A033B; Wed, 10 Jan 2018 12:19:45 +0100 (CET) Original-Received: from kepler.clausfischer.com (kepler.clausfischer.com [10.243.1.2]) by boltzmann.clausfischer.com (Postfix) with ESMTP id A12C0680224; Wed, 10 Jan 2018 12:19:45 +0100 (CET) Original-Received: by kepler.clausfischer.com (Postfix, from userid 1000) id 9B24E7954F; Wed, 10 Jan 2018 12:19:45 +0100 (CET) Content-Disposition: inline In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:141972 Archived-At: --4d7iyx3oys3pwisv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 09, 2018 at 10:39:25PM -0500, Noam Postavsky wrote: > On Tue, Jan 9, 2018 at 7:33 AM, Claus Fischer > wrote: >=20 > > A few years ago, I filed a bug about debugging unter Emacs with > > gud and gdb. >=20 > Using a different email perhaps? I can't seem to find that bug. My apologies - that was way back in 2009, and I forgot about the details. In fact, I filed it as a bug report on Debian, Bug No. 520647. It's hard to follow up on those things when you're in the middle of debugging something big, because the focus is on getting the code running. > Bug#2556 and Bug#22374 seem related, though I'm not sure if they are > the same so I won't merge. >=20 > > Please forward this information to the gud-mode maintainers, >=20 > There aren't any such people, as far as I know, apart from general > Emacs maintainers. Well thanks a lot for your answer, I looked at both bugs, and they seem both to be related. Bug 2556 gives me an idea about a misunderstanding that might be at the heart of the case. Up to now I thought that gud would select the debugging buffer by looking at the buffer text, which is *gud...* and select the window according to that text. However (I hadn't looked at the lisp code and I'm not good at Lisp), bug 2556 gives me the impression that gud mode stores a window id of a window that is created in Emacs. That is, for me, a wholly new line of thinking. That might explain the behaviour: * I run the program in xterm and it gives an error message * I have the file where I'm looking for the error in my Emacs; since that's the one I'm just working on (I have a single frame of Emacs at that time) * I run M-x gud-gdb and give the program name * I re-run the program once under gud to see if the error is reproducible, which it usually is (I have a record-replay facility in my program so if valgrind doesn't complain before, the program is fully deterministic.) * I switch to the buffer with the source code in order to set the break point - at this point, I usually switch buffer in the original frame - gud buffer is no longer visible * I type C-x a b to set the breakpoint * I split the frame (or not) and run the program within gud/gdb * It stops at the breakpoint That's the simple scenario. Given the information that gud-mode stores the gud window by its Emacs window id (is that so? perhaps you can confirm), it's entirely conceivable that sometimes there are other factors in the equation that assign other buffers to that window. For instance: I recompile (M-x recompile, which I have on a function key), run program again in the terminal, get to the next programming error, re-load the program into gdb (file ...), and restart the debugger. Very likely the gud buffer is then in a different window. If that is so, the solution for me would be simple: let gud not remember the window, but let it search for the window with buffer name *gud...* and switch to that one. I have only one such buffer. Just speculating here about Emacs internals. Perhaps you can comment on whether this might make sense. =46rom the two bug reports, it seems that problem is biting a few users sporadically. Perhaps we can manage to find a different strategy. Regards, Claus --=20 Claus Fischer http://www.clausfischer.com/ --4d7iyx3oys3pwisv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSsDMwfnPC53jWSFoqbrLFGHC9EiwUCWlX20QAKCRCbrLFGHC9E izkBAJ9jXwuMIVjz5rqnGZsnflCW1GmvwgCfUmkzOzK4UTdjLt002JLuFtONV5g= =hvQE -----END PGP SIGNATURE----- --4d7iyx3oys3pwisv--