jiebi/CodeConvo huggingface dataset:
Code change:
cursors.setStates( args.source, CursorChangeReason.Explicit, <del> CursorMoveCommands.addCursorDown(context, cursors.getAll()) </del> <ins> CursorMoveCommands.addCursorDown(context, cursors.getAll(), useLogicalLine) </ins> ); cursors.reveal(true, RevealTarget.BottomMost, ScrollType.Smooth); }

Related discussion:
text: VSCode Version: 0.10.11 OS Version: OS X 10.10.5 Steps to Reproduce: a long line of text that wraps in the editor the cursor on the first line and press Cmd-Option-Down (on OS X). This creates a second cursor on the next visual line, which means it is somewhere on the same logical line depending on how the text is wrapped. When creating multiple cursors on adjacent lines, often it is to perform the same edit on multiple (logical) lines that are aligned with each other. The current behavior having the second cursor appear instead at some situation-specific place on the same logical line throws a wrench in this workflow. I can't think of a good situation where it makes sense (though I do realize it is consistent with pressing the down arrow without cmd-option) Definitions: a logical line is a line in the file on disk. A visual line is a line in the editor. A logical line may span multiple visual lines when there is wrapping.
Code change:
this.raw.dispose(); } this.raw = undefined; <ins> this.fetchThreadsScheduler = undefined; </ins> this.model.clearThreads(this.getId(), true); this._onDidChangeState.fire(); }

Related discussion:
text: <!-- Please read our Rules of Conduct: --<!-- 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.41 OS Version: Ubuntu 18.04 Steps to Reproduce: a debug adapter the pause feature the debug adapter and see that pause works the debug adapter using the restart button that pause no longer works <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No The commit is used to slow down fetching threads from a debug adapter. However, when using the default restart mechanism, is disposed (via and therefore no longer runs after restarting the debug adapter.
Thanks for filling this issue. Can you be so kind to fork Mock Debug and to create changes on top of it such that this issue is reproducable. Since I can not reproduce it using node - gif attached !
It looks like I was missing sending an so the same debug session was being reused after restart.
I also made this comment in the pull request: The says "A debug adapter is expected to send this event when it is ready to accept configuration requests (but not before the ‘initialize’ request has finished)." So either the specification needs to say "required" instead of "expected" or there is a bug in VS Code. VS Code doesn't seem to correctly handle the situation where the debug adapter never sends . Although the fix may be to create a new debug session object instead of the fix that I have proposed.
Simply removing the line that sends from the mock debug unfortunately extension doesn't seem to be enough to reproduce the problem, but since I found a workaround, I can't really justify spending more time on it.
did you verify that this works with the latest VS Code insiders as expected?
Code change:
public readonly data: number[] ) { } <del> public static cmp(a: OverviewRulerDecorationsGroup, b: OverviewRulerDecorationsGroup): number { </del> <ins> public static compareByRenderingProps(a: OverviewRulerDecorationsGroup, b: OverviewRulerDecorationsGroup): number { </ins> if (a.zIndex === b.zIndex) { if (a.color < b.color) { return -1;

Related discussion:
text: a TS file, use the keyboard and type out a syntax error. The scrollbar error marker doesn't show up. the text cursor to another location using the mouse. The scrollbar error marker shows up then. says:
Very likely a regression from
Code change:
this._register(this.extensionManagementService.onDidInstallExtensions(async (result) => { const hadLastFoucs = await this.hostService.hadLastFocus(); for (const e of result) { <ins> if (e.context?.[EXTENSIONS_SYNC_CONTEXT_KEY]) { continue; } </ins> // If the window had last focus and the install didn't specify to skip the walkthrough // Then add it to the sessionInstallExtensions to be opened if (hadLastFoucs && !e?.context?.skipWalkthrough) {

Related discussion:
text: I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).
Code change:
}); }); <del> test('updateElementHeight with anchor #121723', async function () { </del> <ins> test('updateElementHeight with anchor', async function () { </ins> await withTestNotebook( [ ['# header a', 'markdown', CellKind.Markup, [], {}],

Related discussion:
text: Ideas to experiment with: Don't shrink a cell while it is executing -less jumpy as output is replaced change the anchor heuristic from "if the resizing cell is partially visible" to "if the cell's output will shrink out of view" Anchor to a focused cell if the focus is in the cell's editor cc
For the new heuristics we are adding (growing upwards or downwards), they should probably be interrupted the moment users start to scroll, for example, if I scroll manually to a specific position, I would expect the scroll top not to change.
I disagree - That could mean if you have a cell focused and anchored, and you scroll to get it higher in the view, it would then start getting pushed down as the previous cell grows.
If I scroll to get it lower in the view, as I want to read the cells above, and since it's still in the view and focused/anchored, the cells I was reading will then pushed upwards, right? This feels unnatural compared to how browser handles scrolling or Terminal. Terminal scenario might be closer to this, as it usually sticks to the bottom when the shell is streaming outputs, but the very moment we scroll upwards, it stops sticking to the bottom.
Code change:
"@parcel/watcher": "2.1.0", "@vscode/iconv-lite-umd": "0.7.0", "@vscode/proxy-agent": "^0.14.1", <del> "@vscode/ripgrep": "^1.15.4", </del> <ins> "@vscode/ripgrep": "^1.15.5", </ins> "@vscode/spdlog": "^0.13.10", "@vscode/vscode-languagedetection": "1.0.21", "@vscode/windows-process-tree": "^0.5.0",

Related discussion:
text: From Probably a regression from making aarch64-linux ripgrep build statically compiled to fix We might need to dynamically compile ripgrep instead of using musl, and find a container to compile it in. related // cc
Looks like jemalloc just needs to be configured with to support 16K page size. This can be achieved by setting the environment variable: (16K page size) Or to support 64K page size as well: (64K page size) In either case, it'd still work for 4K/16K(/64K) page sizes.
Do we have any good news on this? I found the similar thing happened before on other application like , probably we can use the same approach to solve this one?
Any update on this issue ?
Temporary Workaround: To address the issue until it is fixed, follow these steps: Install ripgrep and obtain its path. For Rocky Linux or any RHEL-based Linux distribution, run the following command with root privileges: For Ubuntu, use the following command: Alternatively, you can install ripgrep using Cargo: Verify the installation and retrieve the path by running: Replace the broken rg with a symlink by executing the following script. Please note that you should remove the echo commands to commit the changes: This workaround should help resolve the issue temporarily.
This should be fixed in tomorrow's VS Code Insiders. Please try it out and let me know if it works for you!
I tried but it seems not fixed or not included the fix. execute from the remote server(aarch64) and got <jemalloc: Unsupported system page size <jemalloc: Unsupported system page size memory allocation of 5 bytes failed find: ‘.vscode-server-insiders/bin//nodemodules/ terminated by signal 6 (after resetting the remote environment by deleting .vscode-server-insiders folder on the remote, and vscode reloaded. - 'Developer: Reload Window')
Are you running 16K page size or 64K?
I got $ getconf PAGESIZE on the aarch64 remote (Rocky Linux 8, aws r7g instance/Graviton3 processors).
Code change:
"@parcel/watcher": "2.1.0", "@vscode/iconv-lite-umd": "0.7.0", "@vscode/proxy-agent": "^0.14.1", <del> "@vscode/ripgrep": "^1.15.4", </del> <ins> "@vscode/ripgrep": "^1.15.5", </ins> "@vscode/spdlog": "^0.13.10", "@vscode/vscode-languagedetection": "1.0.21", "@vscode/windows-process-tree": "^0.5.0",

Related discussion:
text: Meanwhile, executing the same command above on x86-64 remote, I got the normal rg help print out as like error: The following required arguments were not provided: and correcting the hand typed typo above of vscode insider version info Version: 1.79.0-insider (user setup) Commit: Date: 2023-05-19T20:39:14.598Z Electron: 22.5.2 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
Hmm ok. I tried setting the env variable to increase max page size for jemalloc, but it seems to not be working. I'll try another approach.
If you let me know what you are attempting, I can also try out some stuff. Page size here is
Is this fixed in the latest release version of VScode? I just check on my arm64 container but it seems not working. VScode Version: 1.79.0 (Universal)
Same with Switched to newest insider build. . Problem not solved. Went to server, killed and deleted . Tried again to bootstrap. Problem is still NOT resolved. Search is still limited to open files.
!
Here is some useful link detailing what I think is the problem. Not sure if it is resolved by now. But if info from the discussion is current, I think you will have to either compile on the target system, or ship different precompiled versions of binary and select the correct one depending on the system specs (see ).
We do cross-compile for different systems for ripgrep I'll have to take another look.
So, my interpretation is, that the page-size is hard-coded into jemalloc. When the system page size at runtime differs from the one it is compiled for, it will fail. In other words, the one shipped right now fails out of the box: From your linked repo, I understand that you now focus on 16k page size. That would also not help me (if my suspicion is right), as my system's page size is: 64k
: Temporary fix. Bootstrap on target ARM system. You should have a directory called now. That is where the vscode server lives.
Code change:
"@parcel/watcher": "2.1.0", "@vscode/iconv-lite-umd": "0.7.0", "@vscode/proxy-agent": "^0.14.1", <del> "@vscode/ripgrep": "^1.15.4", </del> <ins> "@vscode/ripgrep": "^1.15.5", </ins> "@vscode/spdlog": "^0.13.10", "@vscode/vscode-languagedetection": "1.0.21", "@vscode/windows-process-tree": "^0.5.0",

Related discussion:
text: Download and compile : Replace binary deployed by with custom compiled version. Now search should work as expected.
can you check if the following runs fine on your aarch64 setup ? The build is generated from to use 64k for jemalloc.
Thanks built from source works for me!
can any of you verify this:
I untar-ed the file and the binary 'rg' is working good with remote search. (I sym-linked it with vscode 1.79)
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I can confirm it is fixed with the vscode insider downloaded a minute ago of (assume the commit hash changed since)
thanks so much for checking!
Code change:
const specIcon = gulp.src('resources/linux/rpm/code.xpm', { base: '.' }) .pipe(rename('SOURCES/' + product.applicationName + '.xpm')); <del> const all = es.merge(code, desktops, appdata, icon, bash_completion, zsh_completion, spec, specIcon); </del> <ins> const all = es.merge(code, desktops, appdata, workspaceMime, icon, bash_completion, zsh_completion, spec, specIcon); </ins> return all.pipe(vfs.dest(getRpmBuildPath(rpmArch))); };

Related discussion:
text: A Visual Studio Code workspace file is currently recognised in Linux as a normal plain text file. This is because there isn't a MIME type for this file. Applications can provide additional MIME types as described here: Not having a MIME type has a couple of issues, for example the files are shown as plain text files in the GUI, which makes it hard to distinguish source code files from the workspace file. This slows down navigating to a workspace and opening it. Find the workspace in the following screenshot ! It's currently impossible to theme such a file because it's not seen as a different MIME type:
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.461 --<!-- potentialduplicatescomment --
This also means that you can't make double clicking the workspace from a file browser open it in vscode, unless you're OK with all text files opening in vscode, which is probably not what most folks want.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hi can you verify this issue? Check out the previous comment.
I tried to verify this but am not sure how to do this myself. I've not used desktop linux extensively; I tried reinstalling Insiders from the on Lubuntu to see if it associated files with VS Code, but that didn't happen.
Verified by installing insiders from on Ubuntu and was able to see mimetype and set a custom icon ! upon uninstalling it was removed.
Code change:
import { SideBySideEditorInput } from 'vs/workbench/common/editor/sideBySideEditorInput'; import { AutomaticLanguageDetectionLikelyWrongClassification, AutomaticLanguageDetectionLikelyWrongId, IAutomaticLanguageDetectionLikelyWrongData, ILanguageDetectionService } from 'vs/workbench/services/languageDetection/common/languageDetectionWorkerService'; import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; <ins> import { TerminalSettingId } from 'vs/platform/terminal/common/terminal'; </ins> class SideBySideEditorEncodingSupport implements IEncodingSupport { constructor(private primary: IEncodingSupport, private secondary: IEncodingSupport) { }

Related discussion:
text: Testing an editor and write something in it. tab until you reach the terminal. Type something in the terminal. . Realize that tab is correctly not moving focus in the terminal. command "Toggle Tab Key Moves Focus" out of the terminal and keep tabbing until you get back to your editor. something in the editor. again until you reach the terminal. something in the terminal. to tab out of the terminal. It looks like tab moves focus as toggled itself off. Tab moves focus seems to be off for both terminal and editor at this point until reload.
I can also cause similar behavior if I flip the settings.
what is supposed to happen now? What I think I expect to happen (and isn't happening): If I run "Toggle tab key moves focus" while in a place where it doesn't move focus via setting, then it now globally moves focus. If I run "Toggle tab key moves focus" while in a place where it does move focus, then it now globally does not move focus. However, I'm not a "tab moves focus" user, so maybe my expectations are bogus.
Thank you for testing. Those expectations are correct, except that the toggling does not apply globally - it is per area. So, if I have in settings: terminal tab focus mode: on editor tab focus mode: off where: = status bar indicator = no status bar indicator focus the terminal focus the editor focus the terminal and toggle it off focus the editor and toggle it on focus the terminal focus the editor reload the window and focus the terminal focus the editor I see that this is not working atm because I'm not reacting to configuration changes
fyi for easier testing since the command palette can cause the terminal to no longer be focused, I'd suggest using the keybinding to toggle tab focus mode
Code change:
import { Mime, mediaMimes } from '../../util/mimes'; import { Schemes } from '../../util/schemes'; import { createEditForMediaFiles, tryGetUriListSnippet } from './shared'; <ins> import { getParentDocumentUri } from '../../util/document'; </ins> class ResourceDropProvider implements vscode.DocumentDropEditProvider {

Related discussion:
text: I tested on Win11 & Win10. It works as long as you start a new workbook and don't save the jupyter notebook. Once you save the notebook, your pastes of images from the clipboard will no longer be treated as inline attachments. Originally posted by in
Possibly getting overridden by a markdown file paste provider?
were you able to replicate my findings?
Reviewed this thoroughly, and found the following. All cases are performed with a screenshot copied to the clipboard, and pasting into markdown notebook cells using ctrl+v. Using Windows 11 and current insiders. With setting unsaved notebook (command pallete -new jupyuter notebook -) results in broken markdown image link pasted, broken rendering (see screenshots attached) ! ! saved notebook creates image file on disk, creates markdown image link, renders correctly. With setting unsaved notebook (command pallete -new jupyuter notebook -) results in correct inline attachment image link pasted, renders correctly saved notebook results in correct inline attachment image link pasted, renders correctly
With the above investigation, I believe this is likely an issue with markdown paste providers, assigning to take a look at this. to clarify, are you expecting the images to be created on-disk upon paste, and referenced via an image markdown link? Or are you looking for the experience, with images stored in the notebook itself. The latter can be achieved and still works properly with the setting
I prefer the later, where the images are stored in the notebook, this makes it easier to share with others in these scenarios. This used to be working and then stopped working in the build I noted in the original question refenced, but I just tested in the latest build and it is back to working as expected, so must have been a bug that has now been fixed: The version I just tested with is updated now and it is working as expected with the Version: 1.83.1 (system setup) Commit: Date: 2023-10-10T23:48:05.904Z Electron: 25.8.4 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.
Works fine for me too with the default settings. Will disable pasting into untitled notebooks with the setting off
Code change:
) { } public computeSync(anchor: HoverAnchor, lineDecorations: IModelDecoration[]): MarkerHover[] { <del> if (!this._editor.hasModel() || anchor.type !== HoverAnchorType.Range) { </del> <ins> if (!this._editor.hasModel() || anchor.type !== HoverAnchorType.Range && !anchor.supportsMarkerHover) { </ins> return []; }

Related discussion:
text: Hovering inlay hints should show problems "underneath": !
Came here to report the same thing https://user-
This happens because inlay hint have their own hover which are anchored on a . The diagnostics hover explicitly checks for that and . Would be OK to pretend to be a "normal" range hover anchor so that I can get all the hovers together? Or should the diagnostics hover not check for the hover type?
The is used both by inlay hints (via ) and ghost text (directly instantiates it). I think in the case of inlay hints you would want that markers are rendered in the hover, but perhaps ghost text wouldn't want that they appear in the hover, it might want to show only these actions: <img width="598" alt="image" src="https://user-"My suggestion would be to add something to to be able to distinguish the two cases.
Can still repro this
Please update this issue with a real code snippet that allows to reproduce this, please update this issue with what you have tried. Thanks
I just found a reduce function in VS Code sources such as and replace the returned value with the void keyword such as
Something like this only gives a squiggle for the return value, not the arguments or anything with inline hints. To clarify, this will only work for squiggles that spawn across inline hints <img width="699" alt="Screenshot 2023-01-26 at 14 49 07" src="https://user-"
Hmm, maybe it's because it's in a function so the return value becomes incorrect? This in <img width="917" alt="image" src="https://user-"
Thanks for updating
Looks good to me. Version: 1.75.0-insider Commit: !
Code change:
if (toggleData && groups.filter(g => g.extensionInfo).length) { for (const key in toggleData.settingsEditorRecommendedExtensions) { const extension = toggleData.recommendedExtensionsGalleryInfo[key]; <del> const manifest = await this.extensionGalleryService.getManifest(extension, CancellationToken.None); </del> <ins> let manifest: IExtensionManifest | null = null; try { manifest = await this.extensionGalleryService.getManifest(extension, CancellationToken.None); } catch (e) { // Likely a networking issue. // Skip adding a button for this extension to the Settings editor. continue; } </ins> const contributesConfiguration = manifest?.contributes?.configuration; let groupTitle: string | undefined;

Related discussion:
text: Type: <bBug</bVS Code (with or without extensions disabled, makes no difference) File -Preferences -Settings blank UI with no actual settings in it. ! If you leave the settings tab open and restart vs code (such that it reopens the settings tab automatically on restart) the settings GUI will be there, but all the extension settings will be missing (observe that it is missing from the menu here): ! If I then close and reopen settings they will again be empty. VS Code version: Code 1.84.2 (, 2023-11-09T10:50:47.800Z) OS version: Linux x64 6.2.0-36-generic (Ubuntu 22.04 LTS) Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
I also tried with to run this on the nVidia GPU instead of the built in Intel GPU. Makes no difference.
After running the command "Developer: Toggle Developer Tools", do any errors show up under the Console tab?
Yes I got 3 errors, they all seem related to that I'm behind a corporate proxy though. Note that I ran this with , but I still get errors related to extensions. I find this very strange ! ! !
When I'm not behind the proxy, settings work as expected. I find it very odd that VSCode would need to call out to the internet just to open settings. Opening the marketplace for extensions I understand, but not settings. Especially since I can also open settings just fine if I'm completely disconnected. It is just if I'm connected via the corporate network that it falls flat on it's face. For some further debug information: We use Zscaler at my workplace, which acts as a transparent HTTPS MITM proxy (no need/not possible to set any environment variables, but you do need to install the CA certificate). The proper certificate is installed in the system certificate store () and that works as expected with other programs. Also, other internet features in VSCode work fine, such as github copilot. EDIT: I also tried some of the settings in the proxy section of the settings to see if it made any difference. They were all set to the default values before.