jiebi/CodeConvo huggingface dataset:
Code change:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

Related discussion:
text: if (this._placeholderDecoration?.marker.id) { this._decorations.delete(this._placeholderDecoration?.marker.id); } <ins> if (command.command.trim().toLowerCase() === 'clear' || command.command.trim().toLowerCase() === 'cls') { this.clearDecorations(); return; } </ins> this._placeholderDecoration?.dispose(); this.registerCommandDecoration(command); });
Code change:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

Related discussion:
text: const lineHeight = this._configurationService.inspect(TerminalSettingId.LineHeight).value; if (typeof fontSize === 'number' && typeof defaultFontSize === 'number' && typeof lineHeight === 'number') { const scalar = (fontSize / defaultFontSize) <= 1 ? (fontSize / defaultFontSize) : 1; // must be inlined to override the inlined styles from xterm element.style.width = `${scalar * DecorationStyles.DefaultDimension}px`; element.style.height = `${scalar * DecorationStyles.DefaultDimension * lineHeight}px`; element.style.fontSize = `${scalar * DecorationStyles.DefaultDimension}px`; <del> // the first split terminal in the panel has more room if (element.closest(DecorationSelector.FirstSplitContainer)) { element.style.marginLeft = `${scalar * DecorationStyles.MarginLeftFirstSplit}px`; } else { element.style.marginLeft = `${scalar * DecorationStyles.MarginLeft}px`; } </del> <ins> element.style.marginLeft = `${scalar * DecorationStyles.MarginLeft}px`; </ins> } }
Code change:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

Related discussion:
text: element.classList.remove(classes); } element.classList.add(DecorationSelector.CommandDecoration, DecorationSelector.Codicon, DecorationSelector.XtermDecoration); <ins> element.parentElement?.parentElement?.parentElement?.classList.add(DecorationSelector.ShellIntegration); </ins> if (exitCode === undefined) { element.classList.add(DecorationSelector.DefaultColor); element.classList.add(`codicon-${this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationIcon)}`);
Code change:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

Related discussion:
text: this.raw.clearTextureAtlas(); } <ins> clearDecorations(): void { this._decorationAddon?.clearDecorations(true); } </ins> forceRefresh() { this._core.viewport?._innerRefresh();
Code change:
Testing We should consider increasing the line height for headers in order to provide spacing between lines. !
Possibly related: and
cc
It is also perhaps reasonable to suggest that the top margin is too large on the first header so you end up with more space at the top of the markdown block than at the bottom and it is not possible to balance if you want a header at the top. It might be worth considering some styles that remove the margin-top from headers when inside a ?

Related discussion:
text: .monaco-hover p, .monaco-hover .code, <del> .monaco-hover ul { </del> <ins> .monaco-hover ul, .monaco-hover h1, .monaco-hover h2, .monaco-hover h3, .monaco-hover h4, .monaco-hover h5, .monaco-hover h6 { </ins> margin: 8px 0; } <ins> .monaco-hover h1, .monaco-hover h2, .monaco-hover h3, .monaco-hover h4, .monaco-hover h5, .monaco-hover h6 { line-height: 1.1; } </ins> .monaco-hover code { font-family: var(--monaco-monospace-font); }
Code change:
Issue Type: <bBug</bRunning tasks with dependencies in a multi-root workspace executes the wrong dependency tasks, if there are multiple tasks defined under the same label but in different root folders. VSCode will just pick the first occurance in the order of the root folders defined in the workspace settings. To reproduce the issue: a simple multi-root workspace, e.g. each root folder, add a with two tasks. One task depends on the other. Example tasks of : and have the same tasks configured except that they echo their respective folder name instead. task of either or . VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Experiencing same issue on: VS Code version: 1.65.1 OS version: macOS 12.2.1 BuildVersion:21D62
To verify: or create a multi root workspace with 2 roots, FolderOne and FolderTwo (or names of your choice). each of your roots add a .vscode folder. each of your .vscode folders add a file with the following contents: "PrimaryTask" in FolderOne (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderOne" next to it). Verify that both PrimaryTask and DependsTask echo FolderOne's path. "PrimaryTask" in Folder Two (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderTwo" next to it). Verify that both PrimaryTask and DependsTask echo FolderTwo's path.

Related discussion:
text: let resolverData: Map<string, ResolverData> | undefined; <del> async function quickResolve(that: AbstractTaskService, identifier: string | TaskIdentifier) { </del> <ins> async function quickResolve(that: AbstractTaskService, uri: URI | string, identifier: string | TaskIdentifier) { </ins> const foundTasks = await that._findWorkspaceTasks((task: Task | ConfiguringTask): boolean => { <ins> const taskUri = ((ConfiguringTask.is(task) || CustomTask.is(task)) ? task._source.config.workspaceFolder?.uri : undefined); const originalUri = (typeof uri === 'string' ? uri : uri.toString()); if (taskUri?.toString() !== originalUri) { return false; } </ins> if (Types.isString(identifier)) { return ((task._label === identifier) || (task.configurationProperties.identifier === identifier)); } else {
Code change:
Issue Type: <bBug</bRunning tasks with dependencies in a multi-root workspace executes the wrong dependency tasks, if there are multiple tasks defined under the same label but in different root folders. VSCode will just pick the first occurance in the order of the root folders defined in the workspace settings. To reproduce the issue: a simple multi-root workspace, e.g. each root folder, add a with two tasks. One task depends on the other. Example tasks of : and have the same tasks configured except that they echo their respective folder name instead. task of either or . VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Experiencing same issue on: VS Code version: 1.65.1 OS version: macOS 12.2.1 BuildVersion:21D62
To verify: or create a multi root workspace with 2 roots, FolderOne and FolderTwo (or names of your choice). each of your roots add a .vscode folder. each of your .vscode folders add a file with the following contents: "PrimaryTask" in FolderOne (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderOne" next to it). Verify that both PrimaryTask and DependsTask echo FolderOne's path. "PrimaryTask" in Folder Two (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderTwo" next to it). Verify that both PrimaryTask and DependsTask echo FolderTwo's path.

Related discussion:
text: return undefined; } if ((resolverData === undefined) && (grouped === undefined)) { <del> return (await quickResolve(this, identifier)) ?? fullResolve(this, uri, identifier); </del> <ins> return (await quickResolve(this, uri, identifier)) ?? fullResolve(this, uri, identifier); </ins> } else { return fullResolve(this, uri, identifier); }
Code change:
<!-- 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.65.0 OS Version: Windows 11 Enterprise Steps to Reproduce: a remote window, create an untitled file and paste these contents. ! this untitled file, a save prompt (modal) will appear. Click Save button. You will see something like this: ! suggested file name is $schema: and only azuremlschemas.azureedg is highlighted and not the whole file name which was suggested This works fine on a local window as the suggested file name is azuremlschemas.azureedg: as shown below: !
For untitled files, the first line is used as file name. I am not sure why there would be any difference between the simple and native dialog but I actually think the simple one behaves correctly here, though there seems to be mentioned highlighting issue.
I think our main concern is the highlight, for the name we would ideally like to have custom inputs from the extension but that is a completely different discussion.
All the simple file dialog knows is that there is a default save URI given to it. The highlight is done by using the basename of that default URI. I took a look at where the default save URI comes from, and it looks like suffers from the same issue of using the basename that simple file dialog does: The best fix seems to be to fix the default save URI. PR incoming.

Related discussion:
text: // of untitled model if it is a valid path name, // otherwise fallback to `basename`. let untitledName = model.name; <del> if (!(await this.pathService.hasValidBasename(joinPath(defaultFilePath, untitledName)))) { </del> <ins> if (!(await this.pathService.hasValidBasename(joinPath(defaultFilePath, untitledName), untitledName))) { </ins> untitledName = basename(resource); }
Code change:
<!-- 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.66.0-insider OS Version: MacOS 12.3 In iterm2: <img width="810" alt="image" src="https://user-"In VSCode terminal when enable shellIntegration: ! If I disable shellIntegration, everything goes ok: !
related to
I believe this is already fixed, can you see if you can reproduce in the ? /"needs-more-info"
Not quite yet... this is why I personally have shell integration disabled btw. !
This is working for me ! Here's what I did ! from
Looks like suggestion text does show up, but it uses a different history file. So it will suggest entries you have made with shell integration enabled, but not those made in normal terminals.
should it be using the same history file?
is this fine now because we revert to the original? We definitely want to share the zsh history file.
it's using the history from within VS Code only - when should it get refreshed and also suggest things from the broad shell history? tried reloading the window <img width="464" alt="Screen Shot 2022-06-30 at 11 37 34 AM" src="https://user-"
also does not pull from history of terminals that did not have shell integration enabled
it depends when zsh flushes history to , not sure if it's when the shell closes or a command is run.
hmm history is correct for terminals without shell integration, but not in ones w shell integration - even when I reload the window and create a new one <img width="971" alt="Screen Shot 2022-06-30 at 12 37 19 PM" src="https://user-"
what's set to?
<img width="978" alt="Screen Shot 2022-06-30 at 12 45 40 PM" src="https://user-"
I'm guessing we need to fix up as well to point at ?
would you think my error is related to the above discussion? (Cc <img width="847" alt="image" src="https://user-"After a my prompt looks normal again: <img width="846" alt="image" src="https://user-"I believe this usually happens when vscode is updated ...? EDIT: I just found a pre-existing issue in the mcfly repo .
we expect this to be fixed in the upcoming version, see Sorry about the hassle, please let us know if it's not fixed in 1.71

Related discussion:
text: . $USER_ZDOTDIR/.zshrc ZDOTDIR=$VSCODE_ZDOTDIR fi <ins> if [[ -f $USER_ZDOTDIR/.zsh_history ]]; then HISTFILE=$USER_ZDOTDIR/.zsh_history fi </ins> fi # Shell integration was disabled by the shell, exit without warning assuming either the shell has
Code change:
Currently says that the coverage folder is generated at the root of the directory. But this isn't currently the case, the coverage folder is generated under the directory instead.

Related discussion:
text: ## Coverage <del> The following command will create a `coverage` folder at the root of the workspace: </del> <ins> The following command will create a `coverage` folder in the `.build` folder at the root of the workspace: </ins> **OS X and Linux**
Code change:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

Related discussion:
text: import * as vscode from 'vscode'; import { CommandManager } from './commandManager'; import * as commands from './commands/index'; <ins> import { MdDefinitionProvider } from './languageFeatures/definitionProvider'; </ins> import { MdLinkProvider } from './languageFeatures/documentLinkProvider'; import { MdDocumentSymbolProvider } from './languageFeatures/documentSymbolProvider'; import { registerDropIntoEditor } from './languageFeatures/dropIntoEditor';
Code change:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

Related discussion:
text: vscode.languages.registerWorkspaceSymbolProvider(new MdWorkspaceSymbolProvider(symbolProvider, workspaceContents)), vscode.languages.registerReferenceProvider(selector, referencesProvider), vscode.languages.registerRenameProvider(selector, new MdRenameProvider(referencesProvider, workspaceContents, githubSlugifier)), <ins> vscode.languages.registerDefinitionProvider(selector, new MdDefinitionProvider(referencesProvider)), </ins> MdPathCompletionProvider.register(selector, engine, linkProvider), registerDropIntoEditor(selector), registerFindFileReferences(commandManager, referencesProvider),
Code change:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

Related discussion:
text: commandManager.register(new commands.ReloadPlugins(previewManager, engine)); return commandManager; }
Code change:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

Related discussion:
text: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as vscode from 'vscode'; import { Disposable } from '../util/dispose'; import { SkinnyTextDocument } from '../workspaceContents'; import { MdReferencesProvider } from './references'; export class MdDefinitionProvider extends Disposable implements vscode.DefinitionProvider { constructor(private readonly referencesProvider: MdReferencesProvider) { super(); } async provideDefinition(document: SkinnyTextDocument, position: vscode.Position, token: vscode.CancellationToken): Promise<vscode.Definition | undefined> { const allRefs = await this.referencesProvider.getAllReferencesAtPosition(document, position, token); return allRefs.find(ref => ref.kind === 'link' && ref.isDefinition)?.location; } } </ins>