jiebi/CodeConvo huggingface dataset:
Code change:
"values": [ { "name": "center", <del> "desc": "Places the center of the Grid Item's margin box at the center of the the Grid Item's column." </del> <ins> "desc": "Places the center of the Grid Item's margin box at the center of the Grid Item's column." </ins> }, { "name": "end",

Related discussion:
text: <!-- 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 Steps to Reproduce: The documentation has a spelling mistake LINK: -Value of an environment variable on the host machine (in this case, called VARIABLENAME). Unset variables are left blank. To for example, this would set a variable to your local home folder on Linux / macOS or the user folder on Windows:
/ , can you please point me to the GitHub page that corresponds to this page.
Thanks for pointing this out. It looks like we fixed the typo () but have not yet deployed the latest changes.
You are welcome, ! I was trying to fix the issue for Hacktoberfest 2022, but I was unable to figure out in which repo this file was located. Just out of curiosity I would like to know as to where the source file for the page with the typo reside in GitHub?
Thanks for looping me in! Opened a PR in is the repo for
Code change:
const possibleChangesLength = possibleChanges.length; if (inclusive) { <del> if ((getModifiedEndLineNumber(change.change) >= lineNumber) && (change.change.modifiedStartLineNumber <= lineNumber)) { </del> <ins> if (getModifiedEndLineNumber(change.change) >= lineNumber) { </ins> if (preferredProvider && change.label !== preferredProvider) { possibleChanges.push(i); } else {

Related discussion:
text: Open a file with multiple changed regions in git Move cursor inside/next to some change Run "Show Next Change" (alt+f3) It reveals and shows a different change- I think it always shows the last one in the editor. It should show the next one after the cursor position I can press it multiple times to cycle through changes, and that's correct, but it always starts with the last change
I'd like to fix this for April, but it looks like the change could be risky. I will fix it for May.
Found a low risk fix.
This works, thanks! But one thing that my muscle memory is unsure about, did this command previously move the cursor? I'm noticing that if I press it multiple times, then press escape, the view moves back to the place where I started, when I'm expecting this to be like a "navigate" action. I can open a new issue, or if it's always worked like this, it's fine
I went back to 1.74 to check, and it didn't move the cursor there. "Go to Next Change" will move the cursor though.
Code change:
} private async computeAndUpdateEnablement(): Promise<void> { <ins> this.enabled = false; this.class = UpdateAction.DisabledClass; this.label = this.getLabel(); </ins> if (!this.extension) { <del> this.enabled = false; this.class = UpdateAction.DisabledClass; this.label = this.getLabel(); </del> <ins> return; } if (this.extension.deprecationInfo) { </ins> return; }

Related discussion:
text: Code, search for "bracket pair colorizer" how it is nicely rendered as deprecated on install -notice dialog The dialog should offer a third button to configure built-in settings instead. Same if an extension had an alternative extension. Example: ! fyi
I assume you want the extra button to replicate this link in the hover tip, right? ! As an aside, any doc yet about how an extension gets tagged as deprecated?
yes, a button that will replicate that behaviour correct. No docs yet written. I plan to add them soon. The process is to write an email to us or to ping us on GitHub. In the future we will have a more straightforward approach when MP adds UI.
I feel, the third option would be a general options like More Information... clicking on this shall open the extension editor. This will be consistent and useful so that user will get enough info before taking an action
"More Information..." might work, but in order to have one less hop we could render: "Install EXTENSION_NAME Instead" "Enable Native Settings Instead" That would just do the action right straight away. I am not sure if those button names are too long. So just a suggestion. Whatever you prefer...
Yah I see your point, but going to extension editor gives user more information and an opportunity to look at the alternative extension before installing. And also I do not like that this button changes with extension. More Information... would be consistent.
That's fair. We can start with your proposal and see how it goes. My only concern with "More Information" is that the user might think it is more information about the deprecation. While we actually want to guide the user to a solution. So it is something like "More about the alternative". I am not sure if there is a good button label to represent this.
<img width="308" alt="image (1)" src="https://user-"
Changed the second button as follows ! !
Awesome!!
Code change:
export class SettingsChangeRelauncher extends Disposable implements IWorkbenchContribution { <del> private titleBarStyle: 'native' | 'custom' | undefined; private windowControlsOverlayEnabled: boolean | undefined; private windowSandboxEnabled: boolean | undefined; private nativeTabs: boolean | undefined; private nativeFullScreen: boolean | undefined; private clickThroughInactive: boolean | undefined; private updateMode: string | undefined; </del> <ins> private readonly titleBarStyle = new ChangeObserver<'native' | 'custom'>('string'); private readonly windowControlsOverlayEnabled = new ChangeObserver('boolean'); private readonly windowSandboxEnabled = new ChangeObserver('boolean'); private readonly nativeTabs = new ChangeObserver('boolean'); private readonly nativeFullScreen = new ChangeObserver('boolean'); private readonly clickThroughInactive = new ChangeObserver('boolean'); private readonly updateMode = new ChangeObserver('string'); </ins> private accessibilitySupport: 'on' | 'off' | 'auto' | undefined; <del> private workspaceTrustEnabled: boolean | undefined; private settingsProfilesEnabled: boolean | undefined; private experimentsEnabled: boolean | undefined; private enablePPEExtensionsGallery: boolean | undefined; </del> <ins> private readonly workspaceTrustEnabled = new ChangeObserver('boolean'); private readonly settingsProfilesEnabled = new ChangeObserver('boolean'); private readonly experimentsEnabled = new ChangeObserver('boolean'); private readonly enablePPEExtensionsGallery = new ChangeObserver('boolean'); </ins> constructor( @IHostService private readonly hostService: IHostService,

Related discussion:
text: I think a class like this could be helpful: Usage: Originally posted by in
please let me know if you like this!
This class is primarily owned by Hence assigning to him.
Yes, feel free, I can review a PR, thanks.
Code change:
let waitMarkerError: Error; const randomTmpFile = paths.join(os.tmpdir(), Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10)); try { <del> writeFileAndFlushSync(randomTmpFile, ''); </del> <ins> fs.writeFileSync(randomTmpFile, ''); </ins> waitMarkerFilePath = randomTmpFile; argv.push('--waitMarkerFilePath', waitMarkerFilePath); } catch (error) {

Related discussion:
text: This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out).
Code change:
let waitMarkerError: Error; const randomTmpFile = paths.join(os.tmpdir(), Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10)); try { <del> writeFileAndFlushSync(randomTmpFile, ''); </del> <ins> fs.writeFileSync(randomTmpFile, ''); </ins> waitMarkerFilePath = randomTmpFile; argv.push('--waitMarkerFilePath', waitMarkerFilePath); } catch (error) {

Related discussion:
text: There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though. Regardless, cheers and thanks for the work!
the calling process is waiting because it is not clear how long data is being sent to . It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "" at the end?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable it will always win over the guessing This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the command would detect. On Windows I see the  command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.
Code change:
/* No Tab Close Button */ .monaco-workbench > .part.editor > .content > .one-editor-silo > .container > .title .tabs-container > .tab.close-button-off { <del> padding-right: 28px; /* make room for dirty indication when we are running without close button */ </del> <ins> padding-right: 12px; transition: padding-right ease-in-out 100ms; </ins> } .monaco-workbench > .part.editor > .content > .one-editor-silo > .container > .title .tabs-container > .tab.close-button-off.dirty { background-repeat: no-repeat; background-position-y: center; background-position-x: calc(100% - 6px); /* to the right of the tab label */ <ins> padding-right: 28px; /* make room for dirty indication when we are running without close button */ </ins> } .vs .monaco-workbench > .part.editor > .content > .one-editor-silo > .container > .title .tabs-container > .tab.close-button-off.dirty {

Related discussion:
text: If user does not want the close button to be visible - vscode could make tabs more narrow to show more tabs. Tabs with changed content could get wider to show the 'dot' denoting unsaved file ! !
[ ] Verify: when the tab close button is disabled, the tabs are not leaving room for the dirty indicator until the editor is actually dirty.
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Related discussion:
text: Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Related discussion:
text: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Related discussion:
text: Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Related discussion:
text: Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Related discussion:
text: <!-- 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 <!-- 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 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR.