jiebi/CodeConvo huggingface dataset:
Code change:
'use strict'; import * as assert from 'assert'; <del> import { IFilter, or, matchesPrefix, matchesStrictPrefix, matchesCamelCase, matchesSubString, matchesContiguousSubString, matchesWords } from 'vs/base/common/filters'; </del> <ins> import { IFilter, or, matchesPrefix, matchesStrictPrefix, matchesCamelCase, matchesSubString, matchesContiguousSubString, matchesWords, fuzzyMatchAndScore } from 'vs/base/common/filters'; </ins> function filterOk(filter: IFilter, word: string, wordToMatchAgainst: string, highlights?: { start: number; end: number; }[]) { let r = filter(word, wordToMatchAgainst);

Related discussion:
text: <!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.1 OS Version: macOS Is it possible for VSCode to support the following kinds of auto complete, please see screenshots Word completion: <img width="357" alt="screen shot 2017-03-07 at 10 23 19 am" src=""Member function completion: <img width="359" alt="screen shot 2017-03-07 at 10 20 22 am" src=""All auto-completions come with fuzzy matching. Steps to Reproduce:
Agree, actually fuzzy matching only works with camel Case, but in sublime and atom you can get completion by typing any middle letter of the target word. I still miss this feature in vscode
I like, tho will be some work and maybe some adjustment for folks that are used to our current filtering and ranking
This got implemented with <img width="280" alt="screen shot 2017-03-20 at 17 38 54" src=""
And this is valid for all languages then?
Yes, we have changed the default matcher to be more fuzzy.
VSCode: 11.0-insider I appear to be getting stuck in a recursive loop, and according to DevTools (I clicked Pause in the Debugger) it is happening in . I tested this with . I was able to reproduce this with a simple HTML file: After typing the opening and IntelliSense appears, trying to type an additional character will freeze the whole VSCode.
Thanks for the heads-up. You are right, there are situations in which it keeps recursing forever. I have implemented a different approach today and just pushed the last changes. Will be in tomorrows insiders.
Code change:
interface UriState extends UriComponents { $mid: number; <del> fsPath: string; </del> external: string; <ins> fsPath: string; _sep: 1 | undefined; </ins> } <ins> const _pathSepMarker = isWindows ? 1 : undefined; </ins> // tslint:disable-next-line:class-name class _URI extends URI {

Related discussion:
text: The cache is preserved throughout URI serialization. We should invalidate it when the URI crosses platform boundaries. Related to
Code change:
const workingCopyAdapter = new class implements IWorkingCopy { readonly resource = input.modelUri; get name() { return input.getName(); } <del> readonly capabilities = input.isUntitled() ? WorkingCopyCapabilities.Untitled : 0; </del> <ins> readonly capabilities = input.isUntitled() ? WorkingCopyCapabilities.Untitled : WorkingCopyCapabilities.None; </ins> readonly onDidChangeDirty = input.onDidChangeDirty; readonly onDidChangeContent = input.onDidChangeContent; isDirty(): boolean { return input.isDirty(); }

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: head OS Version: n/a This is a bug/inconsistency in the VSC codebase, which is currently obscured because of the specific way the code is written. This wouldn't really matter, but when using a build step that generates files for dependencies, the gets evaluated down to and compilation fails. And overall, it'd be nice for the types to align in a sensible way. Steps to Reproduce: , replace with Expected: compiles fine Actual: there are a number of errors like Property 'getFirstLineText' does not exist on type 'never'. The intersection 'this &amp; IResolvedTextFileEditorModel' was reduced to 'never' because property 'capabilities' has conflicting types in some (2339)TextFileEditorModelIWorkingCopyIResolvedTextFileEditorModelthis.isResolved() is known to be true) says capabilities should be a readonly 2. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since this seems to concern only you with your specific setup, wanna do a PR to fix this?
I would be more than happy to, but I'm not sure what approach you'd find (in)appropriate. could type in as a number instead of an enum (since checks against it are anyways done via bitwise-and) could change in to actually be 2 instead of 0 (though it seems like you also use 0 for this field in other places like , and somehow TSC doesn't care...) could add a enum value of 0 to , since it seems like that's how you use it. I'm leaning towards approach 3. What are your thoughts?
Yeah I think we can give 3. a try in a PR.
Code change:
minimap: { enabled: false }, <ins> wordWrap: 'on', </ins> }; const diffEditorOptions: IDiffEditorConstructionOptions = {

Related discussion:
text: When a test fails, it might sometimes look like this: ! By pressing in both editors, I can get it to look like this, which is more helpful for long strings: ! It might be better to enable word wrapping by default for string comparisons.
Code pointer:
Is this issue up for grabs? I would love to implement this
Yep
Could you assign me to this issue?
No, only people in the Microsoft org can be assigned issues. You can open a PR without being assigned though
I agree this is a better default. Thanks Maybe a setting to make this customizable? Not sure how many people would care.
How do I update commonEditorOptions dynamically? Replace every usage of commonEditorOptions with ?
Code change:
moveTo(thisCursor, 1, 8); moveTo(thisCursor, 3, 9, true); moveToBeginningOfLine(thisCursor, false); <del> assertCursor(thisCursor, new Selection(1, 6, 1, 6)); </del> <ins> assertCursor(thisCursor, new Selection(3, 5, 3, 5)); </ins> }); test('move to beginning of line with selection multiline backward', () => {

Related discussion:
text: VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-09T12:05:39.439Z) OS Version: Linux x64 4.8.0-28-generic Extensions: Steps to Reproduce: an untitled file and add content: the cursor after the shift, press down and then end, the selection should be shift, press home, the selection should be but it is because the select went to the start of the wrong line.
This used to work till yesterday... something broke. I'm pressing <kbdend</kbdafter going 3 lines above, and the cursor goes to the end of the selectionStart line. !
Code change:
this._slider.setHeight(layout.sliderHeight); // Compute horizontal slider coordinates <del> const scrollLeftChars = renderingCtx.scrollLeft / this._model.options.typicalHalfwidthCharacterWidth; const horizontalSliderLeft = Math.min(this._model.options.minimapWidth, Math.round(scrollLeftChars * this._model.options.minimapCharWidth / this._model.options.pixelRatio)); this._sliderHorizontal.setLeft(horizontalSliderLeft); this._sliderHorizontal.setWidth(this._model.options.minimapWidth - horizontalSliderLeft); </del> <ins> this._sliderHorizontal.setLeft(0); this._sliderHorizontal.setWidth(this._model.options.minimapWidth); </ins> this._sliderHorizontal.setTop(0); this._sliderHorizontal.setHeight(layout.sliderHeight);

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.60.2 Commit: Date: 2021-09-22T11:59:27.195Z (1 wk ago) Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: a large file with a long line to be scrollable over the file (x and y axis). right. on minimap. Actual: The minimap slider does not have full width. Expected: The minimap slider is always full width.
Could you please also add a screenshot, I am not sure what you are referring to.
Please check. https://user-
can I work on this issue. if yes code pointers to investigate.
PR welcome.
thanks
what would be the expected behaviour of the minimap for a horizontal scroll?
I think we could just remove that the slider moves horizontally and let it stay put.
I think it should be:
These lines of code should work if you support scrolling horizontally for the minimap slider. At this time, we can only scroll the minimap slider vertically.
Okay, I can do that but I think it would be much better if we allow horizontal scroll in minimap. what do you think about that?
Code change:
return []; } <del> return [currentHistoryItemGroup.name, currentHistoryItemGroup.remote?.name ?? '', currentHistoryItemGroup.base?.name ?? '']; </del> <ins> return [ currentHistoryItemGroup.name, currentHistoryItemGroup.remote?.name, currentHistoryItemGroup.base?.name] .filter(l => l !== undefined); </ins> } private getTooltip(element: SCMHistoryItemViewModelTreeElement): IManagedHoverTooltipMarkdownString {

Related discussion:
text: Testing I find it a little weird how there is a cloud badge on the list item and that represents 2 different items origin/main and origin/HEAD in the hover? <img width="1031" alt="Screenshot 2024-08-27 at 10 31 23 AM" src=""Should these be different icons? Should it be a single item ? Should they be the same color?
Code change:
} while(m); return counter; } <del> } </del>  No newline at end of file <ins> } </ins>

Related discussion:
text: Using regex expressions am unable to find empty lines. Tried both the end of line sequence. Copying the same text in sublime simple n finds all the blank lines.
That has been an issue for me for quite a while. Never really checked again if it's already working because I started to automatically open notepad++ again whenever I needed to replace newlines.
This problem could manifest if the lines are being split before searching as opposed to doing a full text search. Interesting side note; seems to work in find in files (Ctrl+Shift+F), just not in the find dialog (Ctrl+F).
Couldn't even find empty lines with ^$ (in case they were being split without EOL).
Looked at the code, it does indeed look at each line individually. I'm created a new issue for multi-line matching
Code change:
public setInput(input: FileEditorInput, options?: EditorOptions): TPromise<void> { <del> // We have a current input in this editor and are about to either open a new editor or jump to a different // selection inside the editor. Thus we store the current selection into the navigation history so that // a user can navigate back to the exact position he left off. if (this.input) { const selection = this.getControl().getSelection(); if (selection) { this.historyService.add(this.input, { startLineNumber: selection.startLineNumber, startColumn: selection.startColumn }); } } </del> // Return early for same input unless we force to open const forceOpen = options && options.forceOpen; if (!forceOpen && input.matches(this.input)) {

Related discussion:
text: Steps to Reproduce: The cursor should go back to the exact spot where it was before the jump. Instead, it goes one sport further back...
Can you provide more details like VS Code version, OS type and version etc. Also, sample code of what you are trying to do in your extension and a screencast/gif/video ?
Likely
There is no extension involved. This is vanilla behaviour. Using version 1.4 on Ubuntu 16.04. Related to , but not the same. This is likely to be very easy to fix (jumpToDefinition event should push the current cursor position to the history).
I agree we should record the current cursor position on certain actions like "Go to definition".
Pushed a change to improve this situation for the following cases: goto definition will store the current cursor location as history entry so that when jumping back you end up in the same line number opening another editor will now also store the current cursor in the history so that going back puts you to the exact same line number too
Code change:
"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "25.8.0", </del> <ins> "electron": "25.8.1", </ins> "eslint": "8.36.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^46.5.0",

Related discussion:
text: Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.
Code change:
"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "25.8.0", </del> <ins> "electron": "25.8.1", </ins> "eslint": "8.36.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^46.5.0",

Related discussion:
text: I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.
Code change:
private gotoDefinition(position: Position, openToSide: boolean): Promise<any> { this.editor.setPosition(position); <del> const action = new DefinitionAction({ openToSide, openInPeek: false, muteMessage: true }, { alias: '', label: '', id: '', precondition: undefined }); </del> <ins> const openInPeek = this.editor.getOption(EditorOption.definitionLinkOpensInPeek); const action = new DefinitionAction({ openToSide, openInPeek: openInPeek, muteMessage: true }, { alias: '', label: '', id: '', precondition: undefined }); </ins> return this.editor.invokeWithinContext(accessor => action.run(accessor, this.editor)); }

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When we use to jump to definition, would open the definition in a new window, which is inconvenient for me. It would be better if we can choose where to open definition, like in . !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.492 --- <!-- score: 0.467 --<!-- potentialduplicatescomment --
Nice suggestion. If you agree with this, I'll create a setting so one can choose if 'ctrl+click' always opens the peek view.
Normally, ctrl+click runs and cmd+ctrl+click opens . With this setting enabled, they both run . I don't think that's expected. Possibly change to ?
you can reopen verification-found issues
Uhm, I'll take a look on that. Thanks for your feedback!
Please file a bug and don't reopen feature requests
I created
Code change:
<del> <svg xmlns="http://www.w3.org/2000/svg" width="24" height="36" viewBox="0 0 24 36.1"><defs><style>.a{fill:#fff;}</style></defs><title>flipped-cursor-mac-2x</title><polygon points="8.6 33.1 11.8 23.9 2.2 23.9 23 2.5 23 31.3 17.4 26.1 14.2 35.1 8.6 33.1"/><path class="a" d="M22,29.1l-5-4.6-3.062,8.938-4.062-1.5L13,23H5L22,5M0,25H10.4l-3,8.3L15,36.1l3.125-7.662L24,33V0Z"/></svg> </del>  No newline at end of file <ins> <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 26 38" style="enable-background:new 0 0 26 38;" width="26" height="38"><style type="text/css">.st0{stroke:#FFFFFF;stroke-miterlimit:10;}</style>	<title>flipped-cursor-mac</title><path class="st0" d="M10.6,33.2l3.2-9.4H4.2L25,2.4v28.8L19.4,26l-3.2,9.2c-0.4,1-1.6,1.6-2.6,1.2L12,35.8 C10.8,35.4,10.2,34.4,10.6,33.2z"/></svg> </ins>

Related discussion:
text: VSCode Version:1.30.2 OS Version: Applies to Windows and OS X When the cursor flips on line numbers the SVG used has inconsistency's with the system defaults, e.g. tail is shorter Does this issue occur when all extensions are disabled?: Yes
Code change:
} const browserPlugins = [ <ins> new optimize.LimitChunkCountPlugin({ maxChunks: 1 }), </ins> new CopyWebpackPlugin({ patterns: [ { from: 'src', to: '.', globOptions: { ignore: ['**/test/**', '**/*.ts'] }, noErrorOnMissing: true }

Related discussion:
text: developer tools console :bug: see a bunch of errors like this for github authentication, microsoft authentication, typescript language features, remote repositories etc
Code change:
focusNextNotebookCell(cell: IGenericCellViewModel, focus: 'editor' | 'container' | 'output'): Promise<void>; updateOutputHeight(cellInfo: ICommonCellInfo, output: ICellOutputViewModel, height: number, isInit: boolean): void; deltaCellOutputContainerClassNames(diffSide: DiffSide, cellId: string, added: string[], removed: string[]): void; <ins> previousChange(): void; nextChange(): void; </ins> } export interface IDiffNestedCellViewModel {

Related discussion:
text: Testing Ideally there would be commands to navigate between changes. And they might deserve an action in the diff title bar. Same as the editor diff experience. !
Why is for these commands? I would expect them to be available from the command palette, since in a regular text editor Show Previous Change and Show Next Change both appear.
Code change:
focusNextNotebookCell(cell: IGenericCellViewModel, focus: 'editor' | 'container' | 'output'): Promise<void>; updateOutputHeight(cellInfo: ICommonCellInfo, output: ICellOutputViewModel, height: number, isInit: boolean): void; deltaCellOutputContainerClassNames(diffSide: DiffSide, cellId: string, added: string[], removed: string[]): void; <ins> previousChange(): void; nextChange(): void; </ins> } export interface IDiffNestedCellViewModel {

Related discussion:
text: Testing Notice that the scroll range is below the decorations, even though they're on screen <img width="717" alt="image" src="https://user-"Meanwhile if I scroll to where they're shown, they aren't in viewport <img width="713" alt="image" src="https://user-"This was on the following gif: <img width="401" alt="image" src="https://user-"