jiebi/CodeConvo huggingface dataset:
Change:
return document.hasFocus(); } <ins> async hadLastFocus(): Promise<boolean> { const activeWindowId = await this.electronService.getActiveWindowId(); if (typeof activeWindowId === 'undefined') { return false; } return activeWindowId === this.electronEnvironmentService.windowId; } </ins> openWindow(options?: IOpenEmptyWindowOptions): Promise<void>; openWindow(toOpen: IWindowOpenable[], options?: IOpenWindowOptions): Promise<void>; openWindow(arg1?: IOpenEmptyWindowOptions | IWindowOpenable[], arg2?: IOpenWindowOptions): Promise<void> {

Discussion:
I would like to see the release notes when there's an update, because there are always useful additions that I want to know about, but currently VS Code: re-opens release notes that I have already read, release notes in EVERY SINGLE WINDOW. ! These have been happening for years. Please fix them before I jump off a bridge! There should never be any reason to automatically open them more than ONE time. Perhaps consider using the OS notification system to send ONE notification. If you can't do that, please open ONE window with the release notes, instead of one tab in every window.
/needsMoreInfo does this reproduce if you run with all extensions disabled?
Since some of the conditions to reproduce it (a new release) are outside of my control, and outside of my knowledge until I see the release notes, that's very hard to answer. Are you trying to tell me that you do not have the release notes appear in every single window when you reopen Visual Studio Code and there's a new release? And that you never have them appear again after you've already read them? Since I've seen this happen SO many times, I guessed it happened quite widely.
This seems to be triggered from update, moving to Joao.
Yes there is a known issue: when opening release notes, every window opens them. It's pretty dramatic in your case since you seem to have ~20 windows open. But release notes should not appear twice, unless there's been a recovery update. There was one yesterday: 1.42.1... so that might explain it?
I could swear this issue had been fixed in the past... and I was right. Original issue is and fix was This got broken by
Muito obrigado João!
De nada! Make sure you let us know when stuff annoys you. Sometimes it seems obvious that an issue would annoy everyone but sometimes it just doesn't. :+1:
is there a good way to verify this? If not, I have already verified by code review.
Code review should be
Change:
clientHost.reloadProjects(); })); <ins> context.subscriptions.push(commands.registerCommand('typescript.tryAcceptSelectedSuggestionOnDot', () => { // When typing a dot, make sure the character before the dot is a valid indentifier character. const editor = window.activeTextEditor; if (editor && editor.selection && editor.selection.start.character >= 1) { const preText = editor.document.getText(new Range(new Position(editor.selection.start.line, 0), new Position(editor.selection.start.line, editor.selection.start.character - 1))); if (preText.match(/[a-z_$]s*$/ig)) { return commands.executeCommand('acceptSelectedSuggestion'); } } return commands.executeCommand('type', { text: '.' }); })); </ins> window.onDidChangeActiveTextEditor(VersionStatus.showHideStatus, null, context.subscriptions); client.onReady().then(() => { context.subscriptions.push(ProjectStatus.create(client,

Discussion:
VSCode Version: Code 1.8.1 (, 2016-12-19T14:49:23.350Z) OS Version: Windows_NT ia32 10.0. Extensions: Steps to Reproduce: from npm with typings to import a relative path downwards( import Person from '../person' for instance ). The import will suggest "" as it includes a '.' character or something.
in general please include snippets and screenshots that illustrate the problem and provide precise steps with snippets, screenshots that illustrates a problem (see our ).
Sorry, i provided a video now, it includes full editor and you can see the structure there. The is standard, so is with saved and Steps to reproduce is: init install --init in a folder, () containing a class: in a subfolder () to import a relative path to File1. When you're going to type a relative step back (../), it will autocorrect to "" instead of ".." as shown in the video. If anything more is needed, please let me know. hope this make things a bit clearer
thanks for the additional info.
Short update, it does not seem to happen when running js. i thought it might due to the automatic type acquisition, but it works as intended, for me at least.
me too
this looks like an issue we've seen before...
Fix reverted ,
Picked up improved fix with
Change:
this._overflowGuardContainer.setWidth(layoutInfo.width); this._overflowGuardContainer.setHeight(layoutInfo.height); <del> this._linesContent.setWidth(1000000); this._linesContent.setHeight(1000000); </del> <ins> // https://stackoverflow.com/questions/38905916/content-in-google-chrome-larger-than-16777216-px-not-being-rendered this._linesContent.setWidth(16777216); this._linesContent.setHeight(16777216); </ins> } private _getEditorClassName() {

Discussion:
Testing Version: 1.73.0-insider Commit: Date: 2022-10-25T05:18:20.717Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes 1) open a text file with a super long line, in my case 12K characters 2) toggle word wrap 3) scroll to the end -blue button (great!) 4) press the button Observed issues: 1) toggling line wrap or closing and reopening the editor does not bring back the blue button (I would have expected so) 2) <kbdcmd</kbd+<kbdArrowRight</kbddoes not bring me to the end of the line but only half-way 3) scrolling to the end of line and mouse clicking puts the cursor in the same position as 2) 4) scrolling to the end of line does not show me the end of the line but is around 15 characters short Recording of issues: Proposal: Rather than trying to deal with these long lines, use the button to enable line wrapping so that I can confidently deal with these long lines.
I see how it's broken in your screen recording, but I'm having a hard time reproducing. Could you please share your test file? I tried with (87K chars) and could not reproduce: https://user-
Well, it looks like we all think alike.. :). I concatenated two long lines and ran into a situation where Chromium cuts off rendering after 1MM pixels. I thought only IE had such a limit and this might be a new Chromium limitation. But in any case, it would be interesting to get your file to check if you were running into the same thing or not: <img width="739" alt="Screenshot 2022-10-26 at 16 36 27" src="https://user-"
This is the file I used, zipped up:
with the exception of me attempting to test on 1.8 million characters, , the button, reloading, etc, works like a charm. !

note that in large cases that the initial 12k from Kai, (I tested up to some 53k), doesn't go to end of the line, but goes to the button. pressing the button, then will then go to end of the line.
Change:
} }); <del> const registerOpenUserSettingsEditorFromJsonActionDisposables = this._register(new MutableDisposable()); const openUserSettingsEditorWhen = ContextKeyExpr.and( ContextKeyExpr.or(ResourceContextKey.Resource.isEqualTo(this.userDataProfileService.currentProfile.settingsResource.toString()), ResourceContextKey.Resource.isEqualTo(this.userDataProfilesService.defaultProfile.settingsResource.toString())), ContextKeyExpr.not('isInDiffEditor')); const registerOpenUserSettingsEditorFromJsonAction = () => { registerOpenUserSettingsEditorFromJsonActionDisposables.value = registerAction2(class extends Action2 { constructor() { super({ id: '_workbench.openUserSettingsEditor', title: OPEN_USER_SETTINGS_UI_TITLE, icon: preferencesOpenSettingsIcon, menu: [{ id: MenuId.EditorTitle, when: openUserSettingsEditorWhen, group: 'navigation', order: 1 }] }); } run(accessor: ServicesAccessor, args: IOpenSettingsActionOptions) { args = sanitizeOpenSettingsArgs(args); return accessor.get(IPreferencesService).openUserSettings({ jsonEditor: false, ...args }); } }); }; const openSettingsJsonWhen = ContextKeyExpr.and(CONTEXT_SETTINGS_EDITOR, CONTEXT_SETTINGS_JSON_EDITOR.toNegated()); registerAction2(class extends Action2 { constructor() { super({ id: SETTINGS_EDITOR_COMMAND_SWITCH_TO_JSON, title: { value: nls.localize('openSettingsJson', "Open Settings (JSON)"), original: 'Open Settings (JSON)' }, icon: preferencesOpenSettingsIcon, menu: [{ id: MenuId.EditorTitle, when: openSettingsJsonWhen, group: 'navigation', order: 1 }] }); } run(accessor: ServicesAccessor) { const editorPane = accessor.get(IEditorService).activeEditorPane; if (editorPane instanceof SettingsEditor2) { return editorPane.switchToSettingsFile(); } return null; } }); registerOpenUserSettingsEditorFromJsonAction(); this._register(this.userDataProfileService.onDidChangeCurrentProfile(() => { // Force the action to check the context again. registerOpenUserSettingsEditorFromJsonAction(); })); </del> registerAction2(class extends Action2 { constructor() { super({

Discussion:
Ref contributes a lot of actions. Some actions can likely be contributed after others. This issue tracks splitting up that contribution into a few smaller ones, so that some of the contributions can be set to run at a later phase.
Change:
"notifications.background": "#1f1f1f", "notifications.border": "#ffffff15", "notifications.foreground": "#ffffffc5", <del> "panel.background": "#1f1f1f", </del> <ins> "panel.background": "#181818", </ins> "panel.border": "#ffffff15", "panelInput.border": "#ffffff15", "panelTitle.activeBorder": "#2488d8",

Discussion:
Proposal: ! Reasoning: Easier to differentiate editor and terminal/output/etc The "workbench" uses a single color consistently throughout
Change:
const toDispose: DisposableStore = new DisposableStore(); <del> const onMouseLeave = (e: MouseEvent) => hideHover(false, (<any>e).fromElement === htmlElement); toDispose.add(dom.addDisposableListener(htmlElement, dom.EventType.MOUSE_LEAVE, onMouseLeave, true)); const onMouseDown = () => hideHover(true, true); toDispose.add(dom.addDisposableListener(htmlElement, dom.EventType.MOUSE_DOWN, onMouseDown, true)); </del> const target: IHoverDelegateTarget = { targetElements: [htmlElement], dispose: () => { }

Discussion:
! It's those 3 options that don't work, until there are multiple shells running. Once you have two or more shells, those options start working, as below I'm showing me renaming successfully the 2nd shell: ! Originally posted by in
I think related to this
PR fixing it
moving the issue with to this issue as it's not a recent regression
Change:
this.raw.clearTextureAtlas(); } <ins> clearDecorations(): void { this._decorationAddon?.clearDecorations(true); } </ins> forceRefresh() { this._core.viewport?._innerRefresh();

Discussion:
Ref From
When I turn off , the padding remains. When I turn off , the decorations go away for the current terminal, even though shell integration is still on for the terminal. The padding also remains in this case. Are either of these results expected?
I don't think we're considering the setting currently, could you create a new issue on that? For were you testing for terminals that were not the left-most split? The padding should always be 20px for the left-most terminal so the character grid aligns with the first panel title. !
We are considering that: It's working for me https://user-
This is by design But shell integration should not still be on for that terminal.
I just tested it with a non-leftmost terminal now. I can confirm the padding goes away when I disable the decorations. When I re-enable them, the padding reappears, but the decorations don't seem to show up for new commands.
that one's tracked in already

Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially
Change:
this.calculateCodeBlocks(this._currentContent); this._updateContextKeys(provider, true); const widgetIsFocused = this._editorWidget.hasTextFocus() || this._editorWidget.hasWidgetFocus(); <del> this._getTextModel(URI.from({ path: `accessible-view-${provider.id}`, scheme: 'accessible-view', fragment: this._currentContent })).then((model) => { </del> <ins> this._getTextModel(URI.from({ path: `accessible-view-${provider.id}`, scheme: Schemas.accessibleView, fragment: this._currentContent })).then((model) => { </ins> if (!model) { return; }

Discussion:
Testing Repro: "getting started with accessiblity features" second step click on blue button to "open accessible view" results in an error in dev console says that "the editor is not accessible at this time" and advises to turn on screen optimized view, but I already have that on as you can see in status bar item. Version: 1.94.0-insider Commit: Date: 2024-09-24T05:04:12.797Z Electron: 30.5.1 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0
As part of this flow - I was also confused why a new file is opened after I close the Accessible View: !
I'm getting "the editor is not accessible at this time" messages while moving focus to the Python REPL input box or the Copilot Chat input box !
seems like an issue with the walkthrough accessible view?
this looks an issue with the accessible view editor. I'm seeing a similar issue when I open the chat-panel and request the accessible view.
Change:
languageId: string; noThrow: boolean; ignoreCase: boolean; <ins> unicode: boolean; </ins> usesEmbedded: boolean; defaultToken: string; stateNames: { [stateName: string]: any; };

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Feature request for the Monaco Editor. Create an optional flag for Monaco Monarch language definitions to indicate the usage of unicode-aware regular expressions. An example of one such regular expression is , matching the '' character.
What exactly does not work? Since you can pass in regular expressions directly e.g.
Hi, What's currently not working is the unicode-aware regular expressions supported by ES2015. Even though you're able to write a RegExp including unicode-aware characters (in the format ), and even set the unicode flag for that RegExp, they don't work in Monaco Monarch at the moment. Below is the monaco-language file for ABAP, edited to support the character in identifiers. ! This is how it shows up in the editor: ! That happens precisely because the unicode flag is stripped away by compileRegExp, causing the match to fail for that character: If we change that line to, say it works as expected: ! The proposed solution is a way for the developer to tell Monaco Monarch that, instead of stripping away the unicode flag from all the regular expressions, it should instead add it to all the regular expressions if a flag is set in the language definition, just like it's the current behavior for the option. Another option I've considered was to instead use the unicode flag if, and only if, it is set in the regular expression itself, but from what I could gather, that would force us to compile the RegExp an extra time just for testing the flag, or to parse the RegExp manually. Let me know if you need more information.
:+1: Thank you, this makes good sense!
Change:
handleNewRegisteredBackend(backend: ITerminalBackend) { if (backend.remoteAuthority === this._environmentService.remoteAuthority) { this._primaryBackend = backend; <ins> const enableTerminalReconnection = this.configHelper.config.enablePersistentSessions; // Connect to the extension host if it's there, set the connection state to connected when // it's done. This should happen even when there is no extension host. this._connectionState = TerminalConnectionState.Connecting; const isPersistentRemote = !!this._environmentService.remoteAuthority && enableTerminalReconnection; if (isPersistentRemote) { this._remoteTerminalsInitPromise = this._reconnectToRemoteTerminals(); } else if (enableTerminalReconnection) { this._localTerminalsInitPromise = this._reconnectToLocalTerminals(); } else { this._connectionState = TerminalConnectionState.Connected; } </ins> backend.onDidRequestDetach(async (e) => { const instanceToDetach = this.getInstanceFromResource(getTerminalUri(e.workspaceId, e.instanceId)); if (instanceToDetach) {

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
Change:
this._nextCommand = ReadFromTextArea.Type; this._register(dom.addStandardDisposableListener(textArea.domNode, 'keydown', (e: IKeyboardEvent) => { <del> if (this._isDoingComposition && e.equals(KeyCode.KEY_IN_COMPOSITION)) { </del> <ins> if (this._isDoingComposition && e.keyCode === KeyCode.KEY_IN_COMPOSITION) { </ins> // Stop propagation for keyDown events if the IME is processing key input e.stopPropagation(); }

Discussion:
VSCode Version: Code 1.15.1 (, 2017-08-16T17:15:57.756Z) OS Version: Darwin x64 16.3.0 (macOS) Extensions: --disable-extensions Steps to Reproduce: any file. on an IME such as macOS standard IME or Google Japanese IME. some texts with the IME. . Expected: Delete the last character on the IME just like backspace. ]() (in CotEditor) Actual: Delete the last character on the IME and the character before the IME input. ]() In the same way, ctrl-A, ctrl-F, and ctrl-B don't work correctly. I think this is because key down event propagation is not stopped even if the IME is enabled. and are related to this issue. <!-- Launch with to check. --Reproduces without extensions: Yes
Fixed via PR
Change:
this._register(this.titleService.onMenubarVisibilityChange(visible => this.onMenubarToggled(visible))); } <del> // Title Menu changes this._register(this.titleService.onDidChangeCommandCenterVisibility(() => this.layout())); </del> // Theme changes this._register(this.themeService.onDidColorThemeChange(() => this.updateStyles()));

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: Latest OS Version: MacOS Latest Steps to Reproduce: I have already disabled the following but I still have an empty top bar taking space in fullscreen mode, whereas before this change I could have removed the topbar completely. Before <img width="1439" alt="Screenshot 2023-08-03 at 10 13 57" src=""After <img width="1439" alt="Screenshot 2023-08-03 at 10 13 32" src=""Similar issue:
Workaround: It seems to be fixed once I exit/enter the fullscreen mode again.
To clarify--this is the issue you're running into? That issue is just about being able to toggle it in the first place, which does work as expected today. This behavior seems scoped to fullscreen mode specifically.
I also have this problem. I need that top bar completely removed, but I can turn off stuff and it still stays up. Is this really forced on us to not be able to remove?
actually that worked, had to go outside of fullscreen and now in fullscreen it correctly disappears. Cheers ;)
Yeah, I don't think this is intentional but just wanted to confirm the issue.
Change:
const hoverOptions: IHoverDelegateOptions = { content, target: this.target, <del> showPointer: this.hoverDelegate.placement === 'element', hoverPosition: HoverPosition.BELOW, skipFadeInAnimation: !this.fadeInAnimation || !!oldHoverWidget, // do not fade in if the hover is already showing </del> <ins> appearance: { showPointer: this.hoverDelegate.placement === 'element', skipFadeInAnimation: !this.fadeInAnimation || !!oldHoverWidget, // do not fade in if the hover is already showing }, position: { hoverPosition: HoverPosition.BELOW, }, </ins> ...options };

Discussion:
Type: <bBug</bTooltip position changed VSCode insiders and also see the right pointer is also missing Insiders release ! Stable release ! VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-24T15:21:39.004Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ ng-template17.0.2 multi-cursor-case-preserve1.0.5 codeium1.4.20 codium0.7.19 svg-gallery2.1.0 console-log0.6.2 gitlens2023.11.2404 vscode-test-explorer2.21.1 angular2-switcher0.4.0 vscode-jest-test-adapter0.8.1 template-string-converter0.6.1 test-adapter-converter0.1.8 gitpatch0.2.1 material-icon-theme4.32.0 pretty-ts-errors0.5.2 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Assuming this could be a bug in Hover infrastructure. Please let me know if it is otherwise.