jiebi/CodeConvo huggingface dataset:
<!-- 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.51.1 / 1.52.0-insider OS Version: Ubuntu 20.04 / Windows 10 Steps to Reproduce: 4x spaces at the beginning of a line multiple cursors on that line enter Expected: Insert newline at each of the positions where cursor is present Actual Behavior: Inserts newline only at the first (NOT the left most) cursor position (Let me know the relevant settings values required) Addiditional info: I use tabs (width of 4 spaces) for indentation for formatting ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I think this might be caused by one of your installed extensions. Here it is on my machine: ! To validate this, could you please : Run the command Developer: Toggle Keyboard Shortcuts Troubleshooting This will activate logging of dispatched keyboard shortcuts and will open an output panel with the corresponding log file. You can then press <kbdEnter</kbdand check what command is invoked. If you are having trouble understanding the output, please feel free to paste here and I can help decipher it for you.
Here is the renderer keyboard troubleshoot log: Also, the I have disabled all the extensions. And, now, I can reproduce this with the latest stable too and in Ubuntu.
It is also not exclusive to the multi cursors created using keybinding. I can reproduce this by placing mulitple cursors created using the too.
From the keyboard log, I can confirm that nobody is "stealing" Enter via keybindings. But there is another way that extensions can intercept that, via our command. That is the way in which intercepts Enter. Does this reproduce when disabling all extensions? Press and then choose !
Hey , In all of my previuos posts I have made sure that I have disabled all the extensions (by running the command that you have mentioned) and also, at the end of each of my posts I have explicitly stated that I had disabled the extensions. Can it have anything to do with my settings related to tabs?
May be, inspect my settings here: (which has ) and, try to reproduce the issue by applying the exact same settings (copy paste my ).
Also, , Please carefully go through each of the above posts. It seems like you are not reading all the comments. It will save me from repeating the same thing again and again. Thanks.
Thank you for your patience, with your settings, I could finally reproduce. I missed the fact that the editor is configured to use tabs and I believed you might be using vim due to the block cursor in the GIF. You can workaround by using .
Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
I was trying to understand the usage of and the lifecycle of actions created while creating it. I think this originated with the terminal, so looked at the terminal code, but it seems like the problem isn't solved here either. instantiates some Actions which extend Disposable, but they are never tracked or disposed. The ActionViewItems returned from are apparently owned by whatever calls that and get disposed, but not these extra actions that we have to create. So, one solution would be for them to be owned and disposed by although that feels unexpected. But otherwise, there isn't a technically correct way for the code in to know when they should be disposed. Wondering whether I'm missing something or if you have any thoughts.
I spent some time investigating this and the issue is that we use in some places and in others. Only the latter is disposable. This would be a bit involved to rework
VSCode Version: 1.1.1 OS Version: Windows 7 x64 It would be great if holding the key + spinning the mouse wheel would increase / decrease the VS Code zoom value.
I am not sure we want to zoom the entire UI when you use the mousewhell, I would expect only the editor font to increase. Thereby moving to
yes you are correct.
Didn't this feature used to work, or am I just failing to remember correctly? I was just going to report this as a bug, but maybe it never actually worked. I jump between different computer setups fairly regularly, so maybe I am just not remembering. Anyway, I found this dupe, and didn't want to submit a new issue. Thanks for your efforts By the way, I think I would expect this feature to work the same way that and work. VSCode's UI deviates from many other UIs in that it scales well, so I think I'd expect this to scale the entire UI consistently with the keyboard commands.
If this zooms only the editor, shouldn't it be seperate from ?
I would expect and to zoom only the editor. That behaviour would be consistent with most (all?) other editors and apps. Scaling the entire interface is an accessibility feature IMO, so maybe it doesn't need to use such a commonly used shortcut by default? Beyond Ctrl+Wheel, pinch to zoom should also zoom the editor.
Can this be disabled? I'm constantly accidentally zooming my text to a tiny size when I ctrl-click and accidentally brush my fingers over the trackpad.
This is disabled by default, so you must have enabled it in the past --
Thanks - I came here to vote for this feature, and it turns out I just had to turn it on! Shouldn't this issue be closed?
:+1: Closing since this is implemented. The feature is disabled by default due to numerous issues reported by users using touchpads where we begin to unexpectedly zoom in/zoom out when e.g. using ballistic scrolling and pressing the ctrl/cmd modifier. The root problem is that we cannot differentiate events coming in from a real mouse with a wheel from those coming in from touchpads / trackpads.
<!-- 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: 1.90.1 x64 OS Version: Ubuntu 24.04 (Updates 14 Jun 2024) I get the error on a fresh installation of Ubuntu 24.04 and VSCode 1.90.1 Everything works fine with VSCode version . Steps to Reproduce: latest version of Ubuntu 24.04. command. command.
In my case the issue occurred when doing , also on Ubuntu (20.04) and also on vscode 1.90.1 Here is a temp workaround to revert to vscode 1.89.1, if that's useful to anyone:
Hi Having same issue on remote VM Ubuntu 20.04 Install errors with Solved by using the flag
This is a continuation of to implement a proper fix in the runtime or application as necessary. Known data points: SIGTRAP when gpu tried to access resource bundle to load a label for assigning display name when computing vsync interval using the internal implementation rather than the gl extension. Also name from resource bundle is only requested for builtin-displays and not virtual ;l=449-456 Using gpu codepath from main process serves as a workaround. Debian package on the same system didn't trigger the crash codepath, very likely a different gl backend was used. Next steps: 1) Compare gl initialization trace between snap 1.89 and 1.90, using the following categories 2) Compare gl initialization trace between debian 1.90 and snap 1.90 3) Confirm if resource bundle access from gpu process is necessary moving forward.
This turned out to be a regression from https://chromium- which causes the gpu process when using the software display compositor to reach into the resource bundle. Before the CL, gpu process will not call into only the main process did.
is there something to verify here?
This is related to the candidate issue and I was just using it to track fixes. Nothing particular to verify for this particular issue, maybe confirm the checksums for both branches are same vs
Ideas to experiment with: Don't shrink a cell while it is executing -less jumpy as output is replaced change the anchor heuristic from "if the resizing cell is partially visible" to "if the cell's output will shrink out of view" Anchor to a focused cell if the focus is in the cell's editor cc
For the new heuristics we are adding (growing upwards or downwards), they should probably be interrupted the moment users start to scroll, for example, if I scroll manually to a specific position, I would expect the scroll top not to change.
I disagree - That could mean if you have a cell focused and anchored, and you scroll to get it higher in the view, it would then start getting pushed down as the previous cell grows.
If I scroll to get it lower in the view, as I want to read the cells above, and since it's still in the view and focused/anchored, the cells I was reading will then pushed upwards, right? This feels unnatural compared to how browser handles scrolling or Terminal. Terminal scenario might be closer to this, as it usually sticks to the bottom when the shell is streaming outputs, but the very moment we scroll upwards, it stops sticking to the bottom.
Select a portion of a variable name Press F2 Previously, the rename widget would open with the same substring highlighted. It's helpful to quickly rename one subword in a variable name, for example. Now, the full contents of the input in the rename widget are highlighted initially. I don't know who owns this but it looks like you touched it recently
<!-- 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!
Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified
This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.
When exactly does run, is it only when an item gets highlighted in the menu? Can't tell from the docs. I only need to generate for the completion item the user ends up applying -- doing it for other items is unnecessary work that's bogging down the extension host, and I will have to implement yielding. I assume no one would need to generate before a completion item is applied? Is there any kind of completion applied event we can hook into to work around this for the time being?
That's exactly what is about . Today, there is no guarantee that is ever called because its original design is to provide data for the suggest details widget. However, we see that (amongst other things) are computed during resolve and leads to subtle bugs (because don't always call resolve or always await it) Well, is the problem if you do not generate them upfront. select suggestion synchronously inserts the string starts for additional text edits continues to type quickly and all over the place -call eventually returns but it is unclear if the edits are still valid because the state changed many types in-between Solutions: Won't work because in JS you cannot wait for another "thread" or "process", the world always keeps turning Implement a full -solution because this is two entities "typing" concurrently in the same document. However, it will feel awkward because the user doesn't expect to be such a scenario. approach that tries to apply additional edits if possible but inserts the "main edit" (insertText) always synchronously. () "if possible" is currently defined as "no edit has occurred before the first additional edit". That works well if you use additional edits for things like imports or prefixes (which is the indented use-case) but won't work if additional text edits change the main edit, like appending a call-operators with arguments etc
I mean JS can't block but ignoring typing while awaiting is possible -- I was imagining that VSCode would keep the completions menu open and ignore any typing until is resolved and all text edits applied for the accepted item. Obviously this would be bad if resolving takes a long time, but the API has cancelation tokens already, so the UI would just need to show a spinner/cancel icon, and also cancel if the user presses ESC or navigates to a different editor, for a decent UX.
I think this would be less confusing for users too; it's the only way it would be clear when VSCode is completely done applying the completion. I think many users would be confused if imports usually get but not when they resume typing too soon. FWIW I can syncronously generate the additional text edits I need, so I'd be happy if there were an API to synchronously generate them when the completion item is accepted. I know not everyone would be able to generate them sync though.
Also I know my questions may have seemed redundant, but I hadn't seen anyone on this thread point out that it would be ideal to avoid ever computing additional text edits (or even the primary insert text) for unselected completions. Since can get called before any item is accepted (I assume, since it seems to be for showing additional details in the menu), I'd think any solution via could still result in unnecessarily generating additional edits that are ultimately discarded.
The golden rule is that "you can always type inside the editor". Ignoring typing is not a good solution and will bug users. Just think of quick suggest and auto accept characters - you don't want the editor to stop typing just because an extension is taking a little longer (+50ms). To be precise you should have written "typing at or before the offset at which additional edits are going to happen" I honestly think the majority can generate them synchronously but this happens in the extension host process or the language server process, and all of that might happen on a different machine and there is no way to synchronously transport that into the UI.
re with the current changes you should be able to have a "simple insert text", say , and compute an additional text edit, like , that goes in front of it so that you eventually have . Right? Or am I missing something?
that might actually be a good idea ;-) In practice though, we might need to revisit the way the principal TextEdit is computed (i.e rewrite a bunch of stuff from upstream JDT)
I get the desire to be able to always be able to type inside the editor and agree that's an important principle. The only reason I think this case is an exception is that: The user would probably want to wait for all edits to get applied anyway.
Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.
so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected
I've had an SSH window open in the background and noticed that it keeps going through reconnection. Looking at the logs, it looks like vscode is often triggering reconnection, even though nothing strange is going on with my network, as far as I know. Noticed this at home and also the office network. This is the log from vscode. The SSH log doesn't show anything unusual before the resolver is invoked again. Has anything changed here lately?
Sorry this issue fell through the cracks. Are you still running into this?
Yes
Do you perhaps have a log with tracing enabled? The reason in the original log appears to be timeout. That is triggered here -- So the conditions are: a message was written to the socket 20 seconds ago and the server side didn't acknowledge it (and) no data was received from the server within the past 20 seconds (and) no previous timeout event was fired within the past 20 seconds (this just avoid sending many timeout events) (and) the renderer process appears responsive (Just speculating) I think we have fixed something in the terminal land and we now no longer send any data in an idle window. Could it be that your window becomes idle and the connection is dropped by SSH? (I believe due to some terminal heartbeat mechanism there was always data being written every 5 seconds, but now that is no longer happening).
Well, now I can't repro it.
I've more logging via . Please keep an eye out. In case you hit this again, the logging will have more data.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Finally got it
It seems like the log message you touch didn't show up there. But, it does show up in an earlier reconnection in this window (before I enabled trace logging). So I'll just share the full logs This shows a window that was mostly idle with 2 reconnections, the second one had logging at the trace level enabled
Here's my interpretation: the management connection timed out at due to our own timeout logic. We wrote one message and that message didn't get acknowledged within 20s by the server. As an observation, the connection didn't receive any bytes from the server within 320s (5 minutes).