This seems to be fixable by setting

tab key: "Tab", when: "editorTextFocus && !editorReadonly && !editorTabMovesFocus"
Indent Line key: "Tab", when: "editorTextFocus && !editorReadonly && !editorTabMovesFocus && editorHasSelection"

But that disables the indent line key.

👋 Hi there, Martin here, from the VS Code team.

Recently we've announced the Remote Repository feature that lets you browse and edit files and folders directly on GitHub.

Open Remote Repository... opens VSCode on a folder or workspace located on a virtual file system. We call this a virtual workspace. We observed that not all extension support this well, either because they can not, or they haven't thought about it.

It would be fantastic if you could test whether your extension can handle virtual workspaces:

Check out the Virtual Workspaces Extension Author Guide on how to do that.

When done, set the new virtualWorkspaces capability in your 'package.json'.

{
  "capabilities": {
    "virtualWorkspaces": true | false
  }
}

• Use "virtualWorkspaces": true if your extension is prepared for virtual workspaces
• Use "virtualWorkspaces": false if your extension should be disabled when a virtual workspace is opened

For questions and comments please use the Virtual Workspaces Tracking Issue.

Thanks for the support and the great work! ❤️

Ctrl+Alt+S used to save all open buffers

Testing microsoft/vscode#14318

Not sure what's going on here because the command seems to be set, but I need to add this to my keybindings.json the cursors to work like in Atom:

{ "key": "shift+alt+up",          "command": "editor.action.insertCursorAbove",
                                     "when": "editorTextFocus" },
{ "key": "shift+alt+down",        "command": "editor.action.insertCursorBelow",
                                     "when": "editorTextFocus" },

I do notice the following up the top of my Default keybindings, is it not being overridden correctly? Are the keybindings meant to be overridden when they're lower in the file?

{ "key": "shift+alt+up",          "command": "cursorColumnSelectUp",
                                     "when": "editorTextFocus" },
{ "key": "shift+alt+down",        "command": "cursorColumnSelectDown",
                                     "when": "editorTextFocus" },

Testing microsoft/vscode#14318

Suggestions:

• Increase size of icon as it's smaller than most extensions
• Match the keyboard's colors with the One Dark theme (blueish gray with a select few colors for the keys)

Testing microsoft/vscode#14318:

Windows
Install extension, open keybindings

Notice that zoom in has an ctrl+unknown keybinding

How can find duplicate keybindings?

Convert Tabs to Spaces ⌥-⌘-[ (-> editor.action.indentationToSpaces)
Convert Spaces to Tabs ⌥-⌘-] (-> editor.action.indentationToTabs)

Source - http://sweetme.at/2014/03/10/atom-editor-cheat-sheet/

I was considering finally switching to the default VS Code keybindings, but when I uninstalled the extension, I could no longer select a line with "Cmd+L". I checked my keybindings, and it is there, and I even changed the binding. Once I reinstalled the extension, I could once again use the expandLineSelection command.

No matter what settings you have

• default = false
• no setting in workspace settings.json
• enabled = false in settings.json

Each time the workspace (re)loads, the minimap.enabled setting is added if not there, and always set to true.

This is very unfriendly behavior, for people who couldn't care less about the minimap. Please, can you bring back the non-map?

The Atom Keybindings extension causes the workbench.tree.indent setting to be reset to its default once it is enabled. I was able to reproduce it and Atom Keybindings really seems to be the cause for that (see the gif below).

It doesn't matter if it's specified in workspace or user settings or both. Once I enable the Atom Keybindings my filetree isn't indented according to my settings anymore:

The problem also occurs when closing and restarting the editor. I see my 20px indentation for a brief moment then the extension seems to be loaded and the indentation jumps back to 8px.

Testing microsoft/vscode#14318

Linux/Windows: ctrl+shift+</kbd> -> workbench.files.action.showActiveFileInExplorer
Mac: cmd+shift+</kbd> -> workbench.files.action.showActiveFileInExplorer

New users who install this extension will get 2 notifications triggered:

This feels odd as it asks to enable new 3.0 features right after install (not an update). 3.0 also landed 3 years ago.

I have no historic background on why this is prompting users to make this decision. Given the aforementioned friction, could it be dropped (by default opt users into the advanced settings) or explain the why better?

Sometimes, when trying to create new files a or files shift+A (while highlighting file explorer), this keymap is over-ridden by file-filtering.

The solution is to update the following in settings:

"workbench.list.keyboardNavigation": "simple"

solution source and screenshot

Is it possible to update this extension to avoid this conflict?

VS Code Version 1.34.0
Atom Keymap 3.0.6

I'm using VS Code with the atom keybindings on OSX, but I'm used to have it under linux. Is it possible to change the platform that VS Code uses (from the OSX to linux) and use the respective keybinding?

Copied from #4 (comment). OP = @pmbenjamin

Also, Atom supports adding new files/directories in their explorer via keyboard shortcuts.
For example:

• In Atom, when File Explorer is in focus, key a will prompt the user to type a file name (similar to how > Files: New File currently operates in VS Code).
• In Atom, when File Explorer is in focus, key A (or shift+a) will prompt the user to type a directory name (similar to how > Files: New Folder currently operates in VS Code).

I would love to see these shortcuts ported over to VSCode as well.
Since this is currently possible with the Command Palette in VSCode (see screenshot), I think this should be as simple as binding keyboard shortcuts to skip the Command Palette.

I foresee an implementation looking something like:

{
    "mac": "a",
    "win": "a",
    "linux": "a",
    "key": "a",
    "command": "workbench.files.action.createNewFile",
    "when": "explorerFocus"
},
{
    "mac": "shift+a",
    "win": "shift+a",
    "linux": "shift+a",
    "key": "shift+a",
    "command": "workbench.files.action.createNewFolder",
    "when": "explorerFocus"
}

Possible Challenges/Concerns with proposed implementation:

• I don't think VSCode supports explorerFocus
• I don't know what is the command used by the Command Palette to create new files and folders.

If the maintainers feel like this should be a separate GitHub Issue, I'd be glad to create a separate GitHub Issue.

Reveal in Side Bar in vscode dialect.

For international or non-US keyboards is preferred to use oem_comma instead of ,.
Tested only on windows and linux,

Old:

{
     "mac": "cmd+,",
     "win": "ctrl+,",
     "linux": "ctrl+,",
     "key": "ctrl+,",
     "command": "workbench.action.openGlobalSettings"
},

New:

{
     "mac": "cmd+oem_comma",
     "win": "ctrl+oem_comma",
     "linux": "ctrl+oem_comma",
     "key": "ctrl+oem_comma",
     "command": "workbench.action.openGlobalSettings"
},

Refs: microsoft/vscode#14318

Install the extension
F1 > developer tools

Notice many warnings. Some of these are because you are overwriting default keybindings but some should not be used on windows. Not sure if you can do something about it though

Fold Code ⌥-⌘-[ (-> editor.foldAll)
Unfold Code ⌥-⌘-] (-> editor.unfoldAll)

Source - http://sweetme.at/2014/03/10/atom-editor-cheat-sheet/

Request Open global settings shortcut.

Ctrl+, (Comma) — workbench.action.openGlobalSettings

Most other keymaps like Sublime Text, Notepad++ seem to work fine with the github.dev web editor. Atom keybindings mentions that it is currently not supported, but ideally it should.

Testing microsoft/vscode#14318:

• open the extension viewlet, enter 'atom key'
• look at the description on the right.
  It contains a screenshot that looks blends in so well that is is not clear that it is just an image. Silly me tried several times to click on the 'Details' , and links.

Maybe better have a real HTML table there.

Been looking for a package like this and would very much try it out, but the docs are missing installation instructions.

Could you be so kind to provide any? Thanks!

I noticed there are many packages downloaded with this, eg

https://registry.npmjs.org/https-proxy-agent/-/https-proxy-agent-5.0.0.tgz

If I install this is there any communication from the PC its installed on ? Is it collected/sending any of my private data ?

Thanks

I realize this package is unofficial. Just a heads up these break OS X default for selecting text right or left of the current cursor position:

        {
            "key": "shift+cmd+left",
            "command": "workbench.action.focusLeftEditor"
        },
        {
            "key": "shift+cmd+right",
            "command": "workbench.action.focusRightEditor"
        },

You can see my ticket here: microsoft/vscode#11991 (comment)

Versions

VS Code: Version 1.15.1 (1.15.1) | 41abd21afdf7424c89319ee7cb0445cc6f376959 | 2017-08-16T17:11:22.564Z

macOS Sierra: Version 10.12.3

Atom Keymap version: 3.0.1

Problem

⌘-k does not clear the terminal as expected

Steps to Reproduce

1. Install and activate "Atom Keymap" ("Code" > "Preferences" > "Keymap Extensions (⌘-K ⌘-M)")
2. Open integrated terminal and ensure it has focus (⌘- ![firefox-nightly-57-about-logo](https://user-images.githubusercontent.com/7552754/29482008-11f040c8-8446-11e7-9c97-ad216c3ede8f.png) )
3. Press ⌘-k to trigger the clear command

Expected
Clears terminal

Actual
Shows message about chord and does not execute clear:

Notes

• (a) Disabling the Atom Keymap, (b) removing the "atomKeymap.promptV3Features": true, from my settings, and (c) restarting VS Code fixes the problem, but of course, doing so leaves me without the Atom Keymapping. :-(
• related discussion (such that it was): microsoft/vscode#25059

The extension has baked for a while now and might be ready for non-preview release.

Steps to reproduce:

1. Hit Cmd+F in file
2. Hit esc

Should clear the find dialog, but doesn't.

Disabling the atom keybindings extension and it works as normal.

Find Open File ⌘-b (-> workbench.action.showAllEditors)

Source - http://sweetme.at/2014/03/10/atom-editor-cheat-sheet/

Extracted from microsoft/vscode#36635

From @deiberdev @mnunezdm

The extension most likely binds keys to ctrl+alt+.... This should not be done, as it impairs users that use a non US keyboard layout on Windows.

e.g. Spanish keyboard layout, Latin American keyboard layout

Like the title says, when I have the keybinding loaded to the workspace, I can't press the 'h' key without it losing focus, and even sometimes making a new file with the partial file name. When I disable the key binding and reload the workspace, it is fixed and I can rename as expected. I have attached a gif to describe this behavior.

gif

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

Your extension is incredibly popular with VS Code users! We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

Workspace Trust will remain disabled for the month of May, but we are planning on enabling this by default in the future. To prepare for that day, we would love for you to try it out and provide feedback.

We'd love your feedback

Since this issue was created in an automated fashion, we won't be monitoring the responses in this issue (our notifications would explode!). Instead we ask you to drop questions, and feedback in issue #120251 as we've mentioned above.

We're excited to see what you do with workspace trust!

Testing microsoft/vscode#14318

This probably needs a vscode feature request/extension. Personally I feel including the \n is much more useful.

looks to be a typo in the config:

            {
                "mac": "cmd+-",
                "key": "ctrl+=",
                "command": "workbench.action.zoomIn"
            },
            {
                "mac": "cmd+/",
                "key": "ctrl+-",
                "command": "workbench.action.zoomOut"
            },

I assume that the correct config should be:

            {
                "mac": "cmd+=",
                "key": "ctrl+=",
                "command": "workbench.action.zoomIn"
            },
            {
                "mac": "cmd+-",
                "key": "ctrl+-",
                "command": "workbench.action.zoomOut"
            },

This is especially annoying as I've become accustomed to doing cmd+/ to comment out code

Testing microsoft/vscode#14318

Mac, Linux, Windows: ctrl+shift+c -> workbench.action.files.copyPathOfActiveFile

From @klickl on March 20, 2018 19:48

Issue Type: Bug

Hello,

I just installed your latest version, but on windows with AZERTY keyboard layout, I'm not able to display this symbol " ] ", which can be create by this shortcut Alt Gr + ).

To solve the problem I removed in the shortcut the default Ctrl + alt + ), defined to group code inside block.

I think it would be great on next versions to remove this default key binding.

VS Code version: Code 1.21.1 (79b44aa704ce542d8ca4a3cc44cfca566e7720f1, 2018-03-14T14:46:47.128Z)
OS version: Windows_NT x64 10.0.16299

Copied from original issue: microsoft/vscode#46209

Extracted from microsoft/vscode#97906

The "when" clause should be "editorTextFocus && !editorReadonly".

microsoft/vscode#15002

https://code.visualstudio.com/updates/v1_31#_new-tree-widget

Version: 1.31.0

Expected: a key opens dialog for new file, Shift+a opens up dialog for new folder
Actual: Both result in triggering the tree widget filter.

microsoft/vscode#68083

Settings

editor.formatOnPaste: true
editor.minimap.enabled: true

MacOS Emacs style:

Ctrl+e+shift = Select to line end
Doesn't work!

Also:

Ctrl+e+shift
Ctrl+a+shift
Ctrl+f+shift
Ctrl+b+shift
Ctrl+n+shift
Ctrl+p+shift

Alt+f
Alt+b

Testing microsoft/vscode#14318:

The 'GitHub repository', 'package.json file' as well as the MIT link all don't work.

Ctrl key should insert multiple cursors on click instead of alt

Atom Keymap: 1.2.2
VS Code: 1.7.2
OS: Linux / Fedora 22

Testing microsoft/vscode#14318:

Going through http://sweetme.at/2014/03/10/atom-editor-cheat-sheet/ I found the following shortcuts that we could add as well:

Fold Code ⌥-⌘-[ (-> editor.foldAll)
Unfold Code ⌥-⌘-] (-> editor.unfoldAll)
Convert Tabs to Spaces ⌥-⌘-[ (-> editor.action.indentationToSpaces)
Convert Spaces to Tabs ⌥-⌘-] (-> editor.action.indentationToTabs)

Find Open File ⌘-b (-> workbench.action.showAllEditors)

Testing microsoft/vscode#14318:

Fold / unfold shortcuts not working on windows

Whenever I launch VSC, I receive the "use new features" prompt. I select YES. If I close and relaunch VSC, I receive the same prompt. In both my user and workspace settings json, I set "atomKeymap.promptV3Features": false. I still get prompted.

Using VSC Version 1.35.1 (1.35.1)

How do I prevent the new feature prompt from reappearing?

Hi, I'm on the VS Code team. We recently released support for Remote Development and I noticed that your may extension need a small change to ensure users have a good experience when using it remote workspaces.

What is the issue?

To make remote development as transparent as possible to users, VS Code distinguishes two classes of extensions:

• UI Extensions: These extensions make contributions to the VS Code user interface and are always run on the user's local machine. UI Extensions cannot directly access files in the workspace, or run scripts/tools installed in that workspace or on the machine. Example UI Extensions include: themes, snippets, language grammars, and keymaps.

• Workspace Extensions: These extensions are run on the same machine as where the workspace is located. When in a local workspace, Workspace Extensions are run on the local machine. When in a remote workspace, Workspace Extensions are run on the remote machine. Workspace Extensions can access files in the workspace to provide rich, multi-file language services, debugger support, or perform complex operations on multiple files in workspace (either themselves or by invoking scripts/tools).

You can find more details about this architecture here.

VS Code currently infers that your extension is a Workspace Extension. This means that users who have your extension installed must also install it to the remote in order to use it in remote workspaces. I believe that your extension should probably be a UI extension instead. That way your extension will always be enabled for users who install it, even if they open a remote workspace.

How do I fix this?

To tell VS Code that your extension is a UI extension, just add "extensionKind": "ui" to your extension's package.json.

UI Extensions always run on the user's local machine, even when they open a remote workspace.

I'll submit a PR that does this. Please let me know if you have any questions or concerns about the issue. We've also put together a guide to help you test your extension in remote workspaces

PS: As a temporary workaround for a few popular extensions, we've automatically added your extension to an internal whitelist so that is always treated as a UI extension