starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Snap to character grid when resizing window #3966

New Issue
Closed
opened 2026-01-30 23:34:28 +00:00 by claunia · 11 comments
claunia commented 2026-01-30 23:34:28 +00:00
Owner
Copy Link

Originally created by @mcpiroman on GitHub (Sep 21, 2019).

Originally assigned to: @mcpiroman on GitHub.

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)
Originally created by @mcpiroman on GitHub (Sep 21, 2019). Originally assigned to: @mcpiroman on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> 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)
claunia commented 2026-01-30 23:34:29 +00:00
Author
Owner
Copy Link

@mcpiroman commented on GitHub (Sep 22, 2019):

Assigning myself if anyone cares

@mcpiroman commented on GitHub (Sep 22, 2019): Assigning myself if anyone cares
claunia commented 2026-01-30 23:34:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 23, 2019):

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

@zadjii-msft commented on GitHub (Sep 23, 2019): 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
claunia commented 2026-01-30 23:34:29 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (Sep 23, 2019):

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?

@mdtauk commented on GitHub (Sep 23, 2019): 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?
claunia commented 2026-01-30 23:34:29 +00:00
Author
Owner
Copy Link

@mcpiroman commented on GitHub (Sep 23, 2019):

@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.

@mcpiroman commented on GitHub (Sep 23, 2019): @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.
claunia commented 2026-01-30 23:34:30 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Sep 23, 2019):

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!

@DHowett-MSFT commented on GitHub (Sep 23, 2019): 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!
claunia commented 2026-01-30 23:34:30 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Sep 27, 2019):

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 commented on GitHub (Sep 27, 2019): 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.
claunia commented 2026-01-30 23:34:30 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Sep 27, 2019):

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).

@egmontkob commented on GitHub (Sep 27, 2019): > 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](https://bugzilla.gnome.org/show_bug.cgi?id=746690), 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).
claunia commented 2026-01-30 23:34:30 +00:00
Author
Owner
Copy Link

@mcpiroman commented on GitHub (Sep 27, 2019):

@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.

@mcpiroman commented on GitHub (Sep 27, 2019): @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.
claunia commented 2026-01-30 23:34:30 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Sep 27, 2019):

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 :)

@egmontkob commented on GitHub (Sep 27, 2019): > 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 :)
claunia commented 2026-01-30 23:34:30 +00:00
Author
Owner
Copy Link

@mcpiroman commented on GitHub (Sep 28, 2019):

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.

@mcpiroman commented on GitHub (Sep 28, 2019): 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.
claunia commented 2026-01-30 23:34:31 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 14, 2020):

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

Handy links:

@ghost commented on GitHub (Jan 14, 2020): :tada: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](https://github.com/microsoft/terminal/releases/tag/v0.8.10091.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Issue-Task Needs-Tag-Fix Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#3966
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?