[vim/vim] Add 'rightmargin' window option (PR #20754)

11 views
Skip to first unread message

Sergey Vlasov

unread,
7:19 AM (14 hours ago) 7:19 AM
to vim/vim, Subscribed

Problem: Cannot create empty space on the right side of the window.
Solution: Add 'rightmargin' window option.

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/20754

Commit Summary

  • 29621df add 'rightmargin' window option

File Changes

(51 files)

Patch Links:

—
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.Message ID: <vim/vim/pull/20754@github.com>

zeertzjq

unread,
7:31 AM (13 hours ago) 7:31 AM
to vim/vim, Subscribed
zeertzjq left a comment (vim/vim#20754)

I don't think 'rightmargin' is a good name for this option, considering that it's shown on the left when 'rightleft' is set.

—
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.Message ID: <vim/vim/pull/20754/c4951010649@github.com>

Sergey Vlasov

unread,
7:37 AM (13 hours ago) 7:37 AM
to vim/vim, Subscribed
noscript left a comment (vim/vim#20754)

'rightleft' is mirroring almost everything, it is kind of expected that right and left semantics is also swapped.

But I'm fine to rename it. Maybe 'sidemargin'?

—
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.Message ID: <vim/vim/pull/20754/c4951027166@github.com>

zeertzjq

unread,
7:42 AM (13 hours ago) 7:42 AM
to vim/vim, Subscribed
zeertzjq left a comment (vim/vim#20754)

Hmm, actually it's probably fine...

—
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.Message ID: <vim/vim/pull/20754/c4951043121@github.com>

h_east

unread,
1:18 PM (8 hours ago) 1:18 PM
to vim/vim, Subscribed
h-east left a comment (vim/vim#20754)

Before going into the details, I would like to settle whether this option is
worth adding at all.

The motivation in the PR is thin ("cannot create empty space on the right").
The realistic use cases seem decorative and niche: visual breathing room on
ultra-wide monitors in full screen mode, presentations/screencasts, or
reserving a right strip for future floating content.

Most of these are already achievable: an empty ":vnew" + 'winfixwidth' window
(at the cost of a separator), narrowing 'columns', or the spare space of
'signcolumn' / 'statuscolumn' / 'foldcolumn'. This option really only fills the
narrow gap of "a pure empty column with no separator".

The cost is not small: the wp->w_width -> W_WIDTH_INNER sweep (~60 sites) lands
permanently in hot drawing paths (win_line and friends), every future change to
width logic must then account for rmar, and the interaction surface with
rightleft, textprops, smoothscroll and folds is wide (the test file is already
1828 lines). That is a lasting maintenance cost for a low-demand feature.

Also, since the margin is just empty space, there is no visual cue that
'rightmargin' is set, so its state is hard to tell at a glance (an empty
vertical split at least shows a separator).

Could you share the concrete use case, and why an empty vertical split (or the
alternatives above) is not enough?

—
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.Message ID: <vim/vim/pull/20754/c4952065725@github.com>

Sergey Vlasov

unread,
5:33 PM (3 hours ago) 5:33 PM
to vim/vim, Subscribed
noscript left a comment (vim/vim#20754)

or reserving a right strip for future floating content

Yes, exactly that. The goal is to be able to create side panels with popups or images per split that do not cover the text, like custom scroll bars with rich markings or minimaps.

Most of these are already achievable: an empty ":vnew" + 'winfixwidth' window (at the cost of a separator), narrowing 'columns'

I would not consider this approach quite usable. Creating spacer windows requires a lot of hacks, just a few that come to mind immediately:

  • Avoid accidental spacer window getting focus due to closing other windows.
  • Jumping with wincmd h/j/k/l/etc. Such spacer windows will have to be skipped when and also direction of jump also must be taken into account.
  • Moving windows with wincmd H/J/K/L/etc. Spacer windows will have to follow its window.
  • 'winfixwidth' is only about CTRL-W_=, it does not prevent window resizing either by mouse and will not keep fixed width when resizing adjacent windows.
  • Interference with winrestcmd()/winrestview() and restoring after :mksession.
  • Filtering spacer windows when iterating over other windows in plugins.
  • Interference with other plugins.

or the spare space of 'signcolumn' / 'statuscolumn' / 'foldcolumn'.

These are only applicable for creating space on the left side of the window.

(ADD:
Also, by positioning the tabpanel on the right side, you can create a margin on the right.
vim +"set stpl=2 tplo=align:right,columns:10"
)

I have not used tabpanel feature before, but at least this snippet creates a full height empty space across all splits. My feature is about having space per split. Maybe it is possible to create per vim split space with tabpanel, I would need to try it.

The cost is not small: the wp->w_width -> W_WIDTH_INNER sweep (~60 sites) lands
permanently in hot drawing paths (win_line and friends), every future change to
width logic must then account for rmar, and the interaction surface with
rightleft, textprops, smoothscroll and folds is wide (the test file is already
1828 lines). That is a lasting maintenance cost for a low-demand feature.

If I drop MAX macro and cover the cases where MAX needed separately, the cost can be nearly zero. It is just an extra subtraction in most cases, including win_line(). I can think that we can have a separate field in window_S for inner width without relying on macro, that it will be truly zero cost.

The changes indeed touch a lot of places, but I tried to make the logic it simple, simply subtract margin from window width. The worst case scenario I see with maintenance is that rmar feature was not accounted and wp->w_width was used instead of W_WIDTH_INNER(wp). In this case it is only rmar feature that breaks, nothing else.

I also agree the number of tests is large, I poured by blood and tears over the course of almost a year of work to get it all covered. It would be hard to get them any smaller and still keep them easily digestible and maintain 100% code coverage.

Also, since the margin is just empty space, there is no visual cue that
'rightmargin' is set, so its state is hard to tell at a glance (an empty
vertical split at least shows a separator).

I agree. I think we can have a new highlight group for that.

—
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.Message ID: <vim/vim/pull/20754/c4952853639@github.com>

h_east

unread,
6:22 PM (3 hours ago) 6:22 PM
to vim/vim, Subscribed
h-east left a comment (vim/vim#20754)

I would like you to clarify the use case a bit more.
At the moment, the only stated goal is "creating a margin on the right side of the window," but there is insufficient explanation regarding how this would actually be beneficial.
It also seems that consistency with existing features has not been considered.

Furthermore, I am neither criticizing the large number of tests nor arguing that the number of tests should be reduced.
A large number of tests indicates a significant impact on existing functionality and entails ongoing maintenance costs; my point is simply to question whether the feature justifies bearing that burden.

—
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.Message ID: <vim/vim/pull/20754/c4953003572@github.com>

Sergey Vlasov

unread,
7:10 PM (2 hours ago) 7:10 PM
to vim/vim, Subscribed
noscript left a comment (vim/vim#20754)

This is a bit artificial and too busy example, but it is a good approximation of how I work daily. I have custom scrollbars with markers for git signs, search occurrences and more. This can be achieved with popup images today, but I use a different approach based on x11 compositing overlays I developed some years ago.

image.png (view on web)

Minimap is a gimmick for demo purpose. I have not built more features in fear of this not being accepted, but there are many other cases for this to be useful, like vertical tool bars.

Without being able to create a margin on the right side, I have sacrifice text observably. I am not able to see the line fully or that it extends. I have to constantly scroll horizontally back and forth to make sure I see it all. Even if I enabled 'wrap', the text still is covered by my custom UI. Is was always a major inconvenience.

—
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.Message ID: <vim/vim/pull/20754/c4953146762@github.com>

h_east

unread,
8:31 PM (29 minutes ago) 8:31 PM
to vim/vim, Subscribed
h-east left a comment (vim/vim#20754)

You are making too big a leap in logic.
Please provide a "specification-level" explanation of how to implement that image layout.

—
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.Message ID: <vim/vim/pull/20754/c4953420498@github.com>

Reply all
Reply to author
Forward
0 new messages