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

cli activate-pane-direction issues with ssh domain #3448

Closed
joshuarubin opened this issue Apr 4, 2023 · 3 comments
Closed

cli activate-pane-direction issues with ssh domain #3448

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

Comments

@joshuarubin
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

20230403-224617-8ddd0d98

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 connected to an ssh domain, my normal keycode relative pane activation works fine. However, if I use wezterm cli activate-pane-direction <DIR> it seems it can get confused under some circumstances and panes don't activate properly.

To Reproduce

  1. connect to an ssh domain
  2. open 2 panes side by side
  3. in the left pane, open vim
  4. in vim execute :!wezterm cli activate-pane-direction Right
  5. nothing happens
  6. in vim execute :!wezterm cli activate-pane-direction Left
  7. nothing happens
  8. in vim execute :!wezterm cli activate-pane-direction Right
  9. Right pane activates

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response

@joshuarubin joshuarubin added the bug Something isn't working label Apr 4, 2023
wez added a commit that referenced this issue Apr 5, 2023
Previously, we'd record the focused pane only in the per-client
view.

That status didn't propagate through the model fully, leading to
inconsistencies when using activate-pane-direction.

This commit does the full model update to force that through.
I may regret this later: the focus state was intended to be
a per-client attribute and this effectively prevents that
from ever being useful.

Maybe the per-client state should just be removed?
Will ponder that later.

refs: #3448
refs: #3387

Also sneaking in here is not updating the last input time
for a client unless the input was taken by a user.
@wez
Copy link
Owner

wez commented Apr 5, 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 Apr 5, 2023
@joshuarubin
Copy link
Author

Confirmed working, thanks for addressing this.

@wez wez closed this as completed Apr 7, 2023
@github-actions
Copy link

github-actions bot commented May 8, 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 May 8, 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