jiebi/CodeConvo huggingface dataset:
Change:
const textStartLineOffsetWithinEditor = this._textStartPositionWithinEditor.lineNumber - 1; const characterStartPosition = new Position(textStartLineOffsetWithinEditor + editContextStartPosition.lineNumber, editContextStartPosition.column); const characterEndPosition = characterStartPosition.delta(0, 1); <del> const characterRange = Range.fromPositions(characterStartPosition, characterEndPosition); const characterLinesVisibleRanges = this._visibleRangeProvider.linesVisibleRangesForRange(characterRange, true) ?? []; const characterVerticalOffset = this._context.viewLayout.getVerticalOffsetForLineNumber(characterRange.startLineNumber); </del> <ins> const characterModelRange = Range.fromPositions(characterStartPosition, characterEndPosition); const characterViewRange = this._context.viewModel.coordinatesConverter.convertModelRangeToViewRange(characterModelRange); const characterLinesVisibleRanges = this._visibleRangeProvider.linesVisibleRangesForRange(characterViewRange, true) ?? []; const characterVerticalOffset = this._context.viewLayout.getVerticalOffsetForLineNumber(characterViewRange.startLineNumber); </ins> const editorScrollTop = this._context.viewLayout.getCurrentScrollTop(); const top = parentBounds.top + characterVerticalOffset - editorScrollTop;

Discussion:
Version: 1.94.0-insider Commit: Date: 2024-09-23T05:12:01.964Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. ! With , it is worse. !
Hi yes thanks a lot for opening this valuable issue. This is happening because we use the model ranges instead of the view ranges in the control bounds, selection bounds and character bounds positioning. The following PR fixes this:
I try the OSS version from the repository. The issue with is fixed. However, I still see the issue with Version: 1.94.0 Commit: Date: Unknown Electron: 30.5.1 ElectronBuildId: undefined Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. !
Oh I see thanks for letting me know that is curious. I will reopen the issue and have a look.
After investigating the issue, I believe this happens because I didn't remove the editor scroll left position from the bounds set for the selection and character bounds. The following PR should fix this.
Change:
<ins> { "comments": { "lineComment": "//", "blockComment": ["/*", "*/"] }, "brackets": [ ["{", "}"], ["[", "]"], ["(", ")"] ] } </ins>  No newline at end of file

Discussion:
Testing !
The binary is indeed available in the server folder but the libc library it is linked with does not exist on the image.
Ripgrep should also build for rust target in to support alpine images so that it is uses the musl c library.
I can add that, thanks
Ripgrep couldn't build under that target. My understanding is… when building with musl, it uses jemalloc, jemalloc uses backgroundthreadsruntime_support, and that doesn’t support our target. If we can figure out how to un set that flag on jemalloc that might work around it but i don’t know what consequences that would have
from it is not sure whether the bug is in jemalloc config or cargo, but the immediate working solution is to build the crate with I will see if that works.
May I know if there is some workaround for this bug for users? If not, I do not think its good to ship Alpine ARM 64 builds with broken experience.
It will require users to install package that will include the required libraries for the executable built using glibc.
Not with your PR, right And thanks for the PR!
Yup is not needed with the musl binary produced from the PR.
I didn't put up a PR to adjust to download for alpine. Can you take care of it ? Thanks!

When using the block comment feature, only 2 single quotes are put in, instead of three.
Python block comments are triple quotes, not double. Check if that works.
It does! Thanks the bug is then that only 2 quotes are put in.
Fixed, see , reviewed by Alex

Type if ( expected =closing ) actual =nothing
Fixed by me, reviewed by Alex, see ,
Change:
this._updateSummaryMessage(); if (this._diffEnabled) { <del> this._diffZone.show(); </del> <ins> this._diffZone.value.show(); </ins> } if (response.singleCreateFileEdit) { <del> this._previewZone.showCreation(this._session.wholeRange.value, response.singleCreateFileEdit.uri, await Promise.all(response.singleCreateFileEdit.edits)); </del> <ins> this._previewZone.value.showCreation(this._session.wholeRange.value, response.singleCreateFileEdit.uri, await Promise.all(response.singleCreateFileEdit.edits)); </ins> } else { <del> this._previewZone.hide(); </del> <ins> this._previewZone.value.hide(); </ins> } } override async undoChanges(response: EditResponse): Promise<void> { <del> this._diffZone.lockToDiff(); </del> <ins> this._diffZone.value.lockToDiff(); </ins> super.undoChanges(response); } protected override _doToggleDiff(): void { const scrollState = StableEditorScrollState.capture(this._editor); if (this._diffEnabled) { <del> this._diffZone.show(); </del> <ins> this._diffZone.value.show(); </ins> } else { <del> this._diffZone.hide(); </del> <ins> this._diffZone.value.hide(); </ins> } scrollState.restore(this._editor); } override hasFocus(): boolean { <del> return super.hasFocus() || this._diffZone.hasFocus() || this._previewZone.hasFocus(); </del> <ins> return super.hasFocus() || this._diffZone.value.hasFocus() || this._previewZone.value.hasFocus(); </ins> } }

Discussion:
Steps to Reproduce: Copilot Chat the file in VS Code +i It takes like 2s for the UI to show up. One time when I was doing a lot with VS Code it took so long (like 10s) that I thought I didn't have the extension installed. Not sure if this is on the UI side or the extension side, but even still, I think the UI should be instant (even if it's perceived fastness) since all I'm seeing is an input box that I will type in.
I have done a bunch of tricks, most importantly to showing the UI while asking the extension to create a session. Also the UI is more lazily created which helps. However, once there are changes the bottleneck is setting up the embedded diff editor. There isn't much I can do about it <img width="726" alt="Screenshot 2023-06-15 at 16 10 35" src=""
Change:
"scope": "resource", "default": false, "description": "%config.supportCancellation%" <ins> }, "git.sortOrderForBranch": { "type": "string", "enum": [ "committerdate", "alphabetically" ], "default": "committerdate", "description": "%config.sortOrderForBranch%" </ins> } } },

Discussion:
I agree that sometimes it is more useful to but I often feel that it makes it hard to find branches when a naming scheme like "user/feature" is used and I want to quickly find all branches of a user. Even without that scheme there are good reasons why having an alphabetical sort option makes sense, if only for personal preference. To avoid a religious discussion, could the sort order be made into a config option?
, working on this :)
Change:
}); }; <del> function getElementsToOperateOnInfo(viewer: WorkbenchObjectTree<RenderableMatch, void>, currElement: RenderableMatch, sortConfig: ISearchConfigurationProperties): RenderableMatch[] { </del> <ins> function getElementsToOperateOnInfo(viewer: WorkbenchObjectTree<RenderableMatch, void>, currElement: RenderableMatch, sortConfig: ISearchConfigurationProperties): { elements: RenderableMatch[]; mustReselect: boolean } { </ins> let elements: RenderableMatch[] = viewer.getSelection().filter((x): x is RenderableMatch => x !== null).sort((a, b) => searchComparer(a, b, sortConfig.sortOrder)); <ins> const mustReselect = elements.includes(currElement); // this indicates whether we need to re-focus/re-select on a remove. </ins> // if selection doesn't include multiple elements, just return current focus element. if (!(elements.length > 1 && elements.includes(currElement))) { elements = [currElement]; } <del> return elements; </del> <ins> return { elements, mustReselect }; </ins> }

Discussion:
The focus on a search result shouldn't change when removing an element that isn't affected by the removal. ]() Should be like this: ! Likely due to changes in
Change:
/** A context key that is set to the detected shell for the most recently active terminal, this is set to the last known value when no terminals exist. */ export const KEYBINDING_CONTEXT_TERMINAL_SHELL_TYPE = new RawContextKey<string>(KEYBINDING_CONTEXT_TERMINAL_SHELL_TYPE_KEY, undefined, { type: 'string', description: nls.localize('terminalShellTypeContextKey', "The shell type of the active terminal") }); <ins> export const KEYBINDING_CONTEXT_IPAD_KEY = 'isIPad'; export const KEYBINDING_CONTEXT_IPAD = new RawContextKey(KEYBINDING_CONTEXT_IPAD_KEY, false, nls.localize(KEYBINDING_CONTEXT_IPAD_KEY, 'Whether the device is an ipad')); </ins> export const KEYBINDING_CONTEXT_TERMINAL_ALT_BUFFER_ACTIVE = new RawContextKey<boolean>('terminalAltBufferActive', false, true); /** A context key that is set when the integrated terminal does not have focus. */

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- 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: --Hitting + with the terminal focused and a process running (i.e. in a React app) does not kill the process. If someone is able to provide a good starting point, I would be willing to take a stab at this. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.53.0-insider OS Version: iPadOS 14.1 (18A8395) Commit: Date: 2021-01-07T05:25:51.740Z (16 hrs ago) Browser: Mozilla/5.0 (iPad; CPU OS 14_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/87.0.4280.77 Mobile/15E148 Safari/604.1 iPad, open Codespaces environment in Chrome integrated Terminal application (i.e. like a create-react-app - ) terminal and hit + Process () should stop running Terminal receives new line https://user- <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Related:
Perhaps that is not the right sigint.
One other piece of insight: this may not be limited to VSCode. has a product which includes a terminal in the browser. I’m able to reproduce the same issue (see line breaks at the bottom). !
As a temporary workaround, it works if you manually define the shortcut like so: Command Palette for "Preferences: Open Keyboard Shortcuts (JSON)" this: Source:
I found the root reason was iPad Safari report keyCode of ctrl-c as 13, which is not correct, reference from MDN, keyCode is a deprecated property; The key and code property is right, so I suggest just use key property, not keyCode, on the whole html page not just terminal.
I'm still seeing this in codespace, am I testing the right environment?
fixed w
as another workaround, use shortcut instead of , it will interrupt the process as well
Change:
exports.setOptions = setOptions; exports.use = use; exports.walkTokens = walkTokens; })); <ins> // ESM-uncomment-begin // })(); // export var Hooks = (__marked_exports.Hooks || exports.Hooks); // export var Lexer = (__marked_exports.Lexer || exports.Lexer); // export var Marked = (__marked_exports.Marked || exports.Marked); // export var Parser = (__marked_exports.Parser || exports.Parser); // export var Renderer = (__marked_exports.Renderer || exports.Renderer); // export var TextRenderer = (__marked_exports.TextRenderer || exports.TextRenderer); // export var Tokenizer = (__marked_exports.Tokenizer || exports.Tokenizer); // export var defaults = (__marked_exports.defaults || exports.defaults); // export var getDefaults = (__marked_exports.getDefaults || exports.getDefaults); // export var lexer = (__marked_exports.lexer || exports.lexer); // export var marked = (__marked_exports.marked || exports.marked); // export var options = (__marked_exports.options || exports.options); // export var parse = (__marked_exports.parse || exports.parse); // export var parseInline = (__marked_exports.parseInline || exports.parseInline); // export var parser = (__marked_exports.parser || exports.parser); // export var setOptions = (__marked_exports.setOptions || exports.setOptions); // export var use = (__marked_exports.use || exports.use); // export var walkTokens = (__marked_exports.walkTokens || exports.walkTokens); // ESM-uncomment-end </ins> //# sourceMappingURL=marked.umd.js.map

Discussion:
We lost changes that where ESM relevant. I am trying to fix it in our ESM branch, maybe backport it from there: The old code also had this line, which I am not sure is needed: cc
Sorry about that. Is this for Monaco or the esm work? I'd love to get a point where we can just have this as a normal dependency instead of copying it into our sources. Marked now publishes both a commonjs and esm builds too. Is there some way VS Code could use Marked as a normal dependency in a way that would also work for Monaco? If I recall we've tried to avoid adding real dependencies to Monaco
I only noticed for our work, not sure about Monaco ESM. Would be great to get it working again on .
I think the ESM work will unblock this. esbuild will be able to bring in and include node modules into our bundle, the AMD bundler we currently use can only bundle AMD modules and not commonjs modules.
I would have hoped that the Monaco Editor checks would have caught this. Is there something we should improve there?
For monaco-editor-core, these are the only tests: It does not test markdown features.
Change:
export const CONTEXT_DISASSEMBLE_REQUEST_SUPPORTED = new RawContextKey<boolean>('disassembleRequestSupported', false, { type: 'boolean', description: nls.localize('disassembleRequestSupported', "True when the focused sessions supports disassemble request.") }); export const CONTEXT_DISASSEMBLY_VIEW_FOCUS = new RawContextKey<boolean>('disassemblyViewFocus', false, { type: 'boolean', description: nls.localize('disassemblyViewFocus', "True when the Disassembly View is focused.") }); export const CONTEXT_LANGUAGE_SUPPORTS_DISASSEMBLE_REQUEST = new RawContextKey<boolean>('languageSupportsDisassembleRequest', false, { type: 'boolean', description: nls.localize('languageSupportsDisassembleRequest', "True when the language in the current editor supports disassemble request.") }); <ins> export const CONTEXT_FOCUSED_STACK_FRAME_HAS_INSTRUCTION_POINTER_REFERENCE = new RawContextKey<boolean>('focusedStackFrameHasInstructionReference', false, { type: 'boolean', description: nls.localize('focusedStackFrameHasInstructionReference', "True when the focused stack frame has instruction pointer reference.") }); </ins> export const EDITOR_CONTRIBUTION_ID = 'editor.contrib.debug'; export const BREAKPOINT_EDITOR_CONTRIBUTION_ID = 'editor.contrib.breakpoint';

Discussion:
Testing As already pointed out The "Open Disassembly View" command is now only visible when the active stackframe has a instructionPointerReference property. This makes it hard to discover. I suggest to have the context menu's "Open Disassembly View" command always visible if a debug adapter has the supportsDisassembleRequest capability. But the command should only be enabled if the active stackframe has a instructionPointerReference property. That results in a more stable user experience. Apart from that we should have the Open Disassembly View command in the command palette.
That's a fair suggestion. However, we are not sure how to disable a command...
commands have clauses and . clause determines if the command is present at all and if it is disabled. So please use the when registering the editor command for disablement.
Also we should consider to introduce a call stack context menu action for the Open Disassembly View.
will fix this.
Change:
} } <del> if (uri.fragment) { </del> <ins> const extname = path.extname(uri.fsPath); if (uri.fragment && (extname === '' || MarkdownFileExtensions.includes(extname))) { </ins> uri = uri.with({ fragment: this.slugifier.fromHeading(uri.fragment).value });

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- 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. --Version: 1.43.2 (system setup) Commit: Date: 2020-03-24T07:38:38.248Z Electron: 7.1.11 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: in extension's function gives ... '=' character was dropped ! in extension's function gives ... '=' character was not dropped ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Hmm ... extension is needed in this case.
As far as I understand, all links in a markdown file are processed with a "normalizer". As part of the normalization, all uri fragments are "slugified": With a default "slugifier", it means, among other things, removing all punctuation: am I correct in thinking that the "slugification" is needed for links to headings in the current document to work ()? If so, a possible fix is to slugify only those uris that do not have authority and path parts.
Yes I don't think the slugifier should be run if the link points to a location that is clearly not a markdown file (such as the path ending in ). It is however helpful to normalize links to other markdown files within your current workspace. As as scoped fix, we could check . If there is a file extension, don't normalize the fragment. Does that sound good? Would you like to submit a PR that does this?
As far as I understand, that may break links to sections of other markdown files that do have an extension (), but I don't see a good fix for that, other than hard-coding all possible markdown file extensions.
Would it be a valid feature request to have an API to guess language id based only on a resource uri?
Change:
new Action(LightUpdateContribution.openSettingsId, nls.localize('settings', "Settings"), null, true, () => this.commandService.executeCommand(LightUpdateContribution.openSettingsId)), new Action(LightUpdateContribution.openKeybindingsId, nls.localize('keyboardShortcuts', "Keyboard Shortcuts"), null, true, () => this.commandService.executeCommand(LightUpdateContribution.openKeybindingsId)), new Separator(), <ins> new Action(LightUpdateContribution.selectColorThemeId, nls.localize('selectTheme.label', "Color Theme"), null, true, () => this.commandService.executeCommand(LightUpdateContribution.selectColorThemeId)), new Action(LightUpdateContribution.selectIconThemeId, nls.localize('themes.selectIconTheme.label', "File Icon Theme"), null, true, () => this.commandService.executeCommand(LightUpdateContribution.selectIconThemeId)), new Separator(), </ins> this.getUpdateAction() ]; }

Discussion:
Suggest to add the and to the gear menu. !
Would love to see that. Can I provide an pr?
always
Change:
const provider = DocumentRangeFormattingEditProviderRegistry.ordered(model); const pick = await instaService.invokeFunction(showFormatterPick, model, provider); <del> if (pick) { </del> <ins> if (typeof pick === 'number') { </ins> await instaService.invokeFunction(formatDocumentRangeWithProvider, provider[pick], editor, range, CancellationToken.None); }

Discussion:
install open a json document open the context menu, and pick the first entry in the list. Nothing happens.
this is 0 being falsy...
JFR: setting first formatter as default and running "Format Document" works as a workaround.
fix for next insiders and for 1.33.1
wt., 9 kwi 2019, 17:57 użytkownik Johannes Rieken <notifications
verified in Version: 1.34.0-insider Commit:
Change:
// wait for the editor to be created if the cell is in editing mode cell.getEditState() === CellEditState.Editing // wait for the editor to be created if we are revealing the first line of the cell <del> || revealType === CellRevealType.FirstLineIfOutsideViewport </del> <ins> || (revealType === CellRevealType.FirstLineIfOutsideViewport && cell.cellKind === CellKind.Code) </ins> ) && !cell.editorAttached) { return getEditorAttachedPromise(cell); }

Discussion:
a notebook with a code cell and a markdown cell right after it shift+enter on the code cell to run it :bug: focus moves to the markdown cell, but the code cell does not run not a recent regression
I was wrong, this is a regression, just for caused by cc
we wait for the editor to attach for that setting, but a markdown cell in preview might never trigger that event
Change:
/* Action bar */ .action-widget .action-widget-action-bar { <del> margin-top: 4px; </del> background-color: var(--vscode-editorHoverWidget-statusBarBackground); border-top: 1px solid var(--vscode-editorHoverWidget-border); }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --Helo! I use the code spell checker extension which provides quick fixes for spelling "error"s. Often these are just terms that I've adopted as standard in the repo and don't aim to change. However, with the recent change to use custom context menus instead of the native ones the list of spelling quick fixes causes the refactorings I actually want to use to be out of the window, with no way to scroll them into view. With spell checker extension enabled: <img width="590" alt="image" src="https://user-"Without: <img width="610" alt="image" src="https://user-"Ideally the menu would support scroll. I'd accept an option to use native menus instead (the icons are nice to have but not critical). Alternatively, at minimum perhaps the refactorings could be sorted above quick fixes?
We should also limit the height of the menu. Not very pleasant to have it take up the entire height of the window
Works great, thanks!
Change:
return this._remoteTerminalChannel?.getWslPath(original) || original; } <del> setTerminalLayoutInfo(layout: ITerminalsLayoutInfoById): Promise<void> { </del> <ins> async setTerminalLayoutInfo(layout?: ITerminalsLayoutInfoById): Promise<void> { </ins> if (!this._remoteTerminalChannel) { throw new Error(`Cannot call setActiveInstanceId when there is no remote`); }

Discussion:
Also repro's in stable
unsure when this started happening. I don't see any open issues about it, which makes me think this is expected in WSL?
was last working in stable 1.59
and because it was broken in stable 1.60, we can narrow it down - the breaking change happened in August
looks like perhaps a race condition - get layout info is called w the correct workpsaceId, but then set layout info is called so might be wiping out the stored info before the reconnect can occur.
I open a terminal in a Remote-SSH window, reload the window, it is not reconnected
still doesn't work for WSL. based on my investigation, the pty service gets re-created when the window is reloaded, thus losing the and maps
when connected to localhost via ssh, reloading does persist the terminals but I thought this would still be using the ... !
Yep !
Also working for me in codespaces https://user-
It does work in WSL. interestingly, other state isn't persisted that should be though (see the layout change) !
this works on all remote platforms based on my testing. i saw a few times reloading WSL didn't work, but now cannot reproduce
Oh cool, I thought the situation was much worse. I'll reopen to verify on my side since we definitely want to make sure this is working everywhere
All seems to work
verified