I'm to tired to look at this right now, but here is the backtrace in
either case, I might look at it later on.
[EMAIL PROTECTED]:~$ gdb emacs
GNU gdb 6.0-debian
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to cha
Can you answer the first question, please?
Sorry, I thought I did. Hopefully this will answer your questions
once and for all.
Does emacs successfully quit and return to top level, or does it
seemingly ignore the first quit?
The former from the looks...
Is this true for when you hi
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Is this true for when you hit C-g to the normal top level, or only
>if you hit C-g while some lisp function is running?
>
> At top-level, hitting C-g several times doesn't make emacs jump into
> escape mode. I tried running a couple of lisp
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>>Suppose two rapid C-g's come in before Emacs has a chance to
>>respond, because, say, it's paged out.
>>
>> Doesn't matter if you hit C-g rapidly or not, it will cause emacs to
>> jump into escape mode after two C-g's no
>Suppose two rapid C-g's come in before Emacs has a chance to
>respond, because, say, it's paged out.
>
> Doesn't matter if you hit C-g rapidly or not, it will cause emacs to
> jump into escape mode after two C-g's no matter the interval between
> them is.
I can't tel
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Suppose two rapid C-g's come in before Emacs has a chance to
>respond, because, say, it's paged out.
>
> Doesn't matter if you hit C-g rapidly or not, it will cause emacs to
> jump into escape mode after two C-g's no matter the interval betw
Suppose two rapid C-g's come in before Emacs has a chance to
respond, because, say, it's paged out.
Doesn't matter if you hit C-g rapidly or not, it will cause emacs to
jump into escape mode after two C-g's no matter the interval between
them is.
_
Roland McGrath <[EMAIL PROTECTED]> writes:
> One has always seen this from time to time on any system, and I do see it
> once in a while on Linux. I believe this happens when a second SIGINT is
> received while quit-flag is still set. That may just mean that the whole
> path of the first signal
One has always seen this from time to time on any system, and I do see it
once in a while on Linux. I believe this happens when a second SIGINT is
received while quit-flag is still set. That may just mean that the whole
path of the first signal getting handled, the quit getting up to Lisp and
bei
