Snap to character grid when resizing window

[mcpiroman]

Description of the new feature/enhancement

Snap to character grid when resizing window, like many terminals do (gnome-based, git terminal etc.). Questions:

• Make it a setting?
• If so. enable by default? (I'd say yes)

[mcpiroman]

Assigning myself if anyone cares

[zadjii-msft]

My biggest curiosity is how does this work with multiple panes open? Especially if the panes have different fonts or font sizes?

Otherwise yea, this seems like a good feature request

[mdtauk]

Could I argue for a small point. Not sure the feasibility of it. But part of the Window UI pattern is to display part of an item if there is scrolling. So could half of the line at the top be visible when there is scrolling supported?

[mcpiroman]

@zadjii-msft Exactly - that's the biggest and hopefully the only problem here. I suppose we should try to:

• keep all panes aligned
• snap to the closes cell when above is not possible
• maintain size ratio of splitted pane's children close to original one

That should be hard but possible.

[DHowett-MSFT]

This requires no small amount of care: it is trivially easy to break the win32 "move size loop" -- the one that handles snapping and window friction and not letting you size things under the taskbar and all that stuff. Be careful!

[egmontkob]

Other tricky cases are:

• Switching between tabs of different font sizes
• Changing font size of the current tab
• Letting a maximized or fullscreen window really be maximized/fullscreen, without forcing to the character grid.

GNOME Terminal aims to maintain a fixed number of character rows and columns, resulting in the overall window changing its size. It's a constant source of user complaints (many people wish the window to stay at a fixed size, as other apps do, and don't think about how it's incompatible with grid size), as well as a constant source of technical problems.

As a user, I love the terminal size being snapped to the grid, mainly for two reasons:

• Especially with apps that fill the entire terminal area with the nondefault background (such as Midnight Commander), seeing a random amount of gap at the bottom and right gives me an unsettling, frustrating feeling as it's really anything but pleasing to my eyes. I also have a constant urge with such terminals to manually resize to the grid, which – if I do so – wastes a lot of time.

• When editing a long command (that wraps into multiple lines), not knowing whether it's a space character on the right separating two words, or just an almost-a-cell-wide gap, does not let me know if there's actually a space character there or not. It's a potential source of every now and then not noticing typos, faulty commands.

The second problem could be fixed by having a gap that's of a different color than the terminal area, but it might look even uglier.

Yet another approach could be what the Kitty emulator does: cheat a little bit and distribute that extra space among some of the cells. Maybe even do subpixel letter positioning.

As a developer, though, maintaining a resize constraint is often a pain. Part of the story is the "how should it work", which you already started discussing and probably doesn't have clear answers; another part of it is technical problems (I could link to quite a few past or present bugs with GNOME Terminal, but it's sure quite different on Windows, so it wouldn't be useful for you).

Also there's some overlap between these two areas, e.g. (randomly made up example) you might have two panes next to each other, one with font width 9, the other with font width 10, and at a current window width of 800 pixels you might decide that if the user increases the width then you give a cell to the second pane, then one to the first, then another one to the first, i.e. you allow width of 800, 810, 819, 828 etc., whatever seemingly random sequence of numbers computed by the application. On Unix, the X Window system only allows a constant amount of increment (you have to preconfigure that the width is fixed_base + N * fixed_increment), and as far as I know, that's what GTK offers on Wayland too, so we're limited by our surrounding infrastructure. Maybe (hopefully) these limitations aren't there on Windows, I don't know.

[egmontkob]

But part of the Window UI pattern is to display part of an item if there is scrolling. So could half of the line at the top be visible when there is scrolling supported?

@mdtauk This is a great observation, and a really interesting question.

I've thought about it when implementing smooth scrolling in VTE. If you scroll back to the history using a touchpad, this scrolling happens per-pixel in VTE, rather than per-character-row as in most terminals.

I think there are two problems with your idea of showing a partial row at the top. One is that then the initial shell prompt would already have to be displayed with a "random" amount of gap above it, and it's probably confusing and ugly.

The other problem is that there are application that occupy the entire area of the terminal, and don't switch to the alternate screen. top is such an example, but quite a few text editors (e.g. vim) can also be configured so. These apps need to have a concept of the terminal size (rows × columns), and the only reasonable thing to do is to round the available area downwards to an integer. Which, in case of these applications, results in a partial row from a previous command's output (or the shell command line) getting stuck at the top. This would again definitely be misleading and confusing.

However, we can simply turn it "upside down", have that extra area at the bottom instead of the top. This solves both aforementioned problems, there's guaranteed not to be any data below the currently writable area. As soon as the user starts to scroll back, this area on the bottom can also be used to display contents, as done in a non-grid-aligned VTE (e.g. Tilix, or maximized/fullscreen GNOME Terminal).

[mcpiroman]

@egmontkob So, keeping the size aligned on various user actions is quite different thing than proposed 'simple' snapping during window resize; however I think we should (eventually) try to also do the former. The problem is that it cannot be done 'right' in many cases, we'd often have to either:

• (Slightly) resize the window (not possible with fullscreen)
• Increase (or maybe even decrease) configured padding
• Adjust cell spacing
• Otherwise gather/get rid of some space

And there are even more such tricky operations, like resizing panes. I guess that deserves its own issue-tracker entry. Here we could discuss how should it work just for the resizing part.

On Unix, the X Window system only allows a constant amount of increment (you have to preconfigure that the width is fixed_base + N * fixed_increment) [...] Maybe (hopefully) these limitations aren't there on Windows, I don't know.

Fortunately Window's system is much more flexible - for any user's input window rectangle a program can choose arbitrary output rectangle.

[egmontkob]

So, keeping the size aligned on various user actions is quite different thing than proposed 'simple' snapping during window resize; however I think we should (eventually) try to also do the former.

What I'm thinking of is that due to all these problematic cases, probably the best is to do some "best effort" snapping on certain user actions only. Starting with window resize, as you originally proposed, maybe only for when there are no panes?? Trickier cases might come later on.

With panes, I'm wondering if it makes sense to snap to sizes where at least one terminal that actually gets resized (along the relevant axes) resizes to an aligned size? With a truly complex pane layout it might behave silly in the end.

And there are even more such tricky operations, like resizing panes. I guess that deserves its own issue-tracker entry. Here we could discuss how should it work just for the resizing part.

Indeed, this one didn't occur to me. It's technically quite different than resizing the window, isn't it? Can you also specify for each input position the desired output position of the separator?

Fortunately Window's system is much more flexible - for any user's input window rectangle a program can choose arbitrary output rectangle.

Great to hear it!

It's an area where there's no single good solution, there's lots of possibilities to experiment with. I'll be curious to see what comes out of this story :)

[mcpiroman]

To these interested, you may follow the work at https://github.com/mcpiroman/terminal/tree/2834-snap-to-char-grid - it seems to work almost fine now but I'd like to know if there are cases I've missed or what can be done better. Like I said, the biggest and really only problem (yet) are the panes.

With panes, I'm wondering if it makes sense to snap to sizes where at least one terminal that actually gets resized (along the relevant axes) resizes to an aligned size?

Just want to let you know that you saved me quite a lot of time by saying this.

[ghost]

🎉This issue was addressed in #3181, which has now been successfully released as Windows Terminal Preview v0.8.10091.0.:tada:

Handy links:

• Release Notes
• Store Download