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

Support scrolloff with mouse actions #611

Closed
wants to merge 1 commit into from

Conversation

dsseng
Copy link
Contributor

@dsseng dsseng commented Aug 18, 2021

Now clicking will ensure cursor is not on bound of screen and when you drag near the bound of screen view will scroll keeping your selection.

Related: is https://github.com/helix-editor/helix/blob/master/helix-term/src/commands.rs#L926 really required? (maybe should be optional). It would be great to select and not lose selection when scrolling.

@pickfire
Copy link
Contributor

I think it's quite hacky since it doesn't always scroll unless you jiggle your mouse.

I need to move my mouse left and right or up and down for this to work in konsole.

@dsseng
Copy link
Contributor Author

dsseng commented Aug 18, 2021

No problem in GNOME Terminal. Could you record an asciinema or screencast? Code doesn't look hacky: we need to move view according to cursor position and do that. I hope I understood that fn correctly

Edit: but I need the same stuff in WezTerm. Move mouse up&down
Edit: double-checked, ideal in GNOME Terminal 🤷

@@ -815,6 +820,7 @@ impl EditorView {
..
} => {
let (view, doc) = current!(cxt.editor);
view.ensure_cursor_in_view(doc, cxt.editor.config.scrolloff);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might need to be sorta recursive: even if cursor stays in place, scroll unless cursor is moved away from scrolloff area

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw that bug is caused by the following behavior difference:

  1. VTE sends drag events on one-pixel movements that are frequent when holding mouse, even though mouse doesn't move to different character place in terminal
  2. Konsole and WezTerm, on the other hand, send drag events only when mouse moves from one character place to another

@cessen
Copy link
Contributor

cessen commented Aug 18, 2021

If we're going to support this, then I think we'll want something that tracks the last reported location of the mouse, so if the mouse is still held down we can keep scrolling as appropriate.

Having said that, this makes me wonder what kind of corner-cases we'll run into. If the mouse leaves the window, does it report a mouse-up event? How consistent is that between terminal emulators? Etc.

I definitely like the feature, though. But let's make sure we cover our bases to get a consistent experience across terminals, to the extent that's reasonably possible.

@pickfire
Copy link
Contributor

@sh7dm Can you please help to try it out in konsole?

@dsseng
Copy link
Contributor Author

dsseng commented Aug 20, 2021

I don't really know how to (where exactly) loop that action. Maybe spawn a new tokio thread?

@the-mikedavis the-mikedavis added the S-waiting-on-review Status: Awaiting review from a maintainer. label May 18, 2022
@kirawi kirawi added the A-helix-term Area: Helix term improvements label Sep 13, 2022
@pascalkuthe
Copy link
Member

I just noticed that this has already been addressed with #5255

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-helix-term Area: Helix term improvements S-waiting-on-review Status: Awaiting review from a maintainer.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants