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:
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))
I'm studying a long, well documented code form a colleague and I'm allowed only to read it, not edit.
My screen wastes a 20% in blank lines. It is possible to show/hide the empty lines (NOT remove) via a shortcut so I can see a 100% code lines on my screen?
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:
For a half year now, I carry an innovative idea for a modern way of code editing. I just realized what Visual Studio Code extensions are already capable of and made me wonder.
The idea is that a real time code render mode for code editors where code is visualized like rendered documentation (for example Doxygen). Non-commented lines of code are displayed like collapsable codeblocks and documentation comments are displayed as the surrounding markdown/HTML/LaTeX document.
This rendered view still can be edited and navigated in same way as the classic text view so that new graphical elements appear after typing them as text into a comment. Therefore, rich interactive documentation reading (like hiding/showing parts, jumping across locations with hyperlinks) and code editing would be combined into one activity without time needed for switching between both or mapping Documentation with actual code locations. Different from the original literate programming idea, the file's physical content is unchanged and doesn't complicate the process or source code reading.
It's conceptually how Moodle text editors work (HTML code view and render view) or like using a graphical word processor to visualize source code instead of a single monospace text. Of course, the cursor would move along lines in their visually presented order and not in their file's actual order.
Do you know, if such a real time render mode is possible in VSCode?
Did someone had such an idea and made an extension?
btw:
This "render mode" idea is actually quite generic and could be used as general customizable GUI technology that would allow GUI elements to be navigated, edited via an underlying text representation.
Sometimes when I jump into source code, e.g. from search or when looking up the declaration of something, the Eclipse text editor tries to display nearby long lines by horizontal scrolling. This happens even if the item I jumped to is well within the display without scrolling. I find this rather annoying, so:
Is there a way to disable this? I have searched in vain through all the editor settings.
Specifically, this is about Eclipse CDT, but I suppose the behaviour is the same in JDT.
This seems to happen in other eclipse editors too (like PDT for PHP)
It could have been related with the ScrolledFormText, but the Plugin Spy tells us a WorkbenchWindow class is concerned, as well as an AbstractDecoratedTextEditor, that is in essence an org.eclipse.ui.texteditor.AbstractTextEditor.
The source of that AbstractTextEditor indicates having:
a ScrollLinesAction for vertical scrolling
a TextNavigationAction for settings the cursor and potentially triggering horizontal scrolling
I am not sure how to change that behavior, except by contributing somehow to the active editor identifier (for instance, for java, "org.eclipse.jdt.ui.ClassFileEditor"), and modifying that Action.
I was having the same issue and found these open bugs for it on the Eclipse Bugs:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=314208
https://bugs.eclipse.org/bugs/show_bug.cgi?id=321189
You can prevent it from happening when you switch the Code Folding off and reload the file.
grtz,
T
right click on your eclipse shortcut and choose properties. in compatibility tab choose "windows xp(servicepack 3). http://www.vistax64.com/vista-general/133849-disable-dynamic-horizontal-scrolling-vista.html