jiebi/CodeConvo huggingface dataset:
I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.
<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When we use to jump to definition, would open the definition in a new window, which is inconvenient for me. It would be better if we can choose where to open definition, like in . !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.492 --- <!-- score: 0.467 --<!-- potentialduplicatescomment --
Nice suggestion. If you agree with this, I'll create a setting so one can choose if 'ctrl+click' always opens the peek view.
Normally, ctrl+click runs and cmd+ctrl+click opens . With this setting enabled, they both run . I don't think that's expected. Possibly change to ?
you can reopen verification-found issues
Uhm, I'll take a look on that. Thanks for your feedback!
Please file a bug and don't reopen feature requests
I created
<!-- 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/No 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.71.2 (user setup) OS: Windows_NT x64 10.0. CPU: i5- Run command and pick a invalid uri (e.g. path doesn't exist) when having "large" (like a few hundreds) amount of recent history entries, vscode will freeze for a few seconds !
By the way, having "large" amount of recent history entries will also slow down the start up time (both vscode start up and open file time) for a few seconds as well, just tested that with out any history with a few hundreds
thanks for testing that, do you recall how you got into this state of having many entries? Just by opening folders and files that contribute to the history? If you could do me a favor: open the command palette run the command "Log Storage Database Contents" run command "Toggle Developer Tools" click on "Console" expand the first "Storage..." output that is printed there find the entry (see picture below) how many entries do you see? <img width="1005" alt="image" src="https://user-"
Total of 671 entries, most of them are temp files opened from things like MobaXterm and !
Got it, we do have a limit of 500 entries when presented, but I still have to understand the performance issue. You could actually help out by doing a performance trace yourself when this happens by starting performance tracing before invoking the time consuming action and stopping right after.
When you hover over a type in a TypeScript file, the tooltip that appears has a very low max width, making it difficult to read long type signatures.
I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!
! Errors are quite unreadable if the width does not adapt to the font size.
! it would be nice if the tip used the available space instead of wrapping at an arbitrary point in c# too
!
! Same problem using rust's language server.
General styling control would be very helpful. Also line-height. Another approach would be to have a bottom panel that displays the full error and the tooltip displays a shortened version.
!
! When using the auto import feature it is often impossible to differentiate whats what as the import path is cut off due to the limited width of the suggestions window.
Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well. !
Same in Python. We have to jump through hoops trying to flow doc nicely. And when it appears OK on Windows, it breaks on Mac... ! And it is inconsistent. Ex, hover is OK ! But completion list decides to wrap. What gives? ! Looks like hover respects markdown while completion item doc is plain string and gets wrapped randomly.
!
Someone say long type signatures? !
Here is a workaround by hacking the file "C:Program FilesMicrosoft VS Coderesourcesappoutvsworkbench" Simply append the code above after the original content of file, and restart VSCode. (Title bar may alert a warning message "Not Supported" and hacked changes would be overridden by updating VSCode) !
It would be nice to have some control on the width. The above does work but vscode presents the message your installation may be corrupt on restarting.
Instead of hacking the CSS directly as mentioned above, I recommend using the to just override the current CSS. That way when VSCode updates, you can just reload the custom css file that you have specified (personally, I have a project where I hold configurations for my shell, Spacemacs, etc. and this custom CSS file goes there). Until it's officially supported, hacking the CSS is likely the best route.
The suggested widths above were a bit much for me, so I settled on the following values for now:
What is preventing the devs from providing a configuration option for this? This issue has been open for almost 2 years, and it bugs me on a daily basis. Would love to see it fixed.
(since you seem like the most relevant person to ping) is anything likely to be done about this?
I would love to hear an explanation from devs too. What are the difficulties of implementing this? I imagine it's settings a dynamic max-width and adding some more lines to add it in Settings. Are there other design blockers?
Will you take a look at this? In 3 days it will be a 2 year anniversary for this simple feature request.
Assigned to and as I remember we are going to have some UX improvements for editor tooltips and so on.
maybe now is the time to take this on? current iteration tries to solve parameter hints ux and this is not that much different
! I employed CSS and put together full instructions: [Custom CSS and JS Loader extension][1] macOS VS Code: VS Code Insiders: Linux: : [1]: Restart VSCode Ignore "VSCode is corrupt" error You can choose to suppress this notice forever Run command "Reload Custom CSS and JS"
just as a disclaimer, if anyone modifies the CSS/JS of the app, it comes up at “corrupted” in diagnostic checks, and you’ll typically get pushback if you report issues and include diagnostic information. Or, at least, I received pushback when I had custom CSS/JS enabled, and wouldn’t receive help until I turned it off (even though it was harmless/not related to the issue I was having). While this is indeed an okay workaround, we should just keep making our voices heard so that this is natively supported.
100% agree. This is just a workaround. It's hard enough to read TypeScript lint as it is! :)
Currenlty using VSCode 1.30.2, followed instructions step by step, but it's not working. I don't even get the VSCode corrupt error. I'm running Windows 10 (V.1803). Edit: It was my mistake. For anyone who's having trouble, make sure to run Enable Custom CSS and JS from the command palette. Simply restarting won't work.
This issue seems to be fixed in 1.32.0-insider (1.32.0-insider) . I hope this is an intended behavior. I want to thank the developers.
This change is related to . I confirmed that the max width of is still small as mentioned above. <img width="867" alt="2019-02-22 17 06 19" src="https://user-"
Update: in , only the hovers for problems and the hovers with code blocks become to have larger width. Others have smaller width.
Hello there,your solution is great,but I want to ask how to get rid of the word at the title.As sort of OCD,sufferring from that. thx a lot!
This extension was created specifically for solving this:
This has been a long standing annoyance, with an issue that's like 2 and a half year ago. It shouldn't take much effort to have a config property that overrides the width/height of the tooltip, surely? Like, 10 mins of effort? <img width="525" alt="Screen Shot 2019-07-18 at 6 41 15 PM" src="https://user-"
if it's really 10 mins of effort, then I'm sure you can submit a PR for this? I definitely can't do this in anywhere close to 10 mins, so it would be much appreciated!
Seriously, I want instead of this: ! At least something like this (with syntax highlighting it will be even better): !
There's already been a PR. I really don't understand this. I figure most VScode devs develop VScode in VScode, are they comfortable with the current state?
fyi, it would be great if the hover could be resized
How is this issue 4 years old and such a basic thing still isn't implemented?
Is there any word on whether we could see this soon? The suggestion widget has had resizing enabled since v1.51 in October, 2020. Is this tooltip widget considerably harder to add this feature for or are there additional considerations to be made? Whether it's a click to resize, or a manual adjustment in settings, could we have an update on the status of this addition? Opening new editor tabs just to properly read code annotations for some more descriptive components on my large monitors does feel like an unnecessary extra step.
might be very related and close to what you did here:
Hi, Instead of configuring the max width as the title says, could the tooltip hover be resizable ? (Also check for more info on what was done with the suggest widget)
It's sad to see that it's still not a thing.. I would really like to adjust the height of hover description tooltips.. The big brother Visual Studio does a much better job already. Let VS Code catch up a little..
another possible view for this issue
It is 2022/11/11. Christmas is close and I made sure Santa knows what I want!
"Excuse me, it's 2023"
This one will be my favorite. Copilot suggestions and TS errors just can't be seen in this tooltip. It's time to fix it.
If this is still open and no one is looking at it, I'll take a crack at it. Feel free to assign it to me if that's alright.
Hey all, thank you for your patience. A PR has been made which is currently under work but nearing its completion. You may find it here: Once this PR is merged, you will be able to resize content hovers within Insiders.
Would you add "Reset Hover Widget Size" command in Command Palette? Like we have for suggest widget: "Reset Suggest Widget Size". It would be good if we could reset the size to the initial one.
Thank you very much. 1 Is it correct, that this would not stay across different sessions? 2 The default max width is very small, is there any consideration, of increasing that?
Will this feature also allow us to define the window size of a hover provider in a extension above the current limitations?
Hi if is is decided that the hover widget size should be configurable, there will be a command to clear the persisted sizes. This feature is still under discussion. Hi depending on the implementation, it is possible that the persisted sizes are persisted or not across different sessions. This is still under discussion. Currently the implementation is such that the maximum natural width is the same as before. Hi the current implementation does not provide this functionality. This could be addressed in a separate issue as it is related to the usage of the hover widget by extensions. The current PR that is worked on is the following:
Thanks a lot.
And do you consider increasing the default size, that is unfitting to most real world scenarios? The windows is so small, that I feel the need to increase it even on my WXGA Laptop.
Hey all, thank you for the patience. A PR has been merged in order to make the content hover resizable. The change should be visible in tomorrow's VS Code insiders version and in the next stable release which will happen in the coming two weeks. There currently is no mechanism to save the content hover - we are discussing how best to approach it. You may track the issue on persisting the hover content here: we are currently not thinking about increasing the default maximum size. However it is possible that we implement the persisting mechanism as follows: when you increase the content hover size to a specific size, this size is persisted, and it is applied as maximum default size on the next hover appearances. This potential implementation is still under discussion by our team.
Just want to say thank you you seem to have been tackling a lot of these high-level nitpicks that have been in the VSCode backlog for years, and for that I am very appreciative.
I can't find a command to clear/reset hover widget size, is this has been ?
Hi currently the command does not exist because a persisting mechanism has not been put into place as of yet. It will appear when the latter is .
Oh okay, thanks a lot
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- Version: 1.46.0-insider Commit: Date: 2020-06-01T10:32:27.369Z Electron: 7.3.0 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Darwin x64 19.5.0 Steps to Reproduce: a new untitled notebook (using VS Code Python extension) you add a cell or the like, then VSC will invoke the save method on the Problems Adding cells should not invoke save (this happens when user has auto save turned on) Errors thrown in the method are ignored. VSC will assume the notebook was saved and mark it as not dirty (the dirty indicator doesn't exist on the tab anymore) I don't think VSCode should call the method for untitled notebooks. FYI - We create untitled notebooks with a scehme . If this isn't the way to indicate an untitled file (scheme), we might need some API or the like in the notebooks implememtation. /cc
Good catch, untitled file should not trigger save until users explicitly run Save, which will invoke SaveAs.
We should also improve the overall experience for creating untitled notebook documents, they can be created in two approaches: Users press cmd/ctrl+n to create an untitled file, switch to another view type (tracked in ) Users run a specific command to quickly create a notebook untitled file. command should take view type as arguments. cc we may also want to adopt this in Custom Editor world.
We now support opening a untitled file with specified editor view type through the existing new untitled file command (in master, and tomorrow's Insiders) When the command is executed, is invoked with an URI with scheme. is invoked only when users save so no auto save for untitled files as usual.
debugging the loaded scripts view open debugging, notice exception in the console can not reproduce with Stable so it might be that my listener refactoring caused this If you pause on exception you will see that caused it.
did you have a chance to look into this? Or would you like me to investigate? I suspect this is breaking the loaded scripts view and is the root cause for
no, please investigate since this and was working before, and I haven't touched this code for two weeks.
end session events are not arriving in As a consequence the tree for the session is not properly removed.
I see something differnetly, the end sessions are arriving however when the last session end arrives view starts refreshing the tree and while that is in progress the view gets disposed which throws an exception. Looking into a fix...
I have created a PR which address this issue
<!-- 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?: No <!-- 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.82.2 OS Version: MacOS 12.0.1 Steps to Reproduce: our extension (Evidence), create a new project using the VS Code command palette which pages open automatically text file is opened automatically on the left walkthrough is opened automatically on the right This was working until one of the more recent VS Code versions I believe. text file is opened in full walkthrough is opened in full, taking over the editor pane from the text file (i.e. you can only see the walkthrough in your editor) This is the function we use to open the walkthrough: Where maps to I was under the impression that the in this function will open the walkthrough "to the side", which was happening successfully before, but is no longer working.
I had an older version of VS Code running on another computer and have confirmed it used to work in VS Code version
should this command be documented here
I did update our docs last week to include this command. Waiting for the newer changes to be published.
have an eager comments controller extension (see below) open a notebook create a new cell leak warnings are printed
This seems to be rooted at  It looks like a new is created without always disposing the old one. The looks highly suspicious. <img width="1586" alt="Screenshot 2022-10-26 at 14 09 41" src="https://user-"
Suggesting to tackle this for October because after a short while VS Code was crawling due to excessive listening
thanks for good reproduce. The comment thread equality check is wrong, it's an oversight during refactoring iirc. I pushed a fix for this memory leak. Though with it fixed, I found there are issues with "Editing" state of comment thread for cells (focus issue), will look into this next week.
Thanks
It's used in , this would be easiest after that's merged.
I wish instead of explicitly checking whether proposed API is enabled in in the implementation, we could check it when checking distro for whether an extension is allowed a proposal instead.
the list of allowed extensions is not available in code - oss though on local or in CI
That's fair but do we really need to check in code - oss when developing? I would think is being tested out in the final build that's published.
not my area but being strict is good for proposals and it's good to align oss with the product in areas like this. Consider a fork of VS Code that does not have the check, extensions could use the proposals without warning which could lead to easy breakages.
Testing Add a git pre-commit hook that sleeps for 120 seconds Make a change to a file, and commit the change Switch to another VS Code window Expected behaviour: Window should be active while the source control operation running Actual behaviour: Window becomes inactive even though the source control operation is still running
Can this be adopted in SCM? Holding an activity lock is fairly easy, just call this method
these commands are being contributed by the git extension. Should be wired into the so that in case there is an on-going progress indicator the window is considered active?
Yea, I think that's reasonable, thanks for the suggestion. Will take care of it
<!-- 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?: No <!-- 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.69 () OS Version: macOS Ventura (13.0) developer beta 2, Firefox 102.0 Steps to Reproduce: an Insiders Codespace with any repository on Settings Sync until extensions are installed many walkthroughs being opened Here is a video demonstration: Something else that I took note of (also seen in the demo video) is that: Sync is turned off for every new codespace I create the extension setup, the page reloads every time in some stage of the process (this could be expected though) I have tested this both on Brave and Firefox with various different repositories. Original issue:
The respective component owner has to opt into syncing the state.
This user is stating it only happens in codespaces and not on or I'm not sure if settings sync is treated differently here but we do sync walkthrough state
Yes indeed, In addition, this does not happen for me in 1.68.1 (stable).
Created a PR fixing this Can it be cherry-picked to the release branch before tomorrows release :pray: ? This also affects workbench theme as it flashes from default theme to the theme from settings sync which is really annoying, in 1.68 workbench starts with the theme from sync server directly cc
It seems the newly created codespace is not getting initialised with synced data because the workspace says it is not new.
Issue Type: <bBug</bnew VSCode window new Terminal terminal: terminal: in Cmd and mouse over the two listing name. Only the /tmp/Foo.h will be clickable. won't be because of the . VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 19.3.0 <!-- generated by issue reporter --
/duplicate