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

Unimpaired movements cause display to scroll unnecessarily #6177

Closed
rcorre opened this issue Mar 3, 2023 · 4 comments · Fixed by #6193
Closed

Unimpaired movements cause display to scroll unnecessarily #6177

rcorre opened this issue Mar 3, 2023 · 4 comments · Fixed by #6193
Labels
C-bug Category: This is a bug E-good-first-issue Call for participation: Issues suitable for new contributors E-has-instructions Call for participation: Has instructions for fixing the issue and opening a PR

Comments

@rcorre
Copy link
Contributor

rcorre commented Mar 3, 2023

Summary

Sometimes I want to jump to a nearby diagnostic, maybe even on the same line my cursor is currently on.
Sometimes this causes the display to scroll up or down, which is jarring.
If the diagnostic is already visible, we shouldn't scroll (except as needed to respect scrolloff).
Navigating to a diagnostic on the same line as the cursor certainly shouldn't scroll.

https://asciinema.org/a/1HAs9gPmEAaCrkpBJ2zSloC9X

Reproduction Steps

I tried this:

  1. hx example.cpp
  2. 40j
  3. ]d

I expected this to happen:
Cursor moves to diagnostic, display stays at same scroll level.

Instead, this happened:
Cursor moves to diagnostic, display scrolls down.

Helix log

~/.cache/helix/helix.log
please provide a copy of `~/.cache/helix/helix.log` here if possible, you may need to redact some of the lines
[helix.log](https://github.com/helix-editor/helix/files/10886882/helix.log)

Platform

Linux

Terminal Emulator

st 0.8.5

Helix Version

22.12-294-g6494fc1d

@rcorre rcorre added the C-bug Category: This is a bug label Mar 3, 2023
@pascalkuthe
Copy link
Member

This actually is on purpose as we manually call align_view (instead of just letting ensure_cursor_in_view handle it. The rational is that if you jump to a diagnostic then you want that to be in the center of the screen to see the context/what is going on.

That being said we are not consistent here (anything TS based or goto_next_change). Many other unimpaired motions do not center the view. CC @the-mikedavis what is the intended behavior here and do we want to make this configurable?

@the-mikedavis
Copy link
Member

Ah, this looks like an oversight by me in #4713. I agree with

If the diagnostic is already visible, we shouldn't scroll (except as needed to respect scrolloff).

I think that align_view was to make the goto_*_diag commands closer to the diagnostic picker. It makes sense for the diagnostic picker to center the view IMO but for these unimpaired commands it's jarring and inconsistent with the others as you say. I think we should remove the align_view calls 👍

@the-mikedavis the-mikedavis added the E-has-instructions Call for participation: Has instructions for fixing the issue and opening a PR label Mar 4, 2023
@the-mikedavis
Copy link
Member

(Plus you can accomplish the current behavior by using the align_view_center command after the goto_*_diag commands.)

@pascalkuthe pascalkuthe added the E-good-first-issue Call for participation: Issues suitable for new contributors label Mar 5, 2023
@the-mikedavis the-mikedavis linked a pull request Mar 5, 2023 that will close this issue
the-mikedavis pushed a commit that referenced this issue Mar 5, 2023
Remove `align_view` calls from `goto_*_diag` as per issue #6177
@archseer
Copy link
Member

archseer commented Mar 6, 2023

Shouldn't we actually use the same code we use for jumping to search results? ensure_cursor_in_view_center: center if offscreen, but not if it's on the same screen

wes-adams pushed a commit to wes-adams/helix that referenced this issue Jul 4, 2023
Remove `align_view` calls from `goto_*_diag` as per issue helix-editor#6177
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug E-good-first-issue Call for participation: Issues suitable for new contributors E-has-instructions Call for participation: Has instructions for fixing the issue and opening a PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants