If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.


opens the current directory, also opens the current directory - not the parent
Repros on master. Also: opens opens etc.
i see the bug and the fix is in - i guess a short term work around is opens the parent directory
yes the fix should be in the next release, adding a slash is a good work around in the meantime.
I hope something good happens here. cause the way things are going. pretty much saying microsoft has lost all control of windows


when a link, src or url... contains an underscore character ( _ ) , you can't distinguish it from a misplaced space character because of the default underline below the links.
Appears to be impractical to solve using in Chromium until it fully adopts the full CSS 3 spec on . What I'll do is use a instead. Tested locally, and it looks good to me: <img width="454" alt="screen shot 2016-03-30 at 6 04 54 pm" src=""
Fixed via


VS Code should optionally be able to sign git commits with a given GPG key, as it is a good practice for authorization nowadays.
Doesn't GitHub's authentication basically do the same thing, since you need to auth with GitHub to push to repos you have access to?
GitHub auth is NOT related to GPG-signed commits if I know right.
Basically, I would like built-in functionality for appending the command line argument to , as shown .
Sure, but isn't what it's accomplishing done by GitHub account/email linking? You need to link your email to an account and need credentials to the account to push.
GPG can be used in any git environment (for instance: GitLab, BitBucket, etc.) I though this could be actual after seeing the .
thoughts?
I'd argue that for any given repo, you'd either want to sign all commits or none. Based on that, I suggest to use the git configuration in your repo, , which will make git sign all commits by default. Does that work for you
I use exactly that, but when I try to commit from VS Code with that config attribute set, I get the following error output in the Git console of Code:
I misread the issue, I thought you were talking about the vscode repo starting to sign commits, not adding the feature. while looking into signing commits yesterday, this I came across this
Not just vscode is affected: If you're using an agent: As a workaround (a configuration change affecting not just vscode) it's possible to add to your For example, run Snippet from explaining : From what I've noticed, is now less verbose (doesn't remind me that I "need my passphrase" on ; is completely silent on ). I don't know what else this affects and thus I feel bad for suggesting this, but it works. If you're not using an agent: Again referring to Launchpad, you seem to be out of luck.
Thanks for that Does it solve it for you,
Well, having listened to I'm not signing my commits anymore, but thank you for all the help provided!
. It is not strictly accurate that signing each commit is "totally stupid."
it would be nice if vscode gave me the opportunity to sign a commit.
Signing commits is not "totally stupid" and, in fact, has very real security implications. Not all Git code happens to be "pushed" to Github or BitBucket. Many places use git internally for all sorts of things and git commit signing is a very needed feature and often a requirement. I am using a gpg-agent and still am unable to sign commits in VSCode, for what it's worth.
I found the two places that need to be modified for this to work, but wasn't able to setup the vscode repository properly (not able to run tests, linter hangs, unable to run electron) so I just dropped it. I'm leaving the links to the lines here in hope that someone will pick it up, and soon Funny thing is they both do the same thing, and they are both nearly identical, but one is written in async/await and the other uses plain function arguments instead of an options object. Is there a reason for this? Why not just abstract it out as another module and use it through that, would be less hassle maintaining it (and any similar parts that can be solved via the same solution).
^ seems that git support is divided into two parts - one is git workbench that's in and second is git extension (that's built-in?) Is there any progress on this?
i dont there is any work going on yet. I will pick this up but not until this weekend
I like to confirm I am starting work on this. I will a pull request with a WIP title to show progress soon
Hello here, I recently tried committing with set to . However the issue I encountered is related to my name: it contains an accented 'e' (é) and right now VSCode seems to have some encoding problem (at least with git): ! Which prevents git from detecting the correct GPG key.
Hi! Any progress updates? :)
got all the changes needed mapped now going to add menus items etc should be done soon just lots of test and things to write
I have the change almost complete just tidying up and getting ready to commit.
Pull request Added support to GPG signing hope all is oke
would love to see this.
Me too, it was to the June milestone that got me excited but now its back in the backlog.... So I don't know whats going on. The pull request is this one:
Please, that comment, which is purely subjective, is very old and it's quoting achieves nothing, but FUD. Impersonating authors on GitHub is easily done and signing ALL commits is good practice. Especially with hardware tokens, such as Yubikeys. I mean no harm with , I am merely showing how easy it is to submit a commit by another. I feel GitHub could do more here too. On the main page, images are small and easily distracted (I could even change mine, I guess ... and my name). But the "Verified" means we've signed that commit. I believe it's important, as others seem to have commented also. !
I verify ALL my commit is important and we do use yubikeys here at my organisation
GPG signing provides authentication on the commits themselves. What you said in and subsequent comments are irrelevant to the issue. Because without signing the commit, I can easily fake you as the author and submit a fraudulent patch (e.g. intentionally infringing copyright of your rival company) via other channels (e.g. email) to another committer, who will be having a hard time to know whether you actually wrote the patch or not. And if that committer push the CL to GitHub, GitHub will happily link that to your account. See this commit for example:
Hi all, no need to try to convince me anymore
YEAHHHHH!
This error git commit --quiet --allow-empty-message --file - --all git show gpg: cannot open tty `no tty': No such file or directory error: gpg failed to sign the data fatal: failed to write commit object can be cause by password protected gpg key.
something related to the error you seen:
I got it to work for me, but only after signing a previous commit (~5 minutes prior) manually through the integrated terminal. I have a hunch that the root cause of the error message , is that VS Code is requesting to open the prompt, and failing to do so. If you already entered your password via prompt previously, VS Code signs the commits perfectly fine.
You'll probably want to use a pinentry program that remembers the pass code or prompts graphically. (sorry if terse) On Tue, 17 Oct 2017, 08:33 Jeremy Loy, <:
usually you see this problem when you dont things set up properly for gpg signing. that has been my experience
In Linux, I solve /dev/tty problem by adding binary exec of gpg2 path to git global config


Integrated terminal master issue: Open question: Currently pressing <kbdesc</kbdwill hide the terminal, this can be a problem for some terminal programs, for example . Perhaps this should be configurable?
Thinking about desktop terminals, such as iTerm, I can only close them via a global shortcut, an button or running in the shell. <kbdEscape</kbdshould not bubble outside to the workbench.
Marked as candidate as it's a very simple change that's been reported a bunch of times.
Cherry picked to release/1.2


I am using VSCode on Ubuntu 14.04 x64 VSCode About: Version 0.10.10 Commit Date 2016-03-07T10:30:20.458Z Shell 0.35.6 Renderer 45.0.2454.85 Node 4.1.1 Steps to Reproduce: a git repo folder a change the "GIT" tab typing a git message I am thinking of a counter starting with 50 (The number of character that'll be used as the short message appearing in git commits), it helps write meaning full messages, without have a word cut and completed in the description part, the behavior is taken as is from GitKraken
My suggestion would be to, instead of always showing a counter, when the first line's length has surpassed 50 characters. I'd gladly take this as a contribution PR! Wanna give it a try?
It seems easy to implement this, can I give it a try?
Absolutely, looking forward to it.
It unfortunately seems as if is no longer working on this.
Please bring it back!


when i want to compare a local file with a online resource file, i need to save the online file in project folder, and then do compare. it's a little inconvenient. It'll be great if i can copy the content of the online file, and right-click the local file, and choose "compare with clipboard".
An extension would be ideal for a feature like this.
fyi
It would be great too if also is allowed to compare selection with clipboard.
It would be great if we could compare unsaved files...
I would be open to a PR here, I think it is not a lot of work. Some pointers: register a new text document content provider to be able to open the left hand side of the diff editor to be the contents of the clipboard (pointers: ) register a new action to diff the current editor with the resource that can be handled with from the text document content provider (similar to ) Due to sensitivity of data inside the clipboard it would probably make sense to ask the user for confirmation that the clipboard is accessed. Related to
Has someone taken up this issue? I am a complete beginner to the VSCode codebase, would I be able to contribute to this issue?
not yet, but it seems has started a similar PR in which could be used as input to this one. The difference is that the contents of the left hand side are coming from the clipboard instead of the file on disk.


VSCode Version: Version 1.3.0-insider (1.3.0-insider) OS Version: OS X El Capitan 10.11.5 Steps to Reproduce: on the non-link area of a code lens line that nothing at all happens Would really like it to at a minimum to focus the editor (if not already focused), but we really love it if it move the cursor to the previous line. I find myself VERY often clicking on that area to start typing above it and nothing happens.
I'm assuming (maybe) that this wouldn't be a difficult change -- so if someone had the time to point me in the vague direction, I would be happy to attempt to open a PR for this. :)
PR welcome! :) It is in I would extract the code that does the focus: to a closure called inside the method. Then, at you can call and then : The reason focusing is complicated is because IE has some weirdness around redirecting focus when coming from the URL bar and doing a mouse down. And the already is a good indicator that the view zone does not want to handle mouse events.


VSCode Version: 1.5.0 OS Version: OS X 10.11.6 Steps to Reproduce: this snippet to use Then the example Focus is on the newly created terminal and not preserved.
Bug for


VSCode Version: 1.5.3 (commit ) OS Version: Ubuntu Linux 14.04 Steps to Reproduce: some code that prints the characters to the output window. are incorrectly turned into a newline. F# Code: Output: This has already been reported as , but that bug was incorrectly closed as "working as designed" because it was assumed that the code in (I couldn't trace it further back than that). The character sequence is not the ANSI escape for a linefeed/newline; in fact, , since ANSI just uses the single character for that purpose. It's pretty clear, looking at the code, that that's what was the regex was intended to be set to in the lines just above the : it is set to . However, is actually an invalid Javascript hex escape. The specifies that must be followed by two hex digits, because otherwise the sequences (U+0007 BELL) and (U+000C FORM FEED) would be ambiguous. So is an invalid sequence, and is instead interpreted by Javascript as the character followed by the character (the backslash is swallowed). So the correct fix to bug is actually to replace that regex with . Then one could notice that the code immediately below is replacing all occurrences of with , which is a no-op since is . So the regex and the line serve no purpose but to slow things down by spending O(N) time doing a no-op regex search. They can safely be removed without affecting any other code, and this would actually speed things up a fraction.
fyi
Yup, we should look into this and fix
might you be interested into doing a PR that fixes this since you have already done this great analysis? If not, we can follow your analysis to do the changes you proposed. Thanks either way!
Sure, why not? Here's the PR. Do you need me to sign a code licensing agreement of some kind before it can be merged in? If so, let me know how. UPDATE: Oh, I see that MSBOT replied on the PR's comment thread. I'm not surprised that no CLA is required for a commit that removed two lines and none.


VSCode Version: 1.6.0 OS Version: windows7 Steps to Reproduce: Create a vscode extension project. Pull off the cable to keep offine. Launch Extension (F5) I cant set breakpoint in my source file. And I find some warn information in Extension Development Host Window : I change the code in Its works. fyi
Sounds like a potential PR fyi
Yeah, PR welcome.
can you elaborate why your change is fixing this? If I look at the docs of I can see that host per default is .
can`t be resolved when being offline. And fyi
thanks


When you hover over a type in a TypeScript file, the tooltip that appears has a very low max width, making it difficult to read long type signatures.
I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!
! Errors are quite unreadable if the width does not adapt to the font size.
! it would be nice if the tip used the available space instead of wrapping at an arbitrary point in c# too
!
! Same problem using rust's language server.
General styling control would be very helpful. Also line-height. Another approach would be to have a bottom panel that displays the full error and the tooltip displays a shortened version.
!
! When using the auto import feature it is often impossible to differentiate whats what as the import path is cut off due to the limited width of the suggestions window.
Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well. !
Same in Python. We have to jump through hoops trying to flow doc nicely. And when it appears OK on Windows, it breaks on Mac... ! And it is inconsistent. Ex, hover is OK ! But completion list decides to wrap. What gives? ! Looks like hover respects markdown while completion item doc is plain string and gets wrapped randomly.
!
Someone say long type signatures? !
Here is a workaround by hacking the file "C:Program FilesMicrosoft VS Coderesourcesappoutvsworkbench" Simply append the code above after the original content of file, and restart VSCode. (Title bar may alert a warning message "Not Supported" and hacked changes would be overridden by updating VSCode) !
It would be nice to have some control on the width. The above does work but vscode presents the message your installation may be corrupt on restarting.
Instead of hacking the CSS directly as mentioned above, I recommend using the to just override the current CSS. That way when VSCode updates, you can just reload the custom css file that you have specified (personally, I have a project where I hold configurations for my shell, Spacemacs, etc. and this custom CSS file goes there). Until it's officially supported, hacking the CSS is likely the best route. The suggested widths above were a bit much for me, so I settled on the following values for now:
What is preventing the devs from providing a configuration option for this? This issue has been open for almost 2 years, and it bugs me on a daily basis. Would love to see it fixed.
(since you seem like the most relevant person to ping) is anything likely to be done about this?
I would love to hear an explanation from devs too. What are the difficulties of implementing this? I imagine it's settings a dynamic max-width and adding some more lines to add it in Settings. Are there other design blockers?
Will you take a look at this? In 3 days it will be a 2 year anniversary for this simple feature request.
Assigned to and as I remember we are going to have some UX improvements for editor tooltips and so on.
maybe now is the time to take this on? current iteration tries to solve parameter hints ux and this is not that much different
! I employed CSS and put together full instructions: [Custom CSS and JS Loader extension][1] macOS VS Code: VS Code Insiders: Linux: : [1]: Restart VSCode Ignore "VSCode is corrupt" error You can choose to suppress this notice forever Run command "Reload Custom CSS and JS"
just as a disclaimer, if anyone modifies the CSS/JS of the app, it comes up at “corrupted” in diagnostic checks, and you’ll typically get pushback if you report issues and include diagnostic information. Or, at least, I received pushback when I had custom CSS/JS enabled, and wouldn’t receive help until I turned it off (even though it was harmless/not related to the issue I was having). While this is indeed an okay workaround, we should just keep making our voices heard so that this is natively supported.
100% agree. This is just a workaround. It's hard enough to read TypeScript lint as it is! :)
Currenlty using VSCode 1.30.2, followed instructions step by step, but it's not working. I don't even get the VSCode corrupt error. I'm running Windows 10 (V.1803). Edit: It was my mistake. For anyone who's having trouble, make sure to run Enable Custom CSS and JS from the command palette. Simply restarting won't work.
This issue seems to be fixed in 1.32.0-insider (1.32.0-insider) . I hope this is an intended behavior. I want to thank the developers.
This change is related to . I confirmed that the max width of is still small as mentioned above. <img width="867" alt="2019-02-22 17 06 19" src="https://user-"
Update: in , only the hovers for problems and the hovers with code blocks become to have larger width. Others have smaller width.
Hello there,your solution is great,but I want to ask how to get rid of the word at the title.As sort of OCD,sufferring from that. thx a lot!
This extension was created specifically for solving this:
This has been a long standing annoyance, with an issue that's like 2 and a half year ago. It shouldn't take much effort to have a config property that overrides the width/height of the tooltip, surely? Like, 10 mins of effort? <img width="525" alt="Screen Shot 2019-07-18 at 6 41 15 PM" src="https://user-"
if it's really 10 mins of effort, then I'm sure you can submit a PR for this? I definitely can't do this in anywhere close to 10 mins, so it would be much appreciated!
Seriously, I want instead of this: ! At least something like this (with syntax highlighting it will be even better): !
There's already been a PR. I really don't understand this. I figure most VScode devs develop VScode in VScode, are they comfortable with the current state?
fyi, it would be great if the hover could be resized
How is this issue 4 years old and such a basic thing still isn't implemented?
Is there any word on whether we could see this soon? The suggestion widget has had resizing enabled since v1.51 in October, 2020. Is this tooltip widget considerably harder to add this feature for or are there additional considerations to be made? Whether it's a click to resize, or a manual adjustment in settings, could we have an update on the status of this addition? Opening new editor tabs just to properly read code annotations for some more descriptive components on my large monitors does feel like an unnecessary extra step.
might be very related and close to what you did here:
Hi, Instead of configuring the max width as the title says, could the tooltip hover be resizable ? (Also check for more info on what was done with the suggest widget)
It's sad to see that it's still not a thing.. I would really like to adjust the height of hover description tooltips.. The big brother Visual Studio does a much better job already. Let VS Code catch up a little..
another possible view for this issue
It is 2022/11/11. Christmas is close and I made sure Santa knows what I want!
"Excuse me, it's 2023"
This one will be my favorite. Copilot suggestions and TS errors just can't be seen in this tooltip. It's time to fix it.
If this is still open and no one is looking at it, I'll take a crack at it. Feel free to assign it to me if that's alright.
Hey all, thank you for your patience. A PR has been made which is currently under work but nearing its completion. You may find it here: Once this PR is merged, you will be able to resize content hovers within Insiders.
Would you add "Reset Hover Widget Size" command in Command Palette? Like we have for suggest widget: "Reset Suggest Widget Size". It would be good if we could reset the size to the initial one.
Thank you very much. 1 Is it correct, that this would not stay across different sessions? 2 The default max width is very small, is there any consideration, of increasing that?
Will this feature also allow us to define the window size of a hover provider in a extension above the current limitations?
Hi if is is decided that the hover widget size should be configurable, there will be a command to clear the persisted sizes. This feature is still under discussion. Hi depending on the implementation, it is possible that the persisted sizes are persisted or not across different sessions. This is still under discussion. Currently the implementation is such that the maximum natural width is the same as before. Hi the current implementation does not provide this functionality. This could be addressed in a separate issue as it is related to the usage of the hover widget by extensions. The current PR that is worked on is the following:
Thanks a lot. And do you consider increasing the default size, that is unfitting to most real world scenarios? The windows is so small, that I feel the need to increase it even on my WXGA Laptop.
Hey all, thank you for the patience. A PR has been merged in order to make the content hover resizable. The change should be visible in tomorrow's VS Code insiders version and in the next stable release which will happen in the coming two weeks. There currently is no mechanism to save the content hover - we are discussing how best to approach it. You may track the issue on persisting the hover content here: we are currently not thinking about increasing the default maximum size. However it is possible that we implement the persisting mechanism as follows: when you increase the content hover size to a specific size, this size is persisted, and it is applied as maximum default size on the next hover appearances. This potential implementation is still under discussion by our team.
Just want to say thank you you seem to have been tackling a lot of these high-level nitpicks that have been in the VSCode backlog for years, and for that I am very appreciative.
I can't find a command to clear/reset hover widget size, is this has been ?
Hi currently the command does not exist because a persisting mechanism has not been put into place as of yet. It will appear when the latter is .
Oh okay, thanks a lot


VSCode Version: 1.7.2 () OS Version: Windows 10.0. Steps to Reproduce: a file a sentence of text such as Lorem ipsum sit dolar amet. your keyboard cursor after <kbdTab</kbdExpected: Spaces or tabs to be between and Result: word gets converted into an XML tag and auto closed, leaving us with <Lorem</Loremipsum sit dolar amet. !
This is coming from Emmet. To disable this, add: to your settings. Although this is currently the expected behavior, I think we should probably disable emmet expansions in markdown by default because this behavior can be annoying during normal writing. Any thoughts?
this behaviour is a consequence of , which has as the goal to not hard code in which language modes emmet is enabled for. As a heuristic uses the grammar's scope name hierarchy as a hint. This heuristic has worked pretty well. The scope of the markdown grammar is . This means Markdown is treated as a specialization of and since emmets supports , is enabled in Markdown as well. According the emmet doc there is no special syntax profile available for Markdown So a quick fix would be to: hard code an exclusion for markdown in #isEmmetEnableMode change the scope name of the markdown grammar, so that it doesn't inherit from html, not sure what the consequences of this are. do you have other ideas how to improve the support for emmet in Markdown and avoid the surprise described in this issue?
Hello, I see the same way as you suggested above. But, perhaps, we can also disable Markdown in the settings, as it was for . If you decide to disable Emmet inside Markdown, it is better to first option. But my 2 cents: Markdown is a lightweight markup language and it presupposes the existence of HTML constructs within yourself. Thus, it seems to me, to disable Emmet inside Markdown is not correct. P.S. Small news: the creator of Emmet had already started work on the second version aka 2.0.0
thanks for the feedback. I agree with your point that disabling emmet without some way to re-enable it, if someone really wants emmet is better than to totally disable it. Glad to hear about Emmet 2.0.
Could just be in the default setting for ? That would stop most users from triggering emmet unexpectedly in markdown files, while still allowing users to opt back in to emmet for markdown if they wish
the idea is good. It has a small drawback. If someone defines in the settings, then they will not profit from this fix. However, if someone if familiar with this setting and then they know how to disable emmet in markdown, if they are annoyed by it. Bottom line I'm fine with this fix.
Ok, I've merged in which adds to the default list of excluded languages. Not a perfect solution, but it should stop many users from hitting this behavior unexpectedly


VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-06T16:53:46.634Z) OS Version: Darwin x64 15.6.0 Testing The current message seems to general: "For better performance exclude folders with many files." "better performance" is to weak because the typescript server basically shutdown and won't provide any of the advanced features. "folders with many files" is vague, it should mention JavaScript/TypeScript files that the user does not work on (like packages/libraries). could also mention that this happens in the js-, that would set the right expectation for the 'Configure Excludes' button and also inform the user how this can be done manually. Needs more thought: "Too many JavaScript/TypeScript files: To enable advanced editor features in JavaScript/TypeScript files exclude large folders with source files you do not work on." /cc
Also, the status bar button might benefit from being specific about the language it refers to.


VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-20T14:58:38.006Z) OS Version: Linux x64 4.8.0-34-generic Extensions: TypeScript file: ! Press enter: !
verified.


Particularly on Windows, should be called to terminate the process. This will ensure the sockets are closed and the pty agent is shutdown.
Closing in favor of


<!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.2 OS Version: Mac OSX (10.11.6) Steps to Reproduce: VS Code integrated terminal a relative path (eg. ) Description: Let's say you have a build system that outputs a stack trace on a build error or failed test. If this was run from the integrated terminal, the file paths in the output should be included as clickable links which can be clicked to open the file in VSCode. However, this only works if the path is either an absolute path (e.g. ) or a relative path that begins with "./". Many build systems and tools output file paths relative to the directory the command was run, without the leading "./", Karma for example. So the output would be something like: , not . The first is not matched by VSCode as an openable path, but the second is. I believe that what is determined to be a path comes from the Regex in "" Is there a reason why relative paths of this form (e.g. no leading "./") are not included?
The reason was because until 1.11 links aren't validated so there would be heaps of false positives. Performance was also a factor but it shouldn't impact that much really now that I think about it. Now that links are validated maybe we should be more lenient when linkifying.
I'll assign this to April but if someone wants to do a PR before then you're welcome. You will need to: Modify the regex to allow paths that are not qualified with , , etc. Make sure that the new path matcher does not conflict with previously matched links and does not create links with adjacent characters. Eg. we want to avoid this:
Nice. I'll write a PR...
That would be awesome :+1:
Fixed in


VSCode Version: Code - Insiders 1.11.0-insider (, 2017-03-17T08:14:15.805Z) OS Version: Windows_NT ia32 10.0. Extensions: ; Steps to Reproduce: a terminal and run "bash" with a text file containing some lines of text ctrl+v (or right-click) to paste some lines of text What's expected: The text should be appended before the cursor, and the existing text should be there after the cursor. What happens: Existing text disappears, and it seems some extra newlines are when pasting text. Note: there is no such problem when doing the exact same steps with This happens on insider builds, no idea if it happens with standard builds as well.
More information. Here is what happens when I try to paste this text function startagent { echo "Initialising new SSH agent..." /usr/bin/ssh-agent | sed 's/^echo/#echo/' "${SSHENV}" echo succeeded chmod 600 "${SSHENV}" . "${SSHENV}" /dev/null /usr/bin/ssh-add; } In the middle of a file containing this text: existing file with some text Here is what happens with (that's what expected: text is pasted in between existing text): ! Here is what happens with VSCode: text is pasted with extra newlines plus existing text appears in the middle of the pasted text !
Any update on this bug ?
Thanks for the ping. I've validated it's definitely an upstream issue. I tried to fix it a couple of days ago but didn't get anywhere. I'd guess it's related to node-pty or winpty as different shells appeared to handle it differently. It also seemed somewhat inconsistent. No plans to invest further in fixing it just yet.
This is probably a bug with VSCode's JS xterm module, not a node-pty or winpty bug. I placed these two lines in an untitled editor window: I then set the environment variable , started VSCode, and copy-and-pasted the two lines above into VSCode's integrated terminal. This appeared in the winpty trace: The clipboard has CRLF-delimited lines, because we're on Windows. However, in the VT/100 input format, CR means Return, and LF means Ctrl-Return. Something (probably the JS xterm) is copying the clipboard contents into the pty, and that something should normalize LF and CRLF into CR. I described this bug in detail the last time I saw it:
thanks! This is likely the culprit then which replaces all end of line chars with on Windows:
Yeah, I think your change will fix the issue. The function looks like it might also need a change. Maybe something like this?
FYI I think you may have run into these issues before? It would be a good idea to test these changes in in tomorrow's Insiders build.
I've certainly experienced aspects of this issue from the Python extension when running selections of code in the terminal.
I was unable to reproduce the problem anyway, so have no way of testing this. But thanks for letting me know :-)


Chrome-debug supports .js files with query parameters (). But if I load one with "Open loaded scripts", the query parameter is stripped. This happens here: since fsPath doesn't include the query parameter. Any idea how to make this work? I don't think URI is expecting to have a URL with another scheme.
That normalize code should only be executed if the source could not be found - otherwise should not be and the should be passed to the adapter. Do you know why is that? As for the call - I am not married to it and we can change it to whatever uri massaging techinique would work for you and not break the existing behavior. If we change this I would prefer to be in debt week -april
It tries to get the source from , but it looks like that is only populated when it breaks in there, right? Plus it's a different format, the script from the quickopen starts with but the ones in don't.
I don't know about replacing , would do it if that isn't too hacky.
Yes, is only populated once there is a call stack that contains that source - so if it breaks. Yeah that feels like a total hack. Why don't you experiment with different solutions and create a PR where we can comment and try out different approaches if needed?
This regressed from adding back the in DebugContentProvider.getTextContent. is that needed?
Also,
I think opening the file by putting its url into a uri is very fragile, to say the least. I have listed some problems I've noticed while implementing a Loaded Scripts Explorer for the Firefox debug adapter in . My suggestion would be to add the ability to open files using the numerical that the debug adapter assigned to them or using the object that is used for identifying the file in the messages between VS Code and the DA. Whatever solution you adopt, keep in mind that VS Code should be able to determine that the file opened by clicking on a stackframe and the file opened by clicking in the Loaded Scripts Explorer are one and the same - otherwise setting breakpoints in a file opened through the Loaded Scripts Explorer will become problematic.
I've addressed this issue by making sure that the flow -uri -preserves the data so that the initial and resulting objects are identical. The "path" attribute of the source object can contain anything, e.g. a file system path or a full URL. So if a Uri is constructed in the following way: the debugContentProvider inside VS Code will retrieve the content by sending a "sourceRequest" with a "Source" argument to the debug adapter identified by the debug session.
Verify that Rob's Chrome-debug case from above works.
It is escaping the query parameter, but works anyway using the new loadedSources API, because then we can rely on sourceReference instead of a string path.
I have also seen this (with the Firefox debug adapter) and couldn't find any user-visibile ill effects. In particular, the source url is displayed correctly in the tab opened from the Loaded Scripts Explorer (i.e. the query parameter is unescaped there and other escaped characters in the url remain escaped).
Added "Verified" label since both comments from above confirm that this works correctly now.
It does rely on me updating chrome-debug, in case anybody else tries this. I'll do that this week.


Variable substitutions that are available for (see ) do not include currently selected text. I am looking for something similar to $(CurText) that is available in Visual Studio Arguments for External Tools (see ). Please add a variable ${curtext} which would be replaced with the currently selected text in the editor window. If no selection is available, it could use the current line at cursor position.
Nice idea, but I think it's too late for implement that in the current milestone...
Fixed by in
Verifiers: what happens if all text in a 300 MB file is selected...
good point. Maybe we should put a limit on this. Or only to copy the howl line at most (even though the line could also be 300mb I am fine with that) thoughts?
Selecting lots of text, at some point I get . If there's a predictable limit where this will fail, we should just cut the string off there. Unless only sending part of the text could be dangerous or unexpected for the user. In any case I think that sending multiple lines of text could be useful.
there is not a predictable limit since the variables are used in different scenarios. If somebody has an idea for a limit I am open to PRs


Platforms Tested: Insiders 5-30 Code 1.11.1 Stable Windows 7 OS X Sierra (should be all platforms) Problem: Output panel drop-down does not track current active output if output channel is activated later , typically when an extension output Channel is active (eg Git). Output select box will show the default 0 index output (Tasks) Steps to reproduce: Open code with git repository/workspace select Git output Channel close code reopen code Git output will be active but drop-down shows Tasks Fixed with PR always update active select box selection with setOptions call on any output channel update Tested on Windows 7, OS X
Fixed via


Testing Steps to Reproduce: integrated terminal and open the find widget the integrated terminal area very skinny bug The find widget starts overflowing into the explorer area: <img width="420" alt="screen shot 2017-06-28 at 1 25 51 pm" src="https://user-"
After , no more overflow but we now clip the find box: !
I guess we want it to be tiny like in the editor: <img width="221" alt="screen shot 2017-07-07 at 3 02 45 pm" src="https://user-"


I noticed that the terminal no sends Operating System Commands (OSC) like setting the window title. Right now the task runner filters them but this gets more and more complex and I am actually not an expert with this. So I would like to request that the terminal provides API to notify data without control sequences. Currently I used these two regular expressions to filter them:
There are two unknowns to me right now with this: Various control sequences can do , so where is the best place to gather this data? It might be worth seeing if adding listeners to will give what you need. How do this efficiently. Because a lot of data can stream through the terminal, we should probably only enable this when it's explicitly requested (ie. only fire the event if something is listening). It should probably also be batched. PR welcome upstream.
From a problem matcher point of view it would be enough sending the line. We could sent it when a linefeed is . Then there is still the problem of a line content changing. We once discussed the idea of a line identifier to signal that. I agree that sending single characters might not be a smart idea in terms of performance.
If it's just on line feed then many characters could go missing, eg. "abc" <move cursor up a row"def" <linefeedwould result in "def" only. Maybe this is not something we care about, but it could lead to some obscure bugs if people relied on this new API.
This is a good example why something like a line model would be helpful: After looking into the issue it looks like that pester constantly 'repaints' the whole screen hence the terminal sending the same line onData over and over again. For me it is very hard to tell whether I have seen that line and whether I have processed it already (the same content). What would be cool if the terminal could provide a line model where is line has an id (number) and changes are signaled on that model instead of sending raw data.
I actually an ID concept to the buffer when doing the selection stuff () but I ended up not needing it and pulling it out, instead the selection listens to when the buffer is trimmed and adjusts the indexes of its own model. It really didn't feel very good adding it as it introduced much more complexity to the already complex circular list and the overhead of an addition object for every entry - which is a lot when you need to create tens of thousands of these things in an instant. There were other issues that come up with this like IDs being interleaved due to programs having the ability to delete/insert lines so there's no way I could think of to optimize it nicely, leading to a slower, more memory hungry terminal. It would probably be easier and more performant to just deduplicate these errors on your end. For example you could record a hash for current problems and check it before adding new problems, or perhaps even better, record the raw terminal line of the error so you don't need to parse it again for duplicate problems.
I implemented the deduplicate yesterday but it feels like a hack on my side :-) I need to create a unique key for something that doesn't necessarily have one. I still think having a line bassed model comparable to what the editor exposes would be a nice thing. Me giving the raw data is comparable to the editor signaling raw cursor moves and text changes. Instead I get a nice model with text edit events. And I am not interested in color information like I am not interested in this on an editor buffer.
Just for the record. I can not filter on the line itself from the terminal without knowing if I have parsed that line already. Matchers are multiline aware and there could be two equal lines in one output on purpose since they difference is made by a line above. Me knowing this is implementing a line model on top of it :-)
isn't the point of programs rewriting lines that the lines do change and that they may need to be reparsed? Here's one idea that might work for both of us: exposing some data stream you can listen to as in the original comment, but only ever pushing data if it's on the last line in the terminal. Would this cover your use case? For the PS case you would get multiple lines for the last line but maybe this could be more clever somehow in recording when the cursor moves and only reporting the line a single time (not by using IDs but by only reporting once after a call inserts a new line.
yes, it would be cool to be able to reparse a line when it changes. As I tried to outline in this needs to have some sort of model to do it right. I can't simply decide things on the content of a line. So instead me implementing a line model on top of ANSI control sequence characters I was somehow hoping that the terminal could expose its. I my simple mind the terminal works like this: program -Output with control characters -line model -view model (does the wrapping, could do folding, ...) -DOM. I think the last line suggestion will work for parsing problems. However when exposing this as API in the extension host I think it might be a little to limited.
currently there is only the line model, no view model. I did a big write up on introducing one to properly support reflowing lines here This has been a pretty long discussion across a few issues but to clarify where we are now, here are my concerns: Extra memory overhead in the buffer: I'm currently in the process of trying to push down the terminal's memory usage as I need to store more data against each character and memory usage right now is approaching unacceptable limits imo Here is a snapshot of a 160x24 terminal with 5000 scrollback filled which is not out of the ordinary, I typically have two of these running just in the window with Microsoft/vscode opened: ! Extra processing when data/lines are to the buffer: back in December I made a big effort improving the terminal's performance by attacking it in a number of ways. The main take aways from this experience was that trying to write a high performance terminal in JavaScript/DOM is very hard because processing and displaying data is so expensive. I can now safely say that is the fastest JS terminal out there by a long shot and I want us to maintain this status. A proper view model that can track lines that changes would amount to a significant amount of processing in the worst case which would be generally unnecessary for other use cases. Some possible solutions: a new event that you can listen to that fires when a line feed is to the last line, ie. only fire an event once per line and ignore lines being updated or lines being inserted. Pros: It doesn't involve storing any more data or doing anymore processing, other that pulling the string from the buffer. Cons: it probably isn't sufficient to cover all use cases. an ID to each buffer line () and fire an event when there is a line feed against a line or the cursor moves away from it (specifics here would need to be figured out). Pros: It's a more complete solution and covers more use cases. We need an addition JS object and number associated with each line, this probably doesn't add up to that much data as it's on the line rather than the char. Cons: Additional complexity within the data structure. I'm not so sure just yet when exactly we should fire these events. The IDs will be out of order in some cases which may be confusing to consumers. These events may still fire when the line did not change (eg. if the program/script erased and rewrote the line). a proper view model that throws events only when a line changes. Pros: I think this is the ideal solution from your perspective. Cons: All the cons of number 2. The amount of string comparisons needed here is out of the question in the worst case with my current thinking, unless this was disabled by default and generally did not run on a lot of data. Commentary on the solutions: doesn't look like this is sufficient for problem matchers could work, but I'm not sure it helps much with the issue in behind an option on terminal initialization is probably the best way to go, but it's also the most difficult and time consuming to implement. Work on this is blocked on the following active PRs: & , and it should be done in a way that accommodates future line reflowing
thanks a lot for the detailed explanation. Having solution 2 will for sure make my life easier and will not make things worse on my end. Regarding option 3: I am not interested in the view model since I need lines unwrapped. The line model is what would work best for me assuming that the line model doesn't have any in there to make lines visually wrap .
option 3 including reflow is required in order to get unwrapped lines Not sure when I'll have time to work on this, pretty swamped atm. It might be a good opportunity to collaborate if this is high priority for you?
I will be out on vacation until 2. August. I think we need to address this sooner than later since we can't assume that problems always fit onto one line. An interims solution could be as follows: can we introduce a custom control sequence (e.g. a operating system control sequence) that describes the new lines inserted to wrap the text. I could then filter them on my end since I would be able to distinguish them from normal newline. Would this be something you can add in July then I would catchup with it for the July build ?
I actually expect you to get the unwrapped lines currently, just wraps the lines when they are going to overflow , that's the only wrapping it knows about. On Windows though I'm not sure rows are ever marked to be wrapped (not 100% sure), at least on PowerShell. This is just how winpty works.


Would be great to see a tooltip on links, showing the target. Or popping it up in the status bar or elsewhere, like Chrome.
: Could you please explain the preview functionality bit more with screenshots of Chrome? I am new to open source community and this project. I use vscode often and would love to work on this if someone can guide me a little.
Lower left corner of the Chrome window when I hover the link to your name: ! But I think a normal tooltip would be easier.
Ah yes. I understand what you are talking about now. To verify, where the link is leading to. Seems like a beginner friendly feature. I can pick it up this weekend if anyone can nudge me towards the right direction. :)
Sorry for the delayed response. It seems that tooltips are only shown if the element has a attribute, but not for links that only have a . I wasn't able to find if there is an electron setting to enable tooltips for links without . I think we may have to implement this ourselves. To get started, take a look at this PR that a similar feature to another electron app: Here's where our webview code lives: I believe you should be able to attach a handler to the webview handler. Please let me know if you have any questions about the code or want to discuss potential designs
I m happy to receive help! :) I was facing issues while trying to build and fiddle around with the source code. Will definitely look into this PR and the code you pointed out this weekend. Thanks for taking your time to post this info. I ll post any questions or designs which I have.
Hi , I will create a PR to add attribute to every .
For verification: this was implemented as tooltip when you hover over links in a webview


<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issues to prefill these. --- VSCode Version: latest OS Version: Win10 A little bit more space between last line from terminal and the blue line below would be nice !
I 1px border on the bottom would be fine, opening to PRs. Who ever wants to pick this up, you need to make sure the size of the terminal is calculated correctly given the new margin. Relevant files: , .
I'll pick this up. pretty much all of the other terminal issues are already taken, or out of my realm. just let me know somebody's not already working on this ;-)
sounds good
PR posted


FYI I commented out the test. Please fix it and enable it.
The test is failing because the DOM is no longer filled with nodes so these tests can't work the way they did previously. Is it possible with Spectron to pull a DOM node object, including any custom properties it has? If so I could attach a reference to the object to the terminal element which would allow querying the terminal for this sort of information really easily.
Yes, you can access the DOM in Spectron and we do it in multiple places. For example refer to . This will allow you to execute java script code on the renderer process that has access to DOM and let you return the model you want. But please be aware that, Since it runs in a different process than the test process, console log does not work.
PR with fix is out , will merge in after release is branched off.


I admit that it's a niche scenario, but I think that what "Open Changes" shows for not-yet-staged changes to files that have been detected as renamed in the index is incorrect, at least inconsistent with how changes to files in the index are shown that have not been renamed. Steps to Reproduce: an empty directory and initialize a git repository in it. that directory create two files and with identical content: This exact content is somewhat important, as I've confirmed that it triggers git's "rename detection" (checked with git v2.14.1). and commit both files. the first line in both files. to . "": ! does the right thing for both files, that is, it shows the changes between HEAD and the staged version: : ! : ! the first line in both files once more, but don't stage these changes. still shows the right thing for (in this case the changes between the staged version and the file in the working tree): ! As the content of both files is identical both in the index and the working tree, I would have expected the exact same result for , but now the left side is just empty instead of showing the staged version: ! VSCode Version: Code 1.16.1 (, 2017-09-14T16:26:20.018Z) OS Version: Linux x64 4.12.13-1-ARCH
Hehe great catch! Would you like to to it?
So is this issue still open and up for grabs? If so I would like to try to help
Just look above your comment, there's a PR for it already:
Fixed by


a .ts file tab to activate the "import statement" snippet Expected and actual: completes to a .tsx file (TypeScript + JSX) tab to activate the "import statement" snippet Actual: completes to Expected: completes to Is there any reason why the snippet is inconsistent between .ts and .tsx files?
Yes this is unintentional. I've marked this as help wanted in case anyone want to take a look. Here are the relevant snippet files:
Thanks! See I was also thinking it would be useful to add this to .js and .jsx extensions. What do you think?
Thanks for the PR! The change should be in the next insiders build Yes I think adding the same for js/jsx also make sense. Did you want to submit another PR that copies these snippets over to js/jsx?


VSCode Version: Code 1.15.1 (, 2017-08-16T18:07:25.676Z) OS Version: WindowsNT x64 10.0. Extensions: ExtensionVersion ------ overtype0.2.0 python0.7.0 theme-dark-plus-contrast0.1.101 cpptools0.13.0 monitor-file1.0.1 (4 theme extensions excluded) Steps to Reproduce: there is such line in a *.bat file rem set SERVERVERSION=5.7 cursor on it, and uncomment with "Ctrl+/" expected: set SERVERVERSION=5.7 actual result: REM rem set SERVERVERSION=5.7 Looks like uncomment is unnecessarily case-sensitive. It should uncomment despite it is 'rem' or 'REM'. I don't care whether with next "Ctrl+/" it will add Upper-Case 'REM' instead of 'rem' - it is not problem. <!-- Launch with to check. --Reproduces without extensions: Yes/No


VSCode Version: Code 1.17.0 (, 2017-10-05T06:07:51.906Z) OS Version: Darwin x64 16.7.0 Extensions: ExtensionVersion ------ vscode-markdownlint0.10.1 xml1.9.2 code-settings-sync2.8.3 sonarlint-vscode1.1.0 html-snippets0.1.0 Bookmarks0.16.0 markdown-preview-github-styles0.0.4 path-intellisense1.4.2 gitignore0.5.0 vscode-eslint1.3.2 githistory0.2.3 jquerysnippets0.0.1 tslint1.0.9 auto-rename-tag0.0.14 Angular22.7.0 HTMLHint0.4.0 cpptools0.13.1 csharp1.12.1 indent-rainbow0.7.2 tsimporter1.2.14 java0.11.0 vscode-open0.1.0 stylelint0.29.1 code-spell-checker1.4.7 code-spell-checker-spanish1.0.1 bootstrap-3-snippets0.1.0 JavaScriptSnippets1.5.0 Steps to Reproduce: new CSS file to add -bdrd with vendor-prefixed as mention in emmet documentation adding a hyphen before. But not show any suggestion or auto-complation list. Expected result: Emmet Documentation: I'm not see in his documentation if there is a way or option to enable this behaviour: <!-- Launch with to check. --Reproduces without extensions: Yes
You are right, expanding the abbreviations so that all vendor prefixes are included is not supported in Emmet 2.0 Have you used the command? We could just overload that command to add missing vendor prefixes or have a new command to do the same.
I'm not using it, but I think is better add it to a new command.
Note to verifier: The vendor prefixes should be attached as documented in when using the command.


VSCode Version: Code - Insiders 1.19.0-insider (, 2017-12-01T06:07:42.474Z) OS Version: Darwin x64 16.5.0 Extensions: ExtensionVersion ------ beautify1.1.1 vscode-caniuse0.5.0 jshint0.10.15 tslint1.0.24 php-debug1.12.1 php-intellisense2.0.4 php-pack1.0.1 plantuml2.3.3 vscode-duplicate1.2.0 sublime-keybindings3.0.3 debugger-for-chrome3.5.0 laravel-blade1.10.0 Steps to Reproduce: a HTML file with references to javascript files over the path of the JS file in any <scripttag 'll get the tooltip "Alt + click to follow link" Well, there isn't an Alt key in my MacOS keyboard (stock Apple keyboard). So saying "Option + click to follow link" will make more sense for Mac users. Not a big deal though. Thought I'll just point out. :) <!-- Launch with to check. --Reproduces without extensions: Yes/No


VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?


In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.


It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue


With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.


Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) 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.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!


<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.23.0-insiders x64 commit OS Version: Windows 8.1 x64 After update to latest version window is empty (only main menu bar is visible). Renderer process consumes 16-20% CPU but nothing is changing. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
can you run "" from the command line and see if any output is printed?
The output is here:
adding for the (maybe unrelated) spdylog stacktrace that shows up. can you share a screenshot how VSCode looks after it started like this?
!
does it make any difference if you run with "" from the command line?
That literal looks weird. It looks like the user has a problem in one of his variables, possibly . Whats the value of your HOMEPATH variable?
Visually nothing is changed. In console also nothing. is not presented. Username is , but profile folder named as .
does it make any difference if you run "" from the command line?
Yes. Window is opening like normal new profile. My profile is broken. Nice. ! UPD: Erased my old profile. Nothing. Same situation. So, trouble is Cyrillic symbols in path to profile folder.
to verify that can you use the argument with a folder that has the Cyrillic characters and see if you get the same results?
Yes. Launch with Cyrillic characters in path give same result.
it would be easier for me to reproduce if you could post the exact Cyrillic letters that you are using in here as text so that I can copy it.
Here it is: .
I can reproduce and the reason the workbench is not coming up is due to spdylog crashing very early. To reproduce run ""
Just to confirm, you could reproduce by using cyrilic in a path provided to ?
I can. Command: Result:
yes
I can confirm I have an identical problem. My username contains the character 'ø', which now makes the insiders build fail to start. Changing the to a path which does not contain that character fixes the issue. However, the Windows context menu action does not work, as the argument is only provided on the shortcut. The stable release (1.22.2) works as expected. EDIT: I fixed the context menu issue manually in the registry, so everything is back to normal for now :)
I pushed a workaround for now to not crash so badly when we fail to instantiate the spdylog writer. Turns out we already had code in place to protect from failing loads thanks to Alex, but the output channel was failing very early on. fyi maybe you want to quickly check my changes via The real fix probably needs to go into spdylog, pushing to May since this was already happening in stable.
This will break Output channels when not writing into file. When user switches between output channels, they will become empty as there is no way to retrieve content now
I was falling back to old way of writing into channels if fails. I removed this fallback this milestone . You can get that back. But I would really want to remove this fallback because for further enhancements to output channel which depends on spdlog.
this is not a real fix, I would expect some regressions. Previously VS Code would not start at all without my workaround. Do you think the current behaviour with my fix is worse than before? I think its clear that we will work on a fix for May.
IMO The better workaround would be to bring back my fallback . I was doing the same as you except that I fallback to old way of writing into Output channels. This will not have any regressions as it was there in last milestone. When we fix it in May, we can remove the workaround.
Sorry, I am confused. May I know if this issue is due to Loading of spdlog library OR spdlog fails to create a file
I see the workaround is if spldlog fails to create logger/file. So I think it is better to use my fallback.
Pushed the previous workaround I was using. As said, this will not break output channels if there is an issue creating spdlog logger.
I don't see issues running dev with a user-data-dir containing a non-ascii character (eg ) any more. I do not understand if this is because of your workaround or if the new spdlog version actually fixed the issue. Moving it to you in order to check if the issue is fixed already, since I don't understand how to repro.
I too do not see any issues after removing the workaround I before for the crash. Hence removed the workaround. To verify: Open VS Code using an user directory that has non-ascii character (eg ø) Verify that VS Code starts normally and the output channels are properly written Verify that there is no crash
Reopening this as the crash from spdlog is not fixed.
I still see following error in the console with our log files Edit: This is seen in the console even with the workaround. Workaround just mitigates it by falling back to old output channels. Logs will not work though.
Updated node-spdlog library to support in file names. Thanks to for hinting it. With this crash no longer occurs with non ascii or special characters (tested with all reported characters). Added a smoke test to launch VS Code with special characters in user data dir.


I did this on accident, but it took a little effort to figure out how I did it. Drag file from Finder onto Explorer Get scrollbar in Explorer to be visible, like by dragging near the top/bottom of the Explorer The entire explorer becomes highlighted when you hold the file over the scrollbar Drop file onto the scrollbar The entire explorer stays highlighted. It stays highlighted through interacting with the explorer and even switching to another viewlet. Only can be reversed by dragging another file onto the explorer. !
Actually a much easier way to repro is to two-finger scroll while dragging the file to get the scrollbar to appear.
i'm able to reproduce it. will try to fix it
couldn't find where to start. help is appreciated
I gave it a go in this PR:


Have file named in explorer Copy/paste it Window hangs This is from We shouldn't attempt this when the number is = Number.MAXSAFEINTEGER. It loops forever here: This bug will happen whenever incrementFileName fails to modify the file name.
I guess only interesting thing about this what we should do in this case as we need to create some new file name? Add without changing the original number?
that sounds reasonable


Issue Type: <bBug</bJSON syntax highlighting fails on the following array (item 1, "response"): { "request": [24], "response": [152, 26, 0, 0, 227, 147, 4, 0, 0, 0, 0, 0, 64, 233, 245, 229, 2, 43, 60, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 233, 245, 229, 2, 43, 60, 0, 0, 0, 0, 0, 0, 0, 0, 0, 68, 65, 3, 0, 1, 0, 100, 0, 12, 1, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 70, 32, 32, 32, 32, 82, 67, 73, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 221, 41, 12, 1, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 49, 32, 32, 32, 82, 67, 73, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 52, 41, 12, 1, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 50, 32, 32, 32, 82, 67, 73, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 40, 12, 1, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 51, 32, 32, 32, 82, 67, 73, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 69, 32, 12, 1, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 52, 32, 32, 32, 82, 67, 73, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 231, 70, 12, 1, 205, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 53, 32, 32, 32, 82, 67, 73, 32, 84, 48, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 1, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 54, 32, 32, 32, 82, 67, 73, 32, 84, 48, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 221, 41, 12, 1, 207, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 82, 67, 73, 48, 55, 32, 32, 32, 82, 67, 73, 32, 84, 48, 55, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 2, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 83, 70, 85, 50, 32, 32, 32, 32, 83, 84, 79, 67, 75, 32, 70, 85, 84, 85, 82, 69, 83, 44, 32, 68, 69, 67, 61, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 65, 0, 12, 2, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 83, 48, 49, 32, 32, 32, 83, 70, 32, 84, 83, 32, 76, 69, 86, 69, 76, 32, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 3, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 69, 70, 51, 70, 32, 32, 32, 32, 51, 45, 89, 32, 69, 88, 67, 72, 65, 78, 71, 69, 32, 70, 85, 78, 68, 32, 78, 79, 84, 69, 83, 32, 70, 85, 84, 85, 82, 69, 83, 32, 1, 1, 1, 2, 1, 0, 0, 28, 12, 3, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 69, 70, 51, 48, 49, 32, 32, 32, 69, 70, 51, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 3, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 69, 70, 51, 48, 50, 32, 32, 32, 69, 70, 51, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 3, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 69, 70, 51, 48, 51, 32, 32, 32, 69, 70, 51, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 8, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 67, 79, 77, 70, 32, 32, 32, 32, 67, 79, 77, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 4, 1, 0, 0, 0, 12, 8, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 67, 79, 77, 48, 49, 32, 32, 32, 67, 79, 77, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 8, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 67, 79, 77, 48, 50, 32, 32, 32, 67, 79, 77, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 174, 70, 12, 16, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 70, 32, 32, 32, 32, 77, 72, 73, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 4, 1, 0, 0, 0, 12, 16, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 67, 32, 32, 32, 32, 77, 72, 73, 32, 67, 65, 76, 76, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 157, 32, 12, 16, 23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 80, 32, 32, 32, 32, 77, 72, 73, 32, 80, 85, 84, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 16, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 49, 32, 32, 32, 77, 72, 73, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 171, 0, 12, 16, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 50, 32, 32, 32, 77, 72, 73, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 16, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 51, 32, 32, 32, 77, 72, 73, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 16, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 52, 32, 32, 32, 77, 72, 73, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 16, 205, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 53, 32, 32, 32, 77, 72, 73, 32, 84, 48, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 16, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 54, 32, 32, 32, 77, 72, 73, 32, 84, 48, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 16, 207, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 77, 72, 73, 48, 55, 32, 32, 32, 77, 72, 73, 32, 84, 48, 55, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 16, 250, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 77, 67, 95, 77, 72, 73, 32, 77, 72, 73, 32, 84, 77, 67, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 20, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 83, 79, 77, 67, 32, 32, 32, 32, 83, 84, 79, 67, 75, 32, 67, 65, 76, 76, 32, 79, 80, 84, 73, 79, 78, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 2, 32, 32, 12, 20, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 83, 79, 77, 80, 32, 32, 32, 32, 83, 84, 79, 67, 75, 32, 80, 85, 84, 32, 79, 80, 84, 73, 79, 78, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 2, 32, 32, 12, 20, 172, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 83, 79, 77, 49, 32, 32, 32, 32, 83, 79, 77, 32, 83, 89, 78, 84, 72, 69, 84, 73, 67, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 20, 250, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 77, 67, 95, 83, 79, 77, 32, 83, 79, 77, 32, 84, 77, 67, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 73, 66, 70, 32, 32, 32, 32, 72, 73, 66, 79, 82, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 24, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 49, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 50, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 51, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 52, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 205, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 53, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 54, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 207, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 55, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 55, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 208, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 56, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 56, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 24, 209, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 48, 57, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 48, 57, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 210, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 48, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 48, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 211, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 49, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 212, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 50, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 213, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 51, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 214, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 52, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 215, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 53, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 216, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 54, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 179, 71, 12, 24, 217, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 55, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 55, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 218, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 56, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 56, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 219, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 49, 57, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 49, 57, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 220, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 50, 48, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 50, 48, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 71, 7, 12, 24, 221, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 50, 49, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 50, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 24, 222, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 50, 50, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 50, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 23, 71, 12, 24, 223, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 83, 72, 50, 51, 32, 32, 32, 72, 73, 66, 79, 82, 32, 84, 50, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 27, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 68, 74, 73, 70, 32, 32, 32, 32, 68, 74, 73, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 81, 6, 12, 27, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 68, 74, 73, 48, 49, 32, 32, 32, 68, 74, 73, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 27, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 68, 74, 73, 48, 50, 32, 32, 32, 68, 74, 73, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 221, 41, 12, 27, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 68, 74, 73, 48, 51, 32, 32, 32, 68, 74, 73, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 27, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 68, 74, 73, 48, 52, 32, 32, 32, 68, 74, 73, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 34, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 70, 32, 32, 32, 32, 72, 83, 73, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 4, 1, 0, 0, 0, 12, 34, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 67, 32, 32, 32, 32, 72, 83, 73, 32, 67, 65, 76, 76, 32, 79, 80, 84, 73, 79, 78, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 2, 0, 0, 12, 34, 23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 80, 32, 32, 32, 32, 72, 83, 73, 32, 80, 85, 84, 32, 79, 80, 84, 73, 79, 78, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 2, 32, 32, 12, 34, 170, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 73, 83, 84, 68, 32, 32, 32, 32, 73, 78, 68, 69, 88, 32, 83, 84, 82, 65, 68, 68, 76, 69, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 222, 142, 12, 34, 171, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 73, 83, 84, 71, 32, 32, 32, 32, 73, 78, 68, 69, 88, 32, 83, 84, 82, 65, 78, 71, 76, 69, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 34, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 49, 32, 32, 32, 72, 83, 73, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 83, 80, 12, 34, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 50, 32, 32, 32, 72, 83, 73, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 34, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 51, 32, 32, 32, 72, 83, 73, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 84, 12, 34, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 52, 32, 32, 32, 72, 83, 73, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 34, 205, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 53, 32, 32, 32, 72, 83, 73, 32, 84, 48, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 179, 71, 12, 34, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 54, 32, 32, 32, 72, 83, 73, 32, 84, 48, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 34, 207, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 83, 73, 48, 55, 32, 32, 32, 72, 83, 73, 32, 84, 48, 55, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 49, 32, 12, 34, 250, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 77, 67, 95, 72, 83, 73, 32, 72, 83, 73, 32, 84, 77, 67, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 35, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 88, 72, 83, 67, 32, 32, 32, 32, 88, 72, 83, 32, 67, 65, 76, 76, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 35, 23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 88, 72, 83, 80, 32, 32, 32, 32, 88, 72, 83, 32, 80, 85, 84, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 37, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 88, 72, 72, 83, 32, 32, 32, 32, 88, 72, 72, 32, 83, 80, 79, 84, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 2, 2, 2, 0, 0, 0, 0, 12, 37, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 88, 72, 72, 67, 32, 32, 32, 32, 88, 72, 72, 32, 67, 65, 76, 76, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 37, 23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 88, 72, 72, 80, 32, 32, 32, 32, 88, 72, 72, 32, 80, 85, 84, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 38, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 70, 32, 32, 32, 32, 72, 72, 73, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 4, 1, 0, 0, 0, 12, 38, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 67, 32, 32, 32, 32, 72, 72, 73, 32, 67, 65, 76, 76, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 2, 0, 0, 12, 38, 23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 80, 32, 32, 32, 32, 72, 72, 73, 32, 80, 85, 84, 32, 79, 80, 84, 73, 79, 78, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 2, 82, 82, 12, 38, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 49, 32, 32, 32, 72, 72, 73, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 69, 69, 12, 38, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 50, 32, 32, 32, 72, 72, 73, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 38, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 51, 32, 32, 32, 72, 72, 73, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 38, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 52, 32, 32, 32, 72, 72, 73, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 38, 205, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 53, 32, 32, 32, 72, 72, 73, 32, 84, 48, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 78, 73, 12, 38, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 54, 32, 32, 32, 72, 72, 73, 32, 84, 48, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 38, 207, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 72, 72, 73, 48, 55, 32, 32, 32, 72, 72, 73, 32, 84, 48, 55, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 78, 12, 38, 250, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 84, 77, 67, 95, 72, 72, 73, 32, 72, 72, 73, 32, 84, 77, 67, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 32, 32, 12, 51, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 86, 79, 76, 70, 32, 32, 32, 32, 86, 79, 76, 32, 70, 85, 84, 85, 82, 69, 83, 46, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 32, 32, 12, 51, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 86, 79, 76, 48, 49, 32, 32, 32, 86, 79, 76, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 51, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 86, 79, 76, 48, 50, 32, 32, 32, 86, 79, 76, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 175, 70, 12, 60, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 70, 32, 32, 32, 32, 70, 88, 67, 32, 70, 85, 84, 85, 82, 69, 83, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 1, 1, 1, 2, 1, 0, 0, 0, 12, 60, 201, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 48, 49, 32, 32, 32, 70, 88, 67, 32, 84, 48, 49, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 71, 6, 12, 60, 202, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 48, 50, 32, 32, 32, 70, 88, 67, 32, 84, 48, 50, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 60, 203, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 48, 51, 32, 32, 32, 70, 88, 67, 32, 84, 48, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 221, 41, 12, 60, 204, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 48, 52, 32, 32, 32, 70, 88, 67, 32, 84, 48, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 60, 205, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 48, 53, 32, 32, 32, 70, 88, 67, 32, 84, 48, 53, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0, 12, 60, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 70, 88, 67, 48, 54, 32, 32, 32, 70, 88, 67, 32, 84, 48, 54, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 2, 1, 2, 1, 0, 0, 0, 0] } VS Code version: Code 1.23.1 (, 2018-05-10T16:04:33.747Z) OS version: Linux x64 3.13.0-40-generic <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-markdownlint0.18.0 xml2.2.0 vscode-docker0.0.27 gitignore0.5.0 githistory0.4.1 python2018.4.0 cpptools0.17.4 title0.1.0 vscode-icons7.23.0 bash-debug0.2.0 annotator0.11.0 code-spell-checker1.6.10 mako0.2.0 cmake0.0.17 gitblame2.4.2 vscode-todo-highlight0.5.12 (1 theme extensions excluded) </details<!-- generated by issue reporter --
For performance reasons, we skip tokenization for lines that are longer than 20k. It would be good if the user can see a message when that happens.
I would like to take this one if you guys think this is a but I would need some guidance. I already this: but I'm getting this error , so, I'm not sure how to import correctly into this file in order to use the method. cc:
This code runs on the renderer side, while is only for the extension host process. We have to wait for to add his thoughts. There's something similar when we open very large file. Check out the for that.
is API available only to vscode extensions and should not be used in the UI code. The UI code should use and inject itself with it. A possible fix would be to prompt (as suggested above), but prompt only once. It would be very annoying to prompt 20 times if there are 20 lines over 20.000 chars.
PR tackles this.
To verify, open a file with a very large line. A message should be shown, explaining why the large line is not tokenized.
I tried on the production app (May 2018 (version 1.24)) and I didn't get the notification, I guess it hasn't been deployed there yet, right? Where should I verify?
We would want that someone else than the author of the change would verify that the issue is fixed. So, there's nothing for you to do here, since you are the author. Someone from the vscode team will pick up this issue and verify it. (The change will make it to the stable channel in the following couple of weeks. For now it is available in the insiders channel at )
Verified !
How about using field for this kind of information? Lines that long only occure on minified files or base64 data images which doesn't actually need any syntax highlighting so this notification is completely useless in my opinion. How to get rid of it?


Learnings from NVAccess testing: I'm not sure how to get to the "details". Steps: Visual studio code editor. "Ctrl+Shift+X" key navigate to the extension side view bar option. Tab key navigate to the "More" option and select different options( "Show installed Extension, Show outdated extension, Show popular Extension,Etc") an extension and using "Tab" and "Arrow" keys navigate through the extension details window on the RHS
What do you think of a "Read more" button for each item? It will get a little noisy. Any other ideas?
Or just update the aria label on the extension item with "Click to read more" ? Because hitting Enter when the list item has focus, does open the details
definitely prefer making changes on the code side. The label should probably read like “View extension details” so it’s a little more explicit.


This feature request is about accessibility. This is only for removing 1 or 2 Breakpoints from a list of, say 30 breakpoints across multiple files in the Breakpoints List. Right now, there is no Close Button in the Breakpoints List when debugging a program in Visual Studio Code. The only way to remove 1 or 2 breakpoints right now is to: on the Breakpoint from the Breakpoints List. the red dot on the line highlighted by VS Code. the Breakpoint is now removed from the Breakpoints List. I would like to request that we can simplify this process by using the middle scroll wheel click on the mouse, so when you click on one of the Breakpoints with the scroll wheel button, it does all of the 3 steps mentioned above. And, it can act as a Remove Single Breakpoint mouse click action. Just like the middle scroll wheel click on tabs to close 1 tab out of many other tabs.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.647 --- <!-- score: 0.595 --- <!-- score: 0.583 --- <!-- score: 0.563 --- <!-- score: 0.555 --<!-- potentialduplicatescomment --
you can already use "delete" or "cmd + backspace" on the mac to remove the breakpoint. That way you can easily remove multiple. I do not understand what this has to do with accessibility since all these actions are already accessible. A middle click to remove a breakpoint would be consistent with our middle click to remove a tab. Thus I accept prs that fix this Code pointer Simply add a listener in the list for the mouse click, check if it is the middle one and if yes remove the breakpoint. If nobody volunteres I can look into this in the future
I am not aware of using "delete" keypress to remove the breakpoint. How is this triggered? If I press "delete", it would remove a character in my source code.
focus on the breakpoints view in the debug viewlet F1 Debug: focus breakpoints
Wouldn't it be more user-friendly just to add a close button for breakpoint list item? For example: !
It's more about middle scroll wheel click to remove breakpoints, and I think what you pointed out may be a separate issue.
release notes?


Issue Type: <bBug</bThe cursor after pasting, I'd expect it to be at the end of the pasted text: ! VS Code version: Code - Insiders 1.26.0-insider (, 2018-08-02T05:12:16.245Z) OS version: Darwin x64 17.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ 999-pack10.12.6 ssh0.0.4 github-issues-prs0.9.0 vscode-open-in-github1.7.0 </details<!-- generated by issue reporter --


I would like to make a pull request that changes the markdown snippet for links to use HTTPS instead of HTTP. Microsoft seems to encourage HTTPS by default in the latest .NET Core & browsers are also encouraging it. To me HTTPS sites seem to be the default for most websites these days.
Sure, please open a pr. I didn't even know we had a snippet for links :)
Fixed by