Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Do something about the Bell #3

Closed
wez opened this issue Feb 25, 2018 · 4 comments
Closed

Do something about the Bell #3

wez opened this issue Feb 25, 2018 · 4 comments
Labels
enhancement New feature or request

Comments

@wez
Copy link
Owner

wez commented Feb 25, 2018 •
edited
Loading

Currently we don't handle this at all, so we end up printing unhandled vte execute 7 to stderr.
There are varying degrees of support:

  • Print bell! to stderr instead of letting it hit the unhandled case. This is lameish.
  • Don't print anything to stderr at all, but do nothing. This is logically equivalent to explicitly configuring that the bell be disabled.
  • Hook up an audible bell tone. This definitely should be something that we can turn off because I totally hate audible bells.
  • Hook up a visual bell rendering of some kind. There are simplistic approaches of forcing the inverse video bit on, but I'd like something more tasteful and less bright. This also definitely needs an option to turn it off because I hate visual bells too, but they've always been super bright and distracting.
  • Teach tabs about being in an alert state and render some kind of bell graphic in the tab UI that sticks until acknowledged in some way
  • On systems that allow bouncing icons in the dock area, add configurable support for doing that
  • Generate a system "toast" notification

others?
@wez wez added enhancement New feature or request help wanted labels Feb 25, 2018
wez added a commit that referenced this issue Feb 28, 2018
@wez
print ding when the bell is rung
045abee 
refs: #3
@wez wez mentioned this issue Dec 25, 2019
Closed
quark-zju added a commit to quark-zju/wezterm that referenced this issue Jan 6, 2020
@quark-zju
Make UnixTerminalWaker::wake non-blocking
1240de2 
I was running `hg log --config pager.pager=sp` and pressing space without
releasing it. After about 10k lines sp appears to deadlock. It seems sp uses a
single thread for both reading terminal events and sending wake events and it
sends too many wake events without reading the events.

Failing to write to the wake pipe due to EWOULDBLOCK does not seem to be a
problem - there are enough events in the pipe to wake up the other side.
Therefore let's just make wake_pipe_write nonblocking and treat EWOULDBLOCK as
a success.

Context: The stuck thread looks like:

    #0  0x00007f32671ee237 in write () from /usr/lib/libc.so.6
    wez#1  0x000055c466022823 in std::sys::unix::fd::FileDesc::write () at src/libstd/sys/unix/fd.rs:96
    wez#2  std::sys::unix::net::Socket::write () at src/libstd/sys/unix/net.rs:276
    wez#3  <&std::sys::unix::ext::net::UnixStream as std::io::Write>::write ()
        at src/libstd/sys/unix/ext/net.rs:597
    wez#4  <std::sys::unix::ext::net::UnixStream as std::io::Write>::write ()
        at src/libstd/sys/unix/ext/net.rs:582
    wez#5  0x000055c465d010a6 in termwiz::terminal::unix::UnixTerminalWaker::wake (self=0x7ffe6bd32de0)
        at /home/quark/.cargo/git/checkouts/wezterm-6425bab852909cc8/ef1b836/termwiz/src/terminal/unix.rs:278
    wez#6  0x000055c465a6c64b in streampager::event::EventSender::send_unique (self=0x7ffe6bd32dd0, event=..., 
        unique=0x7ffe6bd32de8) at src/event.rs:66
    wez#7  0x000055c465a7e65a in streampager::display::start (term=..., term_caps=..., events=..., files=..., 
        error_files=..., progress=..., mode=streampager::config::FullScreenMode::Auto) at src/display.rs:295
    wez#8  0x000055c465a453a7 in streampager::Pager::run (self=...) at src/lib.rs:171
    wez#9  0x000055c465a0aced in sp::open_files (args=...) at src/bin/sp/main.rs:170
    wez#10 0x000055c465a08e4f in sp::main () at src/bin/sp/main.rs:25
wez pushed a commit that referenced this issue Jan 6, 2020
@quark-zju @wez
Make UnixTerminalWaker::wake non-blocking
6fdae9b 
I was running `hg log --config pager.pager=sp` and pressing space without
releasing it. After about 10k lines sp appears to deadlock. It seems sp uses a
single thread for both reading terminal events and sending wake events and it
sends too many wake events without reading the events.

Failing to write to the wake pipe due to EWOULDBLOCK does not seem to be a
problem - there are enough events in the pipe to wake up the other side.
Therefore let's just make wake_pipe_write nonblocking and treat EWOULDBLOCK as
a success.

Context: The stuck thread looks like:

    #0  0x00007f32671ee237 in write () from /usr/lib/libc.so.6
    #1  0x000055c466022823 in std::sys::unix::fd::FileDesc::write () at src/libstd/sys/unix/fd.rs:96
    #2  std::sys::unix::net::Socket::write () at src/libstd/sys/unix/net.rs:276
    #3  <&std::sys::unix::ext::net::UnixStream as std::io::Write>::write ()
        at src/libstd/sys/unix/ext/net.rs:597
    #4  <std::sys::unix::ext::net::UnixStream as std::io::Write>::write ()
        at src/libstd/sys/unix/ext/net.rs:582
    #5  0x000055c465d010a6 in termwiz::terminal::unix::UnixTerminalWaker::wake (self=0x7ffe6bd32de0)
        at /home/quark/.cargo/git/checkouts/wezterm-6425bab852909cc8/ef1b836/termwiz/src/terminal/unix.rs:278
    #6  0x000055c465a6c64b in streampager::event::EventSender::send_unique (self=0x7ffe6bd32dd0, event=..., 
        unique=0x7ffe6bd32de8) at src/event.rs:66
    #7  0x000055c465a7e65a in streampager::display::start (term=..., term_caps=..., events=..., files=..., 
        error_files=..., progress=..., mode=streampager::config::FullScreenMode::Auto) at src/display.rs:295
    #8  0x000055c465a453a7 in streampager::Pager::run (self=...) at src/lib.rs:171
    #9  0x000055c465a0aced in sp::open_files (args=...) at src/bin/sp/main.rs:170
    #10 0x000055c465a08e4f in sp::main () at src/bin/sp/main.rs:25
@wez wez removed the help wanted label May 8, 2020
@wez
Copy link
Owner Author

wez commented Feb 17, 2021

Having laid some groundwork for #489 I think the plan here is:

The GUI layer changes could be based on some options:

  • Behavior when the tab containing the pane with the bell has focus:
    • Visual bell "flash"
    • Bell noise / system alert
    • Toast notification
    • Nothing
  • Behavior when the tab containing the pane with the bell doesn't have focus:
    • Bell noise / system alert
    • Toast Notification
    • Nothing
    • Bounce icon in dock
    • Annotate tab title with a bell status symbol. Focusing the tab will clear that state (maybe after a configurable delay?)

Panes make it a bit awkward to indicate which pane has the bell state, not sure if we need to do something about that, given that we've gotten this far without anyone making a fuss about the bell doing nothing.

wez added a commit that referenced this issue Feb 19, 2021
@wez
term: plumb Bell through toast notification channel
651e536 
Per my comment: #3 (comment)

this routes the bell through to the GUI layer, where it currently
does nothing about it.
@wez wez mentioned this issue Aug 20, 2021
Closed
@bew bew mentioned this issue Sep 21, 2021
Closed
@valpackett
Copy link
Contributor

With a custom lua hook it would be possible for users to do anything, like hook up an actual physical bell over USB… :D

@ghost
Copy link

ghost commented Sep 21, 2021

With the reverse_video flag fixed for #904, you now have a way to quickly flash the screen.

wez added a commit that referenced this issue Sep 23, 2021
@wez
gui: new bell event for running lua when the bell is rung
2337c06 
This commit adjusts the the window event routing/queuing so that
a queued event can capture a pane_id other than the focused pane.

Since we only allow one queued instance of a given named event in a
window, a consequence of this is that multiple bell events coming
from different panes at the same time may race and the loser's
event will be dropped. We log a warning in that case.

refs: #3
wez added a commit that referenced this issue Sep 25, 2021
@wez
add visual bell
0c1ad71 
refs: #3
wez added a commit that referenced this issue Sep 25, 2021
@wez
gui: tweak visual bell for transparent and non-black backgrounds
3b2f7b8 
refs: #3
wez added a commit that referenced this issue Sep 26, 2021
@wez
add audible_bell config option
72cb110 
This allows using the system beep sound, currently only on macos.

refs: #3
wez added a commit that referenced this issue Sep 26, 2021
@wez
enable audible bell for X11
aefbab5 
refs: #3
wez added a commit that referenced this issue Sep 26, 2021
@wez
implement beeps for Windows
70ab5e7 
refs: #3
wez added a commit that referenced this issue Sep 27, 2021
@wez
docs: cross link the bell related configs
14fb432 
refs: #3
@wez wez closed this as completed Dec 10, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wez @valpackett