bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#7958: Unresponsive visual bell on OSX


From: Jan Djärv
Subject: bug#7958: Unresponsive visual bell on OSX
Date: Wed, 02 Feb 2011 20:47:58 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.14) Gecko/20110123 Thunderbird/3.1.8

I can't reproduce this, starting from -Q and evalling (setq visible-bell t) and making the bell ding. This on trunk and the emacs-23 branch.

Can you reproduce this when starting with -Q?

        Jan D.

Neil Conway skrev 2011-02-02 05.39:
I'm using Emacs 23.2 (from MacPorts) on OSX 10.6.6. My .emacs includes
"(setq visible-bell t)", but when I do something that causes the bell
to be triggered, Emacs becomes very unresponsive (sometimes hanging
for 3 or 4 seconds, usually (much) longer).

Steps to repro:
1. Set visual bell to true
2. Run Emacs in console mode; I've tested using Terminal.app and iTerm2
3. Open a reasonably-sized file (e.g., 10 lines) and scroll past the
end of the file, e.g., using C-v

Instead of a visual bell, emacs instead refuses to respond to user
input for a lengthy period of time. If I attach with gdb, a typical
call stack looks like:

#0  0x00007fff88c81fca in __semwait_signal ()
#1  0x00007fff88c81e59 in nanosleep ()
#2  0x0000000100544fe5 in napms ()
#3  0x00000001005494fb in delay_output ()
#4  0x0000000100549738 in tputs ()
#5  0x0000000100067007 in tty_ring_bell ()
#6  0x0000000100005ae5 in Fding ()
#7  0x00000001000f3713 in Feval ()
[...]

I can actually get emacs to operate normally by forcing the bottom few
stack frames to return via "ret".

If I remove (setq visual-bell t) from my .emacs, I don't see this behavior.







reply via email to

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