emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revise etc/DEBUG documentation


From: Eli Zaretskii
Subject: Re: Revise etc/DEBUG documentation
Date: Sun, 04 Sep 2016 17:42:47 +0300

> From: Alain Schneble <address@hidden>
> CC: <address@hidden>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]