jiebi/CodeConvo huggingface dataset:
This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out).
There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though. Regardless, cheers and thanks for the work!
the calling process is waiting because it is not clear how long data is being sent to . It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "" at the end?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable it will always win over the guessing This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the command would detect. On Windows I see the  command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.
Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?
Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way
<!-- 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.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR.
I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at .
I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up!
I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- 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!
/verified
Just asked hi: ! Expected: ! Version: 1.88.0-insider (user setup) Commit: Date: 2024-03-25T05:49:32.344Z Electron: 28.2.6 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. GitHub Copilot Chat v0.14. (pre-release)
because of
To verify configure have a very wide view port ask AI to change some code make sure the input widget is full width of the zone widget
cmd+i now cmd+backspace invokes instead of deleting the line in the text editor The ChatWidget is writing its context keys to the editor's ContextKeyService, so we need a scoped CKS at some point, either inside the ChatWidget or outside in the inline widgets
pushing a fix to use a scoped CKS but this does look like debt. Isn't a better fix to reset context keys when hiding/dispose the chat widget?
I don't think those context keys should be applied on the editor at all, they are intended to just be active inside the widget's dom tree.
VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.
Issue Type: <bBug</bthe integrated console viewlets to a vertical layout the viewlet narrow When wide enough: ! Once narrowed: ! Expected result: Debug Console search bar shrinks/hides itself in order to show other tabs first (like in the first screenshot). The 3 dots "works", but is, at least in my opinion, more annoying than not being able to search in the Debug Console when the viewlet is narrow. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
The min width is 300, I think that can be narrower. The problems view filter input goes into the body when the view is too narrow, which is sorta cool <img width="571" alt="image" src="https://user-"but I won't implement that right now
Actually it was easy to opt into that. I tweaked the min widths and also when the pane is narrow, the filter box will move down into the body
Holy, I forgot about this issue! Love the idea of copying the behaviour of the Problems tab! Excited to try it on Insiders :) Thanks !
!
updated Insider's and the problem remains
I think this is the same as We will need to always send the exit code and have it get evaluated on the renderer against the extracted command name to fix these problems.
sometimes reproduces on mac
you can check if this is the same issue () by running a command a few times and then when is run if it's a single entry or multiple in the output.
interesting to me that it allows repro on linux/WSL and does so inconsistently on mac. here's linux: !
K, let's try understand this a little better then, that shouldn't happen as the initial history id is 0:
Oh I figured out when it reproes on mac - if you run the same command in a different terminal, then the second and beyond ones don't have an exit code
Running the command again in the terminal where you first ran the command works every time and does not repro on mac. So mac steps are: in terminal 1 - again in terminal 1 - in terminal 2 - Linux: a terminal and run any command - placeholder decoration shown for the first one regardless of exit code
It would be nice to fix this since is the default shell used
Think I see the problem, PR incoming.
Repro: Add a long string item to a list setting, e.g., . Try an item without spaces (like a really long identifier) or with spaces. Expected: Overflow of the item is handled somehow, e.g., elision, broken to separate lines with enough spaces. Actual: The item text overflows horizontally and vertically (depending on spaces in the item), overlapping other UI elements. E.g., <img width="854" alt="Screenshot 2024-02-27 at 11 31 47" src=""<img width="815" alt="image" src=""Version: 1.86.2 Commit: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Embedder: <!-- generated by web issue reporter --
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.
One way of resolving this would be repeating the position information when I press any of the commands, even if there is no change. Another possibility would be to prevent the widget from refocusing when I am in the first / last element, and I try to move beyond that element. In that way pressing the next command will not produce any feedback if I am in the last one, and the previous will not produce any feedback if I am in the first one. Does it make sense? In any case, this would be a refinement, not something that would prevent someone from using the feature. Originally posted by in
Something else to consider when fine tuning the responses. Right now, position information is announced using an alert in macOS, and a status message in Windows. This is a situation where it makes sense to use an alert in all platforms so that screen readers prioritize this over other events. For example, right now JAWS is announcing position information after reannouncing the widget.
Huh, I'm using for all platforms here which appears to be platform agnostic I think it might just be a JAWS issue - does this repro when using NVDA?
It doesn't, but NVDA handles aria-live differently. You may be right dough. I'll debug NVDA on Monday and we'll know for sure which event it is seeing. JAWS may be simply prioritizing the focus event.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Focus an accessible view for which there are several elements (like chat responses or notifications). Verify that if you are on the first or last element, pressing next or previous does not result in repeated alerts. it should not notify the screen reader user as nothing has changed.
Note to verifier there's an issue to disable these actions when they cannot be taken, which is the better fix.
Verified. With NVDA, if I press enter on the Next button while on the last chat response, the focus goes back to the response text instead of staying on the button, though that might be by design.
Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.
Type: <bBug</bAlt+C or Alt+W or Alt+R Now if area with code is in focus, broken search parameter selector will appear without search panel itself. If terminal is in focus, search panel will appear. I think it is completely unneccesary to intercept alt+c globally when no search panel is opened. In my setup it leads to conflict with alt+c fzf's key binding in terminal. VS Code version: Code 1.86.2 (, 2024-02-13T19:41:37.860Z) OS version: Linux x64 6.7.6-arch1-1 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ vscode-nginx-conf0.3.2 vscode-cython0.3.10 vscode-docker1.29.0 autopep82023.8.0 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.2 jupyter2024.1.1 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 cmake-tools1.17.17 cpptools1.19.4 cpptools-extension-pack1.3.0 rust-analyzer0.3.1860 cmake0.0.17 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This is feature - it influences bahavior of Add Selection To Next Find Match (<kbdCtrl</kbd+<kbdD</kbd) and Select all occurrences of current selection (<kbdCtrl</kbd+<kbdShift</kbd+<kbdL</kbd). However not sure how regexp is useful here, except it would be applied for next find.
Can you share a screen recording? I'm not sure if I understand what you're talking about.