Fix minimum gutter line number spacing #18021
Open
+16
−3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I was studying how Zed did the layout in the editor, specifically for the gutter, and noticed that em_width * X is being used as the 'size of X consecutive' characters. Howevever, that math didn't work for me, because em_width doesn't account for the space between characters, so you can't just multiply it by a character count. One place this is actually noticeable is in the logic for `min_width_for_number_on_gutter`, where we try to reserve 4 characters of line number space. However, once you actually hit 4 characters, the actual size is bigger, causing things to resize. This seems clearly counter to the intent of the code. It seems the more correct logic is to use `em_advance` which accounts for the space between the characters. I am leaving the rest of the uses of `em_width` for generic padding. It is also possible that `column_pixels()` would be the more correct fix here, but it wasn't straightforward to use that due to it residing EditorElement source file. On my MacBook this increases the width of the gutter by 6 pixels when there are <999 lines in the file, otherwise it's identical. It might be worth doing some more general audit of some of the other uses of em_width as a concept. (e.g. `git_blame_entries_width`)
cla-bot
bot
added
the
cla-signed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was inspecting how Zed did the layout in the editor, specifically for the gutter, and noticed that
em_width * Xis being used as the 'width of X consecutive characters'. Howevever, that math didn't work for me, because em_width doesn't account for the space between characters, so you can't just multiply it by a character count.One place this is actually noticeable is in the logic for
min_width_for_number_on_gutter, where we try to reserve 4 characters of line number space. However, once you actually hit 4 characters, the actual width is bigger, causing things to resize. This seems clearly counter to the intent of the code.It seems the more correct logic is to use
em_advancewhich accounts for the space between the characters. I am leaving the rest of the uses ofem_widthfor generic padding. It is also possible thatcolumn_pixels()would be the more correct fix here, but it wasn't straightforward to use that due to it residing EditorElement source file.On my MacBook this increases the width of the gutter by 6 pixels when there are <999 lines in the file, otherwise it's identical.
It might be worth doing some more general audit of some of the other uses of em_width as a concept. (e.g.
git_blame_entries_width)zed-gutter-resize.mov
Release Notes: