jiebi/CodeConvo huggingface dataset:
Code change:
this.setInput(input); this.disposables.push(this.onDidChangeSelection(event => { <del> extensionsWorkdbenchService.open(event.elements[0], event.browserEvent instanceof MouseEvent && (event.browserEvent.ctrlKey || event.browserEvent.metaKey || event.browserEvent.altKey)); </del> <ins> if (event.browserEvent && event.browserEvent instanceof KeyboardEvent) { extensionsWorkdbenchService.open(event.elements[0].extension, false); } </ins> })); } }  No newline at end of file

Related discussion:
text: Steps to Repro: Search for an extension pack in extensions view (Say PHP Extension Pack) Open PHP Extension Pack in the editor Go to Extensions Pack tab Click on any extension Fails to open Close to open the editor Does not close Not sure how it happened but I had the extension pack open (as extension editor) and after a while (being on twitter) I wanted to close the editor and I saw error notifications. These are the minified stacktraces from the log the build was
Not able to repro it. Also followed the code and I do not see a path that has no extension in the input. Do you remember any steps you followed during this? Is it possible to guess what could be happening in editor land from the above stack trace?
are you using editors with preview mode, e.g. do they appear italic? Hard to say what the execution flow here is to be honest. Looks like a normal editor opening but failing to get the resource for the editor, which is used to associate the editor in the editor tabs model.
But this is happening while is trying to close the currently opened extension editor.
I don't use tabs, so I am not sure what the model then is... Yes, closing it was. I had the extension editor open, also installed the extension, then waited, and then tried to close the editor. So maybe some cleanup logic hit me or installing the extension made a different...
The preview feature works with tabs enabled or disabled. The fact that an editor is opened can be explained if you closed an editor and the next one below that editor was the extension editor. Closing an editor always means we open the previous editor unless it is the last editor. I suggest you try to figure out how it is possible that is even though it is not typed as such.
Ok
What are the verification steps for this?
Steps to repro are in the description
Code change:
private resetCenteredEditor(layout: boolean = true) { this.centeredEditorLeftMarginRatio = 0.5; <del> this.centeredEditorPreferedSize = Math.floor(this.dimension.width * EditorGroupsControl.GOLDEN_RATIO); </del> <ins> this.centeredEditorPreferredSize = Math.floor(this.dimension.width * EditorGroupsControl.GOLDEN_RATIO); </ins> if (layout) { this.layoutContainers(); } <del> this.storageServise.remove(EditorGroupsControl.CENTERED_EDITOR_LAYOUT_DATA_STORAGE_KEY, StorageScope.GLOBAL); </del> <ins> this.storageService.remove(EditorGroupsControl.CENTERED_EDITOR_LAYOUT_DATA_STORAGE_KEY, StorageScope.GLOBAL); </ins> } public getInstantiationService(position: Position): IInstantiationService {

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21 OS Version: Mac 10.12.16 Steps to Reproduce: editor mode should be in vertical mode on centered layout with one tab, you should see it is centered split editor mode to horizontal mode centered layout will no longer work until you switch back to vertical mode <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --- <!-- score: 0.451 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Thanks for figuring this out. I spent a while trying to figure out what the problem was. Thank to you, I changed splitting to vertical mode and now centered layout works. I can affirm that this big is happening to me too. I'm on a mac as well.
I would expect centered mode to work if I have horizontal layout and only one editor. I tried removing the check to simply also enable it for horizontal layout but somehow the layout gets broken in that case. I plan to fix this in the following week but just to let you know that a PR is more than welcome :)
I just let you know that money is more than welcome :smile: Just kidding... I run on fun xD you shall have your PR :) it has the number . The problem was, that the available size was calculated by using which holds the height and not the width of the editor when in horizontal mode. You have to play around with it a little... it seemed to work but I did no deep testing or anything As bonus I fixed two typos (one of whom I made myself :smile:)
thanks a lot for your PR, I just merged it in I tried it out and it works nicely, also thanks for fixing typos. For money feel free to apply for our internshipts if you are a student or to our open positions :)
:smile: I'll finish university in 4 month... so... I might very well do that xD
Code change:
description: nls.localize('search.globalFindClipboard', "Controls whether the search view should read or modify the shared find clipboard on macOS."), included: platform.isMacintosh }, <ins> 'search.location': { type: 'string', enum: ['sidebar', 'panel'], default: 'sidebar', description: nls.localize('search.location', "Controls whether the search will be shown as a view in the sidebar or as a panel in the panel area for more horizontal space."), deprecationMessage: nls.localize('search.location.deprecationMessage', "This setting is deprecated. Please use the search view's context menu instead.") }, </ins> 'search.collapseResults': { type: 'string', enum: ['auto', 'alwaysCollapse', 'alwaysExpand'],

Related discussion:
text: Used the stable built on v1.42 for sanity test and I see following error ! I suspect this is because we removed the search location setting and trying to remove its value as migration
Instead of removing the setting, please deprecate it.
BTW I see this error in every window until I manually remove the setting.
To verify: to and manually set to . the window ensure that: no error notification appears search is in the panel upon reload the setting is removed from your
Code change:
execution_count: cell.executionSummary?.executionOrder ?? null, source: splitMultilineString(cell.value.replace(/rn/g, 'n')), outputs: (cell.outputs || []).map(translateCellDisplayOutput), <del> metadata: metadata </del> <ins> metadata: cellMetadata.metadata </ins> }; if (cellMetadata?.id) { codeCell.id = cellMetadata.id;

Related discussion:
text: Create an ipynb file (with one Python cell) Save this Verify the entry exists in time line Change the language of the cell to Save this Verify we have an entry Click that item Bug On the left we need On the right there's no such entry in metadata This is incorrect. The ipynb has the above metadata. What seems to be happening is When the language changes, We serialize the ipynb and JSon contains the metadata However the model is not updated with corresponding changes to the ipynb file I.e. model change triggered =ipynb serialize to JSON =Json contains new metadtaa not in model =Missing step is to update the model again If we implement the last step, we could always end up in an infinite loop, Perhaps we should first update the model with metadata when ever we detect chagnes in the model before the save event. E.g. as part of pre-Save (onDidChangeNotebookDocument &/or onWillSaveNotebookDocument) This way, model will always be accurate and upto date when ipynb is serialized.
Easier way to explain the bug Create an ipynb file (with one Python cell) Save this Change the language of the cell to Save this The cell metadata will not contain the new metadata that exists in the ipynb JSON file. (model is not in sync with ipynb json)
Suggested Solution Perform model updates when we're about to save (or when we detect changes to model) When saving, ensure we save the metadata as is, without generating any new content I.e. JSON.stringify the metadata.
/cc
Considering that a serialize operation should not have side effects (ideally), enforcing a "save participant" from ipynb extension makes very good sense to me. We can leverage which support additional async operations, like how we handle attachment clearnup
For such critical metadata change, we might want to handle both auto save and manual save as we want the json and model to be always in sync.
Another simple repro step Create a notebook, and save this Add a new cell The latest entry in timeline will be However there's a difference, one has and the other (current model state) does not have any Again, model does not contain metadta (as this is a new cell) and ipynb JSON contains metadata when serialized.
Code change:
execution_count: cell.executionSummary?.executionOrder ?? null, source: splitMultilineString(cell.value.replace(/rn/g, 'n')), outputs: (cell.outputs || []).map(translateCellDisplayOutput), <del> metadata: metadata </del> <ins> metadata: cellMetadata.metadata </ins> }; if (cellMetadata?.id) { codeCell.id = cellMetadata.id;

Related discussion:
text: <details<summaryInternal Notes</summaryHere's the work flow Add a cell A change event is triggered, undo redo stack is updated Last undo redo is User hits save button Working copy starts to handle the save operation Save participants start We add a save participant and update the model via a work space edit Now a new change event is triggered This results in a whole new undo redo stack The latest (last) undo redo item is Save participants done Working copy keeps track of the last as the entry for Problems Time line does not include , time line shows only I guess this is correct, However from a users perspective, the labels are never going to be meaningful as we'd always say . </details
Code change:
if (editorHighlighterContrib.wordHighlighter.decorations.length > 0) { editorHighlighterContrib.wordHighlighter.decorations.clear(); <ins> editorHighlighterContrib.wordHighlighter.workerRequest = null; </ins> editorHighlighterContrib.wordHighlighter._hasWordHighlights.set(false); } }

Related discussion:
text: Keeping this open as the main tracking issue as I keep an eye on error telemetry. Been quiet and haven't seen any entries in the errors site since early Feb with +
Closing this as fixed by the above linked PR's. Error telem has been quiet with no entries for ~4 weeks.
Code change:
if (editorHighlighterContrib.wordHighlighter.decorations.length > 0) { editorHighlighterContrib.wordHighlighter.decorations.clear(); <ins> editorHighlighterContrib.wordHighlighter.workerRequest = null; </ins> editorHighlighterContrib.wordHighlighter._hasWordHighlights.set(false); } }

Related discussion:
text: ! Version: 1.85.0-insider (user setup) Commit: Date: 2023-12-01T19:00:37.339Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: WindowsNT x64 10.0.
I think that is expected, see This should behave the same for when multiple editor groups are opened in the same window.
The issue is that highlighted words remain until a new word is focused. In the main window, the highlights disappear when the word loses focus.
not for me in this case: ! Do you have a case where highlights remove to reproduce?
In the main window, If you click on a word and then on a blank line, the highlight disappears: !
my assumption here is that the other editor is over a word that then is highlighted in the floating editor. There is probably a heuristic to decide which highlight to apply. Can you double check my theory?
it doesn't matter if it's on the same word or not but I found out this only happens if the same editor is opened on the main window or in other windows (in this case the first floating editor highlights disappear after losing focus). Highlights disappear after losing focus in: Main window Single floating editor (Not opened in main window) Only the first floating editor when there are multiple (Not opened in main window)
I can reproduce but this is not a floating window issue. It reproduces even when you just have 2 editor groups opened next to each other: !
tl;dr: Setting to "off" fixes it. I'm seeing what I think is the same bug, after upgrading to 1.85.1 (first upgrade in a number of months, so I've jumped a few versions). While writing this I think there are two distinct problems. The first is when a single file is open: -click a word. It highlights that word, and in a different grey highlights the same word in rest of document. esc: nothing happens. I now need to click a blank line to get the highlights to go away. (I'm sure esc used to get rid of it before??)
Code change:
if (editorHighlighterContrib.wordHighlighter.decorations.length > 0) { editorHighlighterContrib.wordHighlighter.decorations.clear(); <ins> editorHighlighterContrib.wordHighlighter.workerRequest = null; </ins> editorHighlighterContrib.wordHighlighter._hasWordHighlights.set(false); } }

Related discussion:
text: The second is much more annoying, but only seems to happen when I have same file open twice, after using Split Editor Right. -click a word. It highlights that word, and (in a different shade of grey) highlights the same word in rest of window. In the other window it highlights some (but not all!) of the same word. doesn't get rid of it. Clicking a blank line does not get rid of it. All the grey highlights are there forever. the other window: still the highlights are there. I can now double-click a different word and see it highlight throughout document, click blank line gets rid of that one, but still my first set of highlights survive! only way to get rid of them is to close the editor and open it again. OR, reduce to just one window open, double-click it again, and then click a blank line. Playing around, I've noticed it does not matter which window I do the double-click in, it is the window on the right where the unwanted highlights survive. Regarding mentioned in the 1.84 release notes, searching for that in settings doesn't find anything. But I do have as mentioned in It is currently set to "singleFile" If I set it to "off", everything works as it used to. Double-click still highlights within the open file (only), and esc now cancels it again :-) BTW, testing the 3rd option, "multiFile", it appears to behave exactly as "singleFile" in every respect I described above. Anyway, switching to "off" gives me exactly the behaviour I want, so I'm happy.
Thanks for the detailed writeup! The editor highlights have been reworked to start bringing in support for semantic highlighting between multiple documents. This was primarily tested between multiple different documents and there are some bugs arising that have to do with split view of the same file. Will be addressing in the near future.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Steps for verification: Open a typescript file in split view, with content as follows: In the left panel, click the symbol. In the right panel, click the same symbol. In the right panel, click anywhere else that isn't a symbol.
Code change:
if (editorHighlighterContrib.wordHighlighter.decorations.length > 0) { editorHighlighterContrib.wordHighlighter.decorations.clear(); <ins> editorHighlighterContrib.wordHighlighter.workerRequest = null; </ins> editorHighlighterContrib.wordHighlighter._hasWordHighlights.set(false); } }

Related discussion:
text: choose any whitespace, etc in Stable: The highlights should disappear from the left panel, but persist in the right, even as you click around the right panel. Fixed on insiders: You should not be able to end up in a state with persistent highlights when your cursor is not on a symbol.
Code change:
return true; } <del> if (!this._initialized) { return false; </del> <ins> if (this.environmentService.extensionTestsLocationURI) { return true; // trust running tests with vscode-test </ins> } // Remote - remote authority explicitly sets workspace trust

Related discussion:
text: Steps to Reproduce: an empty window the trust editor, and trust the window the window Expected: Window is trusted Actual: Window is not trusted
This is also repros when you have the setting enabled: <img width="1024" alt="CleanShot 2021-06-08 at 08 17 39 src="https://user-"
Pushed a fix for this issue into , in case we will want to take this as a candidate for the June release.
Code change:
label: markActiveWhen(currentSecurityLevel === MarkdownPreviewSecurityLevel.Strict) + localize('strict.title', 'Strict'), description: localize('strict.description', 'Only load secure content'), }, { <ins> type: MarkdownPreviewSecurityLevel.AllowInsecureLocalContent, label: markActiveWhen(currentSecurityLevel === MarkdownPreviewSecurityLevel.AllowInsecureLocalContent) + localize('insecureLocalContent.title', 'Allow insecure local content'), description: localize('insecureLocalContent.description', 'Enable loading content over http served from localhost'), }, { </ins> type: MarkdownPreviewSecurityLevel.AllowInsecureContent, label: markActiveWhen(currentSecurityLevel === MarkdownPreviewSecurityLevel.AllowInsecureContent) + localize('insecureContent.title', 'Allow insecure content'), description: localize('insecureContent.description', 'Enable loading content over http'),

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21.1 OS Version: MacOS High Sierra 10.13.3 (17D102) Steps to Reproduce: markdown preview in combination with local plantuml server code to use local server for rendering a markdown with embedded plantUML content error about unsafe content ! The current only allow to enable/disable unsafe (HTTP without the S) entirely. Would it make sense to add an option that allows unsafe content from localhost but not from remote sources?
This may be ok (at least for images): If someone wants to take a look at this, you would just need to update the content security policy to allow :
Looking into it, thanks for the pointer.
Code change:
} if (size > 3 * this.minSize && size < this.centeredEditorAvailableSize) { <del> this.centeredEditorPreferedSize = size; </del> <ins> this.centeredEditorPreferredSize = size; </ins> position -= EditorGroupsControl.CENTERED_EDITOR_MIN_MARGIN; position = Math.min(position, this.centeredEditorAvailableSize - this.centeredEditorSize); position = Math.max(0, position);

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21 OS Version: Mac 10.12.16 Steps to Reproduce: editor mode should be in vertical mode on centered layout with one tab, you should see it is centered split editor mode to horizontal mode centered layout will no longer work until you switch back to vertical mode <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --- <!-- score: 0.451 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Thanks for figuring this out. I spent a while trying to figure out what the problem was. Thank to you, I changed splitting to vertical mode and now centered layout works. I can affirm that this big is happening to me too. I'm on a mac as well.
I would expect centered mode to work if I have horizontal layout and only one editor. I tried removing the check to simply also enable it for horizontal layout but somehow the layout gets broken in that case. I plan to fix this in the following week but just to let you know that a PR is more than welcome :)
I just let you know that money is more than welcome :smile: Just kidding... I run on fun xD you shall have your PR :) it has the number . The problem was, that the available size was calculated by using which holds the height and not the width of the editor when in horizontal mode. You have to play around with it a little... it seemed to work but I did no deep testing or anything As bonus I fixed two typos (one of whom I made myself :smile:)
thanks a lot for your PR, I just merged it in I tried it out and it works nicely, also thanks for fixing typos. For money feel free to apply for our internshipts if you are a student or to our open positions :)
:smile: I'll finish university in 4 month... so... I might very well do that xD
Code change:
); // Apply extension environment variable collections to the environment <del> if (!shellLaunchConfig.strictEnv) { </del> <ins> if (shouldUseEnvironmentVariableCollection(shellLaunchConfig)) { </ins> const entries: [string, IEnvironmentVariableCollection][] = []; for (const [k, v, d] of args.envVariableCollections) { entries.push([k, { map: deserializeEnvironmentVariableCollection(v), descriptionMap: deserializeEnvironmentDescriptionMap(d) }]);

Related discussion:
text: <!-- 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. --Version: 1.85.0-insider OS: Linux (codespaces) Steps to Reproduce: in the terminal prompt is contributed via env collection by Python extension. Normal terminal: ! Hovering says that collection is applied. Hidden terminal: ! Although it says that no environment collection is contributed upon hovering, collection is still applied as can be seen in the terminal prompt.
it seems like this is actually a bug where the initially hidden terminal doesn't show the applied environments but should? Making a terminal hidden was just meant to be about visibility, not environment?
I'm fine if we change hidden terminals to also apply environment collection, as long as we get support for Python extension decided not to send activate commands to hidden terminals: , as hidden terminals are considered private terminals belonging to a specific extension. One could probably argue similarly for not applying environment collection to such terminals.
Based on offline discussion we're continue to go with NOT applying environment collection to hidden terminals, due to it affecting remote scenarios.
We investigated that env collection from shell integration in unix is still being applied on hidden terminals, i.e is still being applied when it should not. Any further updates?
Code to disable for terminals: Where vars are set:
I cannot reproduce this on Windows or macOS. Steps: Code - OSS a terminal and verify the environment does not include terminal-sample from vscode-extension-samples via symlink a terminal and verify the environment does and select the new terminal and verify the environment does not include Maybe you had the variable set in the parent environment (main/server?) which is why it showed up?