jiebi/CodeConvo huggingface dataset:
Code change:
return; } this._logService.trace('IPty#pid'); <del> exec('lsof -OPln -p ' + this._ptyProcess.pid + ' | grep cwd', (error, stdout, stderr) => { </del> <ins> exec('lsof -OPln -p ' + this._ptyProcess.pid + ' | grep cwd', { env: { ...process.env, LANG: 'en_US.UTF-8' } }, (error, stdout, stderr) => { </ins> if (!error && stdout !== '') { resolve(stdout.substring(stdout.indexOf('/'), stdout.length - 1)); } else {

Related discussion:
text: a directory at path: /Users/ma//demoproject.(contains Chinese component) the directory from VSCode top menu: File - Open... a new terminal from top menu: Terminal - New Terminal. and terminal window automatically goes to path (demoproject). Command + Q shortcut to quit VSCode completely. VSCode from mac dock icon. and VSCode shows error: The terminal process failed to launch: Starting directory (cwd) "/Users/ma/xe6x9cxacxe5x9cxb0/demoproject" does not exist. the path in step1 does not contain Chinese(like /Users/ma/local/demoproject.), no error shows. the error only shows when the path contains Chinese. Extra VSCode information Version: 1.65.2 (Universal) Commit: Date: 2022-03-10T14:33:49.188Z (1 wk ago) Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 21.4.0
To verifier: When testing make sure shell integration is off
Code change:
return; } this._logService.trace('IPty#pid'); <del> exec('lsof -OPln -p ' + this._ptyProcess.pid + ' | grep cwd', (error, stdout, stderr) => { </del> <ins> exec('lsof -OPln -p ' + this._ptyProcess.pid + ' | grep cwd', { env: { ...process.env, LANG: 'en_US.UTF-8' } }, (error, stdout, stderr) => { </ins> if (!error && stdout !== '') { resolve(stdout.substring(stdout.indexOf('/'), stdout.length - 1)); } else {

Related discussion:
text: when split terminal in chinese path,error!
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.609 --- <!-- score: 0.558 --- <!-- score: 0.557 --- <!-- score: 0.499 --- <!-- score: 0.499 --<!-- potentialduplicatescomment --
I think this is language's problem.English path is very well.
It looks like your report is missing some important information, See for more info on how to report actionable terminal issues.
Thanks for your reply! version: 1.39.2 submit: Data Time: 2019-10-15T15:33:00.827Z Electron: 4.2.10 Chrome: 69.0.3497.128 10.11.0 V8: 6.9.427.31-electron.0 OS: Darwin x64 19.0.0 !
Thanks, you can probably workaround this with this setting:
I has try this settings by your suggestion. And it really not error.Thanks!But this way to create a terminal is not my default way.When I create a new terminal.It go to its father's file path , not it is before. If has a way to realize my need? !
Yeah that's what the setting does, you can't get what you're after until we fix this bug.
OK!I understand.Thank you!
I guess this is obvious, but the problem also occurs with European characters (at least french), and very likely with Arabic, Japanese, Indian, Korean characters as well. I also switched to in order to work around the problem.
I had this issue with the project folder itself containing unicode (greek letters). To my surprise, the hack still worked, the new terminal now sucesfully launches in the project folder.
Also happens when the cwd is set via runInTerminal
Note that in the latter case, it's not just the cwd that's affected - it's also all the command line arguments.
good point, this is probably an issue in debug land actually or related to encoding in the shell. Reopening it.
To verifier: When testing make sure shell integration is off
Code change:
} /** <del> * A result payload for a text search, pertaining to matches within a single file. </del> <ins> * A result payload for a text search, pertaining to {@link TextSearchMatchNew matches} * and its associated {@link TextSearchContextNew context} within a single file. </ins> */ export type TextSearchResultNew = TextSearchMatchNew | TextSearchContextNew;

Related discussion:
text: Testing I can see that the of can be . When should I expect each of these types? I'm not sure I understand what the purpose of is.
is like the surrounding context lines that you see in the search editor. ! For example, here, lines 1791 and 1793 are context lines because they come directly before and after line 1792. I can try to explain this better in the docs, though!
Code change:
} /** <del> * A result payload for a text search, pertaining to matches within a single file. </del> <ins> * A result payload for a text search, pertaining to {@link TextSearchMatchNew matches} * and its associated {@link TextSearchContextNew context} within a single file. </ins> */ export type TextSearchResultNew = TextSearchMatchNew | TextSearchContextNew;

Related discussion:
text: Testing From the API: What is the behavior supposed to be in the following cases: The pattern contains . The pattern contains and is false. The pattern is a regex and is false. The pattern contains whitespace and is true.
If regex is not on, it just looks for literally. I believe that this actually acts as if is true (if I'm interpreting code correctly). Any time that you have regex enabled and explicitly match a newline, it will be multi-line. I should probably document this. Any characters in the regex will also match the other case. ie: should also match all characters, not just lowercase letters. It will look for the whitespace, and will look for line boundaries on either side of the search string.
I can also add extra examples for corner cases so that this is more clear.
Code change:
private _containerReadyBarrier: AutoOpenBarrier; private _attachBarrier: AutoOpenBarrier; <ins> private _icon: TerminalIcon | undefined; </ins> private _messageTitleDisposable: IDisposable | undefined; private _widgetManager: TerminalWidgetManager = this._instantiationService.createInstance(TerminalWidgetManager);

Related discussion:
text: Hi, I would like to request that upon restart vscode, the terminals can be restored. By restored, i mean the layout, the custom names, icon and color for the terminals are retained. The content DOES NOT need to be retain. Otherwise efforts to customize all the opened terminals would gone to waste when vscode is restarted. Alternatively, vscode can provide new workspace configurations, where developer can manually enter a list of terminals' custom names, Vscode, upon starting, will automatically create new terminals based on the configured list. Even better, each time, deveoper manually open a new terminal , vscode will auto update the workspace configuration file to add a new terminal to the configured list. This applies the same to renaming of terminal Hope that this can be achieved without relying on plugin. *Do note that this might not be a duplicate of other look similar kind of feature request. Cos for this request, content does not need to be preserved. And the terminal's custom names should be preserved (sadly, persistentSessionReviveProcess, does not maintain the terminal custom names)
except it doesn't save custom terminal names.
Not only it doesn't save custom terminal names, it also doesn't save icon and color.
This is meant to be supported with including content as well, there are currently some issues with it causing it to be flaky though. They might have to wait until v1.63 where we will focus on testing. Related:
fixed !
It's persisting the icon, color, name, and layout on window reload. Doesn't seem to persist icon, color, or name on restart.
Yes. My request is focusing on restart, not window reload
Code change:
* @param path A file system path (see `Uri#fsPath`) */ static file(path: string): Uri; <ins> /** * Creates new Uri from uri components. * * Unless `strict` is `true` the scheme is defaults to be `file`. This function performs * validation and should be used for untrusted uri components retrieved from storage, * user input, command arguments etc */ </ins> static from(components: { scheme: string; authority?: string; path?: string; query?: string; fragment?: string; <del> }): Uri; </del> <ins> }, strict?: boolean): Uri; </ins> /** * Join a Uri path with path fragments and normalizes the resulting path. *

Related discussion:
text: Following test throws: I found this while investigating At that point the editor component is quite broken because of a lot of errors being thrown. Notice how not even a tab shows for the editor: <img width="1058" alt="image" src="https://user-"
that should already throw because at least a scheme is needed. It doesn't because was designed to be the runtime counter part of which never produces such output so some IPC deserialisation cost can be saved.
, that works for me and will also throw when we get bad objects into such as the from
Yeah, my plan is to add an argument like we have in other URI-places. It will default to true and only IPC should be relaxed
Not doing that because it actually already exists as . I believe the adoption/migration task is to use instead of whenever getting uri components from storage or esp from command arguments. Tho, there is one special case for which is that it automatically uses when the scheme is missing. We could make that configurable but a check for might make this obsolete
Closing this after and the ask to use when creating uri from "untrusted" sources
I will see to adopt , I forgot we had it
Code change:
import { IBufferLine, IBufferRange, Terminal } from 'xterm'; import { ITerminalBackend, ITerminalProcessManager } from 'vs/workbench/contrib/terminal/common/terminal'; import { detectLinks } from 'vs/workbench/contrib/terminalContrib/links/browser/terminalLinkParsing'; <ins> import { ILogService } from 'vs/platform/log/common/log'; </ins> const enum Constants { /**

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --So far, I haven't been able to find any issues around this, but I also haven't found a ton of documentation on this feature either. Basically, I'd like to have finer grained control over how the terminal "word link" auto detection works. This is one of the only comments I was able to find about: Example: In the terminal, I have some output from a compiler that includes relative paths that can be clicked conveniently as an autodetected "word link": Specifically, clicking takes me to the line in question, which is great! However, at some point I tried configuring to include a forward slash (colon has related effects too), e.g. By doing so, the auto-detected file path is no longer clickable, since each path segment is considered as a separate word instead. Notably, the absolute path above is still clickable, but relative paths appear not to be (unless I remove from again). I guess there is probably more than one way to solve this, but a simple solution that comes to mind would be to have a separate config, maybe something like . If null it could fall back to the value, but at least this way it would be possible to configure different separators for double-click selection and link detection. Thanks in advance!
This case is meant to work with the regular non-word link detection as you can see here: <img width="490" alt="Screenshot 2023-05-08 at 6 31 15 am" src="https://user-"This may not work is if the relative path is not relative to the current working directory or you have shell integration disabled (which is provides better cwd detection). In your example is relative to the directory the terminal was currently on? The word links are meant to catch the majority of cases where the verified file links fall through.
Edit: never mind, I think I was testing with the wrong value of as I described in the original issue body :( I did however notice an interesting data point while integration was still disabled: the clickability of the file path seemed inconsistent. Here are a few screenshots showing what I mean (ctrl held in each case): Can't click in a compiler diagnostic, maybe due to the prefix on that line? !
Code change:
import { IBufferLine, IBufferRange, Terminal } from 'xterm'; import { ITerminalBackend, ITerminalProcessManager } from 'vs/workbench/contrib/terminal/common/terminal'; import { detectLinks } from 'vs/workbench/contrib/terminalContrib/links/browser/terminalLinkParsing'; <ins> import { ILogService } from 'vs/platform/log/common/log'; </ins> const enum Constants { /**

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:
import { IBufferLine, IBufferRange, Terminal } from 'xterm'; import { ITerminalBackend, ITerminalProcessManager } from 'vs/workbench/contrib/terminal/common/terminal'; import { detectLinks } from 'vs/workbench/contrib/terminalContrib/links/browser/terminalLinkParsing'; <ins> import { ILogService } from 'vs/platform/log/common/log'; </ins> const enum Constants { /**

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:
return this._repository.add(paths.map(p => Uri.file(p))); } <ins> revert(paths: string[]) { return this._repository.revert(paths.map(p => Uri.file(p))); } </ins> clean(paths: string[]) { return this._repository.clean(paths.map(p => Uri.file(p))); }

Related discussion:
text: <!-- 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. --The built-in git extension exposes methods for most of the base git operations. Unfortunately not , which would be used to unstage changes. Could easily be to , i'll open a PR for this sometime today.
could you verify this by reviewing
Code change:
if (insertIntoNewFileKb) { hint += localize('insertIntoNewFile', " - Insert the code block into a new file ({0}).n", insertIntoNewFileKb); } else { <del> hint += localize('insertIntoNewFileNoKb', " - Insert the code block into a new file by configuring a keybinding for the Chat: Insert at Cursor command.n"); </del> <ins> hint += localize('insertIntoNewFileNoKb', " - Insert the code block into a new file by configuring a keybinding for the Chat: Insert into New File command.n"); </ins> } if (runInTerminalKb) { hint += localize('runInTerminal', " - Run the code block in the terminal ({0}).n", runInTerminalKb);

Related discussion:
text: Testing In the screenshot below, "Chat: Insert at Cursor" should be "Chat: Insert into New File" !
Code change:
if (insertIntoNewFileKb) { hint += localize('insertIntoNewFile', " - Insert the code block into a new file ({0}).n", insertIntoNewFileKb); } else { <del> hint += localize('insertIntoNewFileNoKb', " - Insert the code block into a new file by configuring a keybinding for the Chat: Insert at Cursor command.n"); </del> <ins> hint += localize('insertIntoNewFileNoKb', " - Insert the code block into a new file by configuring a keybinding for the Chat: Insert into New File command.n"); </ins> } if (runInTerminalKb) { hint += localize('runInTerminal', " - Run the code block in the terminal ({0}).n", runInTerminalKb);

Related discussion:
text: Testing There's a double close parenthesis here: <img width="305" alt="image" src=""
Also a missing on the line
Code change:
"@iktakahiro/markdown-it-katex@mjbvz/markdown-it-katex": <del> version "4.0.3" resolved "https://codeload.github.com/mjbvz/markdown-it-katex/tar.gz/58f6637b5883caa8a811f1736bc90b34cd26b395" </del> <ins> version "4.0.4" resolved "https://codeload.github.com/mjbvz/markdown-it-katex/tar.gz/cfcbc640a2780f2349d4e137ad51638f39279aa7" </ins> dependencies: katex "^0.16.2"

Related discussion:
text: in vscode , the formula is rendered with katex, an KaTeX parse Error occurred ! in pycharm , it's rendered properly with mathjax ! latex code:
The equation renders fine if you wrap it in so I reckon it's related to how we handle bare math blocks. Relevant code:
wow
Hi Can I work on this?
sure
Can you let me know where to get started? As per the last comment, it works when wrapping with "$$" so I figure I need to look into how vscode is rendering lateX in general? any other pointers?
the reason is probably katex can't process environments outside $$ , but i wonder if katex has a similar option 'processEnvironments' like MathJax provides
This is the same for .NET Interactive
This is indeed a pain - especially for someone still going through the learning process and not a LaTeX expert by any means.
Code change:
const editorService = accessor.get(IEditorService); const editorGroupService = accessor.get(IEditorGroupsService); const openerService = accessor.get(IOpenerService); <ins> const pathService = accessor.get(IPathService); </ins> const resource = URI.revive(resourceArg); const [columnArg, optionsArg] = columnAndOptions ?? []; <del> // use editor options or editor view column as a hint to use the editor service for opening if (optionsArg || typeof columnArg === 'number') { </del> <ins> // use editor options or editor view column or resource scheme // as a hint to use the editor service for opening directly if (optionsArg || typeof columnArg === 'number' || resource.scheme === Schemas.untitled) { </ins> const [options, column] = mixinContext(context, optionsArg, columnArg); <del> await editorService.openEditor({ resource, options, label }, columnToEditorGroup(editorGroupService, column)); </del> <ins> let input: IResourceEditorInput | IUntitledTextResourceEditorInput; if (resource.scheme === Schemas.untitled && resource.path.length > 1) { // special case for untitled: we are getting a resource with meaningful // path from an extension to use for the untitled editor. as such, we // have to assume it as an associated resource to use when saving. we // do so by setting the `forceUntitled: true` and changing the scheme // to a file based one. the untitled editor service takes care to // associate the path properly then. input = { resource: resource.with({ scheme: pathService.defaultUriScheme }), forceUntitled: true, options, label }; } else { // use any other resource as is input = { resource, options, label }; } await editorService.openEditor(input, columnToEditorGroup(editorGroupService, column)); </ins> } // do not allow to execute commands from here

Related discussion:
text: jupyter-keymap1.0.0 jupyter-renderers1.0.4 remote-containers0.209.5 remote-ssh0.68.0 remote-ssh-edit0.68.0 vsliveshare1.0.5196 vscode-commons0.0.6 vscode-yaml1.2.2 edit-with-shell1.3.0 lua2.5.3 even-better-toml0.14.2 shellcheck0.18.2 redo0.1.0 (6 theme extensions excluded) </details<!-- generated by issue reporter --
Looks like when you call we treat the URI as the associated resource: But we do not do the same from
I tried this with the following code: and both files saved to the correct paths... but I wasn't prompted at all by a file dialog. Is that expected?
Yes. Untitled with associated path don't ask for a file name, that is the whole idea of "untitled with associated resource" vs. "untitled without associated resource".
Code change:
document.body.appendChild(img); }); <del> vscode.postMessage({ type: 'ready' }); </del> <ins> vscode.postMessage({ type: 'ready', userAgent: window.navigator.userAgent }); </ins> </script>`); const ready = getMessage(webview); <del> await ready; </del> <ins> if ((await ready).userAgent.indexOf('Firefox') >= 0) { // Skip on firefox web for now. // Firefox service workers never seem to get any 'fetch' requests here. Other browsers work fine return; } </ins> { const imagePath = webview.webview.asWebviewUri(workspaceFile('image.png')); <del> console.log(imagePath); </del> const response = await sendRecieveMessage(webview, { src: imagePath.toString() }); assert.strictEqual(response.value, true); }

Related discussion:
text: They used to finish in 3m24s before - […]-5f82-0dbc-&t=-371d-5daa-d7a2-
I can confirm that tests started timing out after this commit - The first commit that is started happening is Checking what commits in between would have caused it. FYI
Assigning to as one of his commits has caused this timeout.
Mac seems to be passing pretty reliably now but now windows fails consistently on two tests Been adding a bunch of logging to investigate this. Here's the relevant new error: The service worker should be intercepting this request so it should never be going to the network at all here. Taking a look to see if I can figure out what is going on
Actually it's not windows specific: its Firefox specific. The windows browser tests just happen to be the only ones using Firefox Can reproduce on Mac too