jiebi/CodeConvo huggingface dataset:
All of a sudden, I no longer have GHPRI installed. When I go into I see Settings Sync removed it 11 hours ago, but I'm 100% sure I never uninstalled it. I know I have Settings Sync enabled in both and are those scenarios doing unexpected things to my settings sync? !
I am sure that 4 days ago I re- the extension. Today, I'm on another machine, and GHPRI is again gone.
Lets sync on this
Closing as I couldn't repro.
I was able to reproduce this issue. will sometimes remove and then readd the GitHub Repositories, Issues & PR, and remotehub extensions, except it doesn't readd the keypair to the config, so when I return to my local installation the extensions will sometimes disappear. Not sure why it doesn't always reinstall though. Sometimes won't readd the missing extensions in time, so it gets removed. When the extensions are without the keypair, the local machine can occasionally readd the missing config and keep the extension installed; other times it won't and the extension is removed. Local machine logs from yesterday: Extension config history: Remote removes extensions: Remote readds extensions, but not marked as installed: After I reinstall the extensions locally: logs from a repro today: Extension sync history: Removed extensions: Readd extensions:
Thanks for logs and info. Reopening for investigation.
I am able to reproduce this with following steps: 1: Install GHPRI pre-release extension and sync .dev: Trigger Sync. Note that this is a builtin extension here. 2: Trigger Sync - Make sure GHPR extension is installed. 1: Uninstall GHPRI extension 2: Trigger Sync - Make sure GHPR extension is uninstalled. .dev: Trigger Sync. Make sure GHPRI extension exists in builtin extensions. 1: Trigger Sync. Nothing changes. 2: Trigger Sync. Nothing changes. This step and above step are important because, even though nothing has changed, these machines update their last sync state to have GHPRI extension has builtin extension. 1: Install GHPRI pre-release extension and sync 2: Trigger Sync GHPRI extension is not installed. Come back to Desktop 1: GHPRI extension is removed.
Improved extensions merging to make sure the builtin extensions are handled properly.
Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.
run open in your favorite browser add a breakpoint at notice how the breakpoint is hit every few seconds this ends up transmitting data from the server to the client
A heartbeat fires every 5 seconds so we can detect when the pty host becomes unresponsive: Open to ideas on how to improve this but it's working as designed right now.
Idea: determine if the pty host is responsive or not on the server process only communicate the status of the pty host from the server to the connected renderers when the responsiveness of the pty host changes.
That should work, we only care about the event when it's going from unresponsive-responsive anyway.
Seeing 2 test failures today for integration tests in Web ():
feel free to skip them if needed, they're known to be flaky. This was my top priority for debt week but it was completely consumed with the settings sync preview.
you mean flaky in general or only for web?
Flaky in general, it seems especially on web though.
We can leave them running, I am not seeing them failing often, just found this one. It is not something to look at now, but eventually. Will revisit if I see this again more frequently.
ok seeing them fail again today, pushing to disable them when running in web via checking for . Your tests seem to have a questionable use of , I see one error being that is called multiple times. Why do you not rewrite to use async and promises?
Another one:
I ended up disabling them all for web:
Maybe this has now leaked from the tests into the code itself. I'm creating a new terminal within an extension using the API and give it a pseudo terminal. Sometimes the terminal is shown but no output is displayed and does not work. But I can also see no error or trace. This happens for me in vscode 1.44.2 using linux.
Is this still an issue?
VSCode Version: Code 1.15.1 (, 2017-08-16T18:07:25.676Z) OS Version: WindowsNT x64 10.0. Extensions: ExtensionVersion ------ overtype0.2.0 python0.7.0 theme-dark-plus-contrast0.1.101 cpptools0.13.0 monitor-file1.0.1 (4 theme extensions excluded) Steps to Reproduce: there is such line in a *.bat file rem set SERVERVERSION=5.7 cursor on it, and uncomment with "Ctrl+/" expected: set SERVERVERSION=5.7 actual result: REM rem set SERVERVERSION=5.7 Looks like uncomment is unnecessarily case-sensitive. It should uncomment despite it is 'rem' or 'REM'. I don't care whether with next "Ctrl+/" it will add Upper-Case 'REM' instead of 'rem' - it is not problem. <!-- Launch with to check. --Reproduces without extensions: Yes/No
<!-- 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 <!-- 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: Version: 1.74.3 (on ) OS Version: Linux, Gnome, Chrome Steps to Reproduce: an image in the media-preview extension click on the image and select copy to paste the image somewhere Nothing happens. Also note that Cut and Paste make no sense here as menu items. I assume that these are just the default context menu options from - perhaps these should be removed entirely from the preview extension and we could manually implement copy?
Hey I would like to work on this issue.
assign this to me
Are these the correct steps to reproduce the issue? I'm unable to verify it on my mac. Can you provide more information? I previewed the image and then copied and pasted it. <img width="950" alt="image" src="https://user-"
I would like to wokr on this issue.
I would like to try solving this issue.
You right-click an image and select "copy", then you click a folder in VSCode's explorer and select "paste". The image should be pasted into that folder but it doesn't.
I would like to work on this issuse. here, I tried to copy and paste (Ctrl+v) it. But it doesn't work. https://user-
After a day of researching, I think I can explain why this issue happens.
Basically in the core webview module (see ), three default context menu actions (cut, copy and paste) are to the menu, which are accessible throughout all webviews, and happens to be one of them, so after you right-click anywhere in a image previewer, you will be able to see these three actions. After you clicks one of these actions, the editor will post an message to the image previewer, telling it to cut, copy or paste. If there is a correspondent listener for this perpose, the image will be actually cut, copied, pasted, but unfortunately there is no such listeners defined. This problem has existed for quite a bit of time. The original modification that cause this problem is from here . It is origianlly meant to allow users to copy selected text within an extension's README page. There is also a closed issue that describe such issue in . Personally I think providing action cut, copy and paste for all webviews is a little bit hasty, since there are not universally required for each webview, and even some of them need, the subject to be copied may vary from different webviews, or even different places in a same webview. I can solve it by disabling the default actions first (there is a option to achieve this), then let image previewer to implement its own copy and cut functionality, but I think this is rather a quick and sloppy solution. There should be another better way to solve this issue.
What about adding a handler :
Here's what I tried VSC insiders without any extensions Open a folder with a .png file Open the png file in vscode Right click and select Paste into folder in vscode = does not work Paste into markdown cell in vscode = does not work What am i doing wrong?
Pasting image data into folders isn't supported by VS Code. Pasting into a notebook cells works fine for me though. To verify though you can also paste into an external image editor
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.75.1 OS Version: macOS 12.6 Steps to Reproduce: any CLI utility that displays a loader animation that uses braille, such as every step of the animation, you should see an array of dots that don't use up a full square space, but leave some blank space and look like a "snake" (this works fine in Windows) This is how it looks in other terminals such as iTerm2 or <img width="33" alt="image" src="https://user-"This is how it looks in VS Code (i've tried changing fonts, it doesn't help) <img width="31" alt="image" src="https://user-"This is the character: On Windows version of VS Code, this behaves correctly on macOS, instead of white space it shows circles with transparent filling
any news?
Hello, it's been half a year and it's been tagged many things, I'd love to know if this is being taked into consideration since it's very bad UX
Interesting that this works on windows but not mac.... This issue reproduces in the monaco editor
it looks like for we are using the python3.9 spinners
I found this - have you tried other fonts?
i found out that it's Chromium's fault, the issue happens in Chrome for macOS and every other child browser, but doesn't happen in Firefox nor Safari, so I opened a bug report there
Looking at it appears that whatever font is being fallen back to is adding the empty circles?
If that's the case the fix here would be one of: Try falling back to something like in the font family setting, eg. Support custom glyph rendering for those characters, I really would rather not supporting this unless we absolutely had to though.
This bug is still present in Version: 1.84.2/macOS 14. I tried using Symbola, SF Mono, Menlo and Monaco as the main fonts, without success.
I double checked today and it looks like Chrome Version 127.0.6533.89 renders Braille characters without hollow circles on MacOS. <img width="952" alt="Screenshot 2024-08-02 at 10 50 29" src=""(I have a macOS app that's rendering the top bar differently)
So... I spent a bit too long today investigating what was happening here and here's how I've resolved this issue for myself: Before / After <img width="163" alt="Screenshot 2024-08-07 at 22 22 32" src=""<img width="163" alt="Screenshot 2024-08-07 at 22 22 42" src=""In case the diagnostic steps are useful to someone, here's the portion of my search tree that resulted in this solution / bodge.... I looked through my macOS font book for which fonts were providing symbols for (U+2879) and ended up finding "Apple Braille" and "Apple Symbols". "Apple Symbols" had the wrong amount of whitespace when I set that as the fallback font and the "Apple Braille" looked like a drop-in replacement. Turns out, Apple Braille looked different in the OS's Font Book vs in VS Code. The reason for this ended up being that Apple Braille has multiple variants and... for some reason... the version of Chromium being used in VS Code uses either Outline6Dot or Outline8Dot variants by default (these have the hollow/outline circles) instead of the Regular variant which does not have hollow circles. I assume this has to do with the font-renderer-level behaviour. None the less, the of the specific font variant within the "Apple Braille" family that I want to use was "AppleBraille" and adding that to the stack makes it use the correct-for-me variant of the OS-provided Braille symbols!
VSCode Version: 1.8.0 OS Version: Windows Version 6.3.9600 (Windows 8.1 Enterprise) Steps to Reproduce: High Contrast on Windows VS Code, look at the glorious High Contrast theme a different theme, because you would rather work in that VS Code, your theme choice gets overridden. Essentially, I'd like to be able to disable the auto-detection of the High Contrast theme I'm using in Windows via some setting, because while I prefer Windows in High Contrast mode, I dislike looking at VS Code's High Contrast theme.
I wholeheartedly agree. I'm okay with the default being auto-detection, for the accessibility scenario, but it should definitely be possible to disable this functionality via settings.
An option makes sense to me. If someone wants to provide a PR
Done,
Could you please re-open this issue? Unfortunately, my PR only affected the high-contrast swap that occurred when changing Windows theme while VSCode is open, not the initial theme that is set when VSCode starts, or opens a new folder. I have a new PR that completes the fix.
[x] To verify (Windows): Normally VS Code switches to HC mode automatically when windows is running in HC mode. Verify this new setting can be used to prevent this automatic switch from happening (both on startup as well as when Code is running and you change HC mode in Windows).
<!-- 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. --- VS Code Version: 1.56.1 OS Version: Windows Steps to Reproduce: a (reasonably long) markdown file and scroll down a bit. the dynamic preview for the markdown file. It opens the preview at the top of the file, but should open it where your text editor (containing the target markdown) is scrolled to. This is not adjusted until the user scrolls or resizes the window. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/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. --
One desired behavior of writing a custom is that when the user accepts a given suggestion, the provider is immediately triggered again for another suggestion. We need to track when users accept (or reject) suggestions so that we can measure improvements that we make. Without using the experimental API, the best way to track if a completion is accepted is to provide a value for the field in . When supplying a command, the retriggering behavior is disabled [1]. As a workaround, I tried to indirectly trigger an inline completion via the command , however, it does not work (not sure why, this does work with my unit tests but not when I try to call it from a command I supply via ). [1] I believe this is the code block that retriggers automatically, one can see that the retrigger only happens if the command is the default command:
Note is related.
Note that [1] points to the autocomplete source code, not the inline suggestion feature. I'm not aware of any disablements.
Ok, that's incorrect -- however, adding a 'command' to disables the automatic retrigger.
Place the cursor after and press enter. Then accept. Notice that is not suggested.
That monaco repro / editor is really cool
Thanks! The best thing is that you can use the "Monaco Editor Playground" launch config in the VS Code repo to debug the playground example :)
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:
<!-- 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. --- VSCode Version: 1.44.2 OS Version: macOS Steps to Reproduce: an extension providing in-editor comments via the comments API an editor containing comments the terminal at the bottom a command which causes the comments to be updated. For our comment provider, we automatically detect comments associated with your source control commit. So, for example, use the command line to checkout a different commit. comments will change, causing some of the previous comments to be hidden. When this happens, the editor is focused. This causes you to lose focus on the terminal. The end result UX is that you're typing commands in the terminal, and your focus gets stolen to an open editor for no visible reason, making it annoying if you wanted to keep running more commands. Notably, this depends on the way the comments API is used. I believe many comment providers do not respond to source control, and require clicking a button to activate/deactivate, so it's likely that's why this hasn't been reported before. For us, this is really annoying, and I could see this hitting other providers in the future. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No, because you need an extension which contributes via comments API
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.562 --- <!-- score: 0.513 --- <!-- score: 0.501 --- <!-- score: 0.493 --- <!-- score: 0.492 --<!-- potentialduplicatescomment --
<!-- 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.86 OS Version: macOS 14.3 Steps to Reproduce: run profile programmatically with isDefault = false seems to restore the previously selected state "isDefault", or if there is none, makes the first profile "Default". behavior works for me. But unfortunately after the profile is created and before its state is changed manually in the UI, it reports isDefault = false. Expected: isDefault matches the UI state at all times. //
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This works for me, but note that the synchronization of the new profile is asynchronous after its creation. This is intentional because it's common for extensions to create a profile and then set its properties, like we don't want to cause that to override what the user previously set (especially since making isDefault a 'live' property was a later addition to the API). For me, adding a listener like triggers shortly after its creation
Fascinating! I can't reproduce this bug today.
It seems like there is some inconsistency here
A simple snippet like this surfaces the issue for me: The console is saying And the GUI has run 1 as (Default)
Looks like this is working now:
Add the possibility to persist the content hover sizes
To test, please read the following. Currently the implementation of the persistance mechanism of the content hover works as follows: The content hover has a default maximum size which is defined as follows: const defaultMaxHeight = (().height / 4, 250); const defaultMaxWidth = (().width 0.66, 500); Whenever the content hover is resized, the last hover dimensions are stored. Next time the content hover is shown, the maximum dimensions are updated as follows: const currentMaxHeight = (().height / 4, 250, lastHeight); const currentMaxWidth = (().width 0.66, 500, lastWidth); The content hover is rendered naturally within these constraints. If the lastHeight and lastWidth are smaller than the default max dimensions, then the current max dimensions are unchanged. Therefore the next rendering of the content hover will be the same as the initial rendering. Test that the content hover works according to these constraints. There is some discussion going on about how to better implement a persistance mechanism. We could also persist the size for example on a per-token basis in the editor. Let me know what you think is best!
Do you have an example of how it should work? Regardless of how I resize it, it is not remembered.
You may see an example of how it works here. The content hover is resized to a bigger size in the gif. The current max width is increased to a higher value and at the next rendering of the content hover, the widget takes on a bigger size. To see this behavior you should choose a content hover where the content does not fit in the visible widget, where there is a horizontal scrollbar. I opened an issue for persisting the content hover on a per-token basis here: as an alternative idea.