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

Changing cells within the selection should clear the selection range #9

Closed
wez opened this issue Feb 25, 2018 · 1 comment
Closed

Changing cells within the selection should clear the selection range #9

wez opened this issue Feb 25, 2018 · 1 comment

Comments

@wez
Copy link
Owner

wez commented Feb 25, 2018

This is a UI artifacts issue that typically manifest with alt-screen apps.
If you have selected some text and then switch to a different tmux tab, the selection should be cleared, but isn't.
@wez wez closed this as completed in f3149a5 Feb 28, 2018
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
@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
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@wez