jiebi/CodeConvo huggingface dataset:
Code change:
logMessage: l.logMessage } ); <del> this.debugService.addBreakpoints(uri.revive(dto.uri), rawbps); </del> <ins> this.debugService.addBreakpoints(uri.revive(dto.uri), rawbps, 'extension'); </ins> } else if (dto.type === 'function') { this.debugService.addFunctionBreakpoint(dto.functionName, dto.id); }

Related discussion:
text: When going over our telemetry for debug actions we have the ability to track usage counts of debug actions triggered from keyboard shortcuts and commands, as they execute commands which we emit telemetry for, but we don't seem to have telemetry in place for breakpoints set in the gutter (click or context menu). This is unfortunate as my hypothesis is that the majority of breakpoints are set this way. Ask Add ability to track breakpoint toggles (add/remove/change) from Gutter click Add ability to track breakpoint toggles from gutter context menu
would you like to contribute a PR for this? It shuold be fairly simple and you already have the nice code pointers.
I'd be happy too, but we should land on an agreement on how to implement it. What's the best approach? 1) Add telemetry directly to the gutter actions 2) Re-wire the gutter actions to execute a command instead?
for the best approach let's first see what you want to get exactly? total amount of all breakpoints set (including the gutter) grained events for breakpoint setting based on the way the user initated that aciton In case of 1 we should just add a telemetry ping in the  since everyone should go through there In case of 2 depends on how fine grained you want it, if for every place then we should add an argument or something like that in the addBreakpoints method and then also report that to telemetry.
I'd like us to be able to contribute a source/initiator to given breakpoint, so we can get an UI usage distributions, etc.
I suggest the following Add a third argument In the implementation of that method use the telemetry service to report the appropriate event with the context. And you should nicely get all the errors of all the callers of , simply pass different string context for each caller and you shuold be good to go. Let me know if you have any questions
Cool, I'l see what I can get cooking!
Removing my assignment for this. feel free to assign me back if you do not have time to tackle this and if we need this for August
hey, would you still like this? If yes I can also look into it in October
I'd still like to do this to get my hands dirty.
cool, unasigning myself and let's leave it for October
Verified by code review, adding verified label
Code change:
currentHistoryItemRemoteRef?: ISCMHistoryItemRef, currentHistoryItemBaseRef?: ISCMHistoryItemRef ): number { <del> const getHistoryItemRefPriority = (ref: ISCMHistoryItemRef) => { </del> <ins> const getHistoryItemRefOrder = (ref: ISCMHistoryItemRef) => { </ins> if (ref.id === currentHistoryItemRef?.id) { return 1; } else if (ref.id === currentHistoryItemRemoteRef?.id) {

Related discussion:
text: Testing I wonder how well it scales to show multiple tag icons, why not find a new icon that resembles multiple tags: !
I like that. Adding as that would require a new Codicon...
!
Or just show one tag in the row, but show all of them on hover like you do now.
How about showing one badge pert type (ex: branch, remote branch, tag) and a number indicating how many they are. That way there is no need create new icons that would cause further confusion.
I am actually not entirely sure what value there is to distinguish 1 tag from N tags? I would just show 1 icon if there is any tag.
Seems reasonable. Let's start with that and see how things go.
Code change:
import { ICommentThreadChangedEvent } from 'vs/workbench/contrib/comments/common/commentModel'; import { CommentMenus } from 'vs/workbench/contrib/comments/browser/commentMenus'; import { ICellRange } from 'vs/workbench/contrib/notebook/common/notebookRange'; <ins> import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService'; </ins> export const ICommentService = createDecorator<ICommentService>('commentService');

Related discussion:
text: Issue Type: <bBug</bI am not sure if this was something I accidentally enabled, but it looks like it appeared with the latest VSCode version. Hovering over lines now shows a + symbol in the gutter, and it's highly distracting. Is this a bug, or can it be disabled? VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ vsc-material-theme33.2.0 vsc-material-theme-icons1.2.2 prettier-vscode9.5.0 copilot1.19.5865 gc-excelviewer4.2.54 vsliveshare1.0.5561 material-theme3.13.25 (5 theme extensions excluded) </details<!-- generated by issue reporter --
https://user-
The "+" on line hover indicates that you can leave an extension comment on that line. We used to only show the "+" when you hovered over the gutter itself, but now we show it over the whole line so that it's easier to find. This means that you have an extension installed that let's you leave comments in files. The extension might have a way for you to disable this. I would like to add a feature to VS Code that just disables all commenting. Assigning to June to work on this.
great to know, thank you. i'll see if I can figure out what the extension is and will disable it in the meantime. it's very distracting - can you consider an option that preserves the old symbol behavior where it is only displayed when hovering in the gutter? comments are useful but there is now too much distracting movement on screen. it also shows in Zen mode which I believe is counter productive.
Good point, this should be disabled in Zen mode.
Bit more thoughts on this: Maybe a setting wouldn't be the right fit for this, since a user might forget that it set it and forget about it... or worse, it could be set at workspace level and the user never even knew it was set. Maybe runtime UI state would work best since it isn't as sticky.
Code change:
import { ICommentThreadChangedEvent } from 'vs/workbench/contrib/comments/common/commentModel'; import { CommentMenus } from 'vs/workbench/contrib/comments/browser/commentMenus'; import { ICellRange } from 'vs/workbench/contrib/notebook/common/notebookRange'; <ins> import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService'; </ins> export const ICommentService = createDecorator<ICommentService>('commentService');

Related discussion:
text: Additionally, it would be great if there is some indication that comments are indeed hidden as opposed to the current file not having any comments at all. What do you think?
Having some indication that there are comments, they're just hidden, makes sense. We should do this. We can start with some runtime UI state and add a setting later if there's a desire for it.
Code change:
} } <del> private _getPicksFromMatches(matches: FileMatch[], limit: number): (IQuickPickSeparator | ITextSearchQuickAccessItem)[] { </del> <ins> private _getPicksFromMatches(matches: FileMatch[], limit: number): (IPickerQuickAccessSeparator | ITextSearchQuickAccessItem)[] { </ins> matches = matches.sort(searchComparer); const files = matches.length > limit ? matches.slice(0, limit) : matches; <del> const picks: Array<ITextSearchQuickAccessItem | IQuickPickSeparator> = []; </del> <ins> const picks: Array<ITextSearchQuickAccessItem | IPickerQuickAccessSeparator> = []; </ins> for (let fileIndex = 0; fileIndex < matches.length; fileIndex++) { if (fileIndex === limit) {

Related discussion:
text: ! quick search. over a file name pick item and click the button to open the file. happens :bug:
Code change:
// --- from extension host process $tryShowTextDocument(resource: URI, options: ITextDocumentShowOptions): TPromise<string> { <del> const editorOptions: IEditorOptions = { </del> <ins> const editorOptions: ITextEditorOptions = { </ins> preserveFocus: options.preserveFocus, <del> pinned: options.pinned </del> <ins> pinned: options.pinned, selection: options.selection </ins> }; const input = {

Related discussion:
text: For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !
Code change:
this._labelElement = document.createElement('div'); this._labelElement.classList.add('monaco-button-label'); <del> this._labelElement.tabIndex = -1; </del> this._element.appendChild(this._labelElement); this._descriptionElement = document.createElement('div'); this._descriptionElement.classList.add('monaco-button-description'); <del> this._descriptionElement.tabIndex = -1; </del> this._element.appendChild(this._descriptionElement); }

Related discussion:
text: down in the button, then move outside the button and mouse up You get this border: ! Weirdly enough that's not the same border you get when tabbing onto the button: !
Weird, by performing this gesture you get to focus the inside the button itself. Will see what the best fix is.
It's a bug in the as it does not happen with the "Publish Branch" or "Commit" buttons.
Code change:
<key>list_paragraph</key> <dict> <key>begin</key> <del> <string>(^|G)(?=S)(?![*+-]s|[0-9]+.s)</string> </del> <ins> <string>(^|G)(?=S)(?![*+-&gt;]s|[0-9]+.s)</string> </ins> <key>name</key> <string>meta.paragraph.markdown</string> <key>patterns</key>

Related discussion:
text: VSCode Version: Code 1.18.0 (, 2017-11-08T21:19:36.079Z) OS Version: Windows_NT ia32 6.1.7601 Lists shift the indentation by the level of depth in the list hierarchy. This is just a very minor thing, but the is no longer syntax highlighted when a quote is part of a list item and thus indented. ! Steps to Reproduce: markdown file. a list. a quote to one of the items by indenting the quote. Reproduces without extensions: Yes
Code change:
resetStateMachine:boolean, hasOpenParens:boolean, hasOpenSquareBracket:boolean, <del> hasOpenCurlyBracket:boolean; </del> <ins> hasOpenCurlyBracket:boolean, characterClassifier:CharacterClassifier = new CharacterClassifier(); </ins> for (i = 1, lineCount = model.getLineCount(); i <= lineCount; i++) { line = model.getLineContent(i);

Related discussion:
text: VSCode Version: 1.0 OS Version: OS X 10.11.4 I just upgraded my VSCode to 1.0 release. Since it supports Traditional Chinese now, my default language was set to so that some of comments in the newly config file is in Chinese. As you can see in the following screenshot, a Chinese character "", which is equivalent to the period "." in English, was matched as part of valid URL, and it caused VSCode direct to a incorrect URL. ! I have a working fix for this issue, the naive solution is to check if in is greater than 128, which means a non-ASCII character. Why to match only ASCII character? Because when you copy a URL from most of web browsers to clipboard, it will be automatically converted into ASCII-only string. Also, I came up with another idea to modify the to let it cache all the result of ASCII characters (0~127). In this way, we only need to modify the default case of the switch clause in the state machine. Which solution is more preferable? Please give me some advice then I can submit the patch ASAP.
Code change:
const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Related discussion:
text: 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
Code change:
const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Related discussion:
text: 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.
Code change:
const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Related discussion:
text: 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.
Code change:
const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Related discussion:
text: 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.
Code change:
const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Related discussion:
text: 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.