jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --In markdown mode, Dimmed Monokai theme: does not render bold / italic. no special color for link / image title. !
The markdown used in the screenshot:

Related discussion:
text: } }, { <ins> "name": "Markdown Headings", "scope": "markup.heading.markdown", "settings": { "fontStyle": "bold" } }, { "name": "Markdown Quote", "scope": "markup.quote.markdown", "settings": { "fontStyle": "italic", "foreground": "" } }, { "name": "Markdown Bold", "scope": "markup.bold.markdown", "settings": { "fontStyle": "bold" } }, { "name": "Markdown Link Title/Description", "scope": "string.other.link.title.markdown,string.other.link.description.markdown", "settings": { "foreground": "#AE81FF" } }, { "name": "Markdown Underline Link/Image", "scope": "markup.underline.link.markdown,markup.underline.link.image.markdown", "settings": { "foreground": "" } }, { "name": "Markdown Emphasis", "scope": "markup.italic.markdown", "settings": { "fontStyle": "italic" } }, { "name": "Markdown Punctuation Definition Link", "scope": "markup.list.unnumbered.markdown, markup.list.numbered.markdown", "settings": { "foreground": "" } }, { "name": "Markdown List Punctuation", "scope": [ "punctuation.definition.list.begin.markdown" ], "settings": { "foreground": "" } }, { </ins> "scope": "token.info-token", "settings": { "foreground": "#6796e6"
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ExtensionContext } from 'vscode'; </del> <ins> import { ExtensionContext, Uri } from 'vscode'; </ins> import { LanguageClientOptions } from 'vscode-languageclient'; import { startClient, LanguageClientConstructor } from '../cssClient'; import { LanguageClient } from 'vscode-languageclient/browser';
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: // this method is called when vs code is activated export function activate(context: ExtensionContext) { <del> const serverMain = context.asAbsolutePath('server/dist/browser/cssServerMain.js'); </del> <ins> const serverMain = Uri.joinPath(context.extensionUri, 'server/dist/browser/cssServerMain.js'); </ins> try { <del> const worker = new Worker(serverMain); </del> <ins> const worker = new Worker(serverMain.toString()); </ins> const newLanguageClient: LanguageClientConstructor = (id: string, name: string, clientOptions: LanguageClientOptions) => { return new LanguageClient(id, name, clientOptions, worker); };
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ExtensionContext } from 'vscode'; </del> <ins> import { ExtensionContext, Uri } from 'vscode'; </ins> import { LanguageClientOptions } from 'vscode-languageclient'; import { startClient, LanguageClientConstructor } from '../htmlClient'; import { LanguageClient } from 'vscode-languageclient/browser';
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: // this method is called when vs code is activated export function activate(context: ExtensionContext) { <del> const serverMain = context.asAbsolutePath('server/dist/browser/htmlServerMain.js'); </del> <ins> const serverMain = Uri.joinPath(context.extensionUri, 'server/dist/browser/htmlServerMain.js'); </ins> try { <del> const worker = new Worker(serverMain); </del> <ins> const worker = new Worker(serverMain.toString()); </ins> const newLanguageClient: LanguageClientConstructor = (id: string, name: string, clientOptions: LanguageClientOptions) => { return new LanguageClient(id, name, clientOptions, worker); };
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ExtensionContext } from 'vscode'; </del> <ins> import { ExtensionContext, Uri } from 'vscode'; </ins> import { LanguageClientOptions } from 'vscode-languageclient'; import { startClient, LanguageClientConstructor } from '../jsonClient'; import { LanguageClient } from 'vscode-languageclient/browser';
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: // this method is called when vs code is activated export function activate(context: ExtensionContext) { <del> const serverMain = context.asAbsolutePath('server/dist/browser/jsonServerMain.js'); </del> <ins> const serverMain = Uri.joinPath(context.extensionUri, 'server/dist/browser/jsonServerMain.js'); </ins> try { <del> const worker = new Worker(serverMain); </del> <ins> const worker = new Worker(serverMain.toString()); </ins> const newLanguageClient: LanguageClientConstructor = (id: string, name: string, clientOptions: LanguageClientOptions) => { return new LanguageClient(id, name, clientOptions, worker); };
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: const versionProvider = new StaticVersionProvider( new TypeScriptVersion( TypeScriptVersionSource.Bundled, <del> context.asAbsolutePath('dist/browser/typescript-web/tsserver.web.js'), </del> <ins> vscode.Uri.joinPath(context.extensionUri, 'dist/browser/typescript-web/tsserver.web.js').toString(), </ins> API.v400)); const lazyClientHost = createLazyClientHost(context, false, {
Code change:
The usage of as seen here only works because there is there is special code to return a url-string (instead of a path, see ). For loading extension relative resources the and should be used. That is the new, web-ready replacement API
fyi
tried to adopt this. When will be available. I can't find it in .
Opened for ESLint
It's in the API since 4 months:

Related discussion:
text: return getExtensionApi(onCompletionAccepted.event, pluginManager); }
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: "vscode-ripgrep": "^1.8.0", "vscode-sqlite3": "4.0.10", "vscode-textmate": "5.2.0", <del> "xterm": "4.9.0-beta.8", </del> <ins> "xterm": "4.9.0-beta.24", </ins> "xterm-addon-search": "0.7.0", "xterm-addon-unicode11": "0.2.0", "xterm-addon-webgl": "0.8.0",
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: "vscode-proxy-agent": "^0.5.2", "vscode-ripgrep": "^1.8.0", "vscode-textmate": "5.2.0", <del> "xterm": "4.9.0-beta.8", </del> <ins> "xterm": "4.9.0-beta.24", </ins> "xterm-addon-search": "0.7.0", "xterm-addon-unicode11": "0.2.0", "xterm-addon-webgl": "0.8.0",
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: "semver-umd": "^5.5.7", "vscode-oniguruma": "1.3.1", "vscode-textmate": "5.2.0", <del> "xterm": "4.9.0-beta.8", </del> <ins> "xterm": "4.9.0-beta.24", </ins> "xterm-addon-search": "0.7.0", "xterm-addon-unicode11": "0.2.0", "xterm-addon-webgl": "0.8.0"
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.8.0.tgz#4bc6bb4dbfea5b0d2d7978d6c5cef922d584fb4f" integrity sha512-dlpYPsv0C9S6v6+T/h/d/otSbdUTizMJdxvSoS34tUpMOHev6iW7Zqt5KRFqYxl4vCqpDk9Wmhb3fKL3kwX5fQ== <del> xterm@4.9.0-beta.8: version "4.9.0-beta.8" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.8.tgz#ca121934d63f88668d2d5b11d9b2fc3bde7bd805" integrity sha512-EEonYBLANDUBfEeEnHG632bZdgBaAUWst8LFr6oC6f2uLFfJGHQvVJuLaEkPtRvS+jOeoorEXZRPmso1/ANHXA== </del> <ins> xterm@4.9.0-beta.24: version "4.9.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.24.tgz#48f0990c6d32ad3a9bcc4fb49531d7effdaccea5" integrity sha512-CIVxxxbBiSw1WOMkIjjivaiIC9jNgih4klfWsRGx0qiDF5nbzHuLXkPTt+yAQUu9FCyTUwECm9Pkl3gUsSaGKg== </ins>
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.8.0.tgz#4bc6bb4dbfea5b0d2d7978d6c5cef922d584fb4f" integrity sha512-dlpYPsv0C9S6v6+T/h/d/otSbdUTizMJdxvSoS34tUpMOHev6iW7Zqt5KRFqYxl4vCqpDk9Wmhb3fKL3kwX5fQ== <del> xterm@4.9.0-beta.8: version "4.9.0-beta.8" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.8.tgz#ca121934d63f88668d2d5b11d9b2fc3bde7bd805" integrity sha512-EEonYBLANDUBfEeEnHG632bZdgBaAUWst8LFr6oC6f2uLFfJGHQvVJuLaEkPtRvS+jOeoorEXZRPmso1/ANHXA== </del> <ins> xterm@4.9.0-beta.24: version "4.9.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.24.tgz#48f0990c6d32ad3a9bcc4fb49531d7effdaccea5" integrity sha512-CIVxxxbBiSw1WOMkIjjivaiIC9jNgih4klfWsRGx0qiDF5nbzHuLXkPTt+yAQUu9FCyTUwECm9Pkl3gUsSaGKg== </ins> yauzl@^2.9.2: version "2.10.0"
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: // Listen for modifier before handing it off to the hover to handle so it gets disposed correctly this._hoverListeners = new DisposableStore(); this._hoverListeners.add(dom.addDisposableListener(document, 'keydown', e => { <del> if (this._isModifierDown(e)) { </del> <ins> if (!e.repeat && this._isModifierDown(e)) { </ins> this._enableDecorations(); } })); this._hoverListeners.add(dom.addDisposableListener(document, 'keyup', e => { <del> if (!this._isModifierDown(e)) { </del> <ins> if (!e.repeat && !this._isModifierDown(e)) { </ins> this._disableDecorations(); } }));
Code change:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:

Related discussion:
text: resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.8.0.tgz#4bc6bb4dbfea5b0d2d7978d6c5cef922d584fb4f" integrity sha512-dlpYPsv0C9S6v6+T/h/d/otSbdUTizMJdxvSoS34tUpMOHev6iW7Zqt5KRFqYxl4vCqpDk9Wmhb3fKL3kwX5fQ== <del> xterm@4.9.0-beta.8: version "4.9.0-beta.8" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.8.tgz#ca121934d63f88668d2d5b11d9b2fc3bde7bd805" integrity sha512-EEonYBLANDUBfEeEnHG632bZdgBaAUWst8LFr6oC6f2uLFfJGHQvVJuLaEkPtRvS+jOeoorEXZRPmso1/ANHXA== </del> <ins> xterm@4.9.0-beta.24: version "4.9.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.24.tgz#48f0990c6d32ad3a9bcc4fb49531d7effdaccea5" integrity sha512-CIVxxxbBiSw1WOMkIjjivaiIC9jNgih4klfWsRGx0qiDF5nbzHuLXkPTt+yAQUu9FCyTUwECm9Pkl3gUsSaGKg== </ins> y18n@^3.2.1: version "3.2.1"
Code change:
Below is a recording of a Control-R reload when no workspace is open and one non-builtin extension is contributing to to the Welcome view of Explorer. ! Observe how we start with Explorer's usual "NO FOLDER OPEN" view. Next my extension contributes its text and buttons. Finally the built-in git extension contributes text and a button. Since built-ins get higher priority the content from my extension jumps downward, perhaps while I'm reading it or trying to click one of its actions (link, button). There's no progress indicator when the content is being fetched and assembled, and it's hard to know how long to wait before concluding that no other extensions are going to contribute. VS Code version: Code 1.49.0 (, 2020-09-10T13:22:08.892Z) OS version: Windows_NT x64 10.0.
Similarly on the Source Control view, it starts with a message saying "No source control providers registered" and stays this way long enough for me to worry that something is broken or missing. Eventually the contribution from the git extension arrives. If a progress indicator isn't , maybe at least the initial message could say something like "Please wait while we look for source control providers". Then if nothing contributes (e.g. the git extension has been disabled,) it could then display "No source control providers registered".
This will be very hard to achieve. The problem here isn't actually the extension point, for which we could definitely add a progress indicator, but the activation of the git extension. That git section won't appear until the git extension is activated and all the potential repo locations have been probed... We simply can't add a progress indicator for that in the core unless we add some more API.
On this, we could potentially add a message.
That might help.
Closing this until we get actual user feedback that it's needed, sorry

Related discussion:
text: this.bodyContainer.classList.add('welcome'); this.viewWelcomeContainer.innerText = ''; <del> let buttonIndex = 0; </del> for (const { content, preconditions } of contents) { <ins> let buttonIndex = 0; </ins> const lines = content.split('n'); for (let line of lines) {
Code change:
Below is a recording of a Control-R reload when no workspace is open and one non-builtin extension is contributing to to the Welcome view of Explorer. ! Observe how we start with Explorer's usual "NO FOLDER OPEN" view. Next my extension contributes its text and buttons. Finally the built-in git extension contributes text and a button. Since built-ins get higher priority the content from my extension jumps downward, perhaps while I'm reading it or trying to click one of its actions (link, button). There's no progress indicator when the content is being fetched and assembled, and it's hard to know how long to wait before concluding that no other extensions are going to contribute. VS Code version: Code 1.49.0 (, 2020-09-10T13:22:08.892Z) OS version: Windows_NT x64 10.0.
Similarly on the Source Control view, it starts with a message saying "No source control providers registered" and stays this way long enough for me to worry that something is broken or missing. Eventually the contribution from the git extension arrives. If a progress indicator isn't , maybe at least the initial message could say something like "Please wait while we look for source control providers". Then if nothing contributes (e.g. the git extension has been disabled,) it could then display "No source control providers registered".
This will be very hard to achieve. The problem here isn't actually the extension point, for which we could definitely add a progress indicator, but the activation of the git extension. That git section won't appear until the git extension is activated and all the potential repo locations have been probed... We simply can't add a progress indicator for that in the core unless we add some more API.
On this, we could potentially add a message.
That might help.
Closing this until we get actual user feedback that it's needed, sorry

Related discussion:
text: for (const welcome of contribution.value) { const id = ViewIdentifierMap[welcome.view] ?? welcome.view; const { group, order } = parseGroupAndOrder(welcome, contribution); <ins> const enablement = ContextKeyExpr.deserialize(welcome.enablement); </ins> const disposable = viewsRegistry.registerViewWelcomeContent(id, { content: welcome.contents, when: ContextKeyExpr.deserialize(welcome.when), <ins> // supply the enablement clause for each line in case the line defines a button preconditions: welcome.contents.split('n').map((_) => enablement), </ins> group, order });
Code change:
Below is a recording of a Control-R reload when no workspace is open and one non-builtin extension is contributing to to the Welcome view of Explorer. ! Observe how we start with Explorer's usual "NO FOLDER OPEN" view. Next my extension contributes its text and buttons. Finally the built-in git extension contributes text and a button. Since built-ins get higher priority the content from my extension jumps downward, perhaps while I'm reading it or trying to click one of its actions (link, button). There's no progress indicator when the content is being fetched and assembled, and it's hard to know how long to wait before concluding that no other extensions are going to contribute. VS Code version: Code 1.49.0 (, 2020-09-10T13:22:08.892Z) OS version: Windows_NT x64 10.0.
Similarly on the Source Control view, it starts with a message saying "No source control providers registered" and stays this way long enough for me to worry that something is broken or missing. Eventually the contribution from the git extension arrives. If a progress indicator isn't , maybe at least the initial message could say something like "Please wait while we look for source control providers". Then if nothing contributes (e.g. the git extension has been disabled,) it could then display "No source control providers registered".
This will be very hard to achieve. The problem here isn't actually the extension point, for which we could definitely add a progress indicator, but the activation of the git extension. That git section won't appear until the git extension is activated and all the potential repo locations have been probed... We simply can't add a progress indicator for that in the core unless we add some more API.
On this, we could potentially add a message.
That might help.
Closing this until we get actual user feedback that it's needed, sorry

Related discussion:
text: contents = 'contents', when = 'when', group = 'group', <ins> enablement = 'enablement', </ins> } export interface ViewWelcome {
Code change:
Below is a recording of a Control-R reload when no workspace is open and one non-builtin extension is contributing to to the Welcome view of Explorer. ! Observe how we start with Explorer's usual "NO FOLDER OPEN" view. Next my extension contributes its text and buttons. Finally the built-in git extension contributes text and a button. Since built-ins get higher priority the content from my extension jumps downward, perhaps while I'm reading it or trying to click one of its actions (link, button). There's no progress indicator when the content is being fetched and assembled, and it's hard to know how long to wait before concluding that no other extensions are going to contribute. VS Code version: Code 1.49.0 (, 2020-09-10T13:22:08.892Z) OS version: Windows_NT x64 10.0.
Similarly on the Source Control view, it starts with a message saying "No source control providers registered" and stays this way long enough for me to worry that something is broken or missing. Eventually the contribution from the git extension arrives. If a progress indicator isn't , maybe at least the initial message could say something like "Please wait while we look for source control providers". Then if nothing contributes (e.g. the git extension has been disabled,) it could then display "No source control providers registered".
This will be very hard to achieve. The problem here isn't actually the extension point, for which we could definitely add a progress indicator, but the activation of the git extension. That git section won't appear until the git extension is activated and all the potential repo locations have been probed... We simply can't add a progress indicator for that in the core unless we add some more API.
On this, we could potentially add a message.
That might help.
Closing this until we get actual user feedback that it's needed, sorry

Related discussion:
text: readonly [ViewsWelcomeExtensionPointFields.contents]: string; readonly [ViewsWelcomeExtensionPointFields.when]: string; readonly [ViewsWelcomeExtensionPointFields.group]: string; <ins> readonly [ViewsWelcomeExtensionPointFields.enablement]: string; </ins> } export type ViewsWelcomeExtensionPoint = ViewWelcome[];
Code change:
Below is a recording of a Control-R reload when no workspace is open and one non-builtin extension is contributing to to the Welcome view of Explorer. ! Observe how we start with Explorer's usual "NO FOLDER OPEN" view. Next my extension contributes its text and buttons. Finally the built-in git extension contributes text and a button. Since built-ins get higher priority the content from my extension jumps downward, perhaps while I'm reading it or trying to click one of its actions (link, button). There's no progress indicator when the content is being fetched and assembled, and it's hard to know how long to wait before concluding that no other extensions are going to contribute. VS Code version: Code 1.49.0 (, 2020-09-10T13:22:08.892Z) OS version: Windows_NT x64 10.0.
Similarly on the Source Control view, it starts with a message saying "No source control providers registered" and stays this way long enough for me to worry that something is broken or missing. Eventually the contribution from the git extension arrives. If a progress indicator isn't , maybe at least the initial message could say something like "Please wait while we look for source control providers". Then if nothing contributes (e.g. the git extension has been disabled,) it could then display "No source control providers registered".
This will be very hard to achieve. The problem here isn't actually the extension point, for which we could definitely add a progress indicator, but the activation of the git extension. That git section won't appear until the git extension is activated and all the potential repo locations have been probed... We simply can't add a progress indicator for that in the core unless we add some more API.
On this, we could potentially add a message.
That might help.
Closing this until we get actual user feedback that it's needed, sorry

Related discussion:
text: type: 'string', description: nls.localize('contributes.viewsWelcome.view.group', "Group to which this welcome content belongs."), }, <ins> [ViewsWelcomeExtensionPointFields.enablement]: { type: 'string', description: nls.localize('contributes.viewsWelcome.view.enablement', "Condition when the welcome content buttons should be enabled."), }, </ins> } } });