Open shujaatak opened 2 years ago
One can see a similar issue with monaco-editor here https://github.com/microsoft/monaco-editor/issues/200.
As VS Code doesn't allow users to add custom CSS in it so a setting like editor.contentLeftPadding or built-in default padding for editor's content is required.
cc @roblourens . I think you also needed something like this in Notebooks? (I noticed a commit from you)
I added padding to the glyph margin (breakpoints) then removed it when we didn't need that option anymore. That wouldn't have helped here
Please note that I made this comment the part of the issue's description as it seems relevant.
For proof of concept, I added the following CSS code to the end of this CSS file /usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.css:
.monaco-editor .lines-content {
padding-left: 8px;
}
which produces the following neat and required result, such that, now neither I can't accidentally click on folding buttons nor the code touches the gutter:
But I noticed that unlike HTML textarea tag which allows a user to click in the padding area to place cursor at the start of the nearest line no matter how wide padding you set, in VS Code I can't place the cursor at the start of the line by clicking in the padding region which might be desirable by some users.
@alexdima Can you please somehow expedite the process to resolve this issue? Almost all code editors provide default feature to avoid the issues mentioned above but unfortunately vs code lacks this. We all would be so grateful to you if you please resolve this issue as soon as possible. By the way, I could have helped in resolving this but I don't know very well the internals of vs code.
There are already settings for editor.padding.top
and editor.padding.bottom
, so the setting should be editor.padding.left
and should result in the same amount of spacing as those do.
When can we get the function satisfifed ... have noticed so many similar issues been proposed !!
Echoing OP -- This would be great to have.
So much dead space here-- I don't need empty space in my editor. Please work on adding a way to reduce the gutter around the line numbers. I only need about 2-5 pixels on either side of the line number.
Currently I think there's about 25-30 pixels to the left of line number, and 15-20 to the right.
I'd like to have those 50 pixels available for useful space please. No need for empty, unused space. 😅 😜
In fact, it would be great if there was a "Concise Theme" or "Space Minimalism Theme" that removed as much empty space as possible across Tabs in the editor & terminal, the left & right-side gutters, etc.
Sidenote for anyone trying to reduce unnecessarily large Activity Bar space-- Check out the "Activitus Bar" extension.
Edit: This takes care of some of the issue by allowing me to re-claim pixels from the number bar.. However, it would be great if I could collapse it even more, to 1-2 pixels of gutter.
settings.json
{
"editor.glyphMargin": false,
"editor.folding": false,
}
Hoping for a solution soon :)
@pmeaney if you want less space in the gutter to the left of the line numbers, the ticket for that is https://github.com/microsoft/vscode/issues/93887 or https://github.com/microsoft/vscode/issues/30795
Also, FYI, you can currently reduce the space to the right of the line numbers by setting "editor.showFoldingControls": "never"
, and it looks like you have some other things enabled that are increasing the line decorations space (to the left of the line numbers) because mine is only 20px wide.
@alexdima @bpasero Waiting for a year and counting :yawning_face:
Just stumbled on this looking for this exact solution. Not sure why it's so difficult to get an answer, it's not like it's difficult to implement, as the preliminary work is already there for the padding top and bottom as previously said. Please can we get this implemented.
I am constantly accidently hitting the collapse button when trying to select code starting at the start of a line! Hope this gets implemented at some point. :)
Maybe it helps someone.
"editor.lineDecorationsWidth" : 100
"editor.glyphMargin": false,
It will put space between the line start and the line numbers/folding icon.
I have plenty of space between the folding icon and the line start. It helps me to avoid accidental clicks on folding.
Would love to see this implemented. "lineDecorationsWidth" gets my view part of the way there but a real margin would be a nice visual change.
So this "editor.padding.top": 5,
works but not "editor.padding.left": 5,
But this "editor.lineDecorationsWidth": 15,
works even with
"editor.folding": false,
"editor.lineNumbers": "off",
"editor.glyphMargin": false,
for now i'm using these settings
"editor.lineDecorationsWidth": 15,
"editor.padding.top": 10,
"editor.folding": false,
"editor.lineNumbers": "off",
"editor.glyphMargin": false,
I'm following up on @josevalim's comment in the Livebook thread just mentioned above. I'd like to suggest that there should be a way to make any additional padding clickable. This would make it easier to place the editing cursor (e.g., in Monaco) at the beginning of a line.
There is merely no space where the arrow point in VS code … A little bit more space makes the whole look much better and improves the coding experience for reducing the chance of unwanted folding behaviour, as in PyCharm (and other IDEs) Is it really that difficult to improve it? VSCode need to be more humble to learn from other editors with great reputation.
So is there really no solution for this? Is there an extension I could use or something? Even like 5 pixels of clickable text area to the left would make life so much easier.
This seems like a relatively simple feature with a big QOL benefit, but this issue has been open for two years now. There are several duplicate issues that have been closed to reference back to this one. I see @alexdima was assigned at one point, but then maybe unassigned? I can't really tell.
Alex, do you know if this is being actively worked on at all, or did this slip through the cracks somehow?
@pmeany I think part of the problem here is that we have two, almost contradictory issues bundled together. One issue is wanting to make the left gutter narrower, so that there is less wasted space, which you seem to have found a workable solution for.
The issue I'm concerned with is that I want an option to put more space to the left of the text, specifically space that I can still click with the text cursor, so that it is easier to select text to (or from) the beginning of a line.
IE: 5-10 pixels to the left of the start of each line, where if you click in those pixels, it puts the cursor at the beginning of that line (just to the right of where you clicked)
On Oct 3, 2023, at 16:33, dschil138 @.***> wrote:
... The issue I'm concerned with is that I want an option to put more space to the left of the text, specifically space that I can still click with the text cursor, so that it is easier to select text to (or from) the beginning of a line. IE: 5-10 pixels to the left of the start of each line, where if you click in those pixels, it puts the cursor at the beginning of that line (just to the right of where you clicked)
Yep. I'll even provide a WP quote...
Fitts's law (often cited as Fitts' law) is a predictive model of human movement primarily used in human–computer interaction and ergonomics. The law predicts that the time required to rapidly move to a target area is a function of the ratio between the distance to the target and the width of the target. Fitts's law is used to model the act of pointing, either by physically touching an object with a hand or finger, or virtually, by pointing to an object on a computer monitor using a pointing device. It was initially developed by Paul Fitts. ...
-- https://en.wikipedia.org/wiki/Fitts's_law
-r
Related on Stack Overflow:
Recently on Reddit: https://www.reddit.com/r/vscode/comments/176br36/is_there_any_way_to_adjust_the_autospacing_at_the/
Yeah there seems to be a lot of interest in this issue. Lots of people trying to give answers in all those threads but none of them actually do the thing: Give more clickable space before the first character of the line.
I want to second this idea. Moving from CLion to VSCode, this difference is one of the things that frustrates me the most. The missing editor padding from the gutter makes it less clear when reading unindented lines of code (i.e. function declarations etc.), especially when the gutter color is not the same as the editor background.
I second this one. The missing left padding is a very annoying thing.
Still nothing? This has been years, no?
It should not be difficult. The first change would be equivalent to adding
.monaco-editor .lines-content { padding-left: 8px; }
(or some configurable value) to "vs/workbench/workbench.desktop.main.css" – and then to make sure that any rulers/guides are also drawn shifted by 8px (or the configured value). I am sure that for the devs it should be trivial.
@mocenigo would that solution allow the space to the left of the first character to be clickable? That is crucial. In the first post by @shujaatak, he seemed to say that this approach would work on a visual level, but not allow the user to click in that space to set the cursor at the start of the line, I think.
Is this something that can be accomplished by a 3rd party in a pull request or something like that? I'm not super familiar with how development on this project works.
EDIT: Drake can explain it better than I can
@mocenigo would that solution allow the space to the left of the first character to be clickable? That is crucial. In the first post by @shujaatak, he seemed to say that this approach would work on a visual level, but not allow the user to click in that space to set the cursor at the start of the line, I think.
Yes, It should be clickable. Note that you can already select whole lines by clicking (and dragging) on the line numbers in the gutter.
Why is this not even assigned to a dev? If I knew who to tag, I would. Devs, chime in please. This needs accelerating to the next version!!!!
@yCodeTech there are other issues with more upvotes.
Here is a query to see them
is:issue is:open sort:reactions-+1-desc milestone:Backlog
@yCodeTech @ @ @gjsjohnmurray Please use the link at bottom of this message to request that OpenTeams organize some corporate funding to be thrown at VS Code FOSS Devs on this, as it would result in the request receiving funding & increasing its priority ranking of the backlog.
OpenTeams is "a platform for open source maintainers and contributors to propose specific units of work that businesses can fund to accelerate open source technology roadmaps. This program helps to build a community of like-minded people who can work together to make open source projects better, ultimately leading to faster development and innovation." https://www.openteams.com/cooperative-funding/
@gjsjohnmurray I encourage you to please submit a case study as "Requesting Funding to Prioritize a highly requested but lower-prioritized VS Code feature" at https://www.openteams.com/create-a-case-study-and-profile/ Thanks!
@gjsjohnmurray I think part of the reason it has fewer upvotes is 1). The initial request was worded a little confusingly & also kind of conflated two issues 2). the issue is over two years old, thus ranked very low chronologically.
There WAS a dev assigned to it, and it was even planned to be included for Oct 2021 updates, but then for some reason unassigned and never done.
Little hack since this was bugging me. I'm using the Todo Tree extension, which gives me icons in the gutter, and I didn't like how they looked lacking "editor left padding".
Since I don't use the minimap, I thought maybe I could use it as a padding buffer, and it works perfectly.
{
// "editor left padding"
"editor.minimap.enabled": true,
"editor.minimap.autohide": true,
"editor.minimap.side": "left",
"editor.minimap.maxColumn": 6,
// ---
// gutter settings
"editor.lineDecorationsWidth": 6,
"editor.lineNumbers": false,
"editor.folding": false,
// ---
// gutter styling
"workbench.colorCustomizations": {
"editorGutter.background": "#555"
}, // ---
}
@leafstrat can you click in there and have the cursor go to the beginning of that line?
Since I don't use the minimap, I thought maybe I could use it as a padding buffer, and it works perfectly.
It is nice but if the text is scrolled to the right, it disappears under the minimap, right? A proper padding would leave the text visible instrad.
I just saw the various "workaround" and I see that some make wrong assumpitons. The padding on the left should be at the beginning of the rendered line. So if the first visible column is the first one, you have some spacing between the gutter and the text. If, however, the text is scrolled a bit, then you will see a fraction of text rendered in that padding space.
However if we add
.monaco-editor .lines-content { padding-left: 8px; }
to "vs/workbench/workbench.desktop.main.css"
then the vertical rulers defined by "editor.rulers" in settings.json will not be aligned with the text. In other words, these rulers should be also shifted by 8px. However, this does not happen with the .monaco-editor .lines-content hack.
In other words, it should work exactly as editor.padding.top / bottom
@mocenigo sorry could you rephrase that, I'm not sure I follow. Are you saying that you found a solution?
EDIT: just tried adding the style you included in the comment. It definitely solves the visual element. Unfortunately it appears to be Drake #2 from my meme, unclickable padding :/
I may be misunderstanding if that specific style was the solution that you were suggesting tho
@mocenigo sorry could you rephrase that, I'm not sure I follow. Are you saying that you found a solution?
EDIT: just tried adding the style you included in the comment. It definitely solves the visual element. Unfortunately it appears to be Drake #2 from my meme, unclickable padding :/
I may be misunderstanding if that specific style was the solution that you were suggesting tho
Hi no, I did not find a solution, and my apologies for not answering earlier. That only adds some inactive space and doe not work well with vertical rulers.
I just discovered that there is an option called editor.letterSpacing and this adds spacing between characters in pixels and the vertical rulers work well. So, a parameter like editor.spacingBeforeFirstLetter ( or editor.spacingBeforeLine ) if implemented in the same way would probably work – in other words the changes could be made to the line rendering code instead of the buffer rendering code.
I created a new issue in order to try and revive this old issue. If you still care about this please go give it your support!
Hi @dschil138 Thanks for actively pursuing this improvement!
Here's what I've gone with---
- To reclaim horizontal space:
these settings: https://github.com/microsoft/vscode/issues/30795#issuecomment-410998882
"editor.glyphMargin": false,
"editor.folding": false, // this will disable the vertical column-- therefore it disables minimizing code sections i.e. “folding”
"editor.lineNumbers": "off",
"workbench.activityBar.visible": false
- To reclaim vertical space:
Source 1: https://github.com/microsoft/vscode/issues/174903#issuecomment-1726455954 Source 2: Similar / related: https://github.com/drcika/apc-extension/issues/52#issuecomment-1675837688
"window.titleBarStyle": "native",
"apc.electron": {
"titleBarStyle": "customButtonsOnHover",
},
"apc.header": {
"height": 20
},
"apc.sidebar.titlebar": {
"height": 20
},
"apc.activityBar": {
"size": 77,
"itemSize": 48,
"itemMargin": 0
},
"apc.stylesheet": {
".custom-sidebar-titlebar .sidebar .composite.title": "padding-left: 0;", // Don't indent the sidebar title. We want it horizontally aligned to the left so that it makes a nice vertical column with the controls in the sidebar.
".custom-sidebar-titlebar .sidebar .composite.title .inline-titlebar-placeholder": "padding-left: 0 !important;", // Don't indent the sidebar title. Part 2 to remove the empty space to the left of the sidebar title and complete the proper horizontal left alignment.
".monaco-workbench .part.statusbar>.items-container>.statusbar-item.left.first-visible-item": "padding-left: 0;", // Don't indent the statusbar items. This horizontally aligns the statusbar items with the "Problems" header in the panel, which looks nice.
}, // END -- settings to hide top menu bar and other stylesheet polish
Though the search bar becomes hidden with this improvement, all it takes is cmd-p (mac OS) to access it. I am quite glad to have found this improvement. I wish there was an "Optimize Horizontal Space Saving" and "Optimize Vertical Space Saving" feature within a category of "general user interface options" in VS Code Settings which would yield similar results.
Thanks for keeping this on the radar. I'll freely admit that I don't understand all of the CSS you posted, but I'm happy that you're trying...
y'all gotta go comment on the new issue or this is never getting done. This is our last stand!
"editorGutter.background": "#555"
Exact same issue with TODO, but I'd prefer to keep the minimap. Any ideas on how to achieve it differently?
Damn 3 years passed still no editor.padding.left
eh
Devs do something
@MariuzM @erdemdev guys go leave comments on the new issue, commenting here won't help get this done.
Devs do something
Who needs those boring paddings when AI is now hype train. Choo-choo!🚂
Just moving from notepad++ to vscode and how hard should it be to select the first character of a line? Not this hard.
Just moving from notepad++ to vscode and how hard should it be to select the first character of a line? Not this hard.
The issue has shifted to this one: https://github.com/microsoft/vscode/issues/206914 thanks to @dschil138 . @ajtompkins if you comment on that issue I link above, we may get better traction there.
Note: Please see BOTH screenshots below and also TWO possible solutions at the end!
Please add some option like
editor.contentLeftPadding
or whatever you want to name it, to resolve at least these two issues:Currently in VS Code, the gutter and the code editor are so close that while clicking in the beginning of a line one can accidentally click on collapse button in the gutter region which sometimes really bother the user.
When a user apply a different background color to gutter for either theming purpose or to show that it's not part of the editor region, the code in the editor and also the vertical lines between the first pair of curly braces of code blocks basically touch the gutter. See the following first screenshot.
If we had
editor.contentLeftPadding
then the user could just add that to settings.json like this:which could separate code from the gutter and look like this:
There are two ways to solve this issue:
editor.contentLeftPadding
setting. It will not create any changes to VS Code by default as it would take effect only when the user use this setting, hence, those users who are used to the current user interface of the VS Code will not notice this change.As VS Code doesn't allow users to add custom CSS in it so a setting like
editor.contentLeftPadding
or built-in default padding for editor's content is required.If built-in default padding is added to VS Code then a setting to remove that built-in default padding can also be added so that the user can remove it if the user doesn't like it, just like the following settings to remove folding, glyphMargin and lineNumbers:
Proof of concept Implementation and Observation
For proof of concept, I added the following CSS code to the end of this CSS file /usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.css:
which produces the following neat and required result, such that, now neither I can't accidentally click on folding buttons nor the code touches the gutter:
But I noticed that unlike HTML textarea tag which allows a user to click in the padding area to place cursor at the start of the nearest line no matter how wide padding you set, in VS Code I can't place the cursor at the start of the line by clicking in the padding region which might be desirable by some users.
My VS Code settings.json:
The following are the settings for those who wonder what settings I have for the colors of gutter, tabs and breadcrumb of my VS Code. Note that these color settings look best with Dart+(default dark) theme.