In version 0.10.1 it is no longer possible to write to the root of a drive (which worked up to 0.9.1). When trying to save to e.g. , the following error message appears: Tested on Windows 7 Ultimate and Windows 10 Professional, US language, German region settings.
are you sure you can save there, can you try with nodepad?
Yes, I can write a text file with notepad. And I also tried other drives. What I found out in the meantime is that this happens only when creating a new file. Opening, editing and saving an existing file works correctly.
so you do Ctrl+N, type something and then try to save it to r: from the windows save dialog?
Exactly. The error message appears trying to use Save, Save As or (when creating multiple files), Save All.
is R: some drive created with subst or a real physical drive? I assume it is not the root drive where windows is installed?
R: is a RAM disk - so I suspected this to be the problem at first. That's why I checked on other, "real" drives (except the system drive C:), and I can reproduce the behavior.
What I'm not sure about is why VSCode is trying to run at all. When I do this from a command line (), I get an "Access is denied" there as well - which doesn't surprise me.
It actually tries to create the root path :) If you run VS Code as non-admin, it won't even let you try to save to but if you run VS Code as admin, it will let you try but fails on creating . !
Thanks, will look into it!
This looks like a bad regression in (). It relies on the EEXIST error but when reaching the root drive, it ends in EPERM. I think you touched this function last.
As of now, 0.10.8-insider build run as an administrator lets you save to D:<filenameAs far as I can see, this is truly closed.


I can confirm this happens for me as well. I am using Mac OS X. The operating system's display scaling is off (i.e. 1:1). I have been experimenting and it seems as though the bug is that the right click menu is displayed according to the cursor position, but this calculation is not adjusted to take into account zoom. The reason I say this is because if I right click near the top left of the editor, the cursor is quite close to the top left of the menu. But if I right click near the bottom right of the editor, the cursor is much further away from the top left of the menu. The misalignment is proportional to the distance from the top left of the editor.


This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help


Unsure how I got into this state but changing different files doesn't fix it !
Joao maybe you have an idea.
Sure, drag a file from the desktop over the explorer and press <kbdEscape</kbd.
looks suspicious in though changing that to call seems to break within-tree-dnd (while it fixes this issue).
This code is treacherous since it's full of hacks to make it work across all browsers Monaco used to support.


Unlike the VS Code installer for Windows, the VS Code uninstaller for Windows is not signed. You can fix this by using the directive in your Inno Setup script. See For dual signing it's easiest to use Inno Setup 5.5.8 instead of 5.5.6 as you currently use: 5.5.8 allows you to have two SignTool directives, one for the sha-1 signing and another for the sha-256 signing.
To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed. Thanks for your understanding. Happy coding!


:+1:
+1
Why is this essential feature still not a thing?
because it relies on which is non-trivial and it needs to be prioritized against other work.
+1
+1
+1 or adding a heading list view(TOC view) on the right side, it's really convenient for editing a large markdown file.
Please refer to the org-mode tab feature to implement, it's powerful.
+1
duplicate of
Reopening to track the markdown specific work of
I noticed that this is already implemented in the latest insider build, thanks a lot. One more request, would you please preserve the last blank line of a folded region? I mean becomes instead of One reason is that currently
Can anyone update the status on this?
it's coming to the next stable release.


VSCode Version: 0.10.11 OS Version: Win10 Steps to Reproduce: this key binding: a code file (C#, JS, TS) "publ" followed by the space key Expected: The text should be (with a space at the end) Actual: The text is , no autocompletion occurred. Note: "acceptSelectedSuggestion" without the caret still works
Looking thru the default bindings, I noticed this binding at the very bottom of the file: Pressing does not autocomplete in TypeScript either.
I can confirm it doesn't work on TypeScript due to the context key not being set.
There is two problems: commit introduced a regression in that it turns around the boolean condition (missing ) ended up with having the command two times when working on the acceptOnEnter config setting
Despite the fixes above this still happens. The reason seems to be that uses a timeout. That gives the triggerOnCharacter command a chance to run (and clear the previous suggest model) such that accept doesn't work
the timeout and like breakage happened in
Oh, the missing ! Ugh, sorry about that. The was just a leftover. I made a change that enables me to simply remove it. :+1: can you see whether the now works?
works


VSCode Version: 0.10.11 OS Version: Windows 10 Steps to Reproduce: click on an unknown file type, like or Open with... VS Code and check always use this app to open files of this type The file gets the app icon of VS Code, not the document icon: !


Issue Id: <-bdb0-aec8-eb4a-</b<br /<br /Versions <br /- <br /- <br /Stack <br /TypeError: Cannot read property 'dispose' of undefined<br /<br /<br /<br /at Array.forEach (native)<br /<br /at Array.forEach (native)<br /<br /<br /<br /<br /
Woopsie.
Sorry for the confusion, this one is still open, the other one is fixed.


VSCode Version:0.10.13 alpha OS Version:Windows 10 Steps to Reproduce: an variable to your ex. ${env.PATH} "command": "echo", "isShellCommand": true, "args": ["${env.PATH}"], the task. This will expand correctly on Linux and OS X but not Windows since the expansion is case sensitive and PATH on Windows is "Path". Env Var expansion shouldn't be case sensitive so that the same task can run on all platform. This bug was requested by in vscode-docs issue
this is done by the resolver service. IMO env variables on all OSes are case insensitive. Should we address this.
Let's keep it open and if some user is passionate he can tackle it
On linux and macOS environment variables are case sensitive, so "Path" and "PATH" are different variables on linux and macOS (but not on Windows). So your statement from above "IMO env variables on all OSes are case insensitive." is not correct, right? so you are asking for making env var lookup case insensitive on Windows only, correct?
I thought they are always case insensitive. So it should be case insensitive then on Windows only
I'm actually about done with a change for this if you want to take a look.
thanks, I will review the PR.
did you want me to squash it or anything (fixed a broken test because I forgot the existing code returned an empty string for missing environment variables)? Different projects have different requirements and I didn't see anything about squashing in your contrib docs.
no need to squash, I will add the comments to the PR directly if something is needed. Thanks


VSCode Version: 1.0.0 OS Version: OSX 10.11.3 I noticed that we can set to a keybinding. Which creates a nice input field in the sidebar to create the directory at the current selected position. ! But there is no possibility to do this for a file. Yes you can bind but it does not do the same thing. It just creates a new and when pressing <kbdcmd</kbd+ <kbds</kbdyou have to choose the destination in a picker. So, is it possible to add something for a new file as well? It would really improve my speed because I don't have to touch my mouse anymore to create a new named file in a specific directory.
sounds like a good example for a PR?
Yes I looked into it but to be honest, I have to clue where to start :). So if you can point me in the right direction, I would be very happy to do one :).
I would start by fulltext search for the action id () and that brings you here: From there you can get a feeling how this global action works and maybe add the new one. You will also see the one on top for creating an untitled file (which is not what you want). When you find the references of that action you will see where it is being registered to the system:
Alright, awesome. Thank you very much Will see what I can do :).


VSCode Version: 1.0 OS Version: Ubuntu 16.04 Ubuntu 16.04 (Xenial Xerus) no longer carries , this causes font to be rendered with if Linux desktop user installed MS core fonts (more than likely). Given Ubuntu still carries open source fonts such as or , which are better for LCD than , consider: Adding those to the font list Remove from font list - let the OS decide
I see uses of this font in editor, git and debug land. Starting with editor.
I bumped into this today, after updating to insiders 1.2.0. I'm on Ubuntu 16.10. For now, workaround by manually overriding the font family: Either way, I see no sense in giving "Droid Sans" as a first option, even on Linux. If the user has the MS fonts installed, they should be used.
I also noticed this. I installed "fonts-noto" package from the repositories because some people say Noto font family is similar to Droid.
I solved this by simply installing the font from
this is somewhat related to which has similar issues for the UI font. The real fix here is to lean on Chromium to pull in the system monospace font from the OS if it's available (a system-ui font was proposed in ). Is there any reason just is not used? Also why is Courier New there at all?
for no good reason except version-to-version stability.
I only just became aware of this but it's a pretty big issue imo. If I remove my on Ubuntu 16.10 it falls back to Courier New which really affects readability because of its weight and the fact it's a serif font. If this was what I saw as my first impression I'd be kind of turned off by the default font. Hack: ! Courier New: ! Sure it can always be changed but we can't rely on people knowing or bothering to do that. Also on this PC seems to fall back on Courier New.
My honest suggestion is to ship VSCode with a cool font such as Hack or Inconsolata and have one of those be the default. IMHO too many folks are left with ugly monospace fonts.
I just read your comment but I'll post this anyway since we agree :stuckouttongue: have you considered bundling a standard monospace font that looks good on all platforms with the distributable? The developer of reached out to me a couple of months ago and asked if we'd be interested in doing that, gzipped the 4 font variants are only ~700kb.
Yeah, I've mentioned this to and a couple of times already. Not sure about the legal implications, but IMHO that would be a smart move for us.
Here's the expression of interest I mentioned from the developer of Hack
Is there a reason why couldn't be that alias for the system monospace font?
This now also affects Debian Stretch. After upgrading the font is displayed because the fonts-droid is not in the repositories anymore. Debian maintainers switching from to . I have followed the recommendations and have installed and replaced with in which in my opinion looks very good. Setting the default to on Debian results in a very ugly result. I changed the default font in Gnome Tweak Tool and in fontconfig to . as you can see it is not taken into account: ! Until a font is bundled with VSCode, could we add in the for Linux, and perhaps add as a suggested package in the Debian package? is in the section in Debian repositories. Unfortunately it is in the section in the Ubuntu repositories, thus users must activate it before being able to install the package, this is why I suggest to as a package instead of a recommends/depends.
Isn't this a Debian bug then? AFAIK you can't change the font in gnome-tweak-tool. It will only set a dconf value, not the alias which is configured via fontconfig.
Note that I have also defined as the font in fontconfig by defining an alias in: As you can see NotoMono is returned as the maching font for . And I confirm that the monospace font is now rendered using on other applications running on my system, except Visual Studio Code where it seems to default to . I don't think there is a bug in Debian because other application seem to behave correctly. I agree that the correct and clean solution would be to define as the only font listed in . Although: In my opinion on many systems the default monospace font is ugly. If we really want to use as a default then we need to find out why the font is rendered as on some systems when is defined as another font.
Could be a Chromium/Electron bug then. Can you try in Chromium/Chrome? IMHO that's a bug of those systems and will never be fixed, if applications work around it.
I have interesting results. I have crafted the following html page: And got the following results. ! I noticed that adding quotes around the monospace word would yield different results. I have changed to in VSCode and it is now rendered correctly: !
Try Ubuntu Mono. Monaco is good one but personally, I like Ubuntu Mono. !
Hi, everybody! Replace 'Droid sans mono' by 'Ubuntu mono' looks good to me. I didn't download any font pack.
there was another issue a while ago discouraging the use of Ubuntu Mono as then it's picked up as the default on non-Ubuntu Linux distros . Ideally we would pick up whatever the display manager configures as the default monospace font, but monospace often doesn't give us that.


VSCode Version: 1.2.1 OS Version: Windows 10.0. Steps to Reproduce: editing python document typing in a comment a contraction such as isn't that the editor creates a closing apostrophe that is inappropriate in this context.
Not sure if this is inside the extension or core. But I have seen issues with wrong auto closing often in selfhost too.
Well... this has been there since day 1. Does anyone know how JavaScript solves this, since it's solved there?


VSCode Version: Version 1.3.0-insider (1.3.0-insider) 2016-06-30T05:01:53.185Z OS Version: OSX 10.11.5 (15F34) Steps to Reproduce: a new document, type 'ab'. the editor caret between the two characters. . In any standard OSX text area, this results in the text 'ba'. In VS Code, the result is 'bab', which I cannot imagine justifying as desirable. Note that there is a separate behavior when the caret is at end-of-line: in the EOL case, the previous two characters are transposed. VS Code handles this correctly; it is only the "in between" case that is broken (as far as I can tell). Any fix should make sure to test both cases.
I had a look in the source to see if I could fix this since it's driving me nuts. :) I think it may be an Electron issue since I don't see where this editor command is defined. I'm new to the source code so I may be missing it, but I don't see where a command is defined for ctrl-t.
This seems to have gotten worse recently; occasionally ctrl-t will cause multiple lines of text below the cursor to get duplicated into the text buffer.
do you have any idea if the likely source of this bug is in the vscode or electron code bases? I also went hunting around in vscode and could not find anything. I tried downloading an electron tutorial app but could not find a text field in which to test the problem. Any guidance here would be much appreciated.
For what it's worth the Atom app does not exhibit the broken vscode behavior. However, Atom's implementation has slightly different behavior than 'traditional' bash and native Cocoa controls. The traditional behavior is to transpose characters before and after the cursor AND move the cursor to after the transposed pair, or if there is no character after the cursor (end-of-line case) then transpose the preceding two characters. Atom transposes before and after characters around the cursor but does not move them; for the end-of-line case it does no transposition but instead moves the cursor back by one character.
I would assume that the solution would be to manually reimplement it, like VSCode already does for ^a ^e ^b ^f ^n ^p This extension does just that. It'd be nice if the functionality of this extension were bundled, since it's basic functionality that works on every other macOS textbox. The Sublime Text selection transpose is just bonus that's really nice.
Verified that when the cursor is in between 2 letters, they get transposed. But when cursor is at eol, previously last 2 letters were getting transposed. That doesn't happen anymore. ?
I tried ctrl+t in TextEdit and implemented the behaviour I observed there. Is the behaviour different than what TextEdit does?
I was basing my comment off of the OP's
ctrl+t in the editor now transposes characters like the default mac text editor. IMHO that is a good thing.
sadly it only matches half of the behavior; there are two cases. When I reported this bug I noted that the EOL case worked correctly but the in-between case did not. Now as of insiders build it appears that the situation has been reversed. Could we please reopen the issue? Thank you.
I just noticed that the start-of-line case is also incorrect: TextEdit transposes the newline before the caret with the character after the caret while VSCode simply advances the caret.
I cannot reproduce this issue. Using VS Code 1.12.1 and default key bindings. Move to have this issue closed?
This can probably be closed; I believe Transpose has been rewritten since then for Sublime compatibility?
VSCode does not match TextEdit behavior in the following cases: (where n is newline and ^ is the insertion caret). In all of these cases VSCode does nothing where TextEdit does a transpose operation.
This can be closed. I can't reproduce this issue too. (version: 1.13.1)
I can still reproduce the cases I describe above on OSX; VSCode Version 1.14.0-insider . I think that in order to close this issue somebody needs to explicitly decide that they want VSCode to ship with default behavior that does not match that of OSX and Cocoa.
I can reproduce, too. VS Code's and commands both do something different with each other and both different from the macOS/emacs standard.


For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via


VSCode Version: 1.3.0-Insider OS Version: MacOSX 10.11.5 Steps to Reproduce: document with long lines (longer then screen width to the right and move the cursor to accordingly -Cursor is invisible
Unless I'm misunderstanding the issue, this is expected behaviour. How would you expect the editor to behave? This happens on every editor. If you'd like your long line to wrap, you can control that by setting the configuration to .
No, this has nothing to do with wrapping long lines. My cursor is literally invisible: !
Interesting, but I still can't reproduce... Can you provide a screencast or similar?
Where is your focus? The cursor blinks/is rendered only when the editor is focused
I tried reproducing it with new files, but I'm unable to. This happens with a few xsl files at work. I'll try to see if I can get a 100% reproducible file. The focus is in the active editor. I'm only moving the cursor to the right. Screencast: ! EDIT: The cursor is only visible for as long as it doesn't surpass the last character that was visible in the initial view region of the editor
Thank you for the gif! I've never seen that before. Do you see any errors in the console () ? I've quickly tried with a file with these contents but could not reproduce: Other things that might be relevant: does this reproduce when running code without extensions (close it completely and launch with ), did you customize the font and/or picked a different theme?
I found a way to reliably reproduce this issue. The missing piece was, that it only happens when you have split the main editor. I can't reproduce it with just one editor visible. Launching with doesn't help. I did try with the default user settings and theme as well, but without success. I managed to nail it down to the following steps to reproduce this issue: vscode random file (doesn't matter) the editor with (this is important) random code/text with long lines in one of the 2 editor panels
Forgot to mention: unfortunately there are no errors in the devtools console.
I'm also seeing this issue. VS Code 1.3.0 commit Windows 10.0. Edit: Oops, didn't notice that a fix was already committed yesterday.
can you try my solution in ?
Yes, but disabling extensions doesn't help. This issue only occurs when you have more than a single editor view. See:
We decided to fix this by removing the property from the tabs container. The visual impact is that if you use a theme that introduces a custom background color, it will only be picked up for the active tab. E.g. for our themes "red" and "abyss": ! ! To verify: be on windows have 2 groups open at least have enough tabs open to cause scrolling activate a tab that is at the end of the tab list in group one find a long line and arrow right verify the cursor is not lost
can I ask you to verify this on Windows using this 1.3.1 stable build: Thanks!
I verified this.


There is now a better Intellisense plugins for Vscode PHP: and . In it's known issues it says "There may be duplicate suggestions for functions or variables. This is because VS Code has it's own (very limited) code-completion support for PHP, and there is currently no way to turn this off." This indeed is annoying, the vscode suggestions are too broad and are just noise compared to accurate entries by crane.
It should be possible to uninstall the VS Code php extension.
fyi
I think crane still uses vscode's syntax highlighter for PHP. So if one were to remove VSCode's internal PHP extension, would it also remove the syntax highlighter? P.S. I think simple options would suffice, e.g. "", so it could be turned off.
Yes - but we can also think about splitting our extension into one part that does highlighting and bracket config and another that does completions. That would allow for more freedom.
This is now annoying the testing of proper language server in here : Quote: P.S. I think the option would be a simplest thing to implement for now.
Related
Any update on this?
I have been holding back the PHP IntelliSense release with intelligent completion for over a month now because it is useless if VS Code just spams the completion list with countless functions that do not make sense in the context. When will we get the option to disable or uninstall the built-in PHP completion?
I agree it makes sense to provide a temporary option to disable this. Just submitted a PR here:
Also just checking - at this point in time, is there anything else about the built-in support that is interfering with the experience? (hover, signature help, etc.?)
thanks for looking into this. Signature help is being implemented right now, iirc there is no built-in hover. It would be great if all of them could be disabled (everything except syntax highlighting).
I pushed the PR and changes the setting name for the code completion to "". If disabled, hover and signature help are also disabled.
I don't think the setting achieves the desired result. Setting to I no longer get completion suggestions even from PHP Intellisense extension. If have to use to trigger the completion suggestions list.
I don't think this is related, this only removes the built-in completion provider.
So something else which controls the display of suggestions list from extensions like php intellisense is broken?
Part of the January build. Add to your settings to disable all completions from the built-in PHP extension.


! H1 and H2 are not highlighted. The preview is fine. Tested on VS Code 1.3.1 on OS X 10.11.6
I wanna give this one a try. Here is what I have achieved so far. !
Couple of updates on this: to highlight both lines at the same time, the way I was trying above doesn't look practical. It automatically highlights the current line assuming a match of the begin, until it finds a non matching end/while (Basically the line highlights, and if the next line isn't a '-{3,}' then the syntax goes back to normal mode. alt heading 2 syntax (just the -{3,} part) is conflicting with the rule meta.separator.markdown, which takes precedence and hence the issue. Would it be a better option to fix this conflict instead?
It doesn't work with 1.9.0 !
I believe this is as designed. Getting the TM grammar to highlight both the lines is tricky. If you refer to my previous comment, the first point: This would be confusing for the user. In simple terms, it means that as soon as a user starts typing, the line highlights, and goes back to normal syntax if the next line is neither of the alternate H1/H2 (---/===) text. What do you think?
Is it possible to let the line white and if a line starts with --- oder ===, then this one and the previous one switch to blue? That is the same behavior like in other editors.


VSCode Version: 1.4.0 OS Version: Windows 10 Steps to Reproduce: the "editor.cursorBlinking" setting to either "smooth," "phase," or "expand." cursor either with mouse or arrow keys. The cursor briefly vanishes (as if it's starting the "blink" animation,) then immediately starts the defined animation.
Relevant animations in PR welcome
Just merged in the PR from . Thank you !


VSCode Version: Code - Insiders 1.5.0-insider (, 2016-08-09T16:02:06.523Z) OS Version: Darwin x64 14.5.0


In order to create custom keybindings to toggle focus between the editor and something such as the terminal panel, a command to focus the active/most recently used editor group needs to be . I believe this is the best that can be accomplished currently: Focuses the first group, meaning if the second or third editor groups were focused this would feel wrong: Or this which focused the most recently used editor group but opens the last editor/file in the group: Some context on request:
isn't that as easy as providing a global command that just puts focus into the active editor? E.g. ? PR welcome if you wanna give it a try.
yes, I expect it to be pretty easy.
got a better name than ?
works for me


VSCode Version:1.6 insiders OS Version: doesn't matter All settings related to css, sass, less, html, json and markdown. This might be because these come from extensions that are built in?
I've gone through the builtin extensions and opened new issues for each one that is missing setting localization. Please met me know if I missed any


VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !


VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.


VSCode Version: 1.7.2 OS Version: Windows Server 2008/2012 Steps to Reproduce: No shortcut (underline) for flie right click context menu. ! Such underline shortcut is very useful to fast open the file with VSCode with keyboard.
Are there any recommendations/specifications as to what the shortcut should be for this?
I think the installer is not in the repo ;)


Steps to Reproduce: panel, maximizes the panel out, the panel is no longer maximized but still much larger than usual panel, maximizes the panel
Fixed by


Test item VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-24T10:29:13.076Z) OS Version: Darwin x64 15.6.0 Extensions: None Steps to Reproduce: with: after in some size : : Same goes for single line expansions, although there it is not as bad because it is just one arrow-left key to correct.
Another CSS example is . Pressing when done should land the caret at the end of the line.
This is due to the way snippets get expanded. Take the below example of a snippet When you use the above in any file and after you enter the placeholder followed by ENTER, the cursor remains where the entry was made and does not go to end of line Is there any way to get the cursor to the end of the snippet after completion?
Yes, is the final cursor position which default to the end of the snippet. The sample above it is used to place the cursor elsewhere. Changing above to should do it.
! So the being the final cursor position is a standard behavior for snippets in general or is this VS Code specific rule? The reason I ask is, in order to fix this bug if I make an update to then I wonder if I will be breaking any other editor that uses emmet If it is vscode specific, then I'll make the fix on our end
That's a good question. It is default Textmate behaviour but I don't know if emmet is also Textmate...
emmet does borrow from text mate
Very cool!


This must have broken recently: !
The content is actually there in the DOM: !
Jan candidate?


<!-- Do you have a question? Please ask it on --- VSCode Version: 1.9.1 OS Version: Win 7/64 Home Premium SP 1 Please introduce a setting (ideally changeable via API) to allow an output window (panel) to NOT word-wrap. Reason: I've modified the TODO Parser extension () to write its output in tabular form, which is more concise length-wise. However, the unavoidable word wrapping in the output window usually messes up the formatting. In such cases, it would be preferable for an extension to be able to open an output window that DIDN'T word wrap, and allowed the user to scroll horizontally if required. This suggestion was mentioned as an aside at
This should be possible using language specific settings "[Log]": { "editor.minimap.enabled": false }
I think this issue was closed in error. It is not about the minimap, and changing minimap settings does not affect the output window's wrapping. This doesn't make any difference either: "[Log]":{"editor.wordWrap": "off"} Here's an image of the output window as it currently behaves with a single long line of text. I'd like the option to have this displayed as one line with scrollbar. !
Thanks for reopening. :)


From For a file such as: We currently do not recognize the file as python even though the internal python extension's contribution matches. The reason is that the entire first line has to match: This seems inconsistent with how TextMate uses , and some of our grammars use patterns that do not work well with this restriction, such as : which fails to match:
and Adding you since I had trouble tracking down who implemented the logic in originally. Do you know why we currently require the entire line to match? Can we do like the xml grammar and add to the end of some of the contributions?
sorry I cannot answer this question, the code was a long time ago (I think by ) and since then has not been touched. I am fine changing this so that we align with TextMate's way of doing things. Happy to review a PR if you are interested.


When I put a fenced code area in the middle of a bulleted list, I notice that list entries following the fenced code area lose their formatting, like so: ! Is this intentional behavior? Am I formatting my markdown wrong? Is there any way that I can have formatting in both the fenced code block and the subsequent list items?
The current formatting is somewhat off: the second list is treated as code block. ! This is expected and is in keeping with the common mark spec. The correct formatting would be to indent fenced code block as well: javascript for(var i = 0; i < 5; i++){ ("Hello"); } ! Our syntax coloring is off here though, with the indented code block no longer being highlighted as js
Okay. I didn't read the markdown specification closely enough to understand that the code block should be highlighted as well. I had tried indenting the code block, but when the indented code block lost syntax highlighting, I thought I was doing something incorrect. Should I update the title of this issue to indicate that the real problem is that indented code blocks lose formatting?
Thanks I've just gone ahead and updated the title of the issue to: "Markdown Fenced Code Block in Indented List Not Properly Highlighted". If you do not feel that the new title accurately captures the bug here, feel free to update the title again
New title looks good. Thanks!
I made an extension to fix this Surely it would cause side effects but it is worth it for me at the moment.


VSCode Version: 1.10.2 (code1.10.2-) OS Version: Ubuntu 16.04 LTS Steps to Reproduce: home directory w/ on AFS. . the following error: Code starts normally if moving the directory to a local filesystem and symlinking it in. I would reckon that it's probably not portable to put the kind of thing that is in the homedir, as it may very well be mounted in fun ways or on network filesystems. This behaviour is new since the previous release I ran, which I believe was .
Squinting at the it seems like sockets and other runtime files shall be created in , which on my system is down in .
Not sure what to do here. Best I can do is to recommend not using AFS. Does it support socket files?
I don't have any choice in AFS for my home directory where the default XDG config directory is located. Sure I could point the config elsewhere, but then I'd lose access to the same configuration across machines which is the whole point of a shared homedir. AFS doesn't support named pipes in the filesystem intentionally as it's a distributed filesystem and the semantics for how they would work across the world is hard to pin down. As far as I interpret the XDG specification, you should not use the config directory for runtime state. They explicitly mention the runtime dir for that. I don't know where in the stack this is done, but it's quite wrong to use the possibly shared homedir for machine-local state. supports things like 's named pipes
Got it, thanks.
the same thing for the socket files in /tmp/ like /tmp/vscode--a2f2-4ba7-8e8c- they should go in $XDGRUNTIMEDIR (if available, if not /tmp is ok). the benefit of $XDGRUNTIMEDIR is it goes away when the user logs out.
The same issue appears with sshfs mounted home directory
We were force to undo this change since it breaks many assumptions at startup, when this variable may or may not be set. Unfortunately, the correct workaround for these cases is to call code with .
Hi! Now 1.17. stopped working on AFS Not sure if the workaround you gave makes sense, as the $XDGRUNTIMEDIR directory gets deleted every time the user restarts. I would be happy if you could fix that. Thanks!
Does the workaround work for you at all?
Thanks for the fast reply. It does work for one session, but settings for example get deleted when I reboot.
Why is that? I don't really know AFS.
Me neither, but what I think right now: The XDGRUNTIMEDIR variable gives something like on my machine, which apparently gets deleted when rebooting or the XDGRUNTIMEDIR changes. I can’t say right now as I am not at my computer. If you call code using your workaround, all user data gets stored in that directory and is inaccessible after reboot. But the problem ia not the user data, it is the .sock file that has trouble with AFS. So it is just this file that needs to be stored somewhere else in a non AFS directory.
Currently the files are within user data dir. So... in your system should they live somewhere else? ?
Yeah, for example. I don’t know what the .sock file does, but if it is not a problem that it is removed after reboot that might be an option. But isn’t that what the pull request did? Just storing the .sock file somewhere else...
Yes, did exactly that, but based on an env variable, which is very problematic in many cases. So, I propose to introduce a cli option to set the socket files location on Linux. So you'd need to launch it as: Would that work for you?
Cool, I would expect that to work for me. Thanks! Let me know if you want me to test.
problematic in what cases? the XDG recommendations are pretty clear and easy to follow. You have a DATA dir, CONFIG dir and RUNTIME dir. There are environment variables to specify the directories or there are defaults when the env vars are not there. What doesn't work in vscode with that setup?
Let's talk Linux only. It makes a big difference in terms of process environment if you open an application from within a shell or using a UI gesture. The shell usually has all you favourite environments, often set up in files or similar (think , ). The process (usually some Gnome or KDE process) which spawns Code using the UI gesture doesn't have this environment because it never went through a shell, never really parsed and interpreted . So, users complain they can't use Node or Go within Code; the real problem is that Code's env doesn't match what their shell has. So: on startup, and only if Code wasn't launched in a shell, Code will the user's shell environment as best as it can. This is possibly a lengthy process (have you ever waited 1-2 seconds until you see that bash prompt?) so we can't have that as part of Code's critical startup sequence, otherwise we risk being slow to start as well. We do it in parallel while Code actually starts up and spawns a window. Eventually, when that env is know, it is promptly applied to all Code's processes. There's a race condition here. You see, we need to know the exact location of the IPC sockets at startup, before any window opens. If is (re)defined in the user's , we can't rely on it to compute the location of the sockets. We must know that value independently of the env loading code path. For the past few months we were relying on reading to determine the sockets paths. For some, this works well. For others, Code breaks in very unrelated ways: if is (re)defined in , there was a race condition between reading that value from and computing the sockets paths. It would often happen that the process which served the socket pointed one way while all other processes pointed the other way. We simply can't have that. One alternative for a fix is to ignore the value coming in from the user's . Do you think this would make sense?
XDGRUNTIMEDIR is typically set by pamsystemd, even before their Desktop Envrionment or login shell is started. If people redefine that in .bashrc (for interactive shells only) a lot of things will break for those shells. just an example of the sockets I have there (i.e. software that would break if I changed tne env var): So in conclusion I have not heard of anyone redefining XDGRUNTIME_DIR for interactive shells only, but if they do that, that's the users mistake to break things intentionally.
Alright, then let's do that: we'll simply ignore it when reading it after startup.


I love the peek window. It's pretty much the best thing ever. I would love it ever so slightly more if VSCode would auto-focus it and insert the cursor where it belongs. e.g. if I clicked "peek definition", the cursor should be on the definition of what I peeked. This idea seems so obvious I can't believe it's not part of the default implementation, but I know you guys have your reasons for doing things. If there is such a reason, could this at least be made a setting? Thanks guys!
Fiar request. The reasoning for focusing the tree of the left that you might wanna quickly skim through all references/definitions/etc to get fast overview. That's also the reason for changing the peek editor when the focus changes in the list. We could add a command that allows to toggle between the selected reference/def and the peek view and then remember where you have been last
Ah, I understand. Speaking to my own use case, I use peek definition at least 98% of the time that I use the peek window, so at least 98% of the time there's only one file in the tree, and highlighting the tree doesn't make much sense. (I think it's a bit of a UX problem with the "peek all references" - it feels a little too much information in too constrained a space, so I normally do a global search instead - but that's an alternate request.) Your toggle command sounds great to me. I would also love if there was a keyboard shortcut to focus back on the original text document.
maybe the focus should be on the peek editor directly if there is only one entry in the list, that would be very helpful.
Is there any progress being made on this?
Not entirely sure whether it's appropriate to add this here, but I'd also suggest two other things for the peek window that're in the same vein: the "Keep peek editors open even when double clicking their content or when hitting escape" into two. The two aren't really equivalent, especially since double-clicking selects entire words and I'd for example like to be able to that, but still be able to close the window with Esc. 'd suggest changing the tab order of the peek window for the editor to follow the list. That way, when the peek window is opened you can select the appropriate file and Tab into it instead of Shift+Tabbing.
Any push on this? this is a must have. I seriously don't know how people have gone without this.
This is an open source project, this issue is marked as 'help wanted', so how about you?
I'll give it a try, looking for a way to automatically focus on peek window when there is only one entry in the list, according to suggestion. Do you guys think it's a good solution?
I'd say a command to move focus between them and then a setting to define is focused by default is the better solution. That makes the behaviour predictable, e.g I often press Enter when having just one reference I wouldn't want a new line then
fyi - this is the place (and sample) for adding commands that use the peek view widget:
Besides, we still need a setting to define which component will receive focus by default when Peek Window is shown.
Sorry. I'm so far away from having time to learn how to contribute. I'd like to, but I'm still in college working on several other things at the moment. Also, wouldn't even know where to start learning how to build vscode extensions and stuff.
Hi, I'm a heavy user of peek editor. But I accidentally minimize the peek editor window , which means when I click peek definition or declaration or references, there will be just file along with its path that include the definition will display in the first row , and the editor window (which should be the second row) will not. I have tried many ways to get it back to view, but nothing works. And I search all the settings related to peek, but none of them are about how adjust the size of peek editor. Have you ever encountered the same issue? Thanks for your time to view my question.
fyi - I have change the setting to:


Testing Insiders dated 28th March, 2017 Happens in linux and windows <img width="333" alt="screen shot 2017-03-28 at 11 42 13 am" src=""


Testing in this setup Get this Code lense with '0 References' in ! Clicking the references link just shows an empty peek, it is not clear what is being search for. !
Now I understand what is going on: ! The reference in the template isn't found by the Angular Language Service extension.
Do you suggest we don't show the peek view from zero references code lens? Or should the peek view have more info on what would normally be displayed?
since the empty peek view is not helpful I would not show it and '0 References' should not be shown as a link on hover.


! Note the extra bar the right of the blue block quote bar
I hope my fix will work for you. :smile:


VSCode Version: Code - Insiders 1.12.0-insider (, 2017-04-13T06:10:58.128Z) OS Version: Windows_NT ia32 6.1.7601 Extensions: the listing exceeds the lower minimum of browsers' URL characters limit Steps to Reproduce: any file and try to horizontal scroll either via mouse wheel or shift scroll.
Hello i'm still experiencing this issue , I've noticed a separate issue was closed for Ubuntu users, but still noticing this with Windows.
This seems to be fixed in the latest release.
correction, this issue still exists.
/cc I'm seeing this issue again as well, on my Ubuntu work machine and on Windows: VSCode Version: Code - Insiders 1.12.0-insider (, 2017-04-21T06:12:00.370Z) OS Version: Windows_NT ia32 10.0. Extensions: ;
Some more info: shift+mouse wheel does not work, however when I use the trackpad and two finger swipe horizontally it works fine. Unplugging and plugging in the mouse again didn't fix it.
Hmm the trackpad usually is for forward and back commands. I can confirm this is the same case for me. I'm wondering if electron has switched the forward and back commands for the horizontal scrolling. Because in my mouse settings if I set the horizontal scroll will to page forward and backward it works perfectly. But I shouldn't have to do that.
I tried to reproduce and failed with my setup (Windows 10 and Windows 7 on macOS running in Parallels). Here is what I try: shift-scrolling in the editor wheel-left/right in the editor ! Are you doing something different? Does it reproduce when you run with blank settings?
I tried to reload vscode insiders without any settings, and i'm still having the same experience.
One other note, I have mac os sierra at my home workstation and everything works perfectly there. It seems to be Windows specific. I'm running Windows 7
Here are errors and warnings upon restarting insiders without typing anything. I wonder if this has anything to do with it.
I assume those warnings would go away when you run code . I would not assume however that this would help you for this issue, but worth a try anyway.
I wonder if we could do a little experiment. Can you: download run it from the window that opens make it small enough that horizontal scrollbars appear see if you can scroll ! If so, this would point to a general problem with our UI framework (electron) and we should report it there.
seems to be this line that's throwing an error which may be causing the scroll to not work.
I would think that is unrelated, but please follow my steps to find out more.
I downloaded () on the Linux machine that I can reproduce it on and I can scroll just fine. ! Note that after this gif I updated to latest and it still doesn't work on:
Sorry I didn't see your message until just now. Yes it scrolls fine. On Mon, Apr 24, 2017, 10:31 AM Daniel Imms <:
need your help here for more debugging. First thing that comes to my mind is to add a breakpoint into  to see if this is even triggered when scrolling horizontally?
it's hit, but is set, not as I would expect. ! is set though: ! Are we meant to handle manually?
any chance you could debug stable to verify that e.deltaX is set? Is there any other property that has an increasing value? /cc if you have any clues on this Looking for chrome issues I stumbled upon:
Fixed via
Thank you guys, very much appreciated. Have realized over the last few days just how much I depend on horizontal scrolling.
As i'm not familiar with the insiders release pattern, any idea when we can expect this to come down the pipeline ?
should be in tomorrow's Insiders build
Thank you Daniel Imms <:


VSCode Version: Code - Insiders 1.13.0-insider (, 2017-05-26T05:14:23.944Z) OS Version: Windows_NT ia32 10.0. Currently you can multi-select items in the Git files view and if you right-click, the & menu items will only open the file/change of the focused item, with the stage/unstage command work with the whole selection. It would be great to have these 2 command act upon the whole selection.


<!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.


Currently blocked by:
Branch is at
The arg is causing the issue on Windows. This: Calls which passes to .
It may not work because out-build doesn't exist. I can repro when doing:
After spending quite a bit of time looking into this, I'm pretty stumped on why this is failing. any help would be great as I'm not sure where to go from here. Here's what I've found so far: I can reproduce using the following: Unit tests on Windows fail at random times Passing shows the window and all tests complete, with KeyboardMapper tests failing which I frequently when running unit tests on Windows. ! Listening to the in addition to printing test names seems to stop at random spots, telling me that this isn't related to a single test. Here are the end of some logs from test runs:The test runner pauses for 2-5 seconds after a the last output and then exits.
I just tried to reproduce on Windows, for me the tests are looking all OK. Do you see the test failures on the command line as output?
the output stops before any failures example output: etc.
does this reproduce with mocha tests (and the exact same version that electron 1.7.4 uses) too?
Seems to happen when using node 7.9.0 as well which ships with 1.7.4. Currently the build machine is set up to use 7.10.0 (set in ).
Ok so it seems electron unrelated then. Can you explain this, are you saying the keyboard mapper test is causing this?
No, the keyboard mapper tests on Windows just have always seemed to fail for me a lot on most of my Windows machines.
Created to track upstream. It appears to be happening only when using because calls stop making it to the main process after a short period.
Possibly related:
Update: It appears is an issue with my home desktop only and is different to what we're seeing on the VSTS build server. So I started to add some logs and run more builds on VSTS to see what is going on and it appears like the tests are exiting with but is being set to 255. I made a change to the test script to change error code 255 to 0 to get around this issue since the tests were passing anyway After doing this I did a full build and it succeeded, however it does not launch. running with gives this:
That's pointing at , perhaps it's related to the snapshot stuff?
Commenting out the "Create loader snapshot" step from fixes the exception on launch Also integration tests are not running on VSTS for Windows, this may have caught the snapshot issue earlier.
When updating electron you must also bump the version of . Unsure if there is electron migration guide that should have been updated...
Added to the guide
Discussed with we will shift this to August.
could you look into the exit code issue when you get a chance? We're seeing VSTS giving an exit code of 255 even though appears to be getting called. The change for that is here:
When I log in to the build machine and try to run , the unit tests don't even run at all. All I see is two processes stuck. Do you see this too? ! I also can't find the build where you had a 255 exit code.
interestingly I just noticed that Electron marks 1.7.5 as "latest release" while 1.7.4 is still a pre-release. We should consider being on the latest official release if possible imho. ! !
well I've never been able to log into the machine, I an echo %errorlevel% and it was printing 255 after the tests. It looks like VSTS has discarded the build as it wasn't marked as retain. If the Windows builds succeed after this line is removed then all is well:
Update: I have Electron 1.7.5 on the branch , I'm running into build issues on VSTS/macOS though which appear to be related to using the new file watcher in the build? Not sure why an updated Electron would make this error occur yet though.
We got that error in the official smoke tests and Andre said in Slack that the Mac build machine was messed up. Try it again.
Will do


Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.


VSCode Version: Code 1.17.1 (, 2017-10-10T14:24:50.851Z) OS Version: Windows_NT x64 10.0. Current default keybindings on Windows: has two key bindings, which seems unnecessary. On Linux the default key bindings are (IIRC): Which makes a lot more sense IMHO. Also using this default on Windows would also align Windows/Linux key bindings and maybe even avoid complications like . (same for of course)
We will not change this. See


Generalization of Steps to Reproduce: a markdown file: the js code block, type Bug inserted. Root cause* Markdown defines and as auto closing pairs. Js does not. It appears that we always use the document language's autoclosing pairs instead of the autoclosing pairs of the embedded language at the current cursor position
Good catch, auto close should check language around cursor instead of model.
Another case: Based on JS's auto closing rules, we would expect completion to


VSCode Version: 1.18.0 / 1.19.0-insider OS Version: Windows 10 Steps to Reproduce: a Project with Workspace (Typescript) one external method inside other method in whatever class. Alt+F12 to open "Peek Definition" the method opened in peek definition .. bug reproduced.. file opened in peek definition now be opened in workspace. Even after save the file on peek definition, the file opened on workspace continue without save. <!-- Launch with to check. --Reproduces without extensions: No
Can you please clairify what the problem is. Here's what I see: ! Is the error that file from the peek definition ( in my gif) still has the unsaved indicator in the workspace, even after you save it?
Yes, even after I save the file (). Pointer with focus inside peek definition, and I press and after to save and close peek definition the file continue with unsaved indicator. This behavior did not happen, even after I change file inside peek definition the file changed would not open.
See my gif. Note that the focus is on the peek definition and when I press the saved file is not , but . I believe this behavior is wrong. !
As designed, we open editors that are dirty to prevent data loss.
But this is nothing intuitive See my image, not would be interesting working like this? When change file, show the little ball in peek definition. ! When click to or , then show the confirmation: !
and what should happen when you close the tab?
In this case if close the would could execute one stack of confirmation of files changed starting by
And if close vscode, then would be open the file on tab with changes before close. Like this no data is lost.
I do not like that behaviour, I prefer that one modified editor maps to one opened tab, anything else makes it very hard for the user to track dirty files.
ok.
I've been in Visual Studio to see how it behaves and actually vscode is behaving the same way it does. However, in visual studio when we save the file in focus inside peek definition the file opened in the tab is saved. I think vscode should behave the same way. In this case, I reiterate that saving the and not file when I am with the cursor in peek definition when pressing is a bug. ! Now, see this behavior on vscode on press !
?
Yeah thats a good one, lets take this issue to reflect that.
has there been any updates on this issue? I think this behaviour is rather reasonable and intuitive, though I'm kinda surprised this issue hasn't seen more activity (I'd expect more people to want this). I had someone ask about this very thing on my extension: and this could really help us:
I've found that adding the following to accomplishes nearly the same thing: Works for me since I don't tend to keep unsaved files open often. Might be useful for CSS Peek.
Hi I agree with guys, that is really annoying, I'm wondering why they still didn't fix this problem ... !!! why Ctrl+S work in peek preview ?!? its fine in Visual Studio
! I pushed a change to enable this by default if the embedded editor is focused. Pressing or will now save both the main editor and the embedded editor. Feedback welcome, it will be in tomorrows insider build:


Default order in keybindings (default keybindings and intelliSense) is: ==When you copy from keybindings view and paste: ==


Given , I should be able to Run In parent directory prompt, enter Get popup
Hasn't this issue been solved before ? If it hasn't I'll try to fix it.
Actually it seems the current solution can only handle in the config setting... but not in the input box!
hello I could take a look at the issue if no one is already assigned. It would be my first one. Regards, Pascal.
Hi let me know if you're working on the issue. I think I've found a solution.
go for it !


I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague: ! The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are: try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods) the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user) Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?
I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".
this request makes sense. Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint make your server crash and check if your message is coming through as a or as something else. Thanks
Do you mean the text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message. If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed ).
I mean let's try to see if your error "AAAAARGH" surfaces on our side. You should be able to just run regular vscode, F1 open developer tools, wait some time and put a breakpoint by openning a . Also try to put a breakpoint and check if the error stream spits up something.
The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file
Ok, I got breakpoints in both and . First wasn't called and the second was called but is and is . So seems like the message isn't there. For testing, all I've done is put inside my debug adapter. Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for . When something comes over and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).
That one (in ) didn't seem to be hit either.
Actually, I think I can repro this really easily by just putting in the constructor of the ? Also gets .
This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!
I have removed tha tag and plan to look into this issue this week. Thanks
Investigated and the issue here is that I am not getting any exception data from the spawned process. I simply get the code while all the other error chanels are blank. I am not sure what would be the proper solution here. Suggestions are very welcome. Also are all your debug adapters launched using node? If yes then it might be that our  launch is somehow eating up the error if it happens on startup. If this also happens for adapters which are not realying on node to be launched then is not to blame.
please try to disable the launch for node () and see whether this makes a difference. DAs should work independent from . But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).
Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel. My weekend is starting if someone is feeling smart code review and let me know if you find something fishy about stderr not being wired through.
Then you might want to involve/assign
I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.


From: Steps to Reproduce: VSCode Version: 1.20.1 OS Version: macOS High Sierra 10.13.3 Steps to Reproduce: markdown file markdown to first line in preview or double click on the first line Does this issue occur when all extensions are disabled?: Yes


I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:


In light themes the status bar text changes from white to black, but progress spinners do not so they're hard to see:
This icon is probably not themable yet. E.g. for the status bar feedback smiley we use trick to allow to change the color of it (). Depending on the outcome of we might move this into the notification area though.
fyi, the fix is to use a font for the icon (in this case our octicons). I found the sync icon fitting because we already use it for SCM sync: ! Alternatively we could use this animation: !


Issue Type: <bFeature Request</bVSCode uses different conventions for the problem counters in the problems view and in the status bar. The problems view displays: 1 2 ... 999 1K 2K ... 10K+ and the tooltip shows the actual number. The status bar displays: for errors/warnings: 1 2 ... 99+ and the tooltip doesn't show the actual number. for infos: 1 2 ... (always the actual number), the tooltip doesn't show the actual number. <img width="118" alt="problems-view" src="https://user-"<img width="108" alt="status-bar" src="https://user-"VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.4.0


VSCode Version: 1.21.0 OS Version: Windows 10 Redstone 4 Steps to Reproduce: create a configuration type: { "type": "node", "request": "launch", "name": "Stuff", "program": "${workspaceFolder}Stuff" }, Save correct behavior in drop down where you can select that item. the exact same item (change only the program path, leave name the same) as a second configuration. { "type": "node", "request": "launch", "name": "Stuff", "program": "${workspaceFolder}Stuff2" }, your new item missing in drop down because you used same name. same name, by changing "Stuff" to "Stuff2" { "type": "node", "request": "launch", "name": "Stuff2", "program": "${workspaceFolder}Stuff2" }, your new config shows up but you can not select it. (Hover over does not highlight item, clicking does not select item) VSCode correct behavior. Does this issue occur when all extensions are disabled?: Yes
working on this. fairly certain it's related to terminal disposal and issue drop-down options get updated before the instance count is changed. non- atomic from select box view. It would be very helpful for your review once I have something finalized , I think the order of execution is very critical here.
thanks for looking into this. I can review the PR once it is ready. We can verify if that is the same issue by opening F1 developer tools and checking the debug console for potential errors.
I was able to partially reproduce your issue. While I did not have a problem with two debug configurations with the same name, I did see the hover issue. It it appears that you can still select the item with the keyboard so it's actually probably a misplaced disable class within the CSS. It is also still possibly related to another index problem with a twist on the results. StayTuned. !
One thing I left out that I should have mentioned is I also have configurations spanning mutiple workspaces. This issue was in a single workspace, however I have multiple configs which it merges together.
cc: I can reproduce this in several ways. It appears to be an odd "sticky" class label within the list. I have a fix , I would consider the work around. I will commit tomorrow with comments to at least avoid the problem for now. do you use insiders to check after I merge?
I do not currently, but I can, I'll check it after the merge and let you know.
Merged into master. Should be a next insiders. I am not closing this issue as I still think this is a workaround.


Refs: I like that the relatedInformation message has a nice different verbatim font and that makes it differ well enough, I suggest to not use a different background as imho the effect does not look that nice and we do not do it anywhere else to my knowledge. Also in the F8 we do not use a special background !
Yeah, it's the default rendering we have for markdown. Not sure I have change that without making people sad...
Also, the bullets do not appear in the Problems pane or when F8. Why have them here?


When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !


Issue Type: <bBug</bNavigate to any reccomended extension with a screen reader. The reader will read the extension name, followed by "[object Object]", rather than showing that the extension has been reccomended and why. VS Code version: Code 1.24.0 (, 2018-06-06T17:35:40.560Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --


I've attempted to find any other requests for this but didn't seem to see any. At the moment the CVS context menu shows: ! Only "Pop latest stash" and "Pop stash..." are visible. Is it possible to change the default stash behaviour to "apply" rather than "pop"? Additionally, is it possible to add two lines under "Pop stash..." for the same actions, just using apply: Apply latest stash Apply stash... I just lost a few hours and considerable amount of hair when a popped stash was deleted. I then had to sift through doing on each . Having "Apply stash..." easily accessible might be nicer.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.676 --<!-- potentialduplicatescomment --
I suggest to simply add and commands.
is anyone working on this, if not, I'll like to pick it up as a
looks like it might already be done in
yeah, just confirmed, Thanks. If I may ask, is there any rule around tagging an issue that is being worked on as it would be multiple efforts if I happen to have started it without anyone's knowledge. I've been scouting for an issue with no assignee to work on :-( Thanks for the catch tho!


Issue Type: <bBug</bI haven't been able to reliably reproduce this, but it happens decently often. To repo: -click on a line in an editor (seems to happen more often if it is not the active line) of the time the context menu will open, but sometimes it just flashes in and disappears My guess is that it feels like some sort of conflict between showing a hover vs the context menu. And I'm not sure if GitLens plays a roll here or not (though it never happens with the native menus). Another observation, it seems to be more likely to happen right after you've switched to a editor as well (either that or just becomes less likely after the menu has been shown already or something). VS Code version: Code - Insiders 1.26.0-insider (, 2018-07-18T05:19:07.488Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<!-- generated by issue reporter --
I think vscodebot is drunk This should be tagged and likely assigned to
it just loves to classify things as terminal :sob:
Looks like this happens when the contributor codelens info gets to the editor which may trigger scroll which dismisses context menus. /cc
possibly related
I saw this issue while testing today.
was the behavior unique to the latest insiders or could you reproduce with stable
I tested only on latest insiders did not try on stable
/confirm still repro on 1.30.0 stable version
/confirm
Sorry, I still this one from time to time. Not fixed, but also no steps. can we add logging when programmatically(?) closing a menu, esp. withing 1sec of opening
do you know if yours is the case that a menu item is triggered immediately (because the menu was drawn under the cursor and mouseup triggers the item) or that it is actually dismissed?
That - unless the command is a no op. I think this happens when I open the context menu but not immediately interact with it. Can it be that while the menu is open and context-key events comes in, causing the menu (native. macOS) to hide?
oh, native case, alright, i'll dig into it
This is now reproducing with the custom context menus as well. The scrollTop change does not appear to work anymore(fully?). Something to note is that in VS Code, with the custom titlebar enabled or using a mac, it is not possible to scroll the editor with the conext menu open. Thus, dismissing due to a scroll event is now wrong (I think). Dismissal due to scrolling seems like it was for the benefit of monaco more than vs code. See Do you think we could switch to event? This way, I believe, monaco's behavior should be preserved and vs code would not have this event triggered because of the blocking div when a context menu is open.
:+1: That could work well.


Issue Type: <bBug</bI have a file named F1000-v117.au3. When copying/pasting the file, it creates a file named F1001-v117.au3. This is not the expected result. F1000 is the name of the file and not a version number that should be incremented. Changing the regex within the incrementFileName function fixes the issue. Basically, make sure the first section of the file name is numeric only. to VS Code version: Code 1.25.1 (, 2018-07-11T15:43:11.471Z) OS version: WindowsNT ia32 6.1.7601 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
PR for this is welcome It would be great if the PR contains a unit test fyi
I'll take a look tomorrow.
is the expected result right?
Actually it seems like other cases are broken now. Have a file , copy and paste it The new file is , in 1.26 it was
Thanks for finding that Due to that I had to revert the original fix. So now copying gives However this issue is now not fixed, but it was like that in previous stable so nothing urgent -removing mielstone let me know if you want to fix your fix and provide a working PR. Thanks
Hey guys, I took a crack at fixing this regex have some questions on how the naming / number schema works and I want to make sure I have an understanding of the naming schema. We have our cases here: suffix: prefix: single number: no number: ends with number: mixed (new case / why the above PR broke): prefixed with number: The issue is that mixing letters and numbers triggers the prefix regex which incorrectly increments the number. But all the different variations of prefix / suffix and single number / mixed with letters make this particularly tricky. It seems like edits need to be made to existing regexes to ensure that they are matching digit only groups. However, the above PR regex edits and the edits I've made consistently break other regexes. Any ideas or considerations here?
This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details . If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider. If you wonder what we are up to, please see our and guidelines. Thanks for your understanding and happy coding!


Testing When using the '...' menu to add sort filter options, the option becomes disabled in the menu, preventing it from being twice from that UI. I think it would be nice if the suggestions behaved similarly, not suggesting filters that are already present in the input. ! VS Code version: Code - Insiders 1.26.0-insider (, 2018-07-31T05:18:06.861Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --


Tested in Windows with Insiders for 8/1 Add a couple of spaces in the extension search box Move focus to any of the open editors Come back to the extension search box and enter a letter !


: Check whether it's ok to map to : Add 'null' or "None" item to enum : =- : ?? I don't see this in vscode's core settings Also, . Example:
These are the settings explicitly that I could find with a simple search. Of these, the HTML ones are the only concern. For most of them we should probably just get rid of accepting null, as it doesn't make a ton of sense to have just mean either default or some secondary default. But has very different behavior between and so we'll have to decide on something to do there.
[ ] : fix requires API discussion over adding an additional schema parameter [x] : fixes [x] : fixed [ ] : Probably wont fix? Would require some new components and UI/UX discussion. [x] : fixes
can you add some steps for how to verify?
Here are some settings with compound types - Test that they work as you'd expect. I can't remember which extension has the nullable enum but you can test it with a contribution like
seems to work for the first one, but not second. e.g. here I cannot type "null": ! I can only type numbers (I am on Windows).
For the null|number type, an empty input box will correspond to in the json


<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: master commit OS Version: macOS 10.13.6 Steps to Reproduce: clone vscode ouput: how to fix: update typescript version from to will fix it.


debugging the loaded scripts view open debugging, notice exception in the console can not reproduce with Stable so it might be that my listener refactoring caused this If you pause on exception you will see that caused it.
did you have a chance to look into this? Or would you like me to investigate? I suspect this is breaking the loaded scripts view and is the root cause for
no, please investigate since this and was working before, and I haven't touched this code for two weeks.
end session events are not arriving in As a consequence the tree for the session is not properly removed.
I see something differnetly, the end sessions are arriving however when the last session end arrives view starts refreshing the tree and while that is in progress the view gets disposed which throws an exception. Looking into a fix...
I have created a PR which address this issue


<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.28.0 (1.28.0) OS Version: macOS High Sierra 10.13.6 (17G65) Steps to Reproduce: a markdown file preview to the side ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.721 --- <!-- score: 0.717 --- <!-- score: 0.672 --- <!-- score: 0.651 --- <!-- score: 0.645 --<!-- potentialduplicatescomment --


Voiceover does not read new option details because of describedby issue. May require the new ARIA combo box model.
Any problem with me creating new tags for NVDA and voiceover like there is already a tag for jaws? Accessibility-NVDA Accessibility-Voiceover I will also volunteer to do triage on accessibility issues if I can identify them.


It's clear that the usual set of icons is a minimal case, and that you want the default set to stay minimal. But I think the option to differentiate between start with or without debugging is a feature that every developer could use. Maybe an option in the config to switch the current command to would already be enough. Yes, a plugin could add an extra button. But I don't think this belongs within a plugin, as it's an extension of the existing button. I'm willing to do the work required. But before that: what are your preferences?
this is a fair feature request. I would keep it open and wait if it generastes more user traction. For us to add it to the touch bar we would also need a new icon which would be easily distinguihsable from the current start icon (green play). I would also check what icon Visual Studio is using. The icon design is the actual work, adding is just adding a one liner here
Visual Studio uses a same filled play icon for the default start action. It differentiates with an outline version of that same icon for starting without debugging. Seems reasonable?
Makes somewhat sense. Can you design that icon froum our start icon? fyi
Wait, shouldn't it be the one from ? Anyhow, I made a mockup based on the old designs found in Visual Studio: ! The stripes indicate that it's faster than full debug. While the hollow arrow indicates that it's not as complete as debugging. SVG: Alternatively it could look like this: ! But, in my opinion, it does not convey the faster execution as well.
Not sure if the three lines fit the rest of our icons, I'd go with just the outline. Thanks for creating this!
I like how you explained the icons and I agree with your point of view. However let's listen to and for consistency just use the hollow icon. can you please provide the PR with that icon and we can merge it in. Since I do not have a mac touchbar I do not know, but does it support multiple themes? Do we also need to design the icon for the dark theme?
I'll check! I don't think it has multiple themes though. And what about the location? I think it's the white icon from the folder that's being displayed on my TouchBar. It's white and has a different aspect ratio. Should I redesign that one as well?
You are correct, here is the location So I would place it just next to that one. And yes the icon should follow the style of those icons, so an empty white triangle seems fitting. Thanks a lot!
Cool! One more thing: That icon is not an equilateral triangle. That's correct? Because I could fix both icons at the same time. The current options: <img width="1067" alt="screenshot 2018-10-19 at 12 04 50" src="https://user-"What's your preference,
I would not change the current shape. Though I leave this decision up to
About the theming: Apple states that you should supply themed images (black on transparent), but I don't see these in the VS Code codebase. So I guess Electron has a specific implementation to translate the png icons to TouchBar-safe icons. The png resolution does not seem to match up either, even though it does look good on the TouchBar.
Thanks for looking into this. I am not sure how to change the theme for the touchbar - if the theme changes and our icons look out of place than I would be open for a PR which does the theming of our touch bar icons
Pinging on the design decision.
Sorry about that, this somehow fall off my radar. Assingin to and November for discussion
I'll start a PR in the meantime.
Verification steps: a macbook that has a touchbar or use a file that you can run (i.e. python file with ) the <img width="80" alt="image" src="https://user-"button to start without debugging should run the file, similarly as going from


Issue Type: <bBug</bWhen working with tagged template literals in JS and JSX (styled-components is my use case), the backticks used to auto-close when typed, but that recently changed. The big issue though is that if you go into a multi-line literal, and then try to type the closing backtick, vscode inserts two backticks, leaving you with three. For example if I type: I would expect to have the closing tick automatically inserted and the cursor in between them. Instead it just stops there. If I then go on to enter some css and then manually enter the closing backtick, I get: I then have to manually delete the third backtick, as if I delete the second, the whole pair is deleted because of the auto-close rules. I have verified this is happening on Mac and Windows 10, with extensions enabled and disabled, and in the Insiders build. VS Code version: Code 1.28.1 (, 2018-10-11T18:07:48.477Z) OS version: Darwin x64 18.0.0 <details<summarySystem Info</summary </details<details<summaryExtensions (20)</summaryExtensionVersion ------ ActiveFileInStatusBar1.0.3 better-comments2.0.2 bracket-pair-colorizer1.0.60 vscode-eslint1.6.1 es7-react-js-snippets1.8.7 prettier-vscode1.6.1 dotnet-test-explorer0.5.4 vscode-styled-components0.0.22 mssql1.4.0 python2018.9.0 csharp1.16.2 vsliveshare0.3.790 indent-rainbow7.2.4 vscode-docker0.3.1 seti-icons0.1.3 code-settings-sync3.1.2 mdx0.1.0 vscode-status-bar-format-toggle1.4.0 vim0.16.10 quokka-vscode1.0.154 (3 theme extensions excluded) </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.498 --<!-- potentialduplicatescomment --
It seems to me the editor only adds backtick if it's legal for a template string to be in that place. However your example is only legal if styled components are allowed. Could you give an example with a valid js syntax? If it only happens with styled component syntax, could be it's a bug (or a lack of feature) in the styled component extension.
It works with just plain ES6 syntax as well. This example: Is valid ES6, no React/styled-components, and the same issue occurs when trying to type the multi-line literal. I should note that manually closing the literal on the same line does work okay, although it doesn't auto-close. It is only on multi-line template literals that the auto-close fires on the last tick.
I'm seeing this bug also in python, where backticks have no special meaning . Sometimes I use them to denote arguments in a user string: But when I type the second backtick, vscode inserts two, resulting in: Strangely, this only happens if there is before inserting the backtick. If I type insert in any other part of the string, the doubling doesn't happen. should I open a different issue with this problem, to be tagged as a bug? If so, does it belong here or to ? Thanks !
Can this be for this iteration?
As a workaround, set: Opened to track possible solution
Thanks for that! Anything workaroundish for the cursor coming inside to the next line with an indent on press Enter? !
FWIW, I found disabling the Babel JavaScript extension put a stop to doubling up on backticks when closing a pair. (However as I rely on that extension, disabling it isn't really an option.)


Issue Type: <bBug</bWith at least one folder loaded in Code: to Code Preferences Settings on either "User Settings" or "Workspace Settings" Notice tab spacing is jumpy when changing active selection. It should NOT be as jumpy. I believe it's caused by the text being bolded on active selection. <iDesired</i! <iActual</i! VS Code version: Code 1.28.2 (, 2018-10-17T00:18:43.347Z) OS version: Darwin x64 18.0.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Here's the
I'm not sure about this change, I think the bold is necessary to make the selected tab noticeable. Some themes hide the underline on the selected item, and in some themes, the color difference is not really noticeable. So I would worry that this would make it impossible to tell which tab is selected. I also don't really have an issue with the slight shifting, I've never noticed it before now.
We should try to remove this shift as it's not really smooth. In our other tabs (panels, settings json) we don't use alternate font-weights for active/inactive, so I think we should keep them consistent and the same. Alternatively, if we really want to make the states look different we could adjust the opacity (just like the other tabs) as long as they pass the color contrast ratio: !
I agree that it's not smooth. It's also not consistent with the other tabs in the product. There is a hack that can remove the shifting (discussed with this ), however I think that might be overdoing it to achieve this effect. I would add the opacity change as well to help reinforce the two states.
Should I just borrow the inactive color from the panel tabs, at least for the builtin themes? Or if I should use opacity, can you tell me what color/opacity to use? Looking through some popular ones, I don't think this change would be a problem for that many other themes really... Also for folder settings, the folder name and string "Folder Settings" are currently distinguished by size and color, so we might still need 3 colors.
Actually the current panel tab colors in Monokai don't meet the contrast requirement: ! !
We only need to meet the color contrast on the themes we own, which is light/dark/hc. Here's the contrast on the inactive text: Here's the colors and opacity for the active/inactive panels: For the folder settings, you can change the opacity to (which passes) and will end up looking like this: !
Not using the panel foreground color because the background is not always the same, but I think it looks good as is after the PR.


Issue Type: <bBug</b VS Code version: Code 1.28.2 (, 2018-10-17T00:23:51.859Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.504 --- <!-- score: 0.472 --- <!-- score: 0.457 --<!-- potentialduplicatescomment --


Issue Type: <bBug</bIn Lua, when comment contains "function", like: -- blah blah function then type Enter, the next line will auto indent for one tab, but it shoud not auto indent. VS Code version: Code - OSS 1.27.2 (, 2018-09-14T00:41:55.375Z) OS version: Linux x64 4.18.16-arch1-1-ARCH <details<summarySystem Info</summary </details<details<summaryExtensions (5)</summaryExtensionVersion ------ vscode-language-pack-zh-hans1.27.2 python2018.10.1 cpptools0.20.1 Go0.7.0 markdown-all-in-one1.7.0 </details<!-- generated by issue reporter --
Introduced by


Issue Type: <bBug</bthe settings editor a setting that has a dropdown so that the options are displayed editors The dropdown remains open: ! Not sure if this is an issue with the select itself, or the settings editor. VS Code version: Code - Insiders 1.30.0-insider (, 2018-12-03T06:12:08.874Z) OS version: Darwin x64 18.0.0 <!-- generated by issue reporter --
Nice, for me it even jumps to the corner of the screen for some reason after switching to the editor. ! I think we will need some way to hide the list when the settings editor hides? Is there a way to force it to hide from outside currently?
Ha, I was afraid this would occur. The _sticky flag that Jackson for debugging was changed to true in a recent PR. I was going to ask if this was intentional. My Insiders was just old enough to not have this. was this left as 'true' by mistake when you're doing some mouse work for list? I will verify if this is the case and fix unless requested otherwise...
Good catch, it looks like a mistake, I'll revert it so it can get into tomorrow's build. Let me know if that's not the case
Actually looks like you are on it go ahead if you want to create a PR.
Fixed with,
- you have to merge, I'm not allowed :-(


Issue Type: <bBug</bUsing similar contribution in extension: Command palette is doing it correctly: Keybinginds is only showing . VS Code version: Code 1.29.1 (, 2018-11-15T19:13:36.375Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.447 --<!-- potentialduplicatescomment --
I'm going to work on this.