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.

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

Bell event triggers too much #5985

Closed
gramedek opened this issue Aug 18, 2024 · 2 comments
Closed

Bell event triggers too much #5985

gramedek opened this issue Aug 18, 2024 · 2 comments
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. Stale waiting-on-op Waiting for more information from the original poster

Comments

@gramedek
Copy link

gramedek commented Aug 18, 2024

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

X11 with AwesomeWM as window manager

WezTerm version

20240812.215703.30345b36

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Whenever a BEL character is being printed ('\a' / '\007' / '\x07'), the bells rings multiple times, I noticed it rings the exact same amount of times as the count of opened wezterm windows.

To Reproduce

  • open wezterm
  • run printf "\a"

Configuration

no config

Expected Behavior

The bell only rings once.

Logs

Debug Overlay
wezterm version: 20240812-215703-30345b36 x86_64-unknown-linux-gnu
Window Environment: X11 awesome
Lua Version: Lua 5.4
OpenGL: Mesa Intel(R) Graphics (ADL GT2) 4.6 (Compatibility Profile) Mesa 24.1.5-arch1.1
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
03:07:50.080 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
03:07:50.114 INFO logging > lua: the bell was rung in pane 42 in window 27!
03:07:50.114 INFO logging > lua: the bell was rung in pane 42 in window 29!
03:07:50.115 INFO logging > lua: the bell was rung in pane 42 in window 28!
03:07:50.115 INFO logging > lua: the bell was rung in pane 42 in window 0!
03:07:50.116 INFO logging > lua: the bell was rung in pane 42 in window 25!
03:07:50.117 INFO logging > lua: the bell was rung in pane 42 in window 26!
03:07:50.117 INFO logging > lua: the bell was rung in pane 42 in window 30!

Anything else?

I added the following to log the bell occurrences, but the problem is the same whether or not I have a config file:

wezterm.on('bell', function(window, pane)
	_, _ = window, pane;
	wezterm.log_info(
		'the bell was rung in pane '
		.. pane:pane_id()
		.. ' in window '
		.. window:window_id()
		.. '!'
	);
end);

The problem isn't the audible bell, but the actual bell event, because both trigger the same amount of times.

My current workaround is to disable the builtin bell, and manually run the xkbbell command to trigger the X11 bell, but only if the window id is 0 (to avoid triggering multiple times):

wezterm.on('bell', function(window, pane)
	_, _ = window, pane;
	if (window:window_id() <= 0) then
		wezterm.background_child_process({
			'xkbbell'
		});
	end;
end);
@gramedek gramedek added the bug Something isn't working label Aug 18, 2024
loops added a commit to loops/wezterm that referenced this issue Aug 22, 2024
As per the comment in mod.rs, bell events are sent to
all windows; not just the window containing the pane
which generated the event.

To prevent each bell ringing multiple times, the window
event handler must check if it has the pane, and ignore
the bell event if it doesn't.

This fixes bug wez#5985
wez pushed a commit that referenced this issue Sep 14, 2024
* Restrict bell events to the proper window.

As per the comment in mod.rs, bell events are sent to
all windows; not just the window containing the pane
which generated the event.

To prevent each bell ringing multiple times, the window
event handler must check if it has the pane, and ignore
the bell event if it doesn't.

This fixes bug #5985

Co-authored-by: Sean Estabrooks <sean.estabrooks@eztux.com>
@wez
Copy link
Owner

wez commented Sep 15, 2024

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

@wez wez added fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. waiting-on-op Waiting for more information from the original poster labels Sep 15, 2024
@github-actions github-actions bot added the Stale label Sep 29, 2024
Copy link
Contributor

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. Stale waiting-on-op Waiting for more information from the original poster
Projects
None yet
Development

No branches or pull requests

2 participants