wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.72k stars 793 forks source link

Trackpad scrolling with less causes screen blinking #4186

Open Ray-Eldath opened 1 year ago

Ray-Eldath commented 1 year ago

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

20230822-233408-c91e124f

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

When using trackpad to scroll a lengthy file opened in less -FR, the view is blinking, sometimes turns completely blank:

https://github.com/wez/wezterm/assets/7938763/3c98e5bc-bdba-4d81-975a-7409d55831c7

This only happens when the file exceeds the screen width horizontally. My guess is that when scrolling using trackpad, somehow the cursor stays at the very end of the line where there's no character (as pointed out by @arkbriar), causing the screen to be blank.

I've verified in the same setting, using mouse to scroll doesn't lead to this. the MacOS-built-in Terminal.app also doesn't show such behaviour.

To Reproduce

No response

Configuration

I do have a config file, but my guess is they are irrelevant.

local wezterm = require 'wezterm'
local act = wezterm.action
local config = {}

config.default_prog = { '/opt/homebrew/bin/fish' }
config.default_domain = 'SSH:dev'
config.font = wezterm.font 'Cascadia Code PL'
config.font_size = 16.0
config.color_scheme = 'Unikitty Light (base16)'
config.use_fancy_tab_bar = false
config.tab_bar_at_bottom = false
config.audible_bell = 'Disabled'
config.window_close_confirmation = 'NeverPrompt'
config.keys = {
  { key = 'LeftArrow', mods = 'SHIFT', action = act.ActivateTabRelative(-1) },
  { key = 'RightArrow', mods = 'SHIFT', action = act.ActivateTabRelative(1) },
  { key = '%', mods = 'SUPER|SHIFT', action = act.SplitVertical },
  { key = '"', mods = 'SUPER|SHIFT', action = act.SplitHorizontal },
  { key = 'w', mods = 'CMD', action = act.CloseCurrentPane { confirm = true } },
  { key = 't', mods = 'CMD|SHIFT', action = act.ShowLauncher },
  { key = 'LeftArrow', mods = 'SUPER|SHIFT', action = act.ActivatePaneDirection 'Left' },
  { key = 'RightArrow', mods = 'SUPER|SHIFT', action = act.ActivatePaneDirection 'Right' },
  { key = 'UpArrow', mods = 'SUPER|SHIFT', action = act.ActivatePaneDirection 'Up' },
  { key = 'DownArrow', mods = 'SUPER|SHIFT', action = act.ActivatePaneDirection 'Down' },
}

local TAG_BG_COLOR = '#F7F5F2'
config.colors = {
  tab_bar = {
    -- The color of the strip that goes along the top of the window
    -- (does not apply when fancy tab bar is in use)
    background = TAG_BG_COLOR,

    -- The active tab is the one that has focus in the window
    active_tab = {
      bg_color = '#F0F0F0',
      fg_color = '#3C486B',
      intensity = 'Bold',
    },

    inactive_tab = {
      bg_color = TAG_BG_COLOR,
      fg_color = '#909090',
    },

    inactive_tab_hover = {
      bg_color = TAG_BG_COLOR,
      fg_color = '#808080',
      italic = true,
    },

    -- The new tab button that let you create new tabs
    new_tab = {
      bg_color = TAG_BG_COLOR,
      fg_color = '#909090',
    },

    new_tab_hover = {
      bg_color = TAG_BG_COLOR,
      fg_color = '#808080',
      italic = true,
    },
  },
}

return config

Expected Behavior

No response

Logs

No response

Anything else?

No response

arkbriar commented 11 months ago

I also encountered the same issue. Any idea how to fix it?

arkbriar commented 11 months ago

Damn, I probably know why... Try less -N @Ray-Eldath and you will find the line numbers will always be there. And I found the less in wezterm reacts to trackpad event of moving left/right and that is why the screen sometimes blinks or even becomes blank completely. This doesn't happen in iTerm2.

I believe wezterm just gets things right by wiring the events but it was quite confusing when I first saw it. Is there any way to disable it?

arkbriar commented 11 months ago

FYI, the mouse event is Move which I found in the debug logs.

15:14:49.493  DEBUG  wezterm_gui::termwindow                > MouseEvent(MouseEvent { kind: Move, coords: (-52, 827), screen_coords: (5
57, 1093), mouse_buttons: NONE, modifiers: NONE })
Ray-Eldath commented 11 months ago

I also encountered the same issue. Any idea how to fix it?

this problem persists and my fix is to stop using less -FR and turn to vim w/ soft wrap. sorry.

arkbriar commented 11 months ago

I also encountered the same issue. Any idea how to fix it?

this problem persists and my fix is to stop using less -FR and turn to vim w/ soft wrap. sorry.

Hey, thanks for sharing. I mean that it might not be an actual issue. Take a look at my comments above and try less -N. The line numbers always exist which means the screen isn't actual blank. It's just showing the right part of the file where there's no character.

Ray-Eldath commented 11 months ago

The line numbers always exist which means the screen isn't actual blank. It's just showing the right part of the file where there's no character.

Yes. this's in align with my guess. actually it's already posted in the desc of this issue. I may not express it accurately:

This only happens when the file exceeds the screen width horizontally. My guess is that when scrolling using trackpad, somehow the cursor stays at the very end of the line, causing the screen to be blank.

I've reword the description to clarify.

anyway this is still causing inconvenience. maybe wez shouldn't respond to trackpad left / right events. also I'm not sure why other terminals don't have this issue. maybe they just don't respond to them, maybe they have other clever tricks.

arkbriar commented 11 months ago

I've reword the description to clarify.

Thanks for the clarification.

This only happens when the file exceeds the screen width horizontally.

Based on my previous observation, I think this is not true. I once opened a file where there's only one character x in each line and I could still reproduce it. Somehow I feel the less is overreacting.

anyway this is still causing inconvenience.

Totally agree! I'm now using emacs to open files instead :(