From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Revise etc/DEBUG documentation Date: Sun, 04 Sep 2016 17:42:47 +0300 Message-ID: <83mvjnd8uw.fsf@gnu.org> References: <864m5xtgtf.fsf@realize.ch> <838tv9dxu1.fsf@gnu.org> <86zinpruq0.fsf@realize.ch> <8360qddpc7.fsf@gnu.org> <86vaycslct.fsf@realize.ch> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473000183 5585 195.159.176.226 (4 Sep 2016 14:43:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Sep 2016 14:43:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alain Schneble Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 04 16:42:59 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bgYdO-0000kX-2i for ged-emacs-devel@m.gmane.org; Sun, 04 Sep 2016 16:42:58 +0200 Original-Received: from localhost ([::1]:50094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgYdL-0008Go-Rj for ged-emacs-devel@m.gmane.org; Sun, 04 Sep 2016 10:42:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgYdC-0008Ey-Ij for emacs-devel@gnu.org; Sun, 04 Sep 2016 10:42:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgYd8-0000LA-8p for emacs-devel@gnu.org; Sun, 04 Sep 2016 10:42:45 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgYd8-0000L3-5B; Sun, 04 Sep 2016 10:42:42 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bgYd6-0005gq-CI; Sun, 04 Sep 2016 10:42:40 -0400 In-reply-to: <86vaycslct.fsf@realize.ch> (message from Alain Schneble on Sat, 3 Sep 2016 23:51:30 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207172 Archived-At: > From: Alain Schneble > CC: > Date: Sat, 3 Sep 2016 23:51:30 +0200 > > not sure if we can distinguish between executing > Emacs as GUI or terminal application in .gdbinit. Because for the > latter, we certainly still want it to 'pass' (as it is currently > arranged for in .gdbinit). It is actually more complicated than that, because the same Emacs session could have some GUI frames and some text-mode frames (though not on MS-Windows). That's why saying "Emacs executes as GUI" is problematic at best. > >> With new-console 1, when starting Emacs GUI, the console is visible as a > >> separate window in MS-Windows. And it is this console window that can > >> be used to enter Ctrl-c or Ctrl-Break, even though we are running Emacs > >> as a GUI application. > > > > Are you sure? I see something different here: when Emacs is started > > after setting new-console, the window through which I interact with > > GDB is the one where C-c causes GDB to get control back. Maybe this > > depends on the Windows version (it's XP down here, FWIW). > > I think I was again not clear enough, sorry. FWIW, what I meant is: > > start a new command prompt > gdb > file emacs > set new-console 1 > run > > => there are three windows: 1) GDB console, 2) Emacs console > (empty/"black" window) and 3) Emacs GUI window. > > What I wanted to say is that one /can/ use 2) to enter C-c or C-break as > well. This results in GDB displaying 'Thread [n] received signal SIGINT, > Interrupt.'. I understood what you were saying. But your description doesn't match what I see here. (And no, it's not OS version dependent, as I see the same on Windows 7 as on XP.) My crystal ball says that you see that in a session which either didn't read src/.gdbinit, or you manually issued a 'handle' command that changes how SIGINT is handled by GDB, because under the default setting in .gdbinit, SIGINT has the "noprint" attribute, which implies "nostop". Or maybe you are using some build of GDB that is very different from what I'm using (like the Cygwin build?). Or maybe some other factor is at work here. > Of course you can use 1) as well. But this will show a SIGTRAP instead > of a SIGINT message in GDB ('Thread [m] received signal SIGTRAP, > Trace/breakpoint trap'). >From the user POV, the difference is unimportant, the important part is to get control back to GDB. > >> That it behaves differently than on POSIX, where a SIGINT would > >> terminate Emacs when running in "GUI mode". > > > > That's actually inaccurate: on Windows, Emacs doesn't get a SIGINT in > > this case, AFAIK. > > Well, see my example above. At least GDB shows it as a SIGINT. Not by default, not when using .gdbinit from the Emacs sources. > > +When Emacs is displaying on a text terminal, it is sometimes useful to > ^^^^^^^^^^^^^^^^^^^^^^ > Isn't this always useful or even required? Or is there a standard use > case that requires not doing so? Yes, deleting the "sometimes" part would be beneficial, thanks. > I agree with your changes. These are the important points. Thanks for > your help. Thanks, I will install this in a short while.