jiebi/CodeConvo huggingface dataset:
Code change:
} } linkCandidates.push(...specialEndLinkCandidates); <ins> this._logService.trace('terminalLocaLinkDetector#detect linkCandidates', linkCandidates); </ins> // Validate the path and convert to the outgoing type const simpleLink = await this._validateAndGetLink(undefined, bufferRange, linkCandidates, trimRangeMap);

Related discussion:
text: A command I wrote without line/column numbers works fine: ! A command I wrote with line/column numbers works fine: !
It's a little hard to tell if this is by design or not without knowing the exact cwd and full path of these folders. What we're going for is verify if the file is real if it's relative to the current working directory (which is citro3d-rs in your last 2, not sure for the first), otherwise fall back to word links. Since you changed wordSeparators, the fall back isn't as useful, but it looks like it's working properly.
Ah sorry I forgot to include those extra details. The cwd and path was the same in all 3 cases (i.e., the relative file path should work in each case, I think?): I guess the part that doesn't make sense to me is why the latter two cases work but the first one doesn't - since in each case the path is the same and I haven't changed directories at all. I suppose the workaround of removing and from is still an option but it would be nice if the linking was more consistent.
Yeah this is strange if it's all the same cwd. I Can't repro here I'm improving trace logging in , when that is released to insiders (the day after it's merged) you will be able to set the log level via the command palette (F1) and view the trace logs when hovering the terminal line by looking in the Output panel Window dropdown entry. That will give us some more info on why this is happening.
The logging changes should be in tomorrow's insiders
thanks for that, here is the trace log output that I think is relevant for debugging. Please let me know if you need more info or another reproduction: Edit: the cwd again was and the relative path should resolve: <details<summarytrace output</summary</detailsOne odd thing I noticed - without changing any settings, I actually had one instance where it worked as expected and linked the relative path to . However I'm not sure how or why it worked. When I opened a new terminal the old behavior (not linking) came back. If I can reproduce that again I'll try to capture those trace logs and maybe it will highlight a difference in behavior that's helpful. Thanks again for looking at this!
Code change:
} } linkCandidates.push(...specialEndLinkCandidates); <ins> this._logService.trace('terminalLocaLinkDetector#detect linkCandidates', linkCandidates); </ins> // Validate the path and convert to the outgoing type const simpleLink = await this._validateAndGetLink(undefined, bufferRange, linkCandidates, trimRangeMap);

Related discussion:
text: So there's this in the logs: So it's parsed as a possible link, but not made a link candidate (which checked the file system before making the link). Somehow this part isn't adding the candidate: The only way I think that could happen is if doesn't return anything. I another log to verify the cwd and also improved fallback in case it is undefined. Can you do the same again on the next Insiders which should come out on Monday?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the delay, was a bit busy last week but I was able to check with a recent build (): The link is clickable now, even with and both in ! I'm guessing the fallback changes you did the trick. It seems the triage bot closed this as "not planned" but maybe you are able to update its status to "fixed" or similar? Thanks for your help looking into this issue!
great news! I still don't totally understand how it was failing before but at least the issue is fixed
Code change:
DOM.removeClass(image, 'scale-to-fit'); image.style.minWidth = `${(image.naturalWidth * scale)}px`; <del> image.style.widows = `${(image.naturalWidth * scale)}px`; </del> <ins> image.style.width = `${(image.naturalWidth * scale)}px`; </ins> const newWidth = image.width; const scaleFactor = (newWidth - oldWidth) / oldWidth;

Related discussion:
text: Issue Type: <bBug</bwhen clicking the percentage at the bottom-right of the state bar,zooming function won't work, and the aspect ratio changes to abnormal value. VS Code version: Code 1.28.1 (, 2018-10-11T18:13:53.910Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (9)</summaryExtensionVersion ------ intellij-idea-keybindings0.2.27 vscode-language-pack-zh-hans1.28.2 mssql1.4.0 java0.32.0 vscode-java-debug0.14.0 vscode-java-pack0.4.0 vscode-java-test0.10.0 vscode-maven0.11.1 markdown-all-in-one1.6.2 </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.47 --<!-- potentialduplicatescomment --
Code change:
export function startsWithUTF8BOM(str: string): boolean { return (str && str.length > 0 && str.charCodeAt(0) === __utf8_bom); <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:
import { Extensions, IConfigurationRegistry } from 'vs/platform/configuration/common/configurationRegistry'; import { IQuickInputService, IQuickPickItem } from 'vs/platform/quickinput/common/quickInput'; import { ExtensionsRegistry } from 'vs/workbench/services/extensions/common/extensionsRegistry'; <del> import { ContextKeyExpr, ContextKeyExpression, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </del> <ins> import { ContextKeyExpr, ContextKeyExpression, IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </ins> import { ICommandService } from 'vs/platform/commands/common/commands'; import { getVirtualWorkspaceLocation } from 'vs/platform/workspace/common/virtualWorkspace'; import { Schemas } from 'vs/base/common/network'; import { IsWebContext } from 'vs/platform/contextkey/common/contextkeys'; import { isProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; import { EditSessionsLogService } from 'vs/workbench/contrib/editSessions/common/editSessionsLogService'; <del> import { IViewContainersRegistry, Extensions as ViewExtensions, ViewContainerLocation } from 'vs/workbench/common/views'; </del> <ins> import { IViewContainersRegistry, Extensions as ViewExtensions, ViewContainerLocation, IViewsService } from 'vs/workbench/common/views'; </ins> import { SyncDescriptor } from 'vs/platform/instantiation/common/descriptors'; import { ViewPaneContainer } from 'vs/workbench/browser/parts/views/viewPaneContainer'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation';

Related discussion:
text: fyi
Verification: opt into edit sessions using , then ensure the edit sessions view does not appear in the sidebar until you run the Show Edit Sessions action in the command palette.
Code change:
.search-view > .results > .monaco-tree .monaco-tree-row.focused .content .filematch .monaco-count-badge, .search-view > .results > .monaco-tree .monaco-tree-row.focused .content .foldermatch .monaco-count-badge, .search-view > .results > .monaco-tree .monaco-tree-row.focused .content .linematch .monaco-count-badge { <del> display: none; </del> <ins> margin-right: 0; </ins> } .search-view .focused .monaco-tree-row.selected:not(.highlighted) > .content.actions .action-remove,

Related discussion:
text: <!-- 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.29-insider OS Version: Windows 10 Version 1809 (OS Build .1000) Steps to Reproduce: Find in files and search for something that will return results over different result lines Badge and Action button (Dismiss) are on the left (aligned to the end of result text) I'm expecting that Dismiss action will have fixed horizontal position (on the right side) that will allow me to easily dismiss several results entries. With current position at the end of result text I have to constantly move mouse to hit Dismiss button. In stable version both count badge (for file) and Dismiss action were aligned at the right side of the viewlet which was convenient. At this moment it is hard to filter out result entries because texts have different length and button shifts for each line. I've found which says that button should always stay on the right side, however this isn't case in v1.28.2 independently from viewlet width (both badge and actions are on the right side). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <details<summaryScreenshot</summary<div! </div</details
I guess this only applies to the search panel?
Yes, I observe issue in Search panel. UPD. Checked - same behavior when Search: Location is set to sidebar.
You should see the actions on the right when search is narrow, and on the left when it's somewhat wide. The reason is that when the actions are on the right and the text is aligned to the left, it can be hard to associate the two, so it seems more user-friendly to put the actions closer to the actual result. Maybe the threshold could be tweaked, but it doesn't feel good to click an action on the opposite side of the monitor from the actual text. Does this match what you see?
Yes, that match what I see, but makes it harder to use Dismiss action with mouse. For badge with results count - it is good position, since it is visible without hover. On the other hands actions are only visible on hover, when background can clearly indicate what line will be dismissed.
Code change:
.search-view > .results > .monaco-tree .monaco-tree-row.focused .content .filematch .monaco-count-badge, .search-view > .results > .monaco-tree .monaco-tree-row.focused .content .foldermatch .monaco-count-badge, .search-view > .results > .monaco-tree .monaco-tree-row.focused .content .linematch .monaco-count-badge { <del> display: none; </del> <ins> margin-right: 0; </ins> } .search-view .focused .monaco-tree-row.selected:not(.highlighted) > .content.actions .action-remove,

Related discussion:
text: Previously (September and numerous builds before) I was able to put mouse over X and just click (even without looking) several times to remove unnecessary lines. Now it takes more time/attention to do it with mouse, and if next line after dismissed has longer text - it is easy to open file instead of dismissing it. Open editors view (Close editor button), Source control (action buttons for files), Extensions (Manage button) - have static position of actions that are not changed with sidebar width. My cases are 23" monitor with 1920x1080 and Surface Pro 3. Never had problems when action were on the right side. Users with 4k 30+" will have to snipe for X too.
Yes it was broken for a few months, but this was the behavior from before it was broken I see your point but I will leave this open to think about it
thanks!
Putting the dismiss button to the right would also make it less likley that someone presses it by accident which I just did. The middle of a search result might be just above/below the end of another so that clicking just a bit above/below where you intended could lead you to remove the other search result.
Issue 1) The dismiss buttons are too close to the actual text of the search result making it very easy to accidentally dismiss something. Issue 2) The dismiss buttons are invisible until hover/focus. So if you had your focus on another panel or another window and then click on a search result to focus it, it's too easy to click on an invisible button and accidentally dismiss a search result because of issue 1.
Trying to decide whether we should just always right align... but it seems weird to me to have the X really far away from the row content in some cases. Anyway, if someone wants to add a setting to configure this, I would take that PR.
Code change:
private async doSearch(fqs: IFolderQuery<URI>[], onResult: (match: IInternalFileMatch) => void): Promise<IFileSearchProviderStats | null> { const cancellation = new CancellationTokenSource(); const folderOptions = fqs.map(fq => this.getSearchOptionsForFolder(fq)); <ins> const session = this.provider instanceof OldFileSearchProviderConverter ? this.sessionLifecycle?.tokenSource.token : this.sessionLifecycle?.obj; </ins> const options: FileSearchProviderOptions = { folderOptions, maxResults: this.config.maxResults ?? DEFAULT_MAX_SEARCH_RESULTS, <del> session: this.sessionToken </del> <ins> session </ins> };

Related discussion:
text: a traditional . , listen for debugging the extension, open a file picker, then close it. session token's never gets triggered when the session is done (aka when the file picker is closed) :bug: This contradicts
regression from
Code change:
private async doSearch(fqs: IFolderQuery<URI>[], onResult: (match: IInternalFileMatch) => void): Promise<IFileSearchProviderStats | null> { const cancellation = new CancellationTokenSource(); const folderOptions = fqs.map(fq => this.getSearchOptionsForFolder(fq)); <ins> const session = this.provider instanceof OldFileSearchProviderConverter ? this.sessionLifecycle?.tokenSource.token : this.sessionLifecycle?.obj; </ins> const options: FileSearchProviderOptions = { folderOptions, maxResults: this.config.maxResults ?? DEFAULT_MAX_SEARCH_RESULTS, <del> session: this.sessionToken </del> <ins> session </ins> };

Related discussion:
text: Testing The type cannot be used with because that requires objects (no primitives). We should accommodate for that and change the API accordingly.
Code change:
private open(id: string, extension: IExtension, template: IExtensionEditorTemplate): Promise<IActiveElement | null> { switch (id) { case NavbarSection.Readme: return this.openReadme(template); <del> case NavbarSection.Contributions: return this.openContributions(template); </del> <ins> case NavbarSection.FeatureContributions: return this.openContributions(template); </ins> case NavbarSection.Changelog: return this.openChangelog(template); case NavbarSection.Dependencies: return this.openDependencies(extension, template); case NavbarSection.ExtensionPack: return this.openExtensionPack(extension, template);

Related discussion:
text: Issue Type: <bFeature Request</bI never used the "Contributions" tab in extensions, thinking it was for recent github contributions to the extension. I accidentially pressed it once, and found it very useful. I think the name "Contributions" is confusing and that "Details", "Internals" , "Technical Details", or something similar would make it much clearer. VS Code version: Code 1.41.1 (, 2019-12-18T15:04:31.999Z) OS version: Linux x64 5.4.14-200.fc31.x86_64 <!-- generated by issue reporter --
These are in fact contributions to VS Code. How about ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Code change:
return undefined; } get cwd(): string | undefined { return this._cwd; } <ins> private get _isInputting(): boolean { return !!(this._currentCommand.commandStartMarker && !this._currentCommand.commandExecutedMarker); } get hasInput(): boolean | undefined { if (!this._isInputting || !this._currentCommand?.commandStartMarker) { return undefined; } if (this._terminal.buffer.active.baseY + this._terminal.buffer.active.cursorY === this._currentCommand.commandStartMarker?.line) { const line = this._terminal.buffer.active.getLine(this._terminal.buffer.active.cursorY)?.translateToString(true, this._currentCommand.commandStartX); if (line === undefined) { return undefined; } return line.length > 0; } return true; } </ins> private readonly _onCommandStarted = new Emitter<ITerminalCommand>(); readonly onCommandStarted = this._onCommandStarted.event;

Related discussion:
text: Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.
Code change:
} protected restoreViewState(input: EditorInput) { <del> if (input instanceof UntitledEditorInput) { </del> <ins> if (input instanceof UntitledEditorInput || input instanceof ResourceEditorInput) { </ins> const viewState = this.loadTextEditorViewState(input.getResource().toString()); if (viewState) { this.getControl().restoreViewState(viewState);

Related discussion:
text: Start legacy protocol debug session Open something via "Open loaded scripts" scroll down ctrl+tab to switch to another doc ctrl+tab back to the newly opened script It's scrolled up to the top. Is it being closed/opened each time we switch away?
This problem is independent from the "Open Loaded Scripts" feature. To reproduce: debug a simple node hello world program and stop on entry in the CALL STACK select an internal module press Control-Tab twice (to switch between two editors) Observe: you loose the scroll position in the internal module
March to investigate
Workbench is not preserving scroll location of in memory resources. Same is true for diff view. Forwarding to since he probably already has an issue for this
I do but I cannot find it right now, PR welcome.
give me some code pointers for the PR and I can do it in debt week
we do it for and via the and methods that are actually defined in and we could probably push this down from and and just use it from textEditor for any input that has a resource
Ok, makes sense. Assigning to me and April to look into it
Related:
With landed, we keep the UI state when you switch editors, though we clear it when you close a tab. The rationale is that the lifecycle of these editors that have virtual resources is not known, as such we assume the view state can be ditched once the editor closes.
That sounds perfect!
Code change:
<del> <svg xmlns="http://www.w3.org/2000/svg" width="15" height="21" x="0px" y="0px" viewBox="0 0 15 21" style="enable-background:new 0 0 15 21;"><polygon style="fill:#FFFFFF;stroke:#000000" points="14.5,1.2 1.9,13.8 7.1,13.8 4.5,19.1 7.7,20.1 10.3,14.9 14.5,18"/></svg> </del>  No newline at end of file <ins> <svg xmlns="http://www.w3.org/2000/svg" width="15" height="25" x="0px" y="0px" viewBox="0 0 15 25" style="enable-background:new 0 0 15 25;"><polygon style="fill:#FFFFFF;stroke:#000000" points="14.5,1.2 1.9,13.8 7,13.8 3.2,21.5 6.3,22.5 10.1,14.9 14.5,18"/></svg> </ins>  No newline at end of file

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:
import { WebviewResourceProvider } from './util/resources'; import { isOfScheme, Schemes } from './util/schemes'; <del> const UNICODE_NEWLINE_REGEX = /u2028|u2029/g; </del> /** * Adds begin line index to the output via the 'data-line' data attribute. */

Related discussion:
text: When rendering Markdown preview, Unicode newline characters U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are replaced with an empty string at the source preprocessing stage. This behavior was introduced in to but it breaks the document in multiple ways: double-click word selection does not work as expected, screen readers may announce the text incorrectly, line wrapping and hyphenation does not work correctly, markdown-it plugins that rely on or may work incorrectly, even linkify fails: and so on. Since then it was fixed at the markdown-it side, and is no longer needed: It would be better to revert this change, and keep the Markdown source as is before feeding it to the parser. Steps to reproduce: a Markdown document like this: preview: Expected result: LS and PS are displayed as is, links end at Unicode newlines. Actual result: no Unicode newline characters displayed, links also consume the immediately following word. <!-- 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: OS Version: WindowsNT x64 10.0.
<!-- 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!
Code change:
} .quick-input-widget .interactive-session .interactive-input-part .interactive-execute-toolbar { <del> bottom: 1px; </del> <ins> margin-bottom: 1px; </ins> } .quick-input-widget .interactive-session .interactive-input-and-execute-toolbar {

Related discussion:
text: In VS Code action items inside inputs are vertically aligned to top, in the Chat features they are centered in the middle. This happens when putting in a lot of text or pressing Shift+Enter. Panel: <img width="425" alt="image" src=""Inline: <img width="608" alt="image" src=""Quick: <img width="621" alt="image" src=""For Inline and Quick the action items to the right of the input box should also stick to the top.
Seems like we have a mix of top-aligned and overflow w/ scroll (see below). But I agree that we should be consistent as much as possible. But it does feel like a chat send button should generally but aligned to the bottom, no? We may even consider rendering the toolbar on its own row once we're into multiple lines. That would ensure the text isn't forced to fill a tiny space now that we have 2+ icons. Here's how Teams does it as an example: ! ! ! !
Would be awesome if the text could wrap around it, especially in the narrow search widget case, I've always wanted that but I think it would be a pain to implement.
Don't have a strong opinion about top or bottom, I think each can be justified on a case-by-case basis. but middle looks weird. :) For example, inline Chat may want to do top alignment as the icons would align with those outside the input field (poppet and close) Bottom would help with the wrapping.