jiebi/CodeConvo huggingface dataset:
Code change:
order: 1 }); } <del> function terminalMenuRegistration() { // Manage MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '1_manage', command: { id: 'workbench.action.terminal.new', title: nls.localize({ key: 'miNewTerminal', comment: ['&& denotes a mnemonic'] }, "&&New Terminal") }, order: 1 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '1_manage', command: { id: 'workbench.action.terminal.split', title: nls.localize({ key: 'miSplitTerminal', comment: ['&& denotes a mnemonic'] }, "&&Split Terminal") }, order: 2 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '1_manage', command: { id: 'workbench.action.terminal.kill', title: nls.localize({ key: 'miKillTerminal', comment: ['&& denotes a mnemonic'] }, "&&Kill Terminal") }, order: 3 }); // Run MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '2_run', command: { id: 'workbench.action.terminal.clear', title: nls.localize({ key: 'miClear', comment: ['&& denotes a mnemonic'] }, "&&Clear") }, order: 1 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '2_run', command: { id: 'workbench.action.terminal.runActiveFile', title: nls.localize({ key: 'miRunActiveFile', comment: ['&& denotes a mnemonic'] }, "Run &&Active File") }, order: 2 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '2_run', command: { id: 'workbench.action.terminal.runSelectedFile', title: nls.localize({ key: 'miRunSelectedText', comment: ['&& denotes a mnemonic'] }, "Run &&Selected Text") }, order: 3 }); // Selection MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '3_selection', command: { id: 'workbench.action.terminal.scrollToPreviousCommand', title: nls.localize({ key: 'miScrollToPreviousCommand', comment: ['&& denotes a mnemonic'] }, "Scroll To Previous Command") }, order: 1 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '3_selection', command: { id: 'workbench.action.terminal.scrollToNextCommand', title: nls.localize({ key: 'miScrollToNextCommand', comment: ['&& denotes a mnemonic'] }, "Scroll To Next Command") }, order: 2 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '3_selection', command: { id: 'workbench.action.terminal.selectToPreviousCommand', title: nls.localize({ key: 'miSelectToPreviousCommand', comment: ['&& denotes a mnemonic'] }, "Select To Previous Command") }, order: 3 }); MenuRegistry.appendMenuItem(MenuId.MenubarTerminalMenu, { group: '3_selection', command: { id: 'workbench.action.terminal.selectToNextCommand', title: nls.localize({ key: 'miSelectToNextCommand', comment: ['&& denotes a mnemonic'] }, "Select To Next Command") }, order: 4 }); } </del>  No newline at end of file

Related discussion:
text: We should also take out the "Terminal" menu when using the custom menu: ! //cc
pushed a fix for this only to the release branch. What we do for master is up for discussion. please verify once the build is out in 30 mins. Thanks
Thanks I didn't know about this code.
Code change:
const root = historyService.getLastActiveWorkspaceRoot(Schemas.file); if (root) { terminalService.openTerminal(root.fsPath); <ins> } else { // Opens current file's folder, if no folder is open in editor const activeFile = historyService.getLastActiveFile(); if (activeFile) { terminalService.openTerminal(paths.dirname(activeFile.fsPath)); } </ins> } } });

Related discussion:
text: The "Open in Terminal" does nothing when the current window has no folders. Instead, if there are no folders, it should open a Terminal window in the same directory as the current file.
this works for me, how are you running "Open in Terminal" exactly?
I'm using while I have a saved file focused in VSC. !
That command opens the active workspace folder currently. Maybe we should fallback to the active file if there is no folder open? Open to PRs
I would like to work on this as my first bug. Could I get some advice on how I should go about fixing this?
Great! All the external terminal code is located in the "execution" part You change will be in here: Utilizing the (see for how to pull it into that file).
Code change:
this._onPositionChanged(e); })); <ins> this.toUnhook.add(editor.onDidFocusEditorText((e) => { if (!this.workerRequest) { this._run(); } })); </ins> this.toUnhook.add(editor.onDidChangeModelContent((e) => { this._stopAll(); }));

Related discussion:
text: Keeping this open as the main tracking issue as I keep an eye on error telemetry. Been quiet and haven't seen any entries in the errors site since early Feb with +
Closing this as fixed by the above linked PR's. Error telem has been quiet with no entries for ~4 weeks.
Code change:
this._onPositionChanged(e); })); <ins> this.toUnhook.add(editor.onDidFocusEditorText((e) => { if (!this.workerRequest) { this._run(); } })); </ins> this.toUnhook.add(editor.onDidChangeModelContent((e) => { this._stopAll(); }));

Related discussion:
text: ! Version: 1.85.0-insider (user setup) Commit: Date: 2023-12-01T19:00:37.339Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: WindowsNT x64 10.0.
I think that is expected, see This should behave the same for when multiple editor groups are opened in the same window.
The issue is that highlighted words remain until a new word is focused. In the main window, the highlights disappear when the word loses focus.
not for me in this case: ! Do you have a case where highlights remove to reproduce?
In the main window, If you click on a word and then on a blank line, the highlight disappears: !
my assumption here is that the other editor is over a word that then is highlighted in the floating editor. There is probably a heuristic to decide which highlight to apply. Can you double check my theory?
it doesn't matter if it's on the same word or not but I found out this only happens if the same editor is opened on the main window or in other windows (in this case the first floating editor highlights disappear after losing focus). Highlights disappear after losing focus in: Main window Single floating editor (Not opened in main window) Only the first floating editor when there are multiple (Not opened in main window)
I can reproduce but this is not a floating window issue. It reproduces even when you just have 2 editor groups opened next to each other: !
tl;dr: Setting to "off" fixes it. I'm seeing what I think is the same bug, after upgrading to 1.85.1 (first upgrade in a number of months, so I've jumped a few versions). While writing this I think there are two distinct problems. The first is when a single file is open: -click a word. It highlights that word, and in a different grey highlights the same word in rest of document. esc: nothing happens. I now need to click a blank line to get the highlights to go away. (I'm sure esc used to get rid of it before??)
Code change:
this._onPositionChanged(e); })); <ins> this.toUnhook.add(editor.onDidFocusEditorText((e) => { if (!this.workerRequest) { this._run(); } })); </ins> this.toUnhook.add(editor.onDidChangeModelContent((e) => { this._stopAll(); }));

Related discussion:
text: The second is much more annoying, but only seems to happen when I have same file open twice, after using Split Editor Right. -click a word. It highlights that word, and (in a different shade of grey) highlights the same word in rest of window. In the other window it highlights some (but not all!) of the same word. doesn't get rid of it. Clicking a blank line does not get rid of it. All the grey highlights are there forever. the other window: still the highlights are there. I can now double-click a different word and see it highlight throughout document, click blank line gets rid of that one, but still my first set of highlights survive! only way to get rid of them is to close the editor and open it again. OR, reduce to just one window open, double-click it again, and then click a blank line. Playing around, I've noticed it does not matter which window I do the double-click in, it is the window on the right where the unwanted highlights survive. Regarding mentioned in the 1.84 release notes, searching for that in settings doesn't find anything. But I do have as mentioned in It is currently set to "singleFile" If I set it to "off", everything works as it used to. Double-click still highlights within the open file (only), and esc now cancels it again :-) BTW, testing the 3rd option, "multiFile", it appears to behave exactly as "singleFile" in every respect I described above. Anyway, switching to "off" gives me exactly the behaviour I want, so I'm happy.
Thanks for the detailed writeup! The editor highlights have been reworked to start bringing in support for semantic highlighting between multiple documents. This was primarily tested between multiple different documents and there are some bugs arising that have to do with split view of the same file. Will be addressing in the near future.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Steps for verification: Open a typescript file in split view, with content as follows: In the left panel, click the symbol. In the right panel, click the same symbol. In the right panel, click anywhere else that isn't a symbol.
Code change:
this._onPositionChanged(e); })); <ins> this.toUnhook.add(editor.onDidFocusEditorText((e) => { if (!this.workerRequest) { this._run(); } })); </ins> this.toUnhook.add(editor.onDidChangeModelContent((e) => { this._stopAll(); }));

Related discussion:
text: choose any whitespace, etc in Stable: The highlights should disappear from the left panel, but persist in the right, even as you click around the right panel. Fixed on insiders: You should not be able to end up in a state with persistent highlights when your cursor is not on a symbol.
Code change:
private _layoutNow() { const layoutInfo = this.notebookEditor.getLayoutInfo(); const height = layoutInfo.height; <del> const scrollHeight = layoutInfo.scrollHeight; </del> <ins> const contentHeight = this._diffElementViewModels.map(view => view.layoutInfo.totalHeight).reduce((a, b) => a + b, 0); </ins> const ratio = browser.PixelRatio.value; this._domNode.setWidth(this.width); this._domNode.setHeight(height);

Related discussion:
text: Testing Ideally there would be commands to navigate between changes. And they might deserve an action in the diff title bar. Same as the editor diff experience. !
Why is for these commands? I would expect them to be available from the command palette, since in a regular text editor Show Previous Change and Show Next Change both appear.
Code change:
private _layoutNow() { const layoutInfo = this.notebookEditor.getLayoutInfo(); const height = layoutInfo.height; <del> const scrollHeight = layoutInfo.scrollHeight; </del> <ins> const contentHeight = this._diffElementViewModels.map(view => view.layoutInfo.totalHeight).reduce((a, b) => a + b, 0); </ins> const ratio = browser.PixelRatio.value; this._domNode.setWidth(this.width); this._domNode.setHeight(height);

Related discussion:
text: Testing Notice that the scroll range is below the decorations, even though they're on screen <img width="717" alt="image" src="https://user-"Meanwhile if I scroll to where they're shown, they aren't in viewport <img width="713" alt="image" src="https://user-"This was on the following gif: <img width="401" alt="image" src="https://user-"
Code change:
return createFileStat(resource); } }); <ins> instantiationService.stub(ILogService, new NullLogService()); </ins> resolver = instantiationService.createInstance(TerminalLinkResolver); validResources = [];

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --So far, I haven't been able to find any issues around this, but I also haven't found a ton of documentation on this feature either. Basically, I'd like to have finer grained control over how the terminal "word link" auto detection works. This is one of the only comments I was able to find about: Example: In the terminal, I have some output from a compiler that includes relative paths that can be clicked conveniently as an autodetected "word link": Specifically, clicking takes me to the line in question, which is great! However, at some point I tried configuring to include a forward slash (colon has related effects too), e.g. By doing so, the auto-detected file path is no longer clickable, since each path segment is considered as a separate word instead. Notably, the absolute path above is still clickable, but relative paths appear not to be (unless I remove from again). I guess there is probably more than one way to solve this, but a simple solution that comes to mind would be to have a separate config, maybe something like . If null it could fall back to the value, but at least this way it would be possible to configure different separators for double-click selection and link detection. Thanks in advance!
This case is meant to work with the regular non-word link detection as you can see here: <img width="490" alt="Screenshot 2023-05-08 at 6 31 15 am" src="https://user-"This may not work is if the relative path is not relative to the current working directory or you have shell integration disabled (which is provides better cwd detection). In your example is relative to the directory the terminal was currently on? The word links are meant to catch the majority of cases where the verified file links fall through.
Edit: never mind, I think I was testing with the wrong value of as I described in the original issue body :( I did however notice an interesting data point while integration was still disabled: the clickability of the file path seemed inconsistent. Here are a few screenshots showing what I mean (ctrl held in each case): Can't click in a compiler diagnostic, maybe due to the prefix on that line? !
Code change:
return createFileStat(resource); } }); <ins> instantiationService.stub(ILogService, new NullLogService()); </ins> resolver = instantiationService.createInstance(TerminalLinkResolver); validResources = [];

Related discussion:
text: A command I wrote without line/column numbers works fine: ! A command I wrote with line/column numbers works fine: !
It's a little hard to tell if this is by design or not without knowing the exact cwd and full path of these folders. What we're going for is verify if the file is real if it's relative to the current working directory (which is citro3d-rs in your last 2, not sure for the first), otherwise fall back to word links. Since you changed wordSeparators, the fall back isn't as useful, but it looks like it's working properly.
Ah sorry I forgot to include those extra details. The cwd and path was the same in all 3 cases (i.e., the relative file path should work in each case, I think?): I guess the part that doesn't make sense to me is why the latter two cases work but the first one doesn't - since in each case the path is the same and I haven't changed directories at all. I suppose the workaround of removing and from is still an option but it would be nice if the linking was more consistent.
Yeah this is strange if it's all the same cwd. I Can't repro here I'm improving trace logging in , when that is released to insiders (the day after it's merged) you will be able to set the log level via the command palette (F1) and view the trace logs when hovering the terminal line by looking in the Output panel Window dropdown entry. That will give us some more info on why this is happening.
The logging changes should be in tomorrow's insiders
thanks for that, here is the trace log output that I think is relevant for debugging. Please let me know if you need more info or another reproduction: Edit: the cwd again was and the relative path should resolve: <details<summarytrace output</summary</detailsOne odd thing I noticed - without changing any settings, I actually had one instance where it worked as expected and linked the relative path to . However I'm not sure how or why it worked. When I opened a new terminal the old behavior (not linking) came back. If I can reproduce that again I'll try to capture those trace logs and maybe it will highlight a difference in behavior that's helpful. Thanks again for looking at this!
Code change:
return createFileStat(resource); } }); <ins> instantiationService.stub(ILogService, new NullLogService()); </ins> resolver = instantiationService.createInstance(TerminalLinkResolver); validResources = [];

Related discussion:
text: So there's this in the logs: So it's parsed as a possible link, but not made a link candidate (which checked the file system before making the link). Somehow this part isn't adding the candidate: The only way I think that could happen is if doesn't return anything. I another log to verify the cwd and also improved fallback in case it is undefined. Can you do the same again on the next Insiders which should come out on Monday?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the delay, was a bit busy last week but I was able to check with a recent build (): The link is clickable now, even with and both in ! I'm guessing the fallback changes you did the trick. It seems the triage bot closed this as "not planned" but maybe you are able to update its status to "fixed" or similar? Thanks for your help looking into this issue!
great news! I still don't totally understand how it was failing before but at least the issue is fixed
Code change:
}); test('service validates backup workspaces on startup and cleans up', done => { // 1) backup workspace path does not exist service.registerWindowForBackups(1, false, null, fooFile.fsPath); service.registerWindowForBackups(2, false, null, barFile.fsPath);

Related discussion:
text: Moving this over from After the backups are not restored if the workspace directory doesn't exist anymore. The workspace is no longer tracked but the backups are kept around in the backup directory should they be needed later.
Tricky.... I would expect an empty window to open with those files dirty. This might require some work on the area of restoring on empty workspaces. Have not thought about this longer yet.
Marking as important because this means data loss if the folder is deleted on disk.
maybe this should be done on the main side on startup similarly to If a folder no longer exists, convert it into an empty workspace backup and let it open as empty window.
On test plan:
Code change:
const languageService = accessor.get(ILanguageService); const config = accessor.get(IConfigurationService); <del> const scrollBehavior = config.getValue(NotebookSetting.cellExecutionScroll); </del> <ins> const scrollBehavior = config.getValue(NotebookSetting.scrollToRevealCell); </ins> let focusOptions: IFocusNotebookCellOptions; if (scrollBehavior === 'none') { focusOptions = { skipReveal: true };

Related discussion:
text: a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.
Code change:
const languageService = accessor.get(ILanguageService); const config = accessor.get(IConfigurationService); <del> const scrollBehavior = config.getValue(NotebookSetting.cellExecutionScroll); </del> <ins> const scrollBehavior = config.getValue(NotebookSetting.scrollToRevealCell); </ins> let focusOptions: IFocusNotebookCellOptions; if (scrollBehavior === 'none') { focusOptions = { skipReveal: true };

Related discussion:
text: I think it still works this way out from source in the latest , from what I saw, it's running shift+enter: run cell and move to next This command moves focus to the next cell, so the cell is now the focused cell Then the output of the previous cell (which is no longer focused) starts to grow The change introduced via 's last PR was to ensure that the focused cell stay visually stable, once they are revealed into view can you confirm if this is what you are seeing?
I captured a recording for what probably was comparing, right side is Stable and left side Insiders In both setup, the next cell is fully visible In Stable, shift+enter moves the next cell up, and then push it down, but the new focused cell is still visible in the viewport at the end In Insiders, shift+enter moves the next cell up, and when the previous starts to grow, it does not move the focused cell downwards Even though the new behavior is more self explanatory (from our perspective), but unluckily is not the same as Jupyter Lab. It means we are changing from one custom behavior (our previous heuristics) to another (always keep focused cell stable)
Thanks for clarifying this It was not clear to me that (1) shift+enter and clicking the run cell action did different things, nor that (2) this bug was only about one of these actions.
fixed by