jiebi/CodeConvo huggingface dataset:
Change:
return null; } <del> const IGNORE_ENCODINGS = ['ascii', 'utf-8', 'utf-16', 'utf-32']; </del> /** * Guesses the encoding from buffer. */

Discussion:
utf-8() encoding guessing is disabled by this line. But this didn't mention it. And in my test,the follow text will be guessing as utf-8 correctly(result='utf-8'). ! jschardet result: ! In the other hand,with the follow setting, it will be detect as ! !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.564 --- <!-- score: 0.49 --<!-- potentialduplicatescomment --
These issues will be solve by
In particular, will be treat as !
I like this change because it makes more deterministic by giving it full control over the detection. I still think more work is needed to increase the confidence of the detection, but that can continue in other issues.
I noticed a bad regression though that made me push to ignore the guessed encoding "ascii" for a simple reason: user opens a text file with just ascii characters we guess the encoding to be "ascii" user types special characters (like german umlaut) user saves and closes the file user reopens the file =the file is still guessed as "ascii" because it was not saved with a proper encoding
Verification: configure configure (simply to a non-UTF8 encoding) save a file with special characters contents (e.g. ) as UTF-8 close all files open it in VSCode =the encoding should be from the status bar.
Given scary issues such as I am putting UTF-16 and 32 back to the list of ignored encodings for guessing. Still, UTF-8 can be guessed.
From this issue , we really need to replace jschardet with a new library
Change:
return this._id; } <del> private _serializeParentTerminal(location?: TerminalLocation | vscode.TerminalEditorLocationOptions | vscode.TerminalSplitLocationOptions, parentTerminal?: ExtHostTerminalIdentifier): TerminalLocation | vscode.TerminalEditorLocationOptions | { parentTerminal: ExtHostTerminalIdentifier } | undefined { </del> <ins> private _serializeParentTerminal(location?: TerminalLocation | vscode.TerminalEditorLocationOptions | vscode.TerminalSplitLocationOptions, parentTerminal?: ExtHostTerminalIdentifier): TerminalLocation | { viewColumn: EditorGroupColumn; preserveFocus?: boolean } | { parentTerminal: ExtHostTerminalIdentifier } | undefined { </ins> if (typeof location === 'object') { if ('parentTerminal' in location && location.parentTerminal && parentTerminal) { return { parentTerminal }; } if ('viewColumn' in location) { <del> return { viewColumn: location.viewColumn, preserveFocus: location.preserveFocus }; </del> <ins> return { viewColumn: ViewColumn.from(location.viewColumn), preserveFocus: location.preserveFocus }; </ins> } return undefined;

Discussion:
I noticed terminals can accept : Note that this does not map 1 to 1 to , you have to: offset properly: convert properly: //cc
Steps: open 2 empty editor groups, focus the first group execute a command that triggers below code [1] terminal opens in first group not second
Moving to September. //cc
Change:
description: 'example', after: { content: 'very very long injected text that causes a line break' <del> } </del> <ins> }, showIfCollapsed: true, </ins> } }]);

Discussion:
<!-- 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. --Currently, the inlay hints will clean and shows again as scheduler's strategy. It's might not friendly if you are editing some line who has many hints. I have an idea: Clean all hints where the cursor’s line when we are editing the code and append new hints by the scheduler. I think It's might improve the experience about inlay hints.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.494 --<!-- potentialduplicatescomment --
/gifPlease
!
I think inlay hints should disappear immediately if the surrounding text is deleted. Afaik, currently, when text gets deleted, decorations inside of that text get collapsed but are not deleted.
Yes, I agree that hints should disappear immediately when their "anchor" position is removed. Maybe it's not so easy to know what remove actually means in this case. Arguably this is an editor bug as I was expecting this to work?
I wouldn't call this a bug - decorations are never removed automatically. Alex suggests (I asked him before his vacation): I also suggest to extend the inlay hints API so that a hint refers to a range. The hint itself then can either be after or before the range. The range allows to better predict what should happen with the hint if the text changes. With injected text, we now have two cursor stops around inlay hints - both refer to the same model position. Maybe the move behavior of inlay text should depend on the view position where the text change was caused from? I suggest to think about how we can better predict synchronously how a text change affects inlay hints.
This is how we started, mostly to optionally support overlay hints, and everyone was confused about ranges for inlay hints. Using a range with before/after screams "position" and I don't want to leak an implementation detail into the API. We would also still have the case of empty ranges... I'd rather create "fake ranges" from positions so that I can use the notion of collapsed ranges.
I have pushed a change () to use the range of touching words of inlay positions (when possible).

In that case will be and my expectation was that decorations hide/disappear when removing all their text.. is that a bug in decorations land or am I using this wrong? Should I listen to decoration changes and "manually" remove them?
I think so, decorations are not removed automatically.
But what does mean then?
Ah, maybe I forgot to consider that flag for injected text, I'll look into it tomorrow.
Change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import * as nls from 'vs/nls'; </del> import * as dom from 'vs/base/browser/dom'; import { Color } from 'vs/base/common/color'; import { onUnexpectedError } from 'vs/base/common/errors';

Discussion:
Found no duplicated for this one Currently it's hardcoded I propose a config entry for long line length If you're object, I'd like to create pull request for this feature Your thoughts?
I think this makes sense as a workspace setting that defaults to the current value. Feel free to make a PR!
Change:
private cleanUp(): void { const cache = this.doLoad(); <del> // Remove groups from states that no longer exist cache.forEach((mapGroupToMemento, resource) => { </del> <ins> // Remove groups from states that no longer exist. Since we modify the // cache and its is a LRU cache make a copy to ensure iteration succeeds const entries = [...cache.entries()]; for (const [resource, mapGroupToMemento] of entries) { </ins> Object.keys(mapGroupToMemento).forEach(group => { const groupId: GroupIdentifier = Number(group); if (!this.editorGroupService.getGroup(groupId)) { delete mapGroupToMemento[groupId]; if (isEmptyObject(mapGroupToMemento)) { cache.delete(resource); } } }); <del> }); </del> <ins> } </ins> } }

Discussion:
ERR LinkedMap got modified during iteration.: Error: LinkedMap got modified during iteration. at LinkedMap.forEach (file:///Applications/Visual Studio Code - ) at g.cleanUp (file:///Applications/Visual Studio Code - ) at g.saveState (file:///Applications/Visual Studio Code - ) at file:///Applications/Visual Studio Code - Code is here:
Change:
this.userHome = pathService.defaultUriScheme === Schemas.file ? this.pathService.userHome({ preferLocal: true }) : undefined; const memento = this.storedFormattersMemento = new Memento('cachedResourceFormatters', storageService); <del> this.storedFormatters = memento.getMemento(StorageScope.GLOBAL, StorageTarget.USER); </del> <ins> this.storedFormatters = memento.getMemento(StorageScope.GLOBAL, StorageTarget.MACHINE); </ins> this.formatters = this.storedFormatters?.formatters || []; // Remote environment is potentially long running

Discussion:
Repro: a file in vscode, example copy relative path command copy path of active file command We should add some unit tests for this or improve existing ones to catch this case.
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our . Please take the time to review these and update the issue. Happy Coding!
Latest insiders, macOS, any workspaces. I use these commands many times per day and it's a huge pain to swap the separators every time. Version: 1.68.0-insider Commit: Date: 2022-06-01T05:17:25.414Z Electron: 17.4.6 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0
Can you try to run where is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.
Still happens with
I'm looking into it now to make sure it's not on my end
I was asking because there is a setting, but it only applies to copying relative paths.
I tried clearing user data dir again and it worked, not sure what happened before, might not have made it into the clipboard for some reason or I made a mistake. When I repro it with extensions disabled and all settings cleared there are several formatters with the wrong separator: <img width="438" alt="Screen Shot 2022-06-01 at 9 07 40 am" src="https://user-"Definitely don't have set.
The bad formatters are coming through via the momento: Can extensions register these? Any ideas on how I could track down the source? I'll try adding my extensions in the clear user data dir.
to load all my extensions doesn't repro, I don't suppose the momento is synced across platforms? !
Likely cause of regression: cc
PR out:
this didn't end up fixing it because the synced formatters still seem to be getting pulled in. Any ideas on how we should clear out the bad cache? I was hoping this would be a quick drive by fix.

Anywhere labels are used gets impacted for multi platform users: <img width="396" alt="Screen Shot 2022-06-03 at 4 53 07 am" src="https://user-"
I think a bandaid fix is to either revert this change entirely or change the storage key that is used.
I don't think anyone has a strong preference on name so updating the storage key name is sane to me.
thanks, will do this today
Thanks for fixing this I didn't realize that we synced workspace state as part of settings sync.
Change:
interface SettingIndicator { element: HTMLElement; <ins> /** * The element to focus on when navigating with keyboard. * When undefined, use {@link element} instead. */ focusElement?: HTMLElement; </ins> label: SimpleIconLabel; disposables: DisposableStore; }

Discussion:
Change the key event handling so that the user can tab once into the indicators container, and then use left/right arrows to focus on different indicators.
the Settings editor, search on the setting. tab should focus on the first indicator. again should go to the checkbox. -tabbing twice from there should focus the entire setting again. again to the indicator. The left and right arrow keys, along with the home and end keys should allow the user to focus onto the other indicators. indicators container should keep track of the focused indicator. If the second indicator is focused, and the user tabs to the checkbox and back, the second indicator should be the one focused rather than the first one.
Change:
} else { this.remoteAuthority = this._workbenchEnvironmentService.remoteAuthority; } const backend = this._terminalInstanceService.getBackend(this.remoteAuthority); if (!backend) { throw new Error(`No terminal backend registered for remote authority '${this.remoteAuthority}'`);

Discussion:
There are too many issues with local echo and can really degrade the experience right now for local workspaces. We should add an on/off/auto setting where auto is disabled in local workspaces, so opt-in ssh in local terminal support is there.
what steps would we take to verify? Looks like there's a new setting?
I tested the setting
Change:
const editorService = accessor.get(IEditorService); const viewsService = accessor.get(IViewsService); const notificationService = accessor.get(INotificationService); <ins> const workingCopyFileService = accessor.get(IWorkingCopyFileService); </ins> await viewsService.openView(VIEW_ID, true);

Discussion:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!
Change:
const uri = model.uri; if (e.event.rightButton || (env.isMacintosh && e.event.leftButton && e.event.ctrlKey)) { <ins> // handled by editor gutter context menu </ins> return; } else { const breakpoints = this.debugService.getModel().getBreakpoints({ uri, lineNumber });

Discussion:
<!-- 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.76.0 OS Version: Mac OS Ventura 13.2.1 +click on the "play" icon next to a test (e.g. in ). Screenshot: <img width="583" alt="image" src="https://user-"Will bring up the context menu, like ctrl+clicking on a file tab header will. Executes the primary left-click action, which is to run the test with defaults.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
It reproduces exactly the same in 1.76.0. I have edited the bug description.
sending this your way since you're redoing the context menus here
Seems like ctrl+click in the gutter shows the context menu everywhere except for test decorations so I think this was just never implemented, therefore marking as feature request.
Wow, thanks for the super quick turnaround!
Change:
// Show Search and Find in Files are redundant, but we can't break keybindings by removing one. So it's the same action, same keybinding, registered to different IDs. // Show Search 'when' is redundant but if the two conflict with exactly the same keybinding and 'when' clause, then they can show up as "unbound" - #51780 <del> registry.registerWorkbenchAction(SyncActionDescriptor.from(OpenSearchViewletAction, { primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.KEY_F }, Constants.SearchViewVisibleKey.toNegated()), 'View: Show Search', CATEGORIES.View.value); </del> <ins> registry.registerWorkbenchAction(SyncActionDescriptor.from(OpenSearchViewletAction), 'View: Show Search', CATEGORIES.View.value); </ins> KeybindingsRegistry.registerCommandAndKeybindingRule({ description: { description: nls.localize('findInFiles.description', "Open the search viewlet"),

Discussion:
We register to both and for historic reasons: With the addition of the new setting, , has potentially different behaviour from , but will always overpower it when it's context expression is true (). This means that even after setting , will still open the search view, unless a separate keybinding is registered to unbind .
Just to confirm that if you are aware that this change will not show the keybinding for Search view anymore at following places: <img width="367" alt="image" src="https://user-"<img width="161" alt="image" src="https://user-"Not sure if it is intended.
Not intended, thanks for the heads up. we could add back the keybinding at a lower priority? Edit: even with lower priority on , or a higher priority on , the keybinding is still missing from menus. Looking for a better approach.
To verify: Set to . Hit (make sure the search view isn't already focused), expect to see a new search editor created.
Change:
shortTitle: localize('mergeEditor.compareWithBase', 'Compare With Base'), f1: true, precondition: ctxIsMergeEditor, <del> menu: { id: MenuId.MergeInput2Toolbar } </del> <ins> menu: { id: MenuId.MergeInput2Toolbar, group: 'primary' }, icon: Codicon.compareChanges, </ins> }); }

Discussion:
! I personally find it a bit strange to have no primary action and only secondary actions hidden behind "...". What is the rationale? //cc
We are looking at pulling these out as primary actions like so. See . <img width="1015" alt="CleanShot 2022-10-03 at 09 11 23 src="https://user-"
!
!
Change:
private readonly _onReportError = this._register(new Emitter<IndexedDBFileSystemProviderErrorData>()); readonly onReportError = this._onReportError.event; <del> private readonly versions = new Map<string, number>(); </del> <ins> private readonly mtimes = new Map<string, number>(); </ins> private cachedFiletree: Promise<IndexedDBFileSystemNode> | undefined; private writeManyThrottler: Throttler;

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1/69-insider OS Version: Windows 11 Steps to Reproduce: user file in timeline view :bug: see timeline entries from 52 years ago !
Is this reproducible or a one-off?
Looks like the file system provider that is implemented for is not implementing properly, I see a value of : <img width="851" alt="image" src="https://user-"Moving to
Change:
if (!rawAdapter.type || (typeof rawAdapter.type !== 'string')) { added.collector.error(nls.localize('debugNoType', "Debugger 'type' can not be omitted and must be of type 'string'.")); } <ins> if (rawAdapter.enableBreakpointsFor && rawAdapter.enableBreakpointsFor.languageIds) { rawAdapter.enableBreakpointsFor.languageIds.forEach(modeId => { this.breakpointModeIdsSet.add(modeId); }); } </ins> if (rawAdapter.type !== '*') { const existing = this.getDebugger(rawAdapter.type);

Discussion:
felix becker php-debug extension php file not set breakpoint
Related
This is fixed, thus closing
Can't also set breakpoints on cpp.
please open a new issue. Use the option from the Help menu to do this so you include plenty of information. Add repro steps including pasted screenshots if you think they can help.
Change:
font-family: var(--monaco-monospace-font); } <ins> .settings-editor > .settings-body > .settings-list-container .setting-item-contents .setting-item-markdown hr { border-bottom-width: 0px; margin: 10px 20px; opacity: 0.4; } </ins> .settings-editor > .settings-body > .settings-list-container .setting-item-contents .setting-item-enumDescription { display: none; }

Discussion:
Issue Type: <bBug</bRepro settings Bug The setting description has a pair of white bars: <img width="1390" alt="Screen Shot 2020-07-25 at 12 57 39 AM" src="https://user-"These are markdown horizontal rules but look out of place. I think they are the only place I've seen them used in the settings UI VS Code version: Code - Insiders 1.48.0-insider (, 2020-07-24T05:51:27.957Z) OS version: Darwin x64 19.6.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
I these as part of my PR . IMO this setting is unusual in its complexity, and the lines are intended to help the user parse the large quantity of information being presented.
I think they look alright personally, maybe a little heavy if anything?
This is the only setting I see that uses them so I feel they look out of place. A normal paragraph break the sections would probably work If we keep the horizontal rules, my recommendations would be: Add top and bottom padding to them Adjust the color to be less bright Potentially adjust the width to only span part of the text width may be able to provide better suggestions
I agree with suggestions
Using Developer Tools I the following to the first element created by the markdown: Result is: ! Then I and applied the styling to both lines to get this: ! And with the default light theme: ! Is that more acceptable?
What does it look like with a normal paragraph break?
! Or removing the italics and splitting that into its own para: !
The paragraphs are just as impactful as the rules imo.
The second example with the newlines look good to me. Thanks for taking a look! We may also want to check in the css to make the horizontal rules look better since settings from extensions could still use them
Change:
let tsServerLogFile: string | undefined; if (kind === TsServerProcessKind.Syntax) { <del> if (semver.gte(API.v400rc.fullVersionString, apiVersion.fullVersionString)) { args.push('--serverMode'); args.push('partialSemantic'); } else { </del> <ins> if (apiVersion.gte(API.v401)) { args.push('--serverMode', 'partialSemantic'); } else { </ins> args.push('--syntaxOnly'); } }

Discussion:
Issue Type: <bBug</brepo your user tsdk to use this version, for example: load the VS Code workspace (making sure you are using your user TS version) a file in and try getting the document outline Bug Big delay. This is because two full TS Servers are being spawned instead of a syntax only server + full server (see memory usage in screenshot): <img width="1079" alt="Screen Shot 2020-08-11 at 3 13 33 PM" src="https://user-"VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-11T10:13:04.551Z) OS version: Darwin x64 19.6.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Seems like this was caused by
For verification, try the following cases: Using TS 3.9.7 Using TS 4.0.1-rc Using TS Using an old TS version like 3.5 (older versions don't support the syntax server at all) All should load the document symbols quickly even while the loading spinner is showing You can use the same global install in all cases, just make sure to reload VS Code each time
Assigning this to july milestone since it is a candidate.
following your steps I have verified that the outline get loaded quickly, however I still see two tsservers spinning up when I open the process explorer. If I understood correctly this is by design, since only one of them has a large memory usage. I have verified for TS: 3.9.7, 4.0.1-rc. ts 3.5 Thus adding verified label !