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

automatic italic/bold font style rule generation #6

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

automatic italic/bold font style rule generation #6

wez opened this issue Feb 25, 2018 · 1 comment
Labels
enhancement New feature or request

Comments

@wez
Copy link
Owner

wez commented Feb 25, 2018

Once #5 is done it would be good to evaluate this. The idea is that the user should only need to specify the base font and we'll auto-gen appropriate rules, because this sort of thing is a bit too boiler-platey and would be great to do automatically for a great first run experience:

font_size = 10
font = { fontconfig_pattern = "Operator Mono SSm Lig Medium" }

[[font_rules]]
italic = true
font = { fontconfig_pattern = "Operator Mono SSm Lig Medium:style=Italic" }

[[font_rules]]
italic = true
intensity = "Bold"
font = { fontconfig_pattern = "Operator Mono SSm Lig:style=Italic:weight=bold" }

[[font_rules]]
intensity = "Bold"
font = { fontconfig_pattern = "Operator Mono SSm Lig:style=Italic:weight=bold" }

[[font_rules]]
intensity = "Half"
font = { fontconfig_pattern = "Operator Mono SSm Lig Light" }
@wez wez added the enhancement New feature or request label Feb 25, 2018
@wez wez closed this as completed in 82164ba Mar 1, 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
@mostafaqanbaryan mostafaqanbaryan mentioned this issue May 24, 2022
Open
@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
1 participant
@wez