jiebi/CodeConvo huggingface dataset:
Change:
private async onDidClickPreviewLink(href: string) { let [hrefPath, fragment] = decodeURIComponent(href).split('#'); <del> // We perviously already resolve absolute paths. // Now make sure we handle relative file paths </del> if (hrefPath[0] !== '/') { <del> // Fix #93691, use this.resource.fsPath instead of this.resource.path hrefPath = path.join(path.dirname(this.resource.fsPath), hrefPath); </del> <ins> // We perviously already resolve absolute paths. // Now make sure we handle relative file paths const dirnameUri = vscode.Uri.parse(path.dirname(this.resource.path)); hrefPath = vscode.Uri.joinPath(dirnameUri, hrefPath).path; </ins> } else { // Handle any normalized file paths <del> hrefPath = vscode.Uri.parse(hrefPath.replace('/file', '')).fsPath; </del> <ins> hrefPath = vscode.Uri.parse(hrefPath.replace('/file', '')).path; </ins> } const config = vscode.workspace.getConfiguration('markdown', this.resource);

Discussion:
On Windows: a local empty folder an empty a with the following contents: the Markdown preview the link File opens with a strange input, as if its entire path is the file name. Also, if you open from the Explorer, it now appears twice in Quick Open: once normally and another in the weird long format. !
windows? local/wsl? Doesn't repro on macOS so I suspect an issue with how URIs are being created from the markdown.
This is local Windows, updated the steps.
There is some weird encoding going on with that URL, here is what it should look like: And here is what I get:
I'm working on this issue. I've logged out how the Markdown Preview renders the paths to HTML with "Click Here Absolute Path" containing the same link as in the issue: Markdown: HTML Output: The paths are correct though. Plus I think the link should be given as a relative path (ie. ) instead of an absolute path. Giving the absolute path here () is not correct. Btw, I've tried on other IDEs for comparison, they all don't open the absolute path link properly (or open nothing at all). The relative path link always works. Not sure how would you want to tackle this now?
I have a hunch that maybe the issue is somewhat related to
Thanks, for the pointer. I misunderstood the issue at first...
Change:
* Given a list of arguments as a tuple, attempt to extract the leading, non-service arguments * to their own tuple. */ <del> export type GetLeadingNonServiceArgs<Args> = Args extends [...BrandedService[]] ? [] : Args extends [infer A, ...BrandedService[]] ? [A] : Args extends [infer A, ...infer R] ? [A, ...GetLeadingNonServiceArgs<R>] : never; </del> <ins> export type GetLeadingNonServiceArgs<TArgs extends any[]> = TArgs extends [] ? [] : TArgs extends [...infer TFirst, BrandedService] ? GetLeadingNonServiceArgs<TFirst> : TArgs; </ins> export interface IInstantiationService {

Discussion:
This is the current definition of : Unfortunately, it loses the names of the parameters: ! However, if we change the definition to this: The parameter names are kept: ! I don't know how this affects type-checking performance though.
I think you should just submit this as a PR :)
Change:
flex: 150px 1 1000 } <del> .monaco-workbench .part.editor>.content .gettingStartedContainer .gettingStartedSlideDetails .getting-started-category .codicon { </del> <ins> .monaco-workbench .part.editor>.content .gettingStartedContainer .gettingStartedSlideDetails .gettingStartedDetailsContent>.getting-started-category>.codicon-getting-started-setup { </ins> margin-right: 8px; font-size: 28px; }

Discussion:
This is a bug in the . In general, the extension API allows icons to be embedded in text by referencing them inside of . This functionality does not work consistently in the walkthroughs API. <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: N/A; this is a bug in the extension API VS Code Version: 1.69 OS Version: macOS 12.4 Steps to Reproduce: a walkthrough step in your extension, e.g. "walkthroughs": [ { "id": "welcome", "title": "Example $(github)", "description": "See? The icon looks nice, doesn't it?", "steps": [ { "id": "example-step", "title": "Example step", "description": "Example description", "media": { "image": "", "altText": "" } } ] } ] 2 Observe that the icon in the title ( in the example above) renders correctly in the Open Walkthrough… quickpick list: <img width="372" alt="Screen Shot 2022-07-12 at 10 21 08 AM" src="https://user-"up the walkthrough and observe that the icon is not rendered, and instead you see the literal string : <img width="508" alt="Screen Shot 2022-07-12 at 10 22 09 AM" src="https://user-"
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Yes, it still exists in 1.69.1.
Thanks for the remarkably fast turnaround time, appreciate you.

Still see this in Version: 1.70.0-insider (user setup) Commit: Date: 2022-07-27T05:16:37.759Z OS: Windows_NT x64 10.0. ! ! ! generate a new TypeScript extension with add the snippet from the issue description to the
I only fixed the icon in the place that it didn't work in the issue description, sound like I have a few more places to fix :)
LGTM in the menu, in the walkthrough title, and in a step. <img width="984" alt="image" src="https://user-"
Change:
{ open: ''', close: ''' }, { open: '`', close: '`' }, ], <ins> colorizedBracketPairs: [], </ins> folding: { offSide: true }

Discussion:
As per bracket pairs should not be colorized in .txt files or any other non-programming language related files.
/assign
Makes sense. This can be fixed by setting for .txt and other files. Feel free to file a PR!
Would be good to know how to do that. I've created a folder inside and created a file in it with the following json - an empty array because I don't want any brackets colorized for .txt files, but that doesn't work. I have the exact same problem for .vue files where, in turn, even the <tags are colorized (inside the section of the .vue file) which I don't want to be colorized. I would appreciate if you could hint to a fix for these specifically, per file type/extension (or language type). Thanks.
Would these be non-programming languages? diff, dockerfile, dockercompose, git-commit, git-rebase, ignore, ini search-result, shaderlab, xsl
Good question... I think only the angle brackets colorization should be removed by default, from ALL languages/file extensions, and I hope that will be the road taken in
I couldn't figure out a way to pull changes from microsoft/vscode without introducing additional commits to existing pull request. Using seems to introduce an additional merge commit to the pr. Uisng seems to add me as contributor for new commits and add them to pr.
to avoid this you should have created a branch, made your change on the branch, then submitted the branch as a PR.
Change:
'use strict'; <del> import { CompletionItem, TextDocument, Position, CompletionItemKind, CompletionItemProvider, CancellationToken, WorkspaceConfiguration, TextEdit, Range, SnippetString, workspace } from 'vscode'; </del> <ins> import { CompletionItem, TextDocument, Position, CompletionItemKind, CompletionItemProvider, CancellationToken, WorkspaceConfiguration, TextEdit, Range, SnippetString, workspace, ProviderResult } from 'vscode'; </ins> import { ITypescriptServiceClient } from '../typescriptService';

Discussion:
VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-07T07:05:09.124Z) OS Version: Darwin x64 16.1.0 Steps to Reproduce: ! Enter !
That's a really annoying bug! Not just in .
The TypeScript extension tells the editor to only delete the 2 preceding characters, not the entire word. That might be a problem with the work definition you are using. !
I have extrapolated about snippets to the following piece of code
I think that Typescript needs to be explicit in this case, and provide a range for the completion items. We currently automatically pick up the range from
do you know if this is tracked on TS's side? I want to make sure I have it tracked in the OneNote table appropriately.
I don't think this is an issue on the TypeScript side. The bug was that we were relying on the default VSCode logic for determining what word to replace, and it breaks words that contain or any other non letter or digit characters. The result TypeScript provides to us is correct as far as I know
Change:
}, { label: '⌘', <del> ariaLabel: 'Command+', </del> <ins> ariaLabel: 'Command', </ins> electronAccelerator: null, <del> userSettingsLabel: 'cmd+', </del> <ins> userSettingsLabel: 'cmd', </ins> isWYSIWYG: true, isChord: false, dispatchParts: [null],

Discussion:
Issue Type: <bBug</bWhen using screencast mode, if you press a sequence of keys such as "Ctrl" + "Alt", Visual Studio Code adds an extra + at the end of the sequence. ! VS Code version: Code 1.42.1 (, 2020-02-11T14:45:59.656Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (32)</summaryExtensionVersion ------ 30-seconds-of-code1.0.0 better-comments2.0.5 Bookmarks11.0.0 vscode-color0.4.5 bracket-pair-colorizer1.0.61 javascript-ejs-support1.3.1 vscode-npm-script0.3.11 vsc-material-theme32.5.0 vsc-material-theme-icons1.1.4 php-intellisense2.3.14 vscode-mocha-test-adapter2.2.2 vscode-test-explorer2.17.0 python2020.2. remote-wsl0.42.3 vsliveshare1.0.1653 material-icon-theme3.9.3 java0.57.0 vscode-xml0.10.1 code-settings-sync3.4.3 vscode-spotify3.1.0 java-generate-setters-getters5.3.0 code-spell-checker1.7.24 vscodeintellicode1.2.5 vscode-java-debug0.25.0 vscode-java-dependency0.9.0 vscode-java-pack0.8.1 vscode-java-test0.22.1 vscode-maven0.21.0 change-case1.0.0 vscode-wpilib2020.2.2 viml0.0.2 material-theme3.2.3 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Isn't this an expected behavior? As it only happens with keys that can be used in combinations (Alt, Ctrl, Shift, Win ecc;)
Well I felt like that if I just press Ctrl and Alt it should say Ctrl+Alt instead of Ctrl+Alt+ as if some other letter had been pressed
Also, I can work on this issue if necessary
Verification: (Windows only) Enable Press and confirm that is displayed on the screen and not . Press and confirm that is displayed on the screen.
Change:
this.tree.setFocus([messageNode]); this.tree.setSelection([messageNode]); <ins> this.tree.domFocus(); </ins> })); this._register(this.tree.onDidOpen(async e => {

Discussion:
The original issue comes from Comment from Looks like there is some problem with the editor focus when the test message view is peeked out?
I found a way to view test results and work with tests. When the tests are executed, I need to press CTRL+m for tab key to move between elements, then tab until the close button and after that panel with buttons to go to previous and next failure results there will be a tree with test results. That's accessible with NVDA, I am sure it's also accessible with Orca. Thank you for help all!
Thanks for the issue! at the moment we reveal the failed position and then focus the editor. Instead is it preferable to focus within the peek view like the references peeks do?
yeah, it would be better if you focus inside the peek automatically for accessibility reasons. If you want, you can also differentiate if the command is triggered via keybinding, if yes then move focus, otherwise do not. This is what the editor hover does. Though I think it might be a bit confusing in this case, so I suggest to just pass focus inside the peek.
Thank you for such an active feedback! I also think that it would be more convenient if the focus moves directly to the peek instead of moving it to the editor with the selected line that can be easily deleted by accedent. Thank you!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
how about some verification steps unless resurfaces?
Steps in the original post should still be accurate. Opening test peek output (for a failed test) via should focus and screen-read the peek view, rather than staying in the editor.
Change:
assert.strictEqual(model.normalizeIndentation('  a'), '  a'); assert.strictEqual(model.normalizeIndentation(' a'), ' a'); assert.strictEqual(model.normalizeIndentation('a'), 'a'); <del> assert.strictEqual(model.normalizeIndentation(' t   a'), '        a'); assert.strictEqual(model.normalizeIndentation(' t  a'), '       a'); assert.strictEqual(model.normalizeIndentation(' t a'), '      a'); assert.strictEqual(model.normalizeIndentation(' ta'), '     a'); </del> <ins> assert.strictEqual(model.normalizeIndentation(' t    a'), '        a'); assert.strictEqual(model.normalizeIndentation(' t   a'), '       a'); assert.strictEqual(model.normalizeIndentation(' t  a'), '      a'); assert.strictEqual(model.normalizeIndentation(' t a'), '     a'); assert.strictEqual(model.normalizeIndentation(' ta'), '    a'); </ins> model.dispose(); });

Discussion:
Issue Type: <bBug</bPlease look this, ! Line 2: "Text" Line 3: .... This is auto indent line. ? (:, : ) ABC
I update this issue. But, It is automaticaly closed. Why? Please look this updated isuue.
What are the steps to reproduce? What is happening versus what you would expect to happen?
First line is, ( is white space, is Tab code) "Text" + -key Actual input is: (The above procedure removes the white space.) [Tab]-key, "Text", (move coursor position to the beginning of line), [Space][Space], (move coursor position to end of line), [Enter] The next cursor position is invalid. Please look the image of issue. I think, this is not serious but incorrect behavior.
Thank you for the extra information. Here are simplified steps: have a file with the contents press <kbdEnter</kbdif indentation is configured with tabs, the new line will contain if indentation is configured with spaces, the new line will contain
Thanks.
can we have some verification steps?
Posting again with more explanations: have a file with the contents press <kbdEnter</kbdif indentation is configured with tabs, the new line will contain . <---- this is a bug, the result should be such that the second line aligns with the first line if indentation is configured with spaces, the new line will contain <--- this is a bug, the result should be such that the second line aligns with the first line
Change:
import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { Registry } from 'vs/platform/registry/common/platform'; import { InlineChatController } from 'vs/workbench/contrib/inlineChat/browser/inlineChatController'; <del> import { CTX_INLINE_CHAT_FOCUSED, CTX_INLINE_CHAT_INNER_CURSOR_LAST } from 'vs/workbench/contrib/inlineChat/common/inlineChat'; </del> import { INotebookActionContext, INotebookCellActionContext, NotebookAction, NotebookCellAction, NOTEBOOK_EDITOR_WIDGET_ACTION_WEIGHT, findTargetCellEditor } from 'vs/workbench/contrib/notebook/browser/controller/coreActions'; import { CellEditState } from 'vs/workbench/contrib/notebook/browser/notebookBrowser'; import { CellKind, NOTEBOOK_EDITOR_CURSOR_BOUNDARY } from 'vs/workbench/contrib/notebook/common/notebookCommon';

Discussion:
I'm pretty sure some of these keybindings aren't ever enabled with their context key requirements, e.g. I don't think the inline chat can be focused in a markdown cell that isn't in edit mode. Nor will cursor navigation mode be true while edit mode is false.
Change:
import { TPromise } from 'vs/base/common/winjs.base'; import Event, { buffer } from 'vs/base/common/event'; import { IChannel, eventToCall, eventFromCall } from 'vs/base/parts/ipc/common/ipc'; <del> import { IWindowsService, INativeOpenDialogOptions, IEnterWorkspaceResult } from './windows'; </del> <ins> import { IWindowsService, INativeOpenDialogOptions, IEnterWorkspaceResult, CrashReporterStartOptions } from 'vs/platform/windows/common/windows'; </ins> import { IWorkspaceIdentifier, ISingleFolderWorkspaceIdentifier, IWorkspaceFolderCreationData } from 'vs/platform/workspaces/common/workspaces'; import { IRecentlyOpened } from 'vs/platform/history/common/history'; import { ICommandAction } from 'vs/platform/actions/common/actions';

Discussion:
There a few usages of in which is against our layering rules. I'd suggest to move the whole file into an folder
Unfortunately this might not be so simple given 62 references of which some would also need to be lifted up... An alternative would be to define similar interfaces that contain the properties we actually need instead of depending on Electron.
Also: and
I'd favour to lift them all instead blowing up our code size
with our current code organisation I cannot express the proper way for these references. Here are the issues: Moving this service into src/workbench This was my first idea, but it doesn't work. There are references from (our main side of things) into the windows service because the main side basically implements that service. We should not depend from to other than the file that we load into a window. The only way out I see here is to have something like for services that are shared between and . Moving the service from common into electron-browser This will not help because we have depending on the windows service and thus we would reach from into . The only option would be to introduce a new layer that contains the service and that can be accessed by and . To unblock your 2-CU scenario and to use ES6 features in workbench I suggest to that will inline the Electron references. However if we ever want to tackle this properly it needs some serious new code-structure layout on disk. Thoughts?
Yeah, makes sense... It's unfortunate but reality...
Change:
this._webExtensionContributedProfileContextKey = TerminalContextKeys.webExtensionContributedProfile.bindTo(this._contextKeyService); this._updateWebContextKey(); <del> // Wait up to 5 seconds for profiles to be ready so it's assured that we know the actual // default terminal before launching the first terminal. This isn't expected to ever take // this long. this._profilesReadyBarrier = new AutoOpenBarrier(20000); </del> <ins> this._profilesReadyPromise = this._remoteAgentService.getEnvironment() .then(() => { // Wait up to 20 seconds for profiles to be ready so it's assured that we know the actual // default terminal before launching the first terminal. This isn't expected to ever take // this long. this._profilesReadyBarrier = new AutoOpenBarrier(20000); return this._profilesReadyBarrier.wait().then(() => { }); }); </ins> this.refreshAvailableProfiles(); this._setupConfigListener(); }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.78.0 OS Version: Mac OS 13.3.1 Steps to Reproduce: a new VSCode window using Codespaces. initial terminal window opens a terminal. If I kill that terminal and open a new terminal, I get as expected. I have in my I believe this is a duplicate of these closed issues:
I was expecting this would get fixed as part of , cc
It got , but it only repros using codespaces extension now, before I was able to repro with test resovler extension and remote ssh extension which works as expected now, not sure what's special about codespaces extension as the remote connection logic is the same :thinking:
Ah I can repro now, will take a look, it's because codespaces takes 20s to resolve the remote Edit: There's a :laughing:
PR
/duplicate
Change:
} protected readWatchOptions(configuration: vscode.WorkspaceConfiguration): Proto.WatchOptions | undefined { <del> return configuration.get<Proto.WatchOptions>('typescript.tsserver.watchOptions'); </del> <ins> const watchOptions = configuration.get<Proto.WatchOptions>('typescript.tsserver.watchOptions'); // Returned value may be a proxy. Clone it into a normal object return { ...(watchOptions ?? {}) }; </ins> } protected readIncludePackageJsonAutoImports(configuration: vscode.WorkspaceConfiguration): 'auto' | 'on' | 'off' | undefined {

Discussion:
use safari open open TS initialises forever, console shows the error below
After , this now works fine in Safari tech preview. I suspect there's an issue with our nested worker polyfil but am still looking into this
I've tried debugging what is going on here but can't figure it out (and safari's dev tools are certainly not helping) What I suspect is that our nested worker polyfill causes a message to be dropped somewhere, possibly because a message port is started early or never started Given that everything works in safari tech preview though and given that don't plan on shipping project wide intellisense until cross origin isolation is enabled, this is a lower priority. Un-assigning from this month
I believe this all works in Safari 16.4 which nested worker support. Not sure what the issue was with our nested worker polyfill (note that needs to be merged too to see this working end to end)