jiebi/CodeConvo huggingface dataset:
Change:
} // return inlay hints but with an anchor that reflects "updates" <del> // that happens after receiving them, e.g adding new lines before a hint </del> <ins> // that happened after receiving them, e.g adding new lines before a hint </ins> private _copyInlayHintsWithCurrentAnchor(model: ITextModel): InlayHintItem[] { const items = new Map<InlayHintItem, InlayHintItem>(); for (const [id, obj] of this._decorationsMetadata) {

Discussion:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/
Change:
private static _deserializeRegexValue(serializedValue: string): RegExp | null { if (isFalsyOrWhitespace(serializedValue)) { <del> console.warn('missing regexp-value for =~-expression'); </del> return null; } const start = serializedValue.indexOf('/'); const end = serializedValue.lastIndexOf('/'); <del> if (start === end || start < 0 /* || to < 0 */) { console.warn(`bad regexp-value '${serializedValue}', missing /-enclosure`); </del> <ins> if (start === end || start < 0) { </ins> return null; }

Discussion:
Looks like has some statements. This is fair for local development but shouldn't be shipping in the product.
Change:
} } <del> function getRelativePath(file: vscode.Uri): string | undefined { const dir = getDocumentDir(file); if (dir && dir.scheme === file.scheme && dir.authority === file.authority) { if (file.scheme === Schemes.file) { </del> <ins> function getRelativePath(fromFile: vscode.Uri | undefined, toFile: vscode.Uri): string | undefined { if (fromFile && fromFile.scheme === toFile.scheme && fromFile.authority === toFile.authority) { if (toFile.scheme === Schemes.file) { </ins> // On windows, we must use the native `path.relative` to generate the relative path // so that drive-letters are resolved cast insensitively. However we then want to // convert back to a posix path to insert in to the document <del> const relativePath = path.relative(dir.fsPath, file.fsPath); </del> <ins> const relativePath = path.relative(fromFile.fsPath, toFile.fsPath); </ins> return path.posix.normalize(relativePath.split(path.sep).join(path.posix.sep)); } <del> return path.posix.relative(dir.path, file.path); </del> <ins> return path.posix.relative(fromFile.path, toFile.path); </ins> } return undefined;

Discussion:
a workspace: and drop into Expected Inserts Actual Inserts
Closing as fixed in main and release branch
Change:
handleMouseBackForwardSupport(); } <del> private onMouseDown(event: MouseEvent): void { </del> <ins> private onMouseDownOrUp(event: MouseEvent, isMouseDown: boolean): void { </ins> // Support to navigate in history when mouse buttons 4/5 are pressed <ins> // We want to trigger this on mouse down for a faster experience // but we also need to prevent mouse up from triggering the default // which is to navigate in the browser history. </ins> switch (event.button) { case 3: EventHelper.stop(event); <del> this.goBack(); </del> <ins> if (isMouseDown) { this.goBack(); } </ins> break; case 4: EventHelper.stop(event); <del> this.goForward(); </del> <ins> if (isMouseDown) { this.goForward(); } </ins> break; } }

Discussion:
Use the backward/forward mouse buttons in codespaces. Actual behavior: The cursor jumps back (as if I used Alt+Left/ArrowRight) And: The browser navigates backward/forward, reloading the page Expected behavior: The cursor jumps back The browser does not navigate to the last visited page This looks like prevent default is missing. Intercepting these buttons works here:
Is it maybe this?
We prevent the default, but only in the mouse down listener, where this seems to trigger on mouse up.
<!-- 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!
This works, but consider not preventing default if there are no history entries as it's unexpected for me to not navigate away at that point.
Can you file an issue for that?
Change:
import { TerminalSettingId } from 'vs/platform/terminal/common/terminal'; import { IColorTheme, IThemeService, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; import { ThemeIcon } from 'vs/base/common/themables'; <del> import { TaskSettingId } from 'vs/workbench/contrib/tasks/common/tasks'; </del> import { terminalDecorationError, terminalDecorationIncomplete, terminalDecorationMark, terminalDecorationSuccess } from 'vs/workbench/contrib/terminal/browser/terminalIcons'; import { DecorationSelector, TerminalDecorationHoverManager, updateLayout } from 'vs/workbench/contrib/terminal/browser/xterm/decorationStyles'; import { ITerminalCommand } from 'vs/workbench/contrib/terminal/common/terminal';

Discussion:
I noticed this: We always want to add the sequences as it enabled command navigation, the decorations showing is purely a visual thing that hides the decoration button. So I suggest we remove the ShowDecorations check there and instead call into the terminal addon to disable the decoration.
To verify: repo (or any repo with a task that exits) the default build task to some file the test task it the test task it /ctrl+up should take you to the start of the task in step 6, not the very top of the terminal
I actually think we should remove the setting outright as we already have which essentially does the same thing. This would save us from exposing outside of the terminal part the ability to configure decoration visibility. Timeline: The terminal setting was as a boolean in Feb The task setting was in June The terminal setting was made more granular in July The interaction between the 2 settings confused someone in I'll leave the decision up to you whether we remove it, it feels like too much granularity to me as the user must like the terminal ones but not the task ones.
Let's remove it
Change:
this._sessionCtor = createCancelablePromise<void>(async token => { await this._startSession(token); <ins> assertType(this._model.value); const model = this._model.value; this._widget?.inlineChatWidget.setChatModel(model); </ins> if (fakeParentEditor.hasModel()) { if (this._widget) {

Discussion:
The context key used in terminal and notebook chat which is wrong because it signals that there is a chat participant for the editor location and it doesn't know anything about other locations.
It's now removed from the notebook side.

todays insiders open a notebook use cell generate and submit a prompt nothing happens, the error below appears
Change:
#[cfg(target_os = "windows")] mod service_windows; mod socket_signal; <ins> mod wsl_detect; </ins> <del> pub use control_server::{serve, serve_stream, Next, ServeStreamParams, AuthRequired}; </del> <ins> pub use control_server::{serve, serve_stream, AuthRequired, Next, ServeStreamParams}; </ins> pub use nosleep::SleepInhibitor; pub use service::{ create_service_manager, ServiceContainer, ServiceManager, SERVICE_LOG_FILE_NAME,

Discussion:
This used to work on the same machine however. Not sure when it stopped. Or why.
Please run
that worked! Wonder if the CLI should do it automatically?
BTW I also noticed how it returns exit code 0 (success) even when it failed like that. Perhaps you should avoid just issuing a warning in case some of these operations fails.
Thanks a ton,
Change:
}); registerCompletionsSupport(connection, documents, mdLs, configurationManager); <del> registerDocumentHightlightSupport(connection, documents, mdLs, configurationManager); </del> <ins> registerDocumentHighlightSupport(connection, documents, mdLs, configurationManager); </ins> registerValidateSupport(connection, workspace, documents, mdLs, configurationManager, serverConfig.logger); return {

Discussion:
<!-- 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.73.0 OS Version: macOS 12.1 21C52 x86_64 Recently upgraded to 1.73 and no longer seeing selection highlighting. <img width="1728" alt="Screen Shot 2022-11-09 at 8 44 07 AM" src="https://user-"Default setting still and set on the user level as well to no avail. <img width="1728" alt="Screen Shot 2022-11-09 at 8 41 34 AM" src="https://user-"<img width="803" alt="Screen Shot 2022-11-09 at 8 41 56 AM" src="https://user-"
I am only seeing this in Markdown (including code blocks) but not source code.
The problem seems to be that previously you'd get a match if the cursor was at the start of the word but now only if you select/highlight the entire word (or subset). If this is a change in functionality, any way to update settings to restore previous out-of-box behavior?
I believe this might be caused by markdown now registering a document highlight provider. When a language registers a document highlight provider, the non-semantic based, text editor word highlight takes a back seat. I think you can turn this down via , or maybe . Let me loop in , maybe he has more ideas.
Change:
clearSelection(): void; /** <ins> * When the panel is hidden or a terminal in the editor area becomes inactive, reset the focus context key * to avoid issues like #147180. */ resetFocusContextKey(): void; /** </ins> * Select all text in the terminal. */ selectAll(): void;

Discussion:
https://user- As shown in the recording, when I tried to paste in the editor The terminal paste command is matched, meaning that the terminal is still "focused" based on the context keys The terminal shows a context menu for paste. We are not seeing this in the editor, the terminal should handle in the same way
As long as the terminal is opened once, I have to reload the window to get it fixed.
I think this means that this isn't happening on safari for some reason
This gets hit even when I click in the editor area !
Still reproduced on latest codespace with VS Code insider bits.
Had a call, we believe it's happening because we set when hiding the panel which caused the blur/focusout events to not fire. We also noticed this happens in terminal editors as well. So to fix we need to reset or refresh the state of the context key when the terminal panel/view is hidden as well as when the terminal editor is hidden. Something to verify when these changes are made is to make sure if you have a single terminal editor and a single terminal in the panel, toggling the panel should still keep because the terminal editor will now be focused (ie. the panel hide context key reset should happen before the terminal editor focus is handled).
Change:
import { Action2, MenuId } from 'vs/platform/actions/common/actions'; import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey'; import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; <ins> import { getCommandsContext, resolveCommandsContext } from 'vs/workbench/browser/parts/editor/editorCommands'; import { IEditorCommandsContext } from 'vs/workbench/common/editor'; </ins> import { TextFileEditor } from 'vs/workbench/contrib/files/browser/editors/textFileEditor'; import { MultiDiffEditor } from 'vs/workbench/contrib/multiDiffEditor/browser/multiDiffEditor'; import { MultiDiffEditorInput } from 'vs/workbench/contrib/multiDiffEditor/browser/multiDiffEditorInput'; <ins> import { IEditorGroupsService } from 'vs/workbench/services/editor/common/editorGroupsService'; </ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; export class GoToFileAction extends Action2 {

Discussion:
You should not be assuming that the editor for which the action is being run for is the active editor. Make sure to correctly extract the context from the arguments passed to the script. The run method should be defined the following way: You can get the correct context with and resolve it with Make sure to adopt this for the following MultiDiffActions: - You can test that it works correctly with and 2 editor groups
Change:
}; } <del> private renderMarkdown(markdown: IMarkdownString, element: ChatTreeItem, templateData: IChatListItemTemplate, fillInIncompleteTokens = false): IMarkdownRenderResult { </del> <ins> private renderMarkdown(markdown: IMarkdownString, element: ChatTreeItem, templateData: IChatListItemTemplate, fillInIncompleteTokens = false, codeBlockStartIndex = 0): IChatMarkdownRenderResult { </ins> const disposables = new DisposableStore(); // We release editors in order so that it's more likely that the same editor will be assigned if this element is re-rendered right away, like it often is during progressive rendering const orderedDisposablesList: IDisposable[] = []; const codeblocks: IChatCodeBlockInfo[] = []; <del> let codeBlockIndex = 0; </del> <ins> let codeBlockIndex = codeBlockStartIndex; </ins> const result = this.renderer.render(markdown, { fillInIncompleteTokens, codeBlockRendererSync: (languageId, text) => {

Discussion:
Steps to Reproduce: multiple markdown strings with code blocks interleaved with commands/warnings. (see sample chat extension ) progressive streaming of chat content. The markdown code blocks at the beginning of the stream are replaced with the last streamed code block content. See below gif: !
Change:
order: 1.45 }, { id: MenuId.MenubarGoMenu, <ins> precondition: null, </ins> group: '4_symbol_nav', order: 4, }]

Discussion:
Type: <bBug</b- VS Code Version: 1.74.1 OS Version: Windows NT x64 10.0. Issue appeared just after upgrading VSCode to ver. 1.74.1 Currently, it is impossible to go to the function definition by clicking Ctrl+Click on the function name or using the F12 button. Also, the Go to definition option in Top Menu-Go-Go to Definition is disabled. VS Code version: Code 1.74.1 (, 2022-12-14T10:30:51.966Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
What code language? Is the option also disabled in the context menu? was a previous issue about this and related options not getting enabled in the top-level Go menu. Maybe this has come back. Do you think this didn't happen in 1.74.0?
- maybe caused by
Yeah, looks like the precondition for the command is too strong
Javascript I don't have such an option in the context menu I'm not 100% sure, which version I had previously installed, but I'm using VSCode almost every day, so I'm pretty sure I was using 1.74.0 or 1.73.1, and that behavior has occurred after auto-upgrade to 1.74.1. I've never noticed anything like it before.
After a clean uninstall (Uninstalled and deleted %APPDATA%Code and %USERPROFILE%.vscode), and installing 1.74.1 again, the problem does not occur anymore.
Change:
const checkAll = <HTMLInputElement>dom.append(headerContainer, $('input.quick-input-check-all')); checkAll.type = 'checkbox'; <ins> checkAll.setAttribute('aria-label', localize('quickInput.checkAll', "Toggle all checkboxes")); </ins> this._register(dom.addStandardDisposableListener(checkAll, dom.EventType.CHANGE, e => { const checked = checkAll.checked; list.setAllVisibleChecked(checked);

Discussion:
<!-- 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. --<!-- 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.67.1 Operating System: Windows 11 Screen Reader: NVDA Extensions Installed: Put together an extension to quickly demo the bare VS Code UI features without our normal SDK and extension wrappers. "a11y-kit" () Repro Steps: a11y-kit from VS Code Marketplace command palette and run a11y-kit's menu command , select: "Show Quick Picks - Many" and observe. Expected: There should be a way for the screen reader to inform the user that the checkbox to the left of the main input field is used to select all quick pick items. I suppose the screen reader callout might read to the user something like... "select all items checkbox, unchecked" Actual: When entering the quick pick selection screen, all the quick pick items are listed as check-able items as you select over them; however, the select all checkbox next to the main input box has no such similar screen reader callout. When highlighting directly using keyboard, it states that it is a checkbox but does not describe its specific function in the context of the section. Attachments: ! Thank you!
Change:
import { Disposable, IDisposable, toDisposable } from 'vs/base/common/lifecycle'; import { ILayoutService } from 'vs/platform/layout/browser/layoutService'; import { IContextViewDelegate, IContextViewService } from './contextView'; <ins> import { getWindow } from 'vs/base/browser/dom'; </ins> export class ContextViewService extends Disposable implements IContextViewService {

Discussion:
!
If this is in an aux window, then I don't think there's access to GitLens? Verified that I couldn't repro in a normal window.
Change:
appendPlaceholder(value: string | ((snippet: SnippetString) => any), number?: number): SnippetString; /** <del> * Builder-function that appends a choice (`${1|a,b,c}`) to </del> <ins> * Builder-function that appends a choice (`${1|a,b,c|}`) to </ins> * the [`value`](#SnippetString.value) of this snippet string. * * @param values The values for choices - the array of strings

Discussion:
There's a typo on line 3239 of . Should be (extra pipe character):
Change:
icon: Codicon.newFile, content: { type: 'startEntry', <del> command: 'explorer.newFile', </del> <ins> command: 'workbench.action.files.newUntitledFile', </ins> } }, {

Discussion:
Clicking on "New File" from getting started when in a workspace opens the explorer and places a new file where your selection is: ! This works the opposite way our current welcome page does where it will always create an untitled file: ! I think we should keep these actions consistent and not change the behavior.
Change:
padding-bottom: 2em; display: flex; flex-direction: column; <del> height: 100%; </del> <ins> min-height: 100%; overflow: visible; </ins> } .description-section {

Discussion:
!
is this in OSS or in insiders?
This was oss
yep, this is a known issue in OSS with the css bundling. it ends up fine in Insiders and stable, but unsure why this has been the case for a while now. same as i believe
They still happen in insiders, just the button width isn't the same for some reason (you could inspect the element in devtools to diff the styles): !
Change:
declare readonly _serviceBrand: undefined; public readonly pid = process.pid; exit(code: number) { nativeExit(code); } <del> exists(path: string) { return Promises.exists(path); } realpath(path: string) { return realpath(path); } </del> <ins> fsExists(path: string) { return Promises.exists(path); } fsRealpath(path: string) { return realpath(path); } </ins> }; // Attempt to load uri transformer

Discussion:
Steps to repro: (prereq) make sure Python is installed in or (also repros with stable , does not repo in Desktop) open or wait a bit see that Python gets activated even though this repo has nothing python-y in it (just XML files) ! informed me of which gave me a very curious output: What’s interesting about this is that this repo has no , no , no … so this takes me to the original question. Why is this causing activation? After chatting a bit, pointed out: as suspicious.
I think these host methods are not implemented correctly and they might be the root cause:
Yeah, the function isn't really implemented. Tho, I could change the default to to but the bigger challenge is that the interface assumes local file access - it talks about paths, not uris and therefore this will be hard to implement. And by extension I also think this is buggy for the node EH with workspace not hosted on local disk
NVM - I found the magic and will use that for web EH
Change:
this._register(editContextAddDisposableListener(this._editContext, 'textupdate', (e) => { const compositionRangeWithinEditor = this._compositionRangeWithinEditor; if (compositionRangeWithinEditor) { <del> const position = this._context.viewModel.getPrimaryCursorState().viewState.position; </del> <ins> const position = this._context.viewModel.getPrimaryCursorState().modelState.position; </ins> const newCompositionRangeWithinEditor = Range.fromPositions(compositionRangeWithinEditor.getStartPosition(), position); this._compositionRangeWithinEditor = newCompositionRangeWithinEditor; }

Discussion:
Enable the setting which enabled the native edit context adoption (make sure to reload the editor) Toggle word wrap on Resize the editor, so one of the lines is wrapped Type on that line Part of the line is deleted/incorrectly edited
Looks like this could be an issue with the coordinate system chosen too.
Change:
this.actionRunner, this.options.getKeyBinding, toolBarMoreIcon.classNames, <del> this.options.anchorAlignmentProvider </del> <ins> this.options.anchorAlignmentProvider, true </ins> ); this.toggleMenuActionViewItem.value.setActionContext(this.actionBar.context);

Discussion:
!
Reproduces in an insiders build from 3 days ago. Maybe related to context view changes?
closedWith