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

Exiting search mode doesn't leave the currently selected text selected, scrolls back to prompt #3502

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

Comments

@LeszekSwirski
Copy link
Contributor

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

Linux X11

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

i3

WezTerm version

20230408-112425-69ae8472 / nightly: 20230410-204717-fa0f538d

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

According to https://wezfurlong.org/wezterm/scrollback.html#searching-the-scrollback, exiting search mode with Escape should leave the scrollback scrolled to the selected text. However, since search mode became a facet of copy mode, Escape performs act.CopyMode 'Close', which scrolls back to the prompt, and there's no Close equivalent which leaves the scrollback alone.

Search mode was broken on nightly so I didn't confirm there.

To Reproduce

  • Have text out of view in scroll back
  • Search it with search mode (ctrl-shift-F)
  • Exit search mode (esc)

Configuration

no config

Expected Behavior

Scrollback should stay scrolled.

Logs

No response

Anything else?

No response

@LeszekSwirski LeszekSwirski added the bug Something isn't working label Apr 11, 2023
@aorith
Copy link

aorith commented Apr 17, 2023

Testing this with an empty config (Linux X11):

Works:

  • 20220408-101518-b908e2dd

Doesn't work:

  • 20220624-141144-bd1b7c5d
  • 20220807-113146-c2fee766
  • 20220903-194523-3bb1ed61
  • 20220905-102802-7d4b8249

@LeszekSwirski
Copy link
Contributor Author

That lines up with search mode being merged into copy mode (2710cef, May 5 2022).

@LeszekSwirski
Copy link
Contributor Author

Looking at that commit, search mode's close method just calls schedule_cancel_overlay_for_pane, while copy mode's close method also calls set_viewport(None). Probably there should be a separate CloseWithoutClearingPosition or similar.

@LeszekSwirski
Copy link
Contributor Author

Yeah, adding something like that locally fixes it for me.

@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Jul 22, 2024
@wez wez closed this as completed Jul 22, 2024
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 Aug 22, 2024
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

3 participants