Using Gvim with Athena GUI,
See how a small gap is left behind at the right edge of the window. The gap goes away if I restore and maximize the window again.
The text area spans the whole width of the screen, leaving no gaps behind where a character could fit.
8.2.4298
OS: Artix
Terminal: Gvim
$TERM: rxvt-unicode-256color
Shell: Bash
No response
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
Is there a specific reason you use the Athena version? It's very basic. Most users will use the GTK version. Not sure it's worth improving the Athena version.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
Yes. The main reason is the scrollbar — I would use normal vim if it had one —, which can be customized via X-resources in almost all its aspects. GTK gvim, on the other hand, uses my GTK theme, whose scrollbar is light (doesn't blend well with my dark theme) and too wide.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
There was the same issue in Windows and it was fixed in 8.2.1228.
If gui_mch_get_scrollbar_xpadding() and gui_mch_get_scrollbar_ypadding() are implemented, the issue will be fixed.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
@k-takata Thanks, but my issue is not about the scrollbar not being flushed to the window edge, but rather the gap left behind (marked in red) being larger than it should be, such that it steals away some character cells. In other words, the text area, instead of accommodating x characters, accommodates only x-1 or x-2.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
See the screenshots in #5602. It's the same.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
@k-takata In those screenshots, the gaps are not large enough to fit a character. This is the problem I'm reporting here.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
Is this fixed in 8.2.4320?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
Nope, it only changes the position between the scrollbar and the gap. The text area size is still miscalculated (in the sense that it does not fill the gap as much as possible).
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
@chrisbra this can be closed, at least until re-evaluated. The code was refactored somewhat in dd40b1a
Thus this is no longer tracking current state.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Thanks, closing then
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()