jiebi/CodeConvo huggingface dataset:
Code change:
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !

Related discussion:
text: dispose(): void; } <ins> function clearContainer(container: HTMLElement) { while (container.firstChild) { container.removeChild(container.firstChild); } } </ins> function renderImage(outputInfo: OutputItem, element: HTMLElement): IDisposable {
Code change:
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !

Related discussion:
text: }; function renderHTML(outputInfo: OutputItem, container: HTMLElement): void { <ins> clearContainer(container); </ins> const htmlContent = outputInfo.text(); const element = document.createElement('div'); const trustedHtml = ttPolicy?.createHTML(htmlContent) ?? htmlContent;
Code change:
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !

Related discussion:
text: } function renderText(outputInfo: OutputItem, container: HTMLElement, ctx: RendererContext<void> & { readonly settings: { readonly lineLimit: number } }): void { <ins> clearContainer(container); </ins> const contentNode = document.createElement('div'); contentNode.classList.add('output-plaintext'); const text = outputInfo.text();
Code change:
Issue Type: <bBug</bSteps to Reproduce:  in a Markdown cell in Jupyter notebook. The monospace font used in Jupyter notebook () Markdown code blocks is not consistent with in the settings. ! This does not occur in a seperate Markdown () file. ! VS Code version: Code 1.66.0 (, 2022-03-30T05:50:14.623Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --

Related discussion:
text: code { font-size: 1em; <ins> font-family: var(--vscode-editor-font-family); </ins> } pre code { <del> font-family: var(--vscode-editor-font-family); </del> line-height: 1.357em; white-space: pre-wrap; }
Code change:
<!-- 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.66.0 OS: MacOS Monterey 12.3, Darwin x64 21.4.0 Steps to Reproduce: new new markdown cell, name it for instance or will only show and have deleted the 1) or 1. written manually
cc -- It looks like this is being sanitized out of md strings. A markdown cell containing will be sanitized to render as . If the cell contains it will render as expected, only removing the html tags. It seems to be happening at the following:

Related discussion:
text: if (token.type === 'heading') { yield { depth: token.depth, <del> text: renderMarkdownAsPlaintext({ value: token.text }).trim() </del> <ins> text: renderMarkdownAsPlaintext({ value: token.raw }).trim() </ins> }; } }
Code change:
<img width="776" alt="image" src="https://user-"I don't have stable reproduce, but this happens pretty often, especially I'm moving lines around.
I don't think this is a bug of injected text: When there are not decorations, there cannot be any injected text. This looks like there are some orphaned decorations.
Do you use the setting? Do you still see this with latest & greatest insiders?
I'm using the setting but haven't seen it for a while since I reported the issue.
Leaving this open, lets find steps
Is it possible that this is caused by the recursive issue?
Could be the case! The fix is to use it like this:
Oh, so inside the runner?
Yes, because change events are only send out after returns. Thus, is not reentrant anymore and will be assigned correctly.

Related discussion:
text: } } } <del> const newDecorationIds = this._editor.deltaDecorations(decorationIdsToReplace, newDecorationsData.map(d => d.decoration)); for (let i = 0; i < newDecorationIds.length; i++) { const data = newDecorationsData[i]; this._decorationsMetadata.set(newDecorationIds[i], data); } </del> <ins> this._editor.changeDecorations(accessor => { const newDecorationIds = accessor.deltaDecorations(decorationIdsToReplace, newDecorationsData.map(d => d.decoration)); for (let i = 0; i < newDecorationIds.length; i++) { const data = newDecorationsData[i]; this._decorationsMetadata.set(newDecorationIds[i], data); } }); </ins> } private _fillInColors(props: CssProperties, hint: languages.InlayHint): void {
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 response to , I think this error should only be raised when a request actually fails. I have a network setup where my host operating system reports it doesn't have network connectivity, but it can actually reach the internet just fine through a configured proxy. I believe moving the online check to the would result in a more accurate error flow: Obligatory xkcd for my unique situation:
As mentioned by I expect shall provide right info whether VS Code can connect to internet or not. Is it possible to get this info from the error instead of ?

Related discussion:
text: import { IRequestContext, IRequestOptions, OfflineError } from 'vs/base/parts/request/common/request'; export function request(options: IRequestOptions, token: CancellationToken): Promise<IRequestContext> { <del> if (!navigator.onLine) { throw new OfflineError(); } </del> if (options.proxyAuthorization) { options.headers = { ...(options.headers || {}),
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 response to , I think this error should only be raised when a request actually fails. I have a network setup where my host operating system reports it doesn't have network connectivity, but it can actually reach the internet just fine through a configured proxy. I believe moving the online check to the would result in a more accurate error flow: Obligatory xkcd for my unique situation:
As mentioned by I expect shall provide right info whether VS Code can connect to internet or not. Is it possible to get this info from the error instead of ?

Related discussion:
text: setRequestHeaders(xhr, options); xhr.responseType = 'arraybuffer'; <del> xhr.onerror = e => reject(new Error(xhr.statusText && ('XHR failed: ' + xhr.statusText) || 'XHR failed')); </del> <ins> xhr.onerror = e => reject( navigator.onLine ? new Error(xhr.statusText && ('XHR failed: ' + xhr.statusText) || 'XHR failed') : new OfflineError() ); </ins> xhr.onload = (e) => { resolve({ res: {
Code change:
<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

Related discussion:
text: "vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.24", "xterm-addon-search": "0.9.0-beta.21", </del> <ins> "xterm": "4.19.0-beta.25", "xterm-addon-search": "0.9.0-beta.22", </ins> "xterm-addon-serialize": "0.7.0-beta.12", "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.28", "xterm-headless": "4.19.0-beta.24", </del> <ins> "xterm-addon-webgl": "0.12.0-beta.29", "xterm-headless": "4.19.0-beta.25", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },
Code change:
<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

Related discussion:
text: "tas-client-umd": "0.1.4", "vscode-oniguruma": "1.6.1", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.24", "xterm-addon-search": "0.9.0-beta.21", </del> <ins> "xterm": "4.19.0-beta.25", "xterm-addon-search": "0.9.0-beta.22", </ins> "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.28" </del> <ins> "xterm-addon-webgl": "0.12.0-beta.29" </ins> } }
Code change:
<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

Related discussion:
text: resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f" integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8= <del> xterm-addon-search@0.9.0-beta.21: version "0.9.0-beta.21" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.21.tgz#5348fe25676cdd89ce3be52ae62a316b6f266176" integrity sha512-jh6kfRCpWRvZZkV9QghFYesSYHjybaLNEyYAD6uilZYfNHoGLa0zPgUkLOqoECL7K6rhBmSYOkKbc9MG4wNFMQ== </del> <ins> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </ins> xterm-addon-serialize@0.7.0-beta.12: version "0.7.0-beta.12"
Code change:
<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

Related discussion:
text: import { KeyCode } from 'vs/base/common/keyCodes'; import { FindReplaceState } from 'vs/editor/contrib/find/browser/findState'; import { IMessage as InputBoxMessage } from 'vs/base/browser/ui/inputbox/inputBox'; <del> import { SimpleButton, findPreviousMatchIcon, findNextMatchIcon } from 'vs/editor/contrib/find/browser/findWidget'; </del> <ins> import { SimpleButton, findPreviousMatchIcon, findNextMatchIcon, NLS_NO_RESULTS, NLS_MATCHES_LOCATION } from 'vs/editor/contrib/find/browser/findWidget'; </ins> import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IContextViewService } from 'vs/platform/contextview/browser/contextView'; import { editorWidgetBackground, inputActiveOptionBorder, inputActiveOptionBackground, inputActiveOptionForeground, inputBackground, inputBorder, inputForeground, inputValidationErrorBackground, inputValidationErrorBorder, inputValidationErrorForeground, inputValidationInfoBackground, inputValidationInfoBorder, inputValidationInfoForeground, inputValidationWarningBackground, inputValidationWarningBorder, inputValidationWarningForeground, widgetShadow, editorWidgetForeground, errorForeground } from 'vs/platform/theme/common/colorRegistry'; import { IColorTheme, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; import { ContextScopedFindInput } from 'vs/platform/history/browser/contextScopedHistoryWidget'; import { widgetClose } from 'vs/platform/theme/common/iconRegistry'; <ins> import * as strings from 'vs/base/common/strings'; </ins> const NLS_FIND_INPUT_LABEL = nls.localize('label.find', "Find"); const NLS_FIND_INPUT_" = nls.localize('placeholder.find', "Find");
Code change:
<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

Related discussion:
text: this._matchesCount.className = 'matchesCount'; } this._matchesCount.innerText = ''; <del> const label = count === undefined || count.resultCount === 0 ? `No Results` : `${count.resultIndex + 1} of ${count.resultCount}`; </del> <ins> let label; if (count?.resultCount === -1) { label = ''; } else { label = count === undefined || count.resultCount === 0 ? NLS_NO_RESULTS : strings.format(NLS_MATCHES_LOCATION, count.resultIndex + 1, count?.resultCount); } </ins> this._matchesCount.appendChild(document.createTextNode(label)); this._matchesCount.classList.toggle('no-results', !count || count.resultCount === 0); this._findInput?.domNode.insertAdjacentElement('afterend', this._matchesCount);
Code change:
<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -

Related discussion:
text: dependencies: object-keys "~0.4.0" <del> xterm-addon-search@0.9.0-beta.21: version "0.9.0-beta.21" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.21.tgz#5348fe25676cdd89ce3be52ae62a316b6f266176" integrity sha512-jh6kfRCpWRvZZkV9QghFYesSYHjybaLNEyYAD6uilZYfNHoGLa0zPgUkLOqoECL7K6rhBmSYOkKbc9MG4wNFMQ== </del> <ins> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </ins> xterm-addon-serialize@0.7.0-beta.12: version "0.7.0-beta.12"
Code change:
<!-- 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. --Version: 1.66.2 (Universal) Commit: Date: 2022-04-11T07:49:20.994Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Darwin x64 20.5.0 Steps to Reproduce: push a commit to a repo that user don't have permission message modal will show to ask user if they want to create a fork repo button create a fork for you user don't want to creat a fork, that's why they close it. <img width="504" alt="Screen Shot 2022-04-29 at 11 18 18 PM" src="https://user-"I check the code, looks like github extention only check  to return. What I suggest If you think this were resonable, I will make a PR for it

Related discussion:
text: const no = localize('no', "No"); const answer = await window.showInformationMessage(localize('fork', "You don't have permissions to push to '{0}/{1}' on GitHub. Would you like to create a fork and push to it instead?", owner, repo), yes, no); <del> if (answer === no) { </del> <ins> if (answer !== yes) { </ins> return; }