jiebi/CodeConvo huggingface dataset:
Change:
An issue with the node-pty update caused the conpty setting to not do anything, instead reverting to the node-pty default for conpty (always when Windows + is being used). Since I've recommended using that setting as a workaround for certain ConPTY issues (like ), this feels like it meets the bar for 1.40.
To verify on a Window 10 build + machine (run ver to check build number): to true and verify that a conpty process gets created. Check the process explorer for conpty process. it to false and verify a winpty process gets created. conpty processes look like the ones in red under the window, winpty are in blue: !
Closing to make sure this shows up in our verification query. Testing now
Moved to recovery as we didn't want to push the release out another day.

Discussion:
env?: { [key: string]: string }; encoding?: string; /** <del> * Whether to use the experimental ConPTY system on Windows. When this is not set, ConPTY will * be used when the Windows build number is >= 18309 (it's available in 17134 and 17692 but is * too unstable to enable by default). </del> <ins> * Whether to use the ConPTY system on Windows. When this is not set, ConPTY will be used when * the Windows build number is >= 18309 (instead of winpty). Note that ConPTY is available from * build 17134 but is too unstable to enable by default. </ins> * * This setting does nothing on non-Windows. */ <del> experimentalUseConpty?: boolean; </del> <ins> useConpty?: boolean; </ins> /** * Whether to use PSEUDOCONSOLE_INHERIT_CURSOR in conpty. * @see https://docs.microsoft.com/en-us/windows/console/createpseudoconsole

env, cols, rows, <del> experimentalUseConpty: useConpty, </del> <ins> useConpty, </ins> // This option will force conpty to not redraw the whole viewport on launch conptyInheritCursor: useConpty && !!shellLaunchConfig.initialText };
Change:
pls see the screenshot below, suggest to shift it down so that it doesn't overlap with the filter icon. !
This is shown correctly left to the icon. Menu is rendered according to the given anchor (action element).
typically dropdowns are using an icon that doesn't really extend to the bottom of the anchor element. (usually ...) on macOS, the top position of the menu aligns with the top of the first element, not the top of the full container, giving this alignment. see windows native ! see windows custom ! we could either shift all dropdowns on macOS a few pixels by adding some extra dimension to the anchor, or we could adjust all context menus to account for the top padding of macOS menus. /cc
:+1:

Discussion:
const anchor = delegate.getAnchor(); let x: number, y: number; <ins> let zoom = webFrame.getZoomFactor(); </ins> if (dom.isHTMLElement(anchor)) { let elementPosition = dom.getDomNodePagePosition(anchor); x = elementPosition.left; y = elementPosition.top + elementPosition.height; <ins> // Shift macOS menus by a few pixels below elements // to account for extra padding on top of native menu // https://github.com/microsoft/vscode/issues/84231 if (isMacintosh) { y += 4 / zoom; } </ins> } else { const pos: { x: number; y: number; } = anchor; x = pos.x + 1; /* prevent first item from being selected automatically under mouse */ y = pos.y; } <del> let zoom = webFrame.getZoomFactor(); </del> x *= zoom; y *= zoom;
Change:
utf-8() encoding guessing is disabled by this line. But this didn't mention it. And in my test,the follow text will be guessing as utf-8 correctly(result='utf-8'). ! jschardet result: ! In the other hand,with the follow setting, it will be detect as ! !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.564 --- <!-- score: 0.49 --<!-- potentialduplicatescomment --
These issues will be solve by
In particular, will be treat as !
I like this change because it makes more deterministic by giving it full control over the detection. I still think more work is needed to increase the confidence of the detection, but that can continue in other issues.
I noticed a bad regression though that made me push to ignore the guessed encoding "ascii" for a simple reason: user opens a text file with just ascii characters we guess the encoding to be "ascii" user types special characters (like german umlaut) user saves and closes the file user reopens the file =the file is still guessed as "ascii" because it was not saved with a proper encoding
Verification: configure configure (simply to a non-UTF8 encoding) save a file with special characters contents (e.g. ) as UTF-8 close all files open it in VSCode =the encoding should be from the status bar.
Given scary issues such as I am putting UTF-16 and 32 back to the list of ignored encodings for guessing. Still, UTF-8 can be guessed.
From this issue , we really need to replace jschardet with a new library

Discussion:
return null; } <del> const IGNORE_ENCODINGS = ['ascii', 'utf-8', 'utf-16', 'utf-32']; </del> /** * Guesses the encoding from buffer. */

return null; } <del> const enc = guessed.encoding.toLowerCase(); // Ignore encodings that cannot guess correctly // (http://chardet.readthedocs.io/en/latest/supported-encodings.html) if (0 <= IGNORE_ENCODINGS.indexOf(enc)) { return null; } </del> return toIconvLiteEncoding(guessed.encoding); }
Change:
open one or multiple editors on Windows the text inside the editor is rendered with grayscale antialising ! it should use subpixel AA: !
I just tried 1.40.1. This doesn't fix it on macOS Catalina. 39.2: ! 40.1: !
It did, however, fix the issue on Mojave (as I haven't updated to Catalina yet)

Discussion:
return; } this._layerHint = layerHint; <del> (<any>this.domNode.style).willChange = this._layerHint ? 'transform' : 'auto'; </del> <ins> this.domNode.style.transform = this._layerHint ? 'translate3d(0px, 0px, 0px)' : ''; </ins> } public setAttribute(name: string, value: string): void {
Change:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I was looking through the readme and for Visual Studio Code and noticed how it flip-flops between calling itself Code and alternatively VS Code. The inconsistency is a little confusing and I think Code alone is a little too ambiguous. I believe it would be more clear to consistently refer to itself as VS Code in documentation.
I've updated the How to Contribute wiki page as well. Thanks for pointing this out.

Discussion:
Visual Studio Code is updated monthly with new features and bug fixes. You can download it for Windows, macOS, and Linux on [Visual Studio Code's website](https://code.visualstudio.com/Download). To get the latest releases every day, install the [Insiders build](https://code.visualstudio.com/insiders). ## Contributing There are many ways in which you can participate in the project, for example:

## Related Projects <del> Many of the core components and extensions to Code live in their own repositories on GitHub. For example, the [node debug adapter](https://github.com/microsoft/vscode-node-debug) and the [mono debug adapter](https://github.com/microsoft/vscode-mono-debug) have their own repositories. For a complete list, please visit the [Related Projects](https://github.com/Microsoft/vscode/wiki/Related-Projects) page on our [wiki](https://github.com/Microsoft/vscode/wiki). </del> <ins> Many of the core components and extensions to VS Code live in their own repositories on GitHub. For example, the [node debug adapter](https://github.com/microsoft/vscode-node-debug) and the [mono debug adapter](https://github.com/microsoft/vscode-mono-debug) have their own repositories. For a complete list, please visit the [Related Projects](https://github.com/Microsoft/vscode/wiki/Related-Projects) page on our [wiki](https://github.com/Microsoft/vscode/wiki). </ins> ## Bundled Extensions <del> Code includes a set of built-in extensions located in the [extensions](extensions) folder, including grammars and snippets for many languages. Extensions that provide rich language support (code completion, Go to Definition) for a language have the suffix `language-features`. For example, the `json` extension provides coloring for `JSON` and the `json-language-features` provides rich language support for `JSON`. </del> <ins> VS Code includes a set of built-in extensions located in the [extensions](extensions) folder, including grammars and snippets for many languages. Extensions that provide rich language support (code completion, Go to Definition) for a language have the suffix `language-features`. For example, the `json` extension provides coloring for `JSON` and the `json-language-features` provides rich language support for `JSON`. </ins> ## Code of Conduct
Change:
Issue Type: <bBug</bcode-oss on windows into the browser and click "Open" in resulting dialog ! Works on Mac still, haven't tried Linux VS Code version: Code - OSS Dev 1.41.0 (Commit unknown, Date unknown) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Hi, I have tracked this down to ! It seems that when you run Code - , the command is missing: ! By hardcoding my vscode folder location in: ! The app is able to open: ! Is there a command/utility function that will give this location?
Bingo! You should add this to the array only if not .
Verification: This is a Windows only issue.

Discussion:
// Watch Electron URLs and forward them to the UrlService const args = this.environmentService.args; const urls = args['open-url'] ? args._urls : []; <del> const urlListener = new ElectronURLListener(urls || [], urlService, windowsMainService); </del> <ins> const urlListener = new ElectronURLListener(urls || [], urlService, windowsMainService, this.environmentService); </ins> this._register(urlListener); // Open our first window

*--------------------------------------------------------------------------------------------*/ import { Event } from 'vs/base/common/event'; <ins> import { IEnvironmentService } from 'vs/platform/environment/common/environment'; </ins> import { IURLService } from 'vs/platform/url/common/url'; import product from 'vs/platform/product/common/product'; import { app, Event as ElectronEvent } from 'electron';

constructor( initial: string | string[], @IURLService private readonly urlService: IURLService, <del> @IWindowsMainService windowsMainService: IWindowsMainService </del> <ins> @IWindowsMainService windowsMainService: IWindowsMainService, @IEnvironmentService environmentService: IEnvironmentService </ins> ) { const globalBuffer = ((<any>global).getOpenUrls() || []) as string[]; const rawBuffer = [

this.uris = coalesce(rawBuffer.map(uriFromRawUrl)); if (isWindows) { <del> app.setAsDefaultProtocolClient(product.urlProtocol, process.execPath, ['--open-url', '--']); </del> <ins> const windowsParameters = environmentService.isBuilt ? [] : [`"${environmentService.appRoot}"`]; windowsParameters.push('--open-url', '--'); app.setAsDefaultProtocolClient(product.urlProtocol, process.execPath, windowsParameters); </ins> } const onOpenElectronUrl = Event.map(
Change:
Issue Type: <bBug</bnew Ubuntu 19.10 install. Comes with firefox installed and set as default browser. VSCode from "ubuntu software". any link inside of VSCode, for example HelpTips and Tricks. crashes. VS Code version: Code 1.40.1 (, 2019-11-13T16:49:30.162Z) OS version: Linux x64 5.3.0-23-generic snap <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I followed ctaggart's workaround () and was able to resolve this issue. and purge the current installation and install the deb package from
Had same issue with code installed with a . Installed it as deb package fixed issue too.
This is the same underlying cause as has pointed out the root cause in Crash is gone after unsetting the following env:
I have a LDPRELOAD related solution I can share (which wouldn't touch code's code), but if on launch those can be unset if code or code-insiders is in "SNAPNAME", that should solve the problem too.
On Ubuntu 19.10 uninstalling the "Firefox Web Browser" pre-installed deb package and installing the package named as just "Firefox" (packaged as a snap by Mozilla itself) on the Ubuntu Software store did the trick.
Advice from snapcraft team: this should be fixed by removing the following environment variables after start up:

Discussion:
// Configure static command line arguments const argvConfig = configureCommandlineSwitchesSync(args); <ins> // Remove env set by snap https://github.com/microsoft/vscode/issues/85344 if (process.env['SNAP']) { delete process.env['GDK_PIXBUF_MODULE_FILE']; delete process.env['GDK_PIXBUF_MODULEDIR']; } </ins> /** * Support user defined locale: load it early before app('ready') * to have more things running in parallel.
Change:
Markdown rendering in bundled Monokai has following flaws: links in lists don't are not properly coloured headings are not bold quotes are not rendered in italic bold text is not rendered as bold italic text is not rendered in italic font !
Please share the text of the code along with screenshots
Sure! Maybe VS Code team has a more thorough test file for markdown file. Anyway, that's the one I've used for testing. One morning, when Gregor Samsa woke from troubled dreams, he himself transformed in his bed into a horrible vermin. He lay on his armour-like back, and if he lifted his head a little he could see his brown belly, slightly domed and divided by arches into stiff sections. bold bold italic italic ! list list horizontal rule [1]: "Example"

Discussion:
"name": "Markup Setext Header", "scope": "markup.heading.setext", "settings": { <del> "fontStyle": "", </del> <ins> "foreground": "#A6E22E", "fontStyle": "bold" } }, { "name": "Markup Headings", "scope": "markup.heading.markdown", "settings": { "fontStyle": "bold" } }, { "name": "Markdown Quote", "scope": "markup.quote.markdown", "settings": { "fontStyle": "italic", "foreground": "#75715E" } }, { "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": "#E6DB74" } }, { "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": "#f8f8f2" } }, { "name": "Markdown List Punctuation", "scope": [ "punctuation.definition.list.begin.markdown" ], "settings": { </ins> "foreground": "#A6E22E" } },
Change:
After research some existing issues, I found the closest description of this issue is , however there are some difference. Instead of "behaving strangely", this feature now are not working at all. Instead of macOS Sierra, this issue happened to me with MacOS Catalina. I downloaded the insider version just now and still not working. Mac OS version macOS Catalina 10.15 VS code version Version: 1.40.1 Electron: 6.1.2 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Darwin x64 19.0.0 Issue Look up feature still not working with both "Force click" and "3-fingers tab". Tried to reinstaill, still not working. ! Does this issue occur when all extensions are disabled?: Yes, even when it's brand new
Still does not work w/1.56.2, Big Sur 11.3.1, vanilla vscode install.
Hope to have this fix too
Hope this will be fixed too. It does not work in edit window, but works in preview window. VSCode info as following: Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0
Judging from , the "lookup popup" stopped showing up since version 1.21, so it may be a good starting point to look at the changes made between 1.20 and 1.21.
I found out is the root cause for this issue. I will make a PR for this.

Discussion:
-webkit-user-select: none; -ms-user-select: none; } <ins> /* Use user-select: text for lookup feature on macOS */ /* https://github.com/microsoft/vscode/issues/85632 */ .monaco-editor.mac .lines-content:hover, .monaco-editor.mac .view-line:hover, .monaco-editor.mac .view-lines:hover { user-select: text; -webkit-user-select: text; -ms-user-select: text; } </ins> .monaco-editor.enable-user-select { user-select: initial;
Change:
default shoudl be 100. As pointed out we should measure if this has a perf impact on Edge, Chromium and FF We can also increase the default value only if we see that a screen reader is detected

Discussion:
import { PartFingerprint, PartFingerprints, ViewPart } from 'vs/editor/browser/view/viewPart'; import { LineNumbersOverlay } from 'vs/editor/browser/viewParts/lineNumbers/lineNumbers'; import { Margin } from 'vs/editor/browser/viewParts/margin/margin'; <del> import { RenderLineNumbersType, EditorOption, IComputedEditorOptions } from 'vs/editor/common/config/editorOptions'; </del> <ins> import { RenderLineNumbersType, EditorOption, IComputedEditorOptions, EditorOptions } from 'vs/editor/common/config/editorOptions'; </ins> import { BareFontInfo } from 'vs/editor/common/config/fontInfo'; import { WordCharacterClass, getMapForWordSeparators } from 'vs/editor/common/controller/wordCharacterClassifier'; import { Position } from 'vs/editor/common/core/position';

private _scrollLeft: number; private _scrollTop: number; <del> private _accessibilitySupport: AccessibilitySupport; private _accessibilityPageSize: number; </del> <ins> private _accessibilitySupport!: AccessibilitySupport; private _accessibilityPageSize!: number; </ins> private _contentLeft: number; private _contentWidth: number; private _contentHeight: number;

const options = this._context.configuration.options; const layoutInfo = options.get(EditorOption.layoutInfo); <del> this._accessibilitySupport = options.get(EditorOption.accessibilitySupport); this._accessibilityPageSize = options.get(EditorOption.accessibilityPageSize); </del> <ins> this._setAccessibilityOptions(options); </ins> this._contentLeft = layoutInfo.contentLeft; this._contentWidth = layoutInfo.contentWidth; this._contentHeight = layoutInfo.height;

return options.get(EditorOption.ariaLabel); } <ins> private _setAccessibilityOptions(options: IComputedEditorOptions): void { this._accessibilitySupport = options.get(EditorOption.accessibilitySupport); const accessibilityPageSize = options.get(EditorOption.accessibilityPageSize); if (this._accessibilitySupport === AccessibilitySupport.Enabled && accessibilityPageSize === EditorOptions.accessibilityPageSize.defaultValue) { // If a screen reader is attached and the default value is not set we shuold automatically increase the page size to 1000 for a better experience this._accessibilityPageSize = 1000; } else { this._accessibilityPageSize = accessibilityPageSize; } } </ins> // --- begin event handlers public onConfigurationChanged(e: viewEvents.ViewConfigurationChangedEvent): boolean { const options = this._context.configuration.options; const layoutInfo = options.get(EditorOption.layoutInfo); <del> this._accessibilitySupport = options.get(EditorOption.accessibilitySupport); this._accessibilityPageSize = options.get(EditorOption.accessibilityPageSize); </del> <ins> this._setAccessibilityOptions(options); </ins> this._contentLeft = layoutInfo.contentLeft; this._contentWidth = layoutInfo.contentWidth; this._contentHeight = layoutInfo.height;
Change:
! <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.40.1 OS Version: Darwin x64 17.7.0 Steps to Reproduce: some non-braking chinese words <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.445 --<!-- potentialduplicatescomment --
I've encountered the same problem. The input method I used is MacOS's default Chinese character input method. Version: 1.41.1 Commit: Date: 2019-12-18T14:57:51.166Z Electron: 6.1.5 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Darwin x64 19.2.0
I can reproduce this. Version: 1.44.2 Commit: Date: 2020-04-16T17:07:18.473Z Electron: 7.1.11 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Darwin x64 19.3.0
The same problem here.
I've just found that this issue won't appear when using Mojave. Only Macs using Catalina have this problem.
So how long will it be before you fix this bug... Now I'm using macOS Big Sur and the bug still exsit.
This problem can be reproduced when editor.letterSpacing: 1 is set, Have you also set it?
As you pointed out it's a behavior change of macOS Catalina, it's the system who decides where to position the IME box but somehow it doesn't put it next to the textarea.
that is not right, i am sure that it works properly in previous versions, but i can't tell you which version it is. btw, i use High Sierra all the time and never update anything.
I get the same bug.

Discussion:
top, left, canUseZeroSizeTextarea ? 0 : 1, this._lineHeight ); <ins> // In case the textarea contains a word, we're going to try to align the textarea's cursor // with our cursor by scrolling the textarea as much as possible this.textArea.domNode.scrollLeft = 1000000; </ins> return; }
Change:
Refs: x, open our in a docker container with node10 install, open debug viewlet create a by clicking on the launch gear and press debug start a port 3000 to your localhost 3000. Hit the port locally and notice how you get the application Forwarding port 3000 a port localy and notice that you still get the application even though you stopped the forwarding :bug:

Discussion:
if (--existing.refcount <= 0) { existing.value.then(tunnel => tunnel.dispose()); this._tunnels.delete(tunnel.tunnelRemotePort); <del> this._onTunnelClosed.fire(tunnel.tunnelRemotePort); </del> } <ins> } else { tunnel.dispose(); this._onTunnelClosed.fire(tunnel.tunnelRemotePort); </ins> } } };