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

ctrl +/- to increase/decrease font size #2

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

ctrl +/- to increase/decrease font size #2

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

This will really be CTRL - to decrease and CTRL = to increase (because actually using + is two modifiers and awkward), and CTRL 0 to reset to the configured value.

The changes required are:

  • Introduce a current font size member variable to track what size we're at. The hotkeys can adjust by, say, 1pt increments. Maybe make that increment configurable? Should it be 10% instead of a fixed point size?
  • Allow that to override the base font size in the configuration
  • Probably just recreate the fontconfiguration when the font size is adjusted
  • Recreating the font configuration also needs to blow the glyph cache and texture atlas similar to the changes in 981d939
  • When the DPI scaling factor changes we should map that to a corresponding font size change
@wez wez added the enhancement New feature or request label Feb 25, 2018
wez added a commit that referenced this issue Feb 22, 2019
@wez
Adjust for high dpi displays with the glutin backend
89da009 
This results in a less blurry display.
As a bonus, this lays down some plumbing for changing the font
size on the fly.

Refs: #2
wez added a commit that referenced this issue Feb 22, 2019
@wez
ctrl|cmd +/- to manipulate font size with glutin backend
c818225 
Simliar code needs to be added to the x11 backend in a follow on
commit.

Refs: #2
@wez wez closed this as completed in 26d7ed9 Feb 23, 2019
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
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@wez