Visual Studio Code explorer view scrolling - visual-studio-code

My project contains a LOT of folders, many of which I routinely have open, making for a lengthy explorer view. I find scrolling this view quite frustrating for two reasons:
There is no equivalent of the editor.mouseWheelScrollSensitivity setting for the explorer view. I'm also generally happy with the scroll speed for my mouse in other applications, so don't want to go messing with a system wide setting to compensate for VSC.
The scrollbar is frustratingly difficult to grab at and requires precise mouse placement. The number of times I accidentally grab at the slider and resize the view rather than scroll it is ridiculous.
I've found no useful extension to help in this matter. Has anybody any suggestions? I'll raise an enhancement request in Github if necessary.

Here are 2 shortcuts that can speed up navigation between files:
With Ctrl then Tab you can browse a history of your last viewed files. Great for switching around when working on multiple files.
With Ctrl+P (Go to File... command) you can quickly go to a file by name. You can also search for files inside folders like this: folder/subfolder/file.ext. This is great if you know what you are looking for.
Source and more navigation tips: https://code.visualstudio.com/docs/editor/editingevolved#_quick-file-navigation

This PR in vscode 1.59 may have fixed this issue: https://github.com/microsoft/vscode/pull/110059/commits/61efc577e038ac772f12511fb823de27296dbc69
New settings:
workbench.list.mouseWheelScrollSensitivity
workbench.list.fastScrollSensitivity

Related

How to configure VS Code to only highlight a file in explorer but do not scroll to it(like autoReveal does)?

Atom has exact behavior that I want, it just highlights a file w/o expanding folders and w/o scrolling.
See https://github.com/microsoft/vscode/issues/82828
As of v1.43 vscode will only scroll to a file if it was not previously visible - so maybe that is a partial solution. It will still open folders and scroll if it is off-screen for the explorer. But at least it is of some improvement hopefully for you.
also see this setting:
explorer.autoReveal which will turn off the autoReveal feature completely.

How to attach images to github issues without dragndrop?

Is there a way to attach images to github issues without drag'n'drop, copy-pasting images or jumping through various hoops - just by using a file picker?
I find drag'n'drop very inconvenient, and copy-paste does not work in Firefox (on top of being rather inconvenient as well).
Github help page only mentions drag'n'drop, or copy-paste for Chrome.
The question here on adding images lists additional methods like creating a custom repository or wiki.
All of that is enough of a pain in the ass for me to ask a question here, hoping for a hidden way to use normal file picker.
There is a file picker. Simply click on the Attach files by dragging & dropping, selecting them, or pasting from the clipboard field.
Yes there is, its very simple, but not intuitive.
Consider this example where you want to comment:
Just click the highligted section with the text "Attach files by dragging and dropping, selecting them, ...".
Then a file dialog will open up:

Visual Studio Code - Tabs (editors) of the same project in multiple screens

Using multiple screens I normally place multiple classes (files) in different screens, this helps me a lot while refactoring, checking tests and comparing changes.
Visual Studio Code does not allow me to drag a tab outside the window and view it in (for example) another monitor.
I checked the documentation and plugins, but the only way I found, is to open two windows, pointing to the same project (folder) and put those in different screens.
I don't like this solution, that causes also some problem when I watch code changes using TypeScript.
Any suggestion?
I use Windows 10, latest version of VSCode.
A solution is to press CTRL+K and after releasing CTRL, press O.
This will open the current file in a new window.
There are few things I don't like about this solution:
- Drag and Drop does not work
- Create a new instance of VS Code resulting in (for me) 180MB of ram used
- To open the file it takes to me few seconds (quite slow)
- The file remains open in the original window as well
Update 20/03/2019:
There is a feature request you can track here:
https://github.com/Microsoft/vscode/issues/10121
And an explanation about why this is difficult to implement here:
https://github.com/Microsoft/vscode/issues/10121#issuecomment-345770248
Update 20/03/2019:
Another important side effect highlighted by #Mär is that:
the IntelliSense fails to establish references it had when the file
was opened in the window, where the entire project is opened
The easy way but with the same drawbacks. More ram and resources will be used. Is to wrap your project in a folder.
It's the best possible thing. As by now!
=> Duplicate the workspace.
Open the command pannel ctrl+shift+p or F1.
Then write dupl
You'll get that
That's it.
More
If you want to add more folder to the working space.
=> go to File then Add Folder To Workspace
You can add as many as you like.
 Also better more
You can open a new window (ex: ctrl+n)
And then go File > Add Folder To Workspace.
And start adding folders to your new Workspace. You can add any folder, that is already open or not. That's too way great. You can have all the needed folders for example in the second screen.
A little hack I used is to just stretch the editor window to fill both screens and split the view pane between the monitors such that both screens show just one open file.
This is a cheap hack that works without opening multiple instances of VSC.
It may not be the proper solution, but it works without eating up all my system memory.
I found the following way to work on multiple monitors (important: they must be the same size and resolution):
open a visual studio in windowed mode on the 1st monitor (in my case it is a left monitor)
move the window to the (left) top corner
stretch window to the 2nd monitor (right) bottom corner
split screen by clicking “split editor” several times
move the code sections separator to the edge between the monitors
This is old qestion, but such way can be useful for someone. It is not very convenient, but it works. The solution may have already appeared in the VS itself, but I didn't find it.
Visual Studio Code does not allow me to drag a tab outside the window and view it in (for example) another monitor
Actually, VSCode 1.57 (May 2021, 4 years later) will propose something close:
Improved editor drag and drop across windows
Support for dragging editors to other windows was improved in this release. You can now drag diff editors, custom editors and the entire editor group to another window to open the editors there.
My solution was to use Remote-ssh to connect to self and open in another window. This does take extra resources. But I find this comfortable as I don't need to create additional workspace.
For me on Ubuntu the solution was to create a project folder symlink and ope it in a new window (as it won't open the same folder in another window)

How do you move a complete eclipse (3.x) tab folder of views?

It has always been obvious to me how I could move around a single view (e.g. Console) in eclipse: just drag the view's tab around. However, when switching monitor configurations, I often want to move the entire tab folder of views, not just one view from the folder.
How can that be done?
Grab the tab folder in the tab bar area, but to the right of all the tabs.
It seems obvious now, but it took me a long time to figure this out. I couldn't find the answer via google or stackoverflow searches, even after multiple attempts. Hopefully this saves somebody else's time.

Eclipse: Nested Editor Tabs?

Is anyone aware of any method (or external plugin) that would allow for nested editor tabs? It would be nice to be able to group related open files into their own "master" tabs, but I'm not sure if this is even possible. Any ideas?
This is totally non-obvious, and I discovered it by accident, but...
If you click on a tab and start dragging it downwards, once you get more than half-way down the editor pane, a horizontal line will appear. Let go, and now you'll have two different editor panes, each with tabs of documents. Now you can drag tabs up and down between the two panes to see different documents at the same time.
I think that's as close as you can get.
I think the best you can currently do is "Window->New Window" and then use each new window as a separate "tab" of related editors. Not exactly ideal, I admit.
It's a cool idea though, especially if you could have shortcuts or something that open groups of editors with a single command.
This definitely isn't possible in the current RCP. You might be able to construct an editor component which created a CTabFolder and delegated to other editor components, but I'm not sure how well that would work.
There are Perspectives in Eclipse that you might use to achieve something close, they are more global things though...
But I agree with you, I would like this feature as well! This would be also very useful when editing many files that have the same name but come from different packages, because now it's a mess >_<
For me the utility of such a feature is to reduce context switching time. I'm working on project A, have lots of editors open, now I need to drop that and work on project B. I want to keep all the editors open associated with project A but hide them while I work on B. When I'm done with B, I can pick up right where I left off in A without having to find and open all those A files again; I can even leave them unsaved indefinitely, since Juno never crashes!! :)
I have used the New Window feature, and it's great, but the new window needs a bunch of configuration (closing Views I don't need, moving stuff around to where I want it, opening Views I had open in the old window, and so on) before I can get to work. It also uses a lot more memory than a simple tab group would since it seems to be a complete new copy of Eclipse.
The split-window feature is great and I use it all the time. It is indeed tab groups, and if there were a way to hide a tab group, and for each tab group to have its own tab list (the thing you get when you click ">>5" so you can see editors you have open that don't fit in the tab header), it would totally fill the bill.