jiebi/CodeConvo huggingface dataset:
I am getting the same issue with VS Code Insiders (see atached video file). Version: 1.89.0-insider (user setup) Commit: Date: 2024-04-25T21:21:03.843Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0.
this was a regression in 1.89, so it was fine in 1.88
can you try again but make sure you recreate the terminal?
Thanks for your continued support on this. I can still reproduce on the latest version of insiders. Version: 1.89.0-insider (user setup) Commit: Date: 2024-04-26T00:56:34.034Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0.
Sincerely sorry for replying so late on this issue. I donwloaded and installed the latest VS Code Insiders. Unfortunately, this problem still happen. My PC Info is listed below. Commit: Date: 2024-04-26T00:56:34.034Z (1 day ago) Electron: 28.2.8 ElectronBuildld: Chromium: 120.0.6099.291 18.18.2 W8: 12.0.267.19-electron.0 OS: Windows NT x64 10.0. I found something interesting that while you changed the TERMINAL widget size just like maximized the VS Code window or dragged the left side of terminal list, the strange string will disappear. It seems to mean when you resized a terminal window to control how many characters in a line to show on screen, the string which was already output will be changed or even erased. I captured two new videos of this probloem. The first is the origin problem reproduced in the latest Insiders and the second is changing the window can erase this strange string. Hope these useful for solving this problem.
Reopening issue based on feedback above.
i found issue the didnt occur on 1.87 but then could reproduce after upgrading to 1.89. Version: 1.87.1 (user setup) Commit: Date: 2024-03-06T00:21:36.258Z Electron: 27.3.2 ElectronBuildId: Chromium: 118.0.5993.159 18.17.1 V8: 11.8.172.18-electron.0 OS: WindowsNT x64 10.0. Version: 1.89.0 (user setup) Commit: Date: 2024-05-01T02:09:22.859Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: WindowsNT x64 10.0.
it isn't only when paths are long. in insider i'm seeing this with ohmyposh/poshgit in powershell terminal windows, even if i'm at the root of a drive where the path is only a few characters long (though probably related to whatever posh is doing?) ! i'm on win11, insiders 1.90.0
anyway in 1.89, as a workaround i replaced ~AppDataLocalProgramsMicrosoft VS CoderesourcesappoutvsworkbenchcontribterminalbrowsermediashellIntegration.ps1 with the shellIntegration.ps1 from commit and it resolves the issue.
Looks like the only remaining issue with Windows PowerShell (), the fix for that was only just merged yesterday:
- did you have some reliable steps to repro this?
in Windows PowerShell () run a lot command like a few times and ensure a GUID does not show up in the output.
Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is
Issue Type: <bBug</bmicrosoft/vscode-extension-samples the helloworld-sample folder , build, verift that its contributed "Hello World" command activates the extension and shows a notification. the vscode version references in in two places to use 1.43 minimum. code to activate function in , for example: , run, use "Hello World" command to activate. breakpoint on return line above. a folder. Explorer button or context menu to create a new file. Confirm that the event fires and your breakpoint is hit. from breakpoint. Explorer context menu to copy/paste or use drag/drop with modifier to drip as a copy. :bug: The event callback does not run, despite the API doc stating: Issue also exists in 1.64.2 VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-21T05:15:17.930Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
cc
the extension host's event is only emitting from 's event, but the explorer is using the 's , which doesn't seem to talk to the working copy service. What do you think the fix here should be? (cc
the bulk edit service is using the for its operations. If you look at , there is a bunch of usages for that service. The working copy file service is a wrapper around the file service that ensures the relevant events are emitted and can be participated on. I suspect that for the copy/paste operation or drag/drop we are possibly not using the bulk edit service but the file service directly? I suggest to make a pass over all explorer code and look for raw usages of to replace with bulk edit service. I think that would even enable undo/redo properly.
My bad, the real bug is that this block: doesn't handle events. cc
Pragmatic fix would probably to treat the same as .
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.
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
Currently the scroll top position update is not context-aware, meaning when we have cell height changes, we don't know if it's because output height change, or users re-run a cell and outputs are updated/replaced, or users shift+enter to run cell and navigate to next cell. Users might have different expectations for each scenario but currently our heuristics for updating the scroll top didn't take the context into account. Let's use this issue to finalize the desired behavior of scroll top update. The polished/new design should cover [ ] Update element height API respects context (execution, execute+create, output update) [ ] Reveal API should handle out of sync view/content height Click the run button or press Ctrl+Enter to run focused cell If there is no enough room/space after the cell (e.g., the focused cell is the last cell) Users have disabled [ ] There is no output before execution, the view should scroll up to reveal the output fully [ ] Some users might want the bottom of the output to be fully revealed, when the output is larger than the viewport [ ] There is output before execution, the cell position should be persistent Users have enabled [ ] Reveal cell output If there is enough room after the cell [ ] Reveal cell output [ ] If the cell input is larger than the viewport, execute cell should reveal the output properly [ ] Collapse focused cell output should always keep the cell in viewport [ ] Type/Pasting content into focused cell should keep the cell in viewport [x] [ ] Notebook cell list reveal api might reveal a position on a cell whose view height is not synced with real editor height yet. [ ] Execute non-focused cell, should it keep the focused cell position persistent or keep the top of the target cell persistent? [ ] Non focused cell output height change should not change scroll top on scroll [ ] Shift+enter executes and moves focus to next cell, then new focused cell should always be in viewport [x] Scroll top position of inactive notebook editor should not change if the first partially visible cell's height change
I noticed an issue recently, is this related? Paste a large amount of text into a code cell The notebook scrolls down so far that the focused code cell is out of the viewport I can open a separate issue if you want
I guess what you were seeing is , I'll update the description to include this.
Couple cases discovered in the latest notebook sync.
both of these are likely tied to outputLineLimit being large @ 100 when the shift-enter behavior is set to "firstline" the events are as follows: first line of next cell is focused and shown at the bottom of the viewport output is cleared and the focused cell is pulled upwards against the currently executing cell output streams and pushes the focused cell out of the viewport. my ideal thoughts: anchor the focused cell (with setting), maintaining the first line visible. output will stream in, pushing the executing cell upwards out of the viewport shift-enter set to "fullCell" and next cell has a large output focus shifts to next cell, and the viewport exposes the bottom of the output for that cell. there is no cell editor in the viewport my thoughts: "fullCell" behavior should show the top of the next cell editor at the top of the viewport
In there is , which seems to be called every time the scroll event of the editor fires. That method seems to clear the dom node and reconstruct it unconditionally. When smooth scrolling is turned on, the scroll event fires many times per second and the call seems to take some time: ! I think if you would only rerender the sticky scroll widget when necessary (and generally try to minimize dom API accesses), we could improve the performance here easily. I think could have an equals method and would just do an early return if the new state equals the old state.
Thanks for this remark. It is a very good optimization point.
<!-- 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. --When the user starts an extension defined terminal through the "Split Terminal" submenu of "New Terminal", the new terminal is always created in a new terminal tab, instead of a split. When the user opens a terminal through this menu, VS Code should override the field of the new terminal profile to make it split, as the user requested.
is this not what you're seeing or am I doing something wrong? !
Only when the custom terminal profile is created with . I have a terminal profile that is created with , that looks like this: This terminal profile is created like this:
I heavily use and love inlay hints but find their current styling too prominent for "hints" and think it harms readability and other editor features that use highlighting of words such as "highlight occurrences." Try finding highlighted occurrence of : Current: <img width="1779" alt="Screenshot 2023-06-29 at 11 51 00" src=""With less prominent hints: <img width="1779" alt="Screenshot 2023-06-29 at 11 47 31" src=""I think in the latter screenshot, inlay hints are less prominent but still as useful, as they are literally "hints" and don't need to be so prominent. If not as default, having a setting to tweak the background & color of hints would be great.
I think I've read a similar issue recently (should have the inlay-hint label).
Can be configured via and leaving it up to to tweak this further.
Updatde the default light/dark themes in to make these more subtle. Still want to keep the backgrounds since these could otherwise be confused with the ghost text in Copilot, comments in some themes, etc. <img width="422" alt="CleanShot 2023-06-29 at 11 23 35 src=""<img width="430" alt="CleanShot 2023-06-29 at 11 22 43 src=""
Steps to Repro: Search for an extension pack in extensions view (Say PHP Extension Pack) Open PHP Extension Pack in the editor Go to Extensions Pack tab Click on any extension Fails to open Close to open the editor Does not close Not sure how it happened but I had the extension pack open (as extension editor) and after a while (being on twitter) I wanted to close the editor and I saw error notifications. These are the minified stacktraces from the log the build was
Not able to repro it. Also followed the code and I do not see a path that has no extension in the input. Do you remember any steps you followed during this? Is it possible to guess what could be happening in editor land from the above stack trace?
are you using editors with preview mode, e.g. do they appear italic? Hard to say what the execution flow here is to be honest. Looks like a normal editor opening but failing to get the resource for the editor, which is used to associate the editor in the editor tabs model.
But this is happening while is trying to close the currently opened extension editor.
I don't use tabs, so I am not sure what the model then is... Yes, closing it was. I had the extension editor open, also installed the extension, then waited, and then tried to close the editor. So maybe some cleanup logic hit me or installing the extension made a different...
The preview feature works with tabs enabled or disabled. The fact that an editor is opened can be explained if you closed an editor and the next one below that editor was the extension editor. Closing an editor always means we open the previous editor unless it is the last editor. I suggest you try to figure out how it is possible that is even though it is not typed as such.
Ok
What are the verification steps for this?
Steps to repro are in the description
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21 OS Version: Mac 10.12.16 Steps to Reproduce: editor mode should be in vertical mode on centered layout with one tab, you should see it is centered split editor mode to horizontal mode centered layout will no longer work until you switch back to vertical mode <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --- <!-- score: 0.451 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Thanks for figuring this out. I spent a while trying to figure out what the problem was. Thank to you, I changed splitting to vertical mode and now centered layout works. I can affirm that this big is happening to me too. I'm on a mac as well.
I would expect centered mode to work if I have horizontal layout and only one editor. I tried removing the check to simply also enable it for horizontal layout but somehow the layout gets broken in that case. I plan to fix this in the following week but just to let you know that a PR is more than welcome :)
I just let you know that money is more than welcome :smile: Just kidding... I run on fun xD you shall have your PR :) it has the number . The problem was, that the available size was calculated by using which holds the height and not the width of the editor when in horizontal mode. You have to play around with it a little... it seemed to work but I did no deep testing or anything As bonus I fixed two typos (one of whom I made myself :smile:)
thanks a lot for your PR, I just merged it in I tried it out and it works nicely, also thanks for fixing typos. For money feel free to apply for our internshipts if you are a student or to our open positions :)
:smile: I'll finish university in 4 month... so... I might very well do that xD
Create an ipynb file (with one Python cell) Save this Verify the entry exists in time line Change the language of the cell to Save this Verify we have an entry Click that item Bug On the left we need On the right there's no such entry in metadata This is incorrect. The ipynb has the above metadata. What seems to be happening is When the language changes, We serialize the ipynb and JSon contains the metadata However the model is not updated with corresponding changes to the ipynb file I.e. model change triggered =ipynb serialize to JSON =Json contains new metadtaa not in model =Missing step is to update the model again If we implement the last step, we could always end up in an infinite loop, Perhaps we should first update the model with metadata when ever we detect chagnes in the model before the save event. E.g. as part of pre-Save (onDidChangeNotebookDocument &/or onWillSaveNotebookDocument) This way, model will always be accurate and upto date when ipynb is serialized.
Easier way to explain the bug Create an ipynb file (with one Python cell) Save this Change the language of the cell to Save this The cell metadata will not contain the new metadata that exists in the ipynb JSON file. (model is not in sync with ipynb json)
Suggested Solution Perform model updates when we're about to save (or when we detect changes to model) When saving, ensure we save the metadata as is, without generating any new content I.e. JSON.stringify the metadata.
/cc
Considering that a serialize operation should not have side effects (ideally), enforcing a "save participant" from ipynb extension makes very good sense to me. We can leverage which support additional async operations, like how we handle attachment clearnup
For such critical metadata change, we might want to handle both auto save and manual save as we want the json and model to be always in sync.
Another simple repro step Create a notebook, and save this Add a new cell The latest entry in timeline will be However there's a difference, one has and the other (current model state) does not have any Again, model does not contain metadta (as this is a new cell) and ipynb JSON contains metadata when serialized.
<details<summaryInternal Notes</summaryHere's the work flow Add a cell A change event is triggered, undo redo stack is updated Last undo redo is User hits save button Working copy starts to handle the save operation Save participants start We add a save participant and update the model via a work space edit Now a new change event is triggered This results in a whole new undo redo stack The latest (last) undo redo item is Save participants done Working copy keeps track of the last as the entry for Problems Time line does not include , time line shows only I guess this is correct, However from a users perspective, the labels are never going to be meaningful as we'd always say . </details
! 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??)