jiebi/CodeConvo huggingface dataset:
Code change:
import { IMenuService, MenuId, IMenu, SubmenuItemAction, registerAction2, Action2, MenuItemAction, MenuRegistry } from 'vs/platform/actions/common/actions'; import { registerThemingParticipant, IThemeService } from 'vs/platform/theme/common/themeService'; import { MenuBarVisibility, getTitleBarStyle, IWindowOpenable, getMenuBarVisibility } from 'vs/platform/window/common/window'; <del> import { ContextKeyExpr, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </del> <ins> import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </ins> import { IAction, Action, SubmenuAction, Separator, IActionRunner, ActionRunner, WorkbenchActionExecutedEvent, WorkbenchActionExecutedClassification } from 'vs/base/common/actions'; import { addDisposableListener, Dimension, EventType } from 'vs/base/browser/dom'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding';

Related discussion:
text: In the recent Edit Sessions UX study we ran, we saw several participants searching in vain for the terminal item in the compact menu on , sometimes for minutes: ! Could we consider bringing it back? I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that was a browser application. Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of through our welcome views. ! cc
Yes that is why it was removed. It doesn't do much but if it helps reduce confusion I guess it's worth it?
Not against the idea of having the terminal menu in web but in its current form it's useless and doesn't allow me to actually show a terminal pane, it just deadends all over https://user-
Reverting in
when I enable the menu again and fix up the terminal command, the run/customize task items give this on the scripts/code-web sample-folder: <img width="1229" alt="image" src="https://user-"That does actually run, not sure what it's doing exactly though. Is that a custom execution task running in the web worker ext host? If so you might need a context key on those menu items to only show them when a custom execution task is registered?
Unless I'm missing something, I believe only registered tasks will show there - if they're running when you select them, then I don't think there's an issue.
I think there's a built-in fake task when running code-web is what I mean, when run in actual then running it might do nothing. In that case it should hide similar to how we're changing the behavior of New Terminal depending on whether extension contributed profiles exist
Code change:
import * as platform from 'vs/base/common/platform'; import * as dom from 'vs/base/browser/dom'; import * as paths from 'vs/base/common/paths'; <ins> import * as os from 'os'; </ins> import { Event, Emitter } from 'vs/base/common/event'; import { WindowsShellHelper } from 'vs/workbench/parts/terminal/node/windowsShellHelper'; import { Terminal as XTermTerminal, ISearchOptions } from 'vscode-xterm';

Related discussion:
text: VSCode Version: 1.17.2 OS Version: Win10 Steps to Reproduce: Terminal to bash <Ctrl+<Shift+<Pand type "run active file" command not work because path to the file is windows-style and <.is missing in front.
I would like to fix this.
Looks like the util was introduced in Windows
Code change:
], "filenamePatterns": [ "tsconfig.*.json", <del> "tsconfig-*.json" </del> <ins> "jsconfig.*.json", "tsconfig-*.json", "jsconfig-*.json" </ins> ] } ],

Related discussion:
text: <!-- 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.47.2 (user setup) OS Version: Windows_NT x64 10.0. Steps to Reproduce: a file named in any directory. the file with VS Code. file is opened with the "JSON" language mode (instead of the expected "JSON with Comments" mode). Other file names, e.g. , are also opened in "JSON" language mode. In contrast, is opened in "JSON with Comments" mode even if the file name contains suffixes, e.g. . <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
This is easily fixable, look at the relevant code: Submit a PR
Thank you. Is a local build/test warranted, or would a direct PR suffice? Asking because I don't have a local build environment right now (and setting up one would take some time)
Code change:
'Selection': nls.localize({ key: 'mSelection', comment: ['&& denotes a mnemonic'] }, "&&Selection"), 'View': nls.localize({ key: 'mView', comment: ['&& denotes a mnemonic'] }, "&&View"), 'Go': nls.localize({ key: 'mGoto', comment: ['&& denotes a mnemonic'] }, "&&Go"), <del> 'Terminal': nls.localize({ key: 'mTerminal', comment: ['&& denotes a mnemonic'] }, "&&Terminal"), </del> 'Debug': nls.localize({ key: 'mDebug', comment: ['&& denotes a mnemonic'] }, "&&Debug"), 'Tasks': nls.localize({ key: 'mTasks', comment: ['&& denotes a mnemonic'] }, "&&Tasks"), 'Help': nls.localize({ key: 'mHelp', comment: ['&& denotes a mnemonic'] }, "&&Help")

Related discussion:
text: We should also take out the "Terminal" menu when using the custom menu: ! //cc
pushed a fix for this only to the release branch. What we do for master is up for discussion. please verify once the build is out in 30 mins. Thanks
Thanks I didn't know about this code.
Code change:
import { FileSystemProviderErrorCode, markAsFileSystemProviderError } from 'vs/platform/files/common/files'; import { RemoteAuthorityResolverErrorCode } from 'vs/platform/remote/common/remoteAuthorityResolver'; import { IRelativePatternDto } from 'vs/workbench/api/common/extHost.protocol'; <del> import { CellEditType, ICellPartialMetadataEdit, IDocumentMetadataEdit, isTextStreamMime } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </del> <ins> import { CellEditType, ICellMetadataEdit, IDocumentMetadataEdit, isTextStreamMime } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </ins> import { checkProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; import type * as vscode from 'vscode';

Related discussion:
text: When updating cell metadata for a cell, users call which provides a function to alter the metadata of a cell. This uses defined in . When is called, the CellEditType is marked as , resulting in the metadata of the cell only being updated with the passed in data, rather than fully replaced. This makes it difficult to determine how to remove fields from a cell's metadata, a change needed for fixing . This can be worked around in this situation by setting the field to null. However, if a user calls , it appears that the functionality is a full replacement of initial metadata. There is a slight inconsistency here between the functionality of the two functions. Couple initial ideas: better document to reflect the behavior of . Add in a line stating that this is an iterative change, only altering the fields passed into this function - revise the functionality of either updateCell or updateNotebook metadata functions to align their behavior. This seems dangerous as it could likely break features leveraging this api. deprecate these functions, and rewrite two new ones with clearer functionality and documentation, based on updated needs from the notebook and jupyter teams
Analyzed all extensions using this API and most of them are already doing the right thing: clone the existing metadata, apply the change, and then call the API to update. However there are a few extensions didn't do so: there is one place where the metadata is not updated properly: PR . cc
<!-- 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!
what is the best way to verify this?
It's a bit complex I would love either or to help verify.
Code change:
} registerTerminalContribution(TerminalInitialHintContribution.ID, TerminalInitialHintContribution, false); class TerminalInitialHintWidget extends Disposable {

Related discussion:
text: I've verified that I can see the terminal hint in insiders. Does this also need to be tested in stable?
Yes this needs a stable build as it checks quality. You could verify out of sources by setting quality to stable as well
Code change:
} registerTerminalContribution(TerminalInitialHintContribution.ID, TerminalInitialHintContribution, false); class TerminalInitialHintWidget extends Disposable {

Related discussion:
text: Can this support right click to toggle the setting to hidden? !
right click shows our terminal context menu, perhaps we should just put it in there rather than adding a new one? !
this isn't a feature the others offer, thus not a bug IMO
Code change:
() => { }, (linkCandidates: string, cb: (result: { uri: URI, link: string, isDirectory: boolean } | undefined) => void) => { cb({ uri: URI.file('/'), link: linkCandidates[0], isDirectory: false }); <del> } </del> <ins> }, true </ins> ); // Write the text and wait for the parser to finish

Related discussion:
text: Logging errors from the file service I notice that the terminal seems to stat the terminal prompt multiple times: ! Notice the at the end of the file path.
When you hover a line in the terminal links are resolved, one of the link providers gets confirmation on whether it's a file or directory and gives a high confidence link (underline shows when you hover without cmd) and on macOS we treat as a valid path character. This is how it's always worked. but we could cache this stat result with a TTL (10s?) so it doesn't spam so many stat calls and will be able to return the link faster on successive hovers.
Code change:
import { Action2, registerAction2 } from 'vs/platform/actions/common/actions'; import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { CATEGORIES } from 'vs/workbench/common/actions'; <del> import { getNotebookEditorFromEditorPane, ICellViewModel, ICommonCellViewModelLayoutChangeInfo, INotebookEditor, INotebookEditorContribution } from 'vs/workbench/contrib/notebook/browser/notebookBrowser'; </del> <ins> import { getNotebookEditorFromEditorPane, ICellViewModel, ICommonCellViewModelLayoutChangeInfo, INotebookDeltaCellStatusBarItems, INotebookEditor, INotebookEditorContribution } from 'vs/workbench/contrib/notebook/browser/notebookBrowser'; </ins> import { registerNotebookContribution } from 'vs/workbench/contrib/notebook/browser/notebookEditorExtensions'; import { NotebookEditorWidget } from 'vs/workbench/contrib/notebook/browser/notebookEditorWidget'; <ins> import { CellStatusbarAlignment, INotebookCellStatusBarItem } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </ins> import { INotebookService } from 'vs/workbench/contrib/notebook/common/notebookService'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService';

Related discussion:
text: Open Select the top cell and page down a few times Focus hits a cell that is longer than the viewport, which is maybe important, then the next page down moves to a higher cell
When a list item is larger than the viewport, and it's also the only element in the viewport, pressing page down will reveal to the previous element, this is because we did a here (the catch is, the last page element is also the first page element)
Code change:
* Must be disposed as soon as the model detaches from the editor. */ export class ActiveGhostTextController extends Disposable { <del> private readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </del> <ins> public readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </ins> public readonly model = this._register(this.instantiationService.createInstance(GhostTextModel, this.editor)); public readonly widget = this._register(this.instantiationService.createInstance(GhostTextWidget, this.editor, this.model));

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When using Copilot, users would like to be able to only partially accept suggestion instead of the whole suggestion at once. The users demand either word by word or line by line completion. Desired behaviour: Press a predefined key and accept the whole suggestion. Use a predefined combination of 2 keys to accept the top line of the suggestion. (eg: For a suggestion of 3 lines, the user would need to press the combination 3 times to accept the whole suggestion). The prompt would not show the line already accepted.
this sounds to me like a UX problem. Is there a mock sketch for a potential solution here? Is there some other editor which already supports this? We can also discuss it in one of our UX weekly meetings.
I don’t have a mock sketch. No other editors are supporting this yet but it is a requested features. I wanted to get the discussion going (doing the same for the other editors) to understand the constraints around it as well.
Technically, I think this would be rather easy to implement. I'd love to hear some more UX discussion before we implement this thought. What key-binding do you have in mind?
do you have some UX designers on your team that would like to help here? Once we have some good ux proposal we can bring it in our UX weekly sync on Wednesday to start the discussion.
No I dont have a UX designer in my team. I ll see how i can come up with a suggestion and get back to you
This is similar to Solution for me was 'CMD + -' to accept a word at a time. Something similar here would be great.
Fish shell allows word-by-word completion using the <kbdAlt</kbd+ <kbd&;</kbdkey-combo, which—at least on macOS—is used system-wide for navigating text word-by-word. I notice that I keep trying to automatically use this key-combo, so big +1 from me. ( Did not realise this is the vscode repo.) 
awesome idea. since you said this is low hanging maybe we assign to July for the initial investigation? What do you think?
This would be great.
Code change:
* Must be disposed as soon as the model detaches from the editor. */ export class ActiveGhostTextController extends Disposable { <del> private readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </del> <ins> public readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </ins> public readonly model = this._register(this.instantiationService.createInstance(GhostTextModel, this.editor)); public readonly widget = this._register(this.instantiationService.createInstance(GhostTextWidget, this.editor, this.model));

Related discussion:
text: I am loving copilot so far, but this is my biggest UX gripe. Copilot's first suggestions in a new piece of code tend to only be accurate for the first few words. It tends to get much better only after more context is . Not a blocker, but it'd make it much easier to get started.
We did an initial investigation and this is not low hanging as I have initially commented above. Also, this milestone we have been mostly focusing on improving the merge editor. So this one will have to continue in September.
Had a sync with the VS folk and here's some very early thinking: When partial completion is accepted the ghost text should not change - we should use the cache. VS did multiple user studies and users always get shocked when the ghost text changes beneath them Undo is the user gesture to undo the last partial acceptance (this should work out of the box for us). Simple keybindings like word next navigation, and navigate to end of line should be used for partial word acceptance, and whole line acceptance. So same keybindnigs as and commands. Open questions (probably not for first version): How to make this keybindings discoverable Should we support the mouse? For example alt + mouse click to accept until the mouse click
I've also previously advocated for a way to accept only a single line out of the multi-line completion. I would strongly support doing this at a line granularity, rather than e.g. token granularity, since I ~never run into the case where I want to accept 'more than 0 tokens but less than a line' of a multi-line completion -- it's ~always either one line or maybe a couple, or the whole completion. Repurposing regular cursor movement commands for partial acceptance when a ghost text completion is open sounds error-prone. I see this kind of key-stealing behavior in some autocomplete systems (especially for ), but it's always optional, since it's really easy to interfere with muscle memory and frustrate people. This would apply to text navigation commands for sure, and it would be even worse in the middle-of-the-line completion case (which would also be wonky if we want an 'accept a single token' shortcut).
Hi! A use case for per-word completion: comment/natural language completion. I want this almost every time that copilot gives me a comment suggestion.
Code change:
* Must be disposed as soon as the model detaches from the editor. */ export class ActiveGhostTextController extends Disposable { <del> private readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </del> <ins> public readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </ins> public readonly model = this._register(this.instantiationService.createInstance(GhostTextModel, this.editor)); public readonly widget = this._register(this.instantiationService.createInstance(GhostTextWidget, this.editor, this.model));

Related discussion:
text: To make sure I understand the shape of the discussion, I think three issues are separable here: 1) whether to offer partial completion; 2) at what granularities (here the use case and example-based analysis is most relevant, and feed back into question 1); 3) if doing it, what default keybindings at these levels to provide so as not to hijack muscle memory (but possibly still utilize it in a parallel modifier key universe)? Is that right, and if so at what stage does the team currently see the conversation? For 3), in Lisp-y language tools, Paredit's keybindings might be a decent template too: in some sense what we are doing here is structurally selecting part of what is an (falling back on a as above) structure before "acceptance" (which is already well-understood as a result of by default keybinding users). That would be a more elaborate form of the partial acceptance, though, requiring a language-sensitive parse, so definitely not low hanging fruit.
It's a marketing problem, they market the code you accept as efficiency. If they would also add the 97% of the code you have to remove carefully again it wouldn't be that a nice metric. I believe we need to adapt the plugins on our own or write a plugin watchdog, something that monitors completions, immediately removes them and offers a word-by-word insert of the code.
A use case from He wants to accept the first couple of words here (but not the entire completion): ! ... ~~ A use case for line based acceptance: !
For jetbrains IDE's you can use my plugin () You press CTRL+ALT+D and it will complete the sentence word by word. So in your example you press it 3 times (you'll be after "to", then you type "have a per" and you can continue with the shortcut 3 more times on the new completion text. Or just "TAB" if all is good after your intervention, it doesn't block you from using the default behavior of copilot Though the plugin only works on IntelliJ IDE's (you need to install 'LivePlugin' and 'Stewardess')
I love this suggestion. I encounter the scenario of wanting to only accept a suggestion partially a lot.
would you prefer word-by-word partial acceptance or line-by-line?
Code change:
* Must be disposed as soon as the model detaches from the editor. */ export class ActiveGhostTextController extends Disposable { <del> private readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </del> <ins> public readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </ins> public readonly model = this._register(this.instantiationService.createInstance(GhostTextModel, this.editor)); public readonly widget = this._register(this.instantiationService.createInstance(GhostTextWidget, this.editor, this.model));

Related discussion:
text: It would be awesome to be able to do both, but if only one of the two is possible, then I would prefer word-by-word.
There is no reason why only one would be doable. A line based completion is a couple of lines of code. Word based completion is half a page if you want to do the word separation smart, or an abstract if it's dumb.
First iteration has been implemented in
Code change:
"makefile" ], "extensions": [ <ins> ".mak", </ins> ".mk" ], "filenames": [

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --VS Code currently associates the extension with the Make language. is another common file extension for files included by s. It's associated with Make by , i.e. files are recognized by , and there are a few dozen public . VS Code should recognize this extension automatically.
could you point me to some documentation about please?
Hi I've updated the issue description with some additional information. Notably, , which I consider to be a fairly canonical source. I've not any of the other file extensions recognized by GitHub Linguist for Make, as I've not seen them in use. Anecdotally, my employer has been using the extension internally since at least 2001.
Here are some additional examples which demonstrate inclusion of files by s:
That's good enough for me, thank you!
/verified
Code change:
"tas-client-umd": "0.1.6", "vscode-oniguruma": "1.6.1", "vscode-textmate": "7.0.1", <del> "xterm": "5.0.0-beta.32", "xterm-addon-canvas": "0.2.0-beta.15", "xterm-addon-search": "0.10.0-beta.3", "xterm-addon-unicode11": "0.4.0-beta.3", "xterm-addon-webgl": "0.13.0-beta.32" </del> <ins> "xterm": "5.0.0-beta.35", "xterm-addon-canvas": "0.2.0-beta.17", "xterm-addon-search": "0.10.0-beta.5", "xterm-addon-unicode11": "0.4.0-beta.5", "xterm-addon-webgl": "0.13.0-beta.35" </ins> } }

Related discussion:
text: Repro: folder test task, wait to finish another terminal test task again <img width="1344" alt="Screen Shot 2022-08-07 at 11 40 14 am" src="https://user-"
In repo, ctrl+shift+b is focusing the terminal: !
Reproduces on webgl only
Guessing it's related to canvas recreation:
Yep: !