I'm looking for something that detects when a file's content does not fill the entire viewport of the editor, then adds extra space at the TOP of the file instead of at the BOTTOM.
VSCode does offer the option to add a default padding at the top of editors but it doesn't automatically display the padding when opening the file (and this isn't exactly the functionality I'm looking for either, since that would be inconvenient for larger files that take up more space than the viewport of the editor).
Bonus points if someone knows the answer to this for IntelliJ as well (if it exists) :)
How it looks now:
What I'm looking for:
Related
Is there a way to configure VS Code to increase the number of files that are able to be displayed across the tabs at the top?
There are currently just 4 files1 visible in that top area, but ~10 would be ideal:
Example
Sublime text uses smaller font on file names (despite similar font size of the code itself), and so allows about twice as much space for displaying files:
Current work around
I hit opt + command + right arrow a few times to quickly survey open files.
Ideas
Perhaps open files could be quickly surveyed (without key presses) if it is possible to:
Expand the area to have more than 1 row of files
Configure VS Code to show only part of the filename
Use smaller font on the file names (not the code itself), similar to sublime text
Something else?
1 The habits of using long file names, and having a lot of files open at the same time don't help, I'm aware of that.
workbench.editor.tabSizing
There's the "workbench.editor.tabSizing": "shrink" setting value, which is documented as so:
Allow tabs to get smaller when the available space is not enough to show all tabs at once.
(the default value for workbench.editor.tabSizing) is "fit".
workbench.editor.wrapTabs
As other have mentioned, there's the workbench.editor.wrapTabs setting, which you can find more about in this Q&A: Multirow Tabs for VSCode.
TL;DR from the setting's description:
Controls whether tabs should be wrapped over multiple lines when exceeding available space or whether a scrollbar should appear instead. This value is ignored when #workbench.editor.showTabs# is disabled.
git.decorations.enabled
You can shave a few pixels by disabling git decorations if you're working on a git project (of course- this is only if you're okay with disabling git decorations). Git decorations add letter indicators to the tab handles that summarize what has changed about those files. Ex. "M" means the file has been modified, and "A" means it has been added.
"git.decorations.enabled": false
workbench.editor.tabCloseButton
You can shave a few pixels by disabling the close button on tabs (if you're okay with that (you'll still be able to close the tab with the associated keyboard shortcut, or by middle-clicking the tab handle)):
"workbench.editor.tabCloseButton": "off"
workbench.editor.showTabs
If your aim is really to declutter, you can take the hardcore/nuclear route and do:
"workbench.editor.showTabs": false,
Et voila! Now the tab handles take up zero space because they're gone :D (and you can navigate tabs using ctrl+tab and ctrl+shift+tab (that's on Windows and Linux- not sure what it is on MacOS), or by using the Explorer view's "Open Editors" section (you might need to enable it first under the three-dots menu))
im trying to make wider spaces between HTML parent and child elements. I tried with many settings but my tree is still super unreadable. I can't see what exactly each div contains.
The current look:
I'm trying to achieve wider structure, like this one:
"editor.tabSize": 2,
You're using a variable-width font. Spaces in variable-width fonts are often much thinner than other glyphs/characters. The image of what you want is using a monospace font (where every glyph/character has the same width). Use the editor.fontFamily setting in the settings.json file. You'll need to consult your OS / Desktop environment to see what fonts you have installed for selection. If there's one you want and don't have, you'll need to install it.
I have a VSCode extension that helps me autocomplete file paths, however many file paths grow long and are truncated in the VSCode intellisense popover window.
How can I set VSCode to either:
have a fixed width that I can set to be large
automatically expand to fit the intellisense options (preferable)
I happen to have written the extension so if needed I can update it if that is required.
One way around this is to press Ctrl + Space (or what ever your "Trigger suggestion" shortcut is) while the suggestion popover is open to show more detail about current selection.
So this (where I can't differentiate between the Trans imported from #lingui/macro and the one from #lingui/react):
Becomes this:
I don't think this is possible, VSCode generally gives extensions very little control over the built-in UI. See also the Restrictions section of the Extensions Capabilities Overview. Technically there is a way to hack around that, but I wouldn't necessarily recommend it.
There are also a number of settings for the suggest widget, but none of them seems to correspond directly to width. The closest you can get would be reducing the font size with "editor.suggestFontSize".
I'm have reinstalled my emacs and now I'm using emacs v24.3.50 with auto-complete v1.4 and popup.el v0.5. Unfortunately the popup "menu" of auto-complete is kinda broken (see attached screenshot).
The different items are not aligned along a commong vertical line [ignore the black overlay, that stems from CEDET and is probably meant to be placed on the right side next to the popup menu; the problem remains when disabling CEDET, so it is not related).
From what I can tell it looks like the extent of this "shift" between lines depends on how much the length of the strings differs. Also, when selecting a different suggestion using the arrow keys the horizontal shift of the lines changes a little (~few pixels) each time the mark is moved one line up/down.
I have uploaded the part of my .emacs.d/init.el that is used for configuring auto-complete here.
Any suggestions on how to fix this?
It appears you are using a proportional font, which breaks the calculation of the left edge of the overlay.
You can try changing the way auto-complete computes the column:
(setq popup-use-optimized-column-computation nil)
You can also change to a fixed width font.
Note that some other completion systems for Emacs can use tooltips instead of overlays, which would avoid this problem.
When I scroll to the bottom of an open document in the Eclipse editor, the last line is at the bottom of the file. This is a tad annoying when editing code at the bottom of the file / screen.
How can I enable Eclipse to scroll (much like Vim or VS) down far enough that the last line of code reaches the top of the editor window?
I'm asking for the reverse of this question, in Eclipse: How to make Visual Studio editor stop scrolling past bottom of a file?
Considering the current implementation of a Scrollbar, this is not possible.
(See org.eclipse.swt.widgets.ScrollBar.java)
At any given moment, a given scroll bar will have a single 'selection' that is considered to be its value, which is constrained to be within the range of values the scroll bar represents (that is, between its minimum and maximum values).
In the JDT (Java Editor) realm, the range is strongly linked to the number of lines a source file has.
Adding artificial "logical lines" to allows scrolling past the last line would have unintended consequences on many other parts of the JDT, related to displaying informations based on the line number of a source file (like a compilation error red underline).
This is also why there is no soft wrapping in those editors, despite
a 7-years old bug 35779 (one of the most upvoted).
Allowing word/soft wrap in the editor while typing is easy but not enough, a mapping between the model lines and the visual lines must be introduced to e.g. correctly show annotations.
It also introduces various problems that need to be solved, e.g. 'Go to Line': tools like a debugger, compiler etc. will report the model line but a user it will look strange that a different line will be selected than the one entered into the 'Go to Line' dialog
So for now, the SWT scrollbar example is still limited by the bottom of the window: