jiebi/CodeConvo huggingface dataset:
Code change:
} private _onMouseWheel(e: StandardMouseWheelEvent): void { <ins> let browserEvent = e.browserEvent; if (browserEvent.ctrlKey){ let zoomLevel:number = Browser.getEditorZoomLevel(); let delta = e.deltaY > 0 ? 1 : -1; zoomLevel += delta; Browser.setEditorZoomLevel(zoomLevel); return; } </ins> if (Platform.isMacintosh && e.browserEvent && this._options.saveLastScrollTimeOnClassName) { // Mark dom node with timestamp of wheel event let target = <HTMLElement>e.browserEvent.target;

Related discussion:
text: VSCode Version: 1.1.1 OS Version: Windows 7 x64 It would be great if holding the key + spinning the mouse wheel would increase / decrease the VS Code zoom value.
I am not sure we want to zoom the entire UI when you use the mousewhell, I would expect only the editor font to increase. Thereby moving to
yes you are correct.
Didn't this feature used to work, or am I just failing to remember correctly? I was just going to report this as a bug, but maybe it never actually worked. I jump between different computer setups fairly regularly, so maybe I am just not remembering. Anyway, I found this dupe, and didn't want to submit a new issue. Thanks for your efforts By the way, I think I would expect this feature to work the same way that and work. VSCode's UI deviates from many other UIs in that it scales well, so I think I'd expect this to scale the entire UI consistently with the keyboard commands.
If this zooms only the editor, shouldn't it be seperate from ?
I would expect and to zoom only the editor. That behaviour would be consistent with most (all?) other editors and apps. Scaling the entire interface is an accessibility feature IMO, so maybe it doesn't need to use such a commonly used shortcut by default? Beyond Ctrl+Wheel, pinch to zoom should also zoom the editor.
Can this be disabled? I'm constantly accidentally zooming my text to a tiny size when I ctrl-click and accidentally brush my fingers over the trackpad.
This is disabled by default, so you must have enabled it in the past --
Thanks - I came here to vote for this feature, and it turns out I just had to turn it on! Shouldn't this issue be closed?
:+1: Closing since this is implemented. The feature is disabled by default due to numerous issues reported by users using touchpads where we begin to unexpectedly zoom in/zoom out when e.g. using ballistic scrolling and pressing the ctrl/cmd modifier. The root problem is that we cannot differentiate events coming in from a real mouse with a wheel from those coming in from touchpads / trackpads.
Code change:
public setDetailsProvider(provider: (index: number) => { details: string, isMarkdown: boolean }): void { this.detailsProvider = provider; <ins> if (this.options) { const currentOptions = this.options; this.options = []; this.setOptions(currentOptions, this.selected, this.disabledOptionIndex); } </ins> } public focus(): void {

Related discussion:
text: New enum/select box detailed descriptions should be read by reader. Add describedby attribute handling for details provider within selectbox.
Either describedby or just
Yep, I've thought about live/alert also. By my research this does not really match the expected taxonomy for the accessibility tree, an extended description is pretty much exactly what describedby is for. That said, describedby probably will not be happy changing which will mean I will need the static set of descriptions in the Dom. Not a big deal, just another example of where nothing is straightforward. But, that's why we get paid the big bucks ... well at least you :-o ! What I really want to solve is getting rid of the multiple 'clickable' readings. I think I may have a way to avoid that which will be very important for these descriptions given the number of links.
Good point, I have no idea if pointing all of the selectbox items at the same details box will work, or if there's something we can do to order events to make it work better. Or maybe changing the 'id' of the details element for each item. I'm very curious what's causing that! Very weird.
describedby can have a list of IDs associated with it. like labeled by and most other ARIA aspects it does not like things changing underneath it, that of course is what aria-live is for but, but everything I read says use this judiciously. I think having a separate set of descriptions (modified for reader output/minimal clickable) will not be a big deal. Just as the options are static, so are the descriptions so hiding them in the select for use will not be an issue. I haven't done the definitive experiment yet but, I believe the multiple clickable issue has to do with something like this: I think the reader can find these as all clickable elements when they are descendents of a managed accessibility tree. my research has yet to determine if this is considered a bug or as designed
Code change:
const activeTextEditor = window.activeTextEditor; // Must extract these now because opening a new document will change the activeTextEditor reference <del> const previousVisibleRange = activeTextEditor?.visibleRanges[0]; </del> <ins> const previousVisibleRanges = activeTextEditor?.visibleRanges; </ins> const previousURI = activeTextEditor?.document.uri; const previousSelection = activeTextEditor?.selection;

Related discussion:
text: When using the new diff editor with enabled, I very rarely get to the right editor position whenever I click the top action, above the editor.
You mean go to reference is broken?
diff editors have an action to open the original file (I think contributed from SCM?). When clicking that, expectation is that the current view state of the diff editors right hand side applies to the opening editor so that you stay in exactly the same view state (for example: the selection and viewport). <img width="140" alt="image" src=""
I really like the collapsed diff editor but this is a very frustrating regression from it which makes me want to shut it off. The issue is 100% reproducible in my usual workflow and I encounter this issue many times per hour.
I can reproduce. The "Open File" command is a mystery to me. Debugging shows me that is called twice, but both times with unhelpful stack traces: ! ! The second invocation sets . However, there is no reveal mechanism.
Further investigation showed that the "Open File" action is actually implemented in the git extension (even when comparing two files on disk) :/ Which I think is very questionable design, as it should be a core diff editor feature.
Code change:
<ins> 3af1be2861b5de836b35e7a2e5eeaffa2b4517c3024ebd8658033be5aa98c3ce *electron-v22.3.11-darwin-arm64-symbols.zip 5441f785aefc23d53466872b8f1836a172b20f0a0ddf019dfe6cfc498e9e8e19 *electron-v22.3.11-darwin-arm64.zip 473ba98236a945113f3ea5e3b7d3c3d1bc108bb8c99c5d35917c4ee01c0bb4be *electron-v22.3.11-darwin-x64-symbols.zip 8bd965b00c19de5e880feeff92e01cb0570c436ff6a97e271123e340fee157c3 *electron-v22.3.11-darwin-x64.zip 689281dc20066f98673261b77337d018237f8b0d11f6e3b14dedec24d90f2df4 *electron-v22.3.11-linux-arm64-symbols.zip d9ade7f28e10c3ca0ddc5ada982574a3d84f30fb9f92a82608666608b801ca8a *electron-v22.3.11-linux-arm64.zip 926a0adfb9bf1d2ed3cd26b0bcc8efe66eb793ddc309dff8e6f230abf12ca6e5 *electron-v22.3.11-linux-armv7l-symbols.zip 857eadea9ba34dacf7822d4bb58fd62fd585cc5c5a5b81c0ac32e55108038382 *electron-v22.3.11-linux-armv7l.zip 529057b7fe9be5958bd56b2d18b32d85cb9337ccb76878c67afb799b0f166130 *electron-v22.3.11-linux-x64-symbols.zip 6b5d2a18eab1d14b9f60180c246fb07cd09b298e4e8da1bf517b83ca6c0d0242 *electron-v22.3.11-linux-x64.zip 472a3a15ee7e94ba4cc47052ec4be90fa1072955367bdf135591f12e623af167 *electron-v22.3.11-win32-arm64-pdb.zip 104a685a78556c61c3f7c6fe33f84a3091199150e44e701e513a5d49afef0c55 *electron-v22.3.11-win32-arm64-symbols.zip 3debd92e3be6b74c6b8f25ec7963e8ab94fb877c50c06026aea4bac308311604 *electron-v22.3.11-win32-arm64.zip 38617bd350dd5f757be2cd43afb2238ac42d97714f96a1f27839d04447a31d82 *electron-v22.3.11-win32-ia32-pdb.zip 12b8a47ddae57eb55dcf8aa1fdf39b9575fcb150de1c9bb2444d8702a7d3efec *electron-v22.3.11-win32-ia32-symbols.zip 463062b6bdc09c11ab083c667aae2d6b677f945449ff7bf482059c6086a28e7b *electron-v22.3.11-win32-ia32.zip 3f5bf196a4de1c2b8efedc5f0ef690a41645b33a36e62c307164cb66e20cfaa7 *electron-v22.3.11-win32-x64-pdb.zip b4edb586a021013333badb6e1974e42e0b673f5f49bc7909a338b3e9ad46f7ef *electron-v22.3.11-win32-x64-symbols.zip 7944be5db19c2fa16aa887ec0ca287e84dfe8676d8223165b811ffec1dd57b3d *electron-v22.3.11-win32-x64.zip f2e3db6dc9c7b6e779a034bc4ede297213a05f1a80e0d5fc7fa02e6f8438ecd2 *ffmpeg-v22.3.11-darwin-arm64.zip 5b1732b2f67aa98cb5a0ad9b5caf085c11449bc9710971a2344c10f471cc986f *ffmpeg-v22.3.11-darwin-x64.zip 8233e865973bed62bb1d16011a29eb1e39851725509523bb3c54281b9ecad7e0 *ffmpeg-v22.3.11-linux-arm64.zip 18464ab29adc06c72602b30b4c101ed27edadccee9476f3bd54411e791b415ee *ffmpeg-v22.3.11-linux-armv7l.zip 4467c2e6c5b45cf11d8c2e06bfed76982c95fc50701cf13350b19d100080addd *ffmpeg-v22.3.11-linux-x64.zip 8abc4dddf1e105a3375f56a8dd804101c014919a87dcd231cdb3b19ad6c30f7a *ffmpeg-v22.3.11-win32-arm64.zip 295d3d628460c4b25f751ebc3763bf7ec72a57a337f89ed1ef6f666e3dcfecf5 *ffmpeg-v22.3.11-win32-ia32.zip 17c5e7ec2248521d7064cfa91e9d894981e53a6391e65b83e35ff4f30001b2c5 *ffmpeg-v22.3.11-win32-x64.zip </ins>

Related discussion:
text: Today when running out of sources and/or building, we get some components from online resources such as GitHub or our Marketplace. We should add SHA256 checksum verification to these: [x] [x] built-in extensions [x] electron
Adding the foundation for this for and extensions in
Code change:
<del> 2024-07-04T16:31:11.121Z </del> <ins> 2024-08-06T11:06:57.600Z </ins>

Related discussion:
text: It appears that this is possible now, and we should consider adopting this in VS Code ()
There is community interest:
Please add this!
Steps for verification: Connect to Windows arm64 using the latest pre-release of SSH extension () Verify that connection is successful Use or similar tool to confirm that executable is of architecture.
Code change:
"icon": "images/icon.png", "activationEvents": [ "onProfile", <del> "onProfile:github" </del> <ins> "onProfile:github", "onLanguage:json", "onLanguage:jsonc" </ins> ], "enabledApiProposals": [ "profileContentHandlers"

Related discussion:
text: Type: <bBug</bExpected: ! Actual: ! Steps to Reproduce: a file. one configuration for any language. in ${} block and intellisense doesn't provide proper hints. More Info: bug is likely related to and . bug can be reproduced in 1.79.0-insider. VS Code version: Code 1.78.2 (, 2023-05-10T14:39:26.248Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
Going way back to , this change seems right since the configuration-editing extension has contributions for these languages but the extension doesn't actually activate unless I add explicit activation events. I can't figure out why the auto activation event isn't kicking in?
Oh, sorry--we revised the event to only do auto activation if the extension also contributed a language definition for that language, since otherwise this led to extensions like Python being activated too eagerly. For debug we should restore the explicit activation events too.
I see, thanks
Code change:
@IInstantiationService private readonly _instantiationService: IInstantiationService, @ILabelService labelService: ILabelService, @IFileService fileService: IFileService, <del> @IFilesConfigurationService filesConfigurationService: IFilesConfigurationService </del> <ins> @IFilesConfigurationService filesConfigurationService: IFilesConfigurationService, @IExtensionService extensionService: IExtensionService, @IEditorService editorService: IEditorService </ins> ) { super(resource, undefined, labelService, fileService, filesConfigurationService); this._defaultDirtyState = !!options.startDirty;

Related discussion:
text: Testing a new notebook and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , :bug: The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
can you maybe check from the notebook side?
Luna paint behaves similarly with one extra step: a new image and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , (different) and the switch profile operation is blocked switch profiles again The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
Somehow today I cannot reproduce an issue with insiders: ! Please give me more detailed steps and see if you still find this.
still seeing it. Did you try making edits after switching? that's when the dirty indicator doesn't show up anymore. ! I saved as a different filename in the gif, but keeping the untitled filename still doesn't show a dirty indicator, nor does it auto-save.
This seems to me like something notebooks need to handle better: if you enter an extension host that does not have the notebook extension and you make edits, the editor should probably not allow that. I.e. the editor should maybe turn readonly once the extension is disabled or not present.
- the notebook extension is built-in so it's still available in an empty profile. The repro steps can even start with an empty profile -and make an edit to the first cell profile to default and save as 1.ipynb when prompted an edit in the notebook :bug: file is not dirty
oh nice, sounds like an issue related to EH restart then, will update the title With your working copy knowledge you might be even able to figure this out ;)
It looks like the issue in the notebook scenario is that it's calling save directly on the workingCopy in the : In the untitled case, that will delegate to saveAs, which will dispose the untitled workingcopy without opening a new editor with the resulting . The editor is left open with its underlying WorkingCopy disposed. For non-built-in custom editors though, it seems like we should just close them if we don't know if they will be supported in the new profile.
Code change:
@IInstantiationService private readonly _instantiationService: IInstantiationService, @ILabelService labelService: ILabelService, @IFileService fileService: IFileService, <del> @IFilesConfigurationService filesConfigurationService: IFilesConfigurationService </del> <ins> @IFilesConfigurationService filesConfigurationService: IFilesConfigurationService, @IExtensionService extensionService: IExtensionService, @IEditorService editorService: IEditorService </ins> ) { super(resource, undefined, labelService, fileService, filesConfigurationService); this._defaultDirtyState = !!options.startDirty;

Related discussion:
text: I don't see how we can expect a custom editor to support a scenario where its source extension isn't installed - is that even possible? I went over the issue with and concluded that we can defer to next release since the previous stable version also didn't handle this scenario well.
fyi I just created which is a similar issue for custom editors. Here for notebooks I suggest the following: if the EH restarts and still has the notebook extension for the opened notebooks, reconnect to the EH and allow to further make edits on the editor (I actually thought this was already implemented based on the work did) if the EH restarts and there is no more extension for the notebook editor, turn the notebook readonly and inform the user somehow Does that make sense?
The previous change just doesn't account for untitled notebooks, but I think I can fix that. That makes sense, although I'm surprised that we would require all custom editors to handle this (asked about it in the other issue)
Code change:
newDocument.body.appendChild(defaultScripts); styleBody(newDocument.body); <ins> const frame = getTarget(); frame.setAttribute('id', '_oldTarget') </ins> // keep current scrollTop around and use later <del> const scrollTop = getTarget().contentDocument.body.scrollTop; </del> <ins> const scrollTop = frame.contentDocument.body.scrollTop; const newFrame = document.createElement('iframe'); newFrame.setAttribute('id', '_target'); newFrame.setAttribute('frameborder', '0'); newFrame.style.cssText = "margin: 0; overflow: hidden; position: absolute; width: 100%; height: 100%; display: none"; document.body.appendChild(newFrame); </ins> // write new content onto iframe <del> getTarget().contentDocument.open('text/html', 'replace'); </del> <ins> newFrame.contentDocument.open('text/html', 'replace'); </ins> // set DOCTYPE for newDocument explicitly as DOMParser.parseFromString strips it off // and DOCTYPE is needed in the iframe to ensure that the user agent stylesheet is correctly overridden <del> getTarget().contentDocument.write('<!DOCTYPE html>'); getTarget().contentDocument.write(newDocument.documentElement.innerHTML); getTarget().contentDocument.close(); </del> <ins> newFrame.contentDocument.write('<!DOCTYPE html>'); newFrame.contentDocument.write(newDocument.documentElement.innerHTML); newFrame.contentDocument.close(); </ins> // workaround for https://github.com/Microsoft/vscode/issues/12865 // check new scrollTop and reset if neccessary <del> setTimeout(function () { if (scrollTop !== getTarget().contentDocument.body.scrollTop) { getTarget().contentDocument.body.scrollTop = scrollTop; </del> <ins> setTimeout(() => { if (scrollTop !== newFrame.contentDocument.body.scrollTop) { newFrame.contentDocument.body.scrollTop = scrollTop; </ins> } <ins> document.body.removeChild(frame); newFrame.style.display = 'block'; </ins> }, 0); ipcRenderer.sendToHost('did-set-content', stats);

Related discussion:
text: I notice that when I edit our 1.9 release notes, the markdown preview seems to jump up and down all the time there is a change. Compared to 1.8 stable, this seemed to not happen.
Better, I still see flickering that it jumps up and down a little bit and the decoration to the left to show me the current edited location is also flickering. let me know if I should open a separate issue on that or if you think that is fixable.
The flicker should now be better than VSCode 1.8, but we can still do better. I've noticed the same sort of slight flicker on images in particular and on the current paragraph indicator as you noted. Please open another, lower priority issue so that we can track further improvements Thanks
Code change:
} } case 'server': <del> if (arch === 'arm64') { throw new Error(`Unrecognized: ${product} ${os} ${arch} ${type}`); } </del> return `server-win32-${arch}`; case 'web': <del> if (arch === 'arm64') { throw new Error(`Unrecognized: ${product} ${os} ${arch} ${type}`); } </del> return `server-win32-${arch}-web`; case 'cli': return `cli-win32-${arch}`;

Related discussion:
text: It appears that this is possible now, and we should consider adopting this in VS Code ()
There is community interest:
Please add this!
Steps for verification: Connect to Windows arm64 using the latest pre-release of SSH extension () Verify that connection is successful Use or similar tool to confirm that executable is of architecture.
Code change:
}); }); <del> test('Expand abbreviation with no self closing tags for html', () => { </del> <ins> test.skip('Expand abbreviation with no self closing tags for html', () => { </ins> return withRandomFileEditor('img', 'html', async (editor, _doc) => { editor.selection = new Selection(0, 6, 0, 6); await expandEmmetAbbreviation({ language: 'html' });

Related discussion:
text: Build:
Hit this again with
Again:
is trying to get more details when this happens:
Also saw this
This is because of atomic writing and in windows renaming is failing sometimes and I think this is because some other processes (defender ) might be holding the file that has to be renamed. I have seen similar issues in extensions when I implemented atomic installation of extensions long time back, ie. extracting the zip to a temp file in the same folder and renaming it. I have to retry renaming multiple times to avoid this. I am not sure if this is the right solution for FS atomic write. So, I would wait for until then I will revert my atomic write changes.
Check this issue - This is common in windows and it seems the workaround is to retry.
should the skipped tests be restored, I think they are still skipped
Seems like they can probably be restored.
Code change:
private _hide(): void { this._accessibleBuffer.classList.remove('active'); <del> this._xtermElement.classList.remove('hide'); </del> this._xterm.raw.focus(); }

Related discussion:
text: Type: <bBug</bcc: Since Friday the 3rd, I have not been able to access the terminal accessibility buffer in my linux environment. I activate a terminal and am informed by orca about accessibility in the terminal. But pressing shift+tab does not move the focus to the accessibility buffer. Am I doing something wrong or has something changed from day 3? VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-06T05:21:55.128Z) OS version: Linux x64 6.1.14-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (39)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-chatgpt3.9.4 rest-client0.25.1 better-cpp-syntax1.17.2 azure-pipelines1.208.0 vscode-docker1.24.0 csharp1.25.4 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.283.0 remote-ssh0.99. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.14.4 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell-preview2023.2.1 remote-explorer0.3. vsliveshare1.0.5832 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.16. vscode-xml0.25. vscode-yaml1.11.0 sonarlint-vscode3.15.1 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.44.0 vscode-java-debug0.49. vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.40.
Code change:
private _hide(): void { this._accessibleBuffer.classList.remove('active'); <del> this._xtermElement.classList.remove('hide'); </del> this._xterm.raw.focus(); }

Related discussion:
text: vscode-spring-boot-dashboard0.11.1 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
You can use this command for now, but I can repro the issue
The other change that has been made here is tab moves focus mode has to be on for that keybinding to work. This prevents issues where the terminal should be handling shift + tab such as for or autocomplete. The clause for this command can be configured in the keybindings editor though if you do not like this behavior.
After using the command Terminal: Focus Accessible Buffer, the behavior was a little strange. focus is on the accessible buffer, the tab key does not move focus to the terminal, but to the status bar. When I'm in the accessible buffer I need to press tab and then shift+tab to access the terminal. seems that the accessible buffer is not always updated when I execute a command in the terminal.
Yes thanks, covered in these issues:
Code change:
private _hide(): void { this._accessibleBuffer.classList.remove('active'); <del> this._xtermElement.classList.remove('hide'); </del> this._xterm.raw.focus(); }

Related discussion:
text: there's an issue now because tabbing goes to the status bar instead of the terminal. I see that isn't set on the element. even when I set that explicitly, it seems like it's removed Originally posted by in