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
Add ability for pixel by pixel scroll in GUI apps #5154
Comments
Arseny Nasokin wrote:
**Is your feature request related something that is currently hard to do? Please describe.**
There's no way to make pixel by pixel scroll in GUI version just because of how Vim is working.
The screen is logically divided into a part with a text and a part with a status line. GUI apps are just emulating terminals which provide a number of lines and columns. Extending in both ways by amount of pixels less than one symbol is not possible.
This will produce much better user experience than extending window only by font size.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
Vim will have two sets of parameters: full lines/columns as before, and a flag if window can show a partially visible line/column used for text and syntax highlighting and scripts.
so text will be processed with higher number (when the visible lines/column are wider than divided) and partially rendered (cut out) if needed.
and status line will be rendered with only fully visible lines and status line background will be "prolonged" if number of columns is higher.
**Describe alternatives you've considered**
1) If GUI tells that it has one more column, not only text will be extended, but status line too and it won't look nice. And if GUI tells it has one more line, only status line will be cut, which is not an option for a user
2) GUI may try to cut-off pixels of text but status line. However, it's too much work and it'll be much slower than if it'll be provided by GUI. This _could_ be done without changing Vim but with great slowdown.
**Additional context**
Add any other context or screenshots about the feature request here.
Many GUI editors support this feature and implementation of this in the kernel will provide better UX for GUI versions of ViM.
This feature will be great for GVim for Linux, Windows and MacOS.
Related feature was registered for MacVim years ago: macvim-dev/macvim#273 and prevents to implement some features in better ways like better scroll bars (which are narrower than a font height and width).
We should first look into scrolling per screen line. That is also
useful in a terminal with very long lines.
…--
Shift happens.
-- Doppler
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
I thought of this and saw it at the top of the issues list here. Hoping I understand correctly that the idea proposed is "smoother" scrolling essentially, instead of the current choppy line-by-line scrolling. I just wanted to add that Gnome-terminal seems to have pixel-by-pixel scrolling so I was wondering if this feature, were it implemented in future, would work inside a terminal where the functionality is already present. |
I haven't seen Linux terminals with that because many programs counts on the fixed amount of lines and columns to show information, and |
When I scroll using the touchpad in gnome-terminal buffer, it scrolls by pixel and not by line - similar to atom or web browser. As you say, the apps running in terminal don't do this. |
@forgetmenotz But for graphical UI it's important to have pixel-by-pixel scroll, and I don't see any other good implementation rather than change the core. |
Note that the 'smoothscroll' option has been added. It allows for scrolling by screen line. |
What is the current status on this? You mentioned bugs needed to be fixed, any ETA? I downloaded latest version from Github page, turned on the option and nothing changes. Using gvim on windows 10. |
no ETA. and smoothscroll still has some bugs. |
Is your feature request related something that is currently hard to do? Please describe.
There's no way to make pixel by pixel scroll in GUI version just because of how Vim is working.
The screen is logically divided into a part with a text and a part with a status line. GUI apps are just emulating terminals which provide a number of lines and columns. Extending in both ways by amount of pixels less than one symbol is not possible.
This will produce much better user experience than extending window only by font size.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Vim will have two sets of parameters: full lines/columns as before, and a flag if window can show a partially visible line/column used for text and syntax highlighting and scripts.
so text will be processed with higher number (when the visible lines/column are wider than divided) and partially rendered (cut out) if needed.
and status line will be rendered with only fully visible lines and status line background will be "prolonged" if number of columns is higher.
Describe alternatives you've considered
If GUI tells that it has one more column, not only text will be extended, but status line too and it won't look nice. And if GUI tells it has one more line, only status line will be cut, which is not an option for a user
GUI may try to cut-off pixels of text but status line. However, it's too much work and it'll be much slower than if it'll be provided by GUI. This could be done without changing Vim but with great slowdown.
Additional context
Add any other context or screenshots about the feature request here.
Many GUI editors support this feature and implementation of this in the kernel will provide better UX for GUI versions of ViM.
This feature will be great for GVim for Linux, Windows and MacOS.
Related feature was registered for MacVim years ago: macvim-dev/macvim#273 and prevents to implement some features in better ways like better scroll bars (which are narrower than a font height and width).
The text was updated successfully, but these errors were encountered: