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

Text renders underneath bottom border until window resize. #3333

Closed
davidspry opened this issue Mar 23, 2023 · 4 comments
Closed

Text renders underneath bottom border until window resize. #3333

davidspry opened this issue Mar 23, 2023 · 4 comments
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.

Comments

@davidspry
Copy link

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

macOS

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

No response

WezTerm version

20230320-124340-559cb7b0

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

Text renders underneath the bottom border until the window is resized. It looks as though the bottom border isn't accounted for until a window-resize occurs.

Here's an example using borders on each side:

  1. Prior to resizing the window (the cursor is underneath the bottom border):
    Screenshot 2023-03-23 at 7 00 35 pm

  2. After resizing the window:
    Screenshot 2023-03-23 at 7 00 45 pm

Here's another example using only the bottom border:

  1. Prior to resizing the window:
    Screenshot 2023-03-23 at 7 05 36 pm

  2. After resizing the window:
    Screenshot 2023-03-23 at 7 05 39 pm

Here's a third example, using a minimal config (specifying only the border size, the border colour, and the window padding):

  1. Prior to resizing the window:
    Screenshot 2023-03-23 at 7 13 00 pm

  2. After resizing the window:
    Screenshot 2023-03-23 at 7 13 05 pm

To Reproduce

The steps required to reproduce this are:

  1. Specify a bottom border in the config file. This is the config that I used in the 'minimal' example above:
local wezterm = require 'wezterm'

return {
  window_frame = {
    border_left_width = '1cell',
    border_right_width = '1cell',
    border_bottom_height = '0.5cell',
    border_top_height = '0.5cell',
    
    border_left_color = '#444',
    border_right_color = '#444',
    border_bottom_color = '#444',
    border_top_color = '#444',
  },

  window_padding = {
    left = '1.5cell',
    right = '1.5cell',
    top = '0.5cell',
    bottom = '0.5cell',
  },
}

Configuration

local wezterm = require 'wezterm'

return {
  window_frame = {
    border_left_width = '1cell',
    border_right_width = '1cell',
    border_bottom_height = '0.5cell',
    border_top_height = '0.5cell',
    
    border_left_color = '#444',
    border_right_color = '#444',
    border_bottom_color = '#444',
    border_top_color = '#444',
  },

  window_padding = {
    left = '1.5cell',
    right = '1.5cell',
    top = '0.5cell',
    bottom = '0.5cell',
  },
}

Expected Behavior

I expected the bottom border to be accounted for when positioning the text (without needing to resize the window first).

Logs

No response

Anything else?

No response

@davidspry davidspry added the bug Something isn't working label Mar 23, 2023
wez added a commit that referenced this issue Mar 23, 2023
This one was a bit weird because something appeared to be a bit
non-deterministic.  With this config:

```lua
local wezterm = require 'wezterm'

return {
  window_frame = {
    border_left_width = '1cell',
    border_right_width = '1cell',
    border_bottom_height = '0.5cell',
    border_top_height = '0.5cell',

    border_left_color = '#444',
    border_right_color = '#444',
    border_bottom_color = '#444',
    border_top_color = '#444',
  },

  window_padding = {
    left = '1.5cell',
    right = '1.5cell',
    top = '0.5cell',
    bottom = '0.5cell',
  },
}
```

starting wezterm could result in a terminal that reported either 23 or
24 lines. I got 24 when running the build from da7e29d but usually
23 when running a build out of my repo.

Looking closely, the issue is that the initial window size didn't
account for the configured border size, and that we'd subsequently
fix that up when we later do a resize fixup after creating the window.

This commit refactors the window border logic so that it can be
used prior to having fully constructed the terminal window and then
uses that to fixup the initial computed dimensions.

I also noticed with this config that increasing the font size
with CTRL-+ could also result in an inconsistency between the displayed
terminal size and the pty size we set in the kernel: it was missing
the border adjustment as well, so I added it in there.

refs: #3333
@wez
Copy link
Owner

wez commented Mar 23, 2023

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 the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Mar 23, 2023
@wez
Copy link
Owner

wez commented Mar 23, 2023

Thank you for the detailed report! It made it easy to understand and figure out!

@davidspry
Copy link
Author

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.

It works perfectly in the nightly build. Thanks!

@github-actions
Copy link
Contributor

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 Apr 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.
Projects
None yet
Development

No branches or pull requests

2 participants