jiebi/CodeConvo huggingface dataset:
Code change:
type: 'boolean', default: false }, <ins> 'terminal.integrated.altClickMovesCursor': { description: localize('terminal.integrated.altClickMovesCursor', "If enabled, alt/option + click will move the prompt cursor to position underneath the mouse. This may not work reliably depending on your shell."), type: 'boolean', default: true }, </ins> 'terminal.integrated.copyOnSelection': { description: localize('terminal.integrated.copyOnSelection', "Controls whether text selected in the terminal will be copied to the clipboard."), type: 'boolean',

Related discussion:
text: if no one picks this up from the community it would be a good change for you in debt week.
Thank you so much! :tada:
Once it's released in insider's, to verify, set
Hi! Thanks for fixing this Just to understand, may I ask: Why will the future setting default to true? One year ago the problem didn't happen on a fresh install, so why not fix the regression Why is this issue closed but the bug still exists in the latest Insiders? Thank you
As far as I understand this is a new feature in . The special characters only get displayed in certain situations (probably when the running command prevents the shell from moving the cursor). Also the default setting for multicursor is <kbdCtrl</kbdso you would not use <kbdAlt</kbdnormally unless you want exactly this new feature.
I just want to open a file from within the terminal out of the box ! I typically do when running in watch mode On Linux the shortcut is Ctrl+Alt+Click even if the screenshot says otherwise Can users do this without having to find this issue and the corresponding setting? Also, when the filling happens, often the terminal gets stuck, I cannot kill the process with anymore, should I open another issue about this?
Thank you for voicing your concerns - I have to agree that OFF should be the default behavior as Alt-Click is mapped to the file open command in VS Code, and ON is therefore most likely to be the undesired behavior.
<kbdAlt</kbd+<kbdClick</kbdis not the default. The default for opening links and definitions is the one key not used by the multicursor modifier which is by default <kbdAlt</kbd. You can confirm this by looking in the docs or viewing the default value in the settings UI.
Just tried in Portable mode on Linux with no settings nor extension installed. The problem still reproduces. fixes the problem but I'm not sure how new users would know about this
You may be misunderstanding what this option attempts to solve. It's unfortunate that the name was chosen for the setting, since the setting is not about vs. , but rather about enabling or disabling the pseudo-mouse-cursor-moving feature in xTerm entirely. I concur with go back a year and VSCode didn't have this annoying broken "feature" of the terminal.
Code change:
type: 'boolean', default: false }, <ins> 'terminal.integrated.altClickMovesCursor': { description: localize('terminal.integrated.altClickMovesCursor', "If enabled, alt/option + click will move the prompt cursor to position underneath the mouse. This may not work reliably depending on your shell."), type: 'boolean', default: true }, </ins> 'terminal.integrated.copyOnSelection': { description: localize('terminal.integrated.copyOnSelection', "Controls whether text selected in the terminal will be copied to the clipboard."), type: 'boolean',

Related discussion:
text: Now that we've recognized it's broken and updated the xTerm dependency to a version that allows us to get rid of the broken "feature", the default behavior from a VSCode perspective should be to have the feature disabled, since we really never wanted it in the first place. Also, as pointed out, when the typical user hits this strange behavior, are we just expecting them to "VSCode terminal fills with ^[[D^[[D^[[D^[[D^[[D^[[D and locks up" into Google and hope for the best? This "feature" does not work 100%. It should be considered beta/experimental and disabled by default.
I can attempt a PR that Changes the setting name to perhaps (something that doesn't mention vs. ) Default value of But I'm not sure how the open-source community handles requests like this. Any advice on how to proceed? Or is this a closed/merged PR and conversation over?
After re-reading this I realized this is capturing the bug (alt+click conflict) as well as the feature request (new setting), I thought they were separate issues. to fix let's: Override the value of to be false when . Document this override in 's description, that also makes the name correct as this feature only ever works on alt+click. I think that name is good as it aligns with . we're a little tight on time as we're closing in on the end of the iteration, can handle it
Thanks, and I'm really looking forward to being able to click links in the terminal again.
/verified
Code change:
_serviceBrand: undefined; <del> protected readonly url: string | undefined; </del> <ins> protected url: string | undefined; </ins> private _state: State = State.Uninitialized;

Related discussion:
text: run you'll notice that in the main process before creating the renderer the update service takes its time (~5-10ms). while that's not much it seems unnecessary and "block" the renderer for no good reason <img width="1101" alt="Screenshot 2020-01-31 at 14 45 07" src="https://user-"
This is only problematic in macOS where calls into the native which blocks.
Thanks
Code change:
ZDOTDIR=$VSCODE_ZDOTDIR fi <del> if [[ -f $USER_ZDOTDIR/.zsh_history ]]; then </del> <ins> if [[ -f $USER_ZDOTDIR/.zsh_history && -z HISTFILE ]]; then </ins> HISTFILE=$USER_ZDOTDIR/.zsh_history fi fi

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. --- VS Code Version: 1.72.2 OS Version: macOS Monterey 12.5 Steps to Reproduce: custom HISTFILE (example custom HISTFILE per project) integrated terminal (zsh) in VS code will be /Users//.zsh_history instead of custom history file What i use: vscode I found that the changes made to break the ability to use a custom HISTFILE because the HISTFILE is always overwritten by these changes:
Trying to set HISTFILE directly in settings, fails the same way HISTFILE is always set to
Hi I have opened a PR with a possible solution to this issue. Let me know, if it solves the problem.
thanks a lot Sorry for the stupid question, but do you have any macos silicon build that I could try ? I never contributed to vscode and finding how to compile it from source may take some time
Unfortunately, I don't have a Mac, however, I use Linux with Zsh so I could reproduce the bug and I could test the fix on it.
I think this might be related to with McFly.
Code change:
export function activate(context: vscode.ExtensionContext) { const serializer = new NotebookSerializer(context); <del> ensureAllNewCellsHaveCellIds(context); </del> <ins> keepNotebookModelStoreInSync(context); </ins> context.subscriptions.push(vscode.workspace.registerNotebookSerializer('jupyter-notebook', serializer, { transientOutputs: false, transientCellMetadata: {

Related discussion:
text: Create an ipynb file (with one Python cell) Save this Verify the entry exists in time line Change the language of the cell to Save this Verify we have an entry Click that item Bug On the left we need On the right there's no such entry in metadata This is incorrect. The ipynb has the above metadata. What seems to be happening is When the language changes, We serialize the ipynb and JSon contains the metadata However the model is not updated with corresponding changes to the ipynb file I.e. model change triggered =ipynb serialize to JSON =Json contains new metadtaa not in model =Missing step is to update the model again If we implement the last step, we could always end up in an infinite loop, Perhaps we should first update the model with metadata when ever we detect chagnes in the model before the save event. E.g. as part of pre-Save (onDidChangeNotebookDocument &/or onWillSaveNotebookDocument) This way, model will always be accurate and upto date when ipynb is serialized.
Easier way to explain the bug Create an ipynb file (with one Python cell) Save this Change the language of the cell to Save this The cell metadata will not contain the new metadata that exists in the ipynb JSON file. (model is not in sync with ipynb json)
Suggested Solution Perform model updates when we're about to save (or when we detect changes to model) When saving, ensure we save the metadata as is, without generating any new content I.e. JSON.stringify the metadata.
/cc
Considering that a serialize operation should not have side effects (ideally), enforcing a "save participant" from ipynb extension makes very good sense to me. We can leverage which support additional async operations, like how we handle attachment clearnup
For such critical metadata change, we might want to handle both auto save and manual save as we want the json and model to be always in sync.
Another simple repro step Create a notebook, and save this Add a new cell The latest entry in timeline will be However there's a difference, one has and the other (current model state) does not have any Again, model does not contain metadta (as this is a new cell) and ipynb JSON contains metadata when serialized.
Code change:
export function activate(context: vscode.ExtensionContext) { const serializer = new NotebookSerializer(context); <del> ensureAllNewCellsHaveCellIds(context); </del> <ins> keepNotebookModelStoreInSync(context); </ins> context.subscriptions.push(vscode.workspace.registerNotebookSerializer('jupyter-notebook', serializer, { transientOutputs: false, transientCellMetadata: {

Related discussion:
text: <details<summaryInternal Notes</summaryHere's the work flow Add a cell A change event is triggered, undo redo stack is updated Last undo redo is User hits save button Working copy starts to handle the save operation Save participants start We add a save participant and update the model via a work space edit Now a new change event is triggered This results in a whole new undo redo stack The latest (last) undo redo item is Save participants done Working copy keeps track of the last as the entry for Problems Time line does not include , time line shows only I guess this is correct, However from a users perspective, the labels are never going to be meaningful as we'd always say . </details
Code change:
import { score } from 'vs/editor/common/languageSelector'; import { Emitter } from 'vs/base/common/event'; import { withNullAsUndefined } from 'vs/base/common/types'; <ins> import { IUriIdentityService } from 'vs/platform/uriIdentity/common/uriIdentity'; </ins> function createProviderComparer(uri: URI): (a: QuickDiffProvider, b: QuickDiffProvider) => number { return (a, b) => {

Related discussion:
text: Type: <bBug</bTo reproduce: VS Code a folder and choose a git repo with changes a file with changes and notice the gutter is shown a folder to the workspace and choose a git repo the gutter is still visible close the file and reopen it Expected behavior: the gutter is shown Actual behavior: the gutter is not shown this may be related to . actually pretty much the same issue. However a reload (I assume that is ) doesn't help in this case. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-10T05:24:23.805Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for the @ mention and for the repro steps!
Also having the same issue. Installing a previous version () helped to solve it (temporarily, until it's fixed).
Folks who are seeing this issue: Could you please install the latest insiders build and confirm that you no longer see the issues there?
Yes. The issue resolved in the latest insider version.
Related Stack Overflow questions: I'd prefer using this one as a duplicate target on Stack Overflow since it's asked much cleaner.
Thanks for confirming that the issue is fixed in insiders!
Wow, so it was a bug, not an actual symlink-issue as I thought. So happy now, thanks! Context: I'll try the fix/update.
This issue seems to be fixed in version 1.76.2 for git repositories, however it is not yet fixed for Mercurial ( extension).
I am still seeing this bug in
can you share some exact repro steps that we can use to reproduce the issue?
I can't reproduce the issue on a new clean git repo, hmm
Im having the same issues, reinstalling helped fix the current file having the issue but any file created after wont show the indicators. Disabling extensions wont work either and Im not sure on how to reproduce the steps Version: 1.76.2 (user setup) OS: Windows_NT x64 10.0.
Code change:
constructor(label: string | CompletionItemLabel, values: ChatVariableValue[]); } <del> export type ChatExtendedRequestHandler = (request: ChatRequest, context: ChatContext, response: ChatExtendedResponseStream, token: CancellationToken) => ProviderResult<ChatResult>; </del> <ins> export type ChatExtendedRequestHandler = (request: ChatRequest, context: ChatContext, response: ChatExtendedResponseStream, token: CancellationToken) => ProviderResult<ChatResult | void>; </ins> export namespace chat { /**

Related discussion:
text: Testing If there's no error case, I now need to return something like:
Hi we have branched off from today, so I am pinging about the milestone here. Would you like to make this issue a candidate or move it out to the milestone?
Moving to March for now. Feel free to move this issue back to February if it turns out to be a candidate.
It's already a , which allows 'undefined' but not void. Is it weird to say ?
+1 on this, I have to explicitly today
Code change:
margin-left: 0.8em; } <del> .search-view.wide .foldermatch .badge, .search-view.wide .filematch .badge { </del> <ins> .search-view .foldermatch .badge, .search-view .filematch .badge { </ins> margin-left: 10px; }

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:
margin-left: 0.8em; } <del> .search-view.wide .foldermatch .badge, .search-view.wide .filematch .badge { </del> <ins> .search-view .foldermatch .badge, .search-view .filematch .badge { </ins> margin-left: 10px; }

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:
'disable-inspect': { type: 'boolean' }, 'force-user-env': { type: 'boolean' }, <ins> // chromium flags 'no-proxy-server': { type: 'boolean' }, 'proxy-server': { type: 'string' }, 'proxy-bypass-list': { type: 'string' }, 'proxy-pac-url': { type: 'string' }, </ins> 'js-flags': { type: 'string' }, // chrome js flags <ins> 'inspect': { type: 'string' }, 'inspect-brk': { type: 'string' }, </ins> 'nolazy': { type: 'boolean' }, // node inspect '_urls': { type: 'string[]' },

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.39.0 OS Version: Linux RHEL 7 Steps to Reproduce: code with --no-proxy-server flag "Option 'proxy-server' is unknown. Ignoring." error appears. I think the proxy is still disabled, the error message is simply wrong? If I run without the flag, I get prompted to log into the proxy, if I run with the flag, the proxy appears disabled (no log in prompting) but the error appears on the command line.
I suggest to include that fix in the recovery builds to avoid any confusion due to the message printed by the cli. The cli says for all chromium options, but in fact, they are used. My understanding is that most of the chromium options are not for the end-user except and the proxy settings, so I these to the list of the valid (supported) args. Please speak up if I missed one of the options. PR is
This is not fixed in the latest stable release candidate. The reason is that the PR was actually not merged and this issue was closed erroneously
The discussion in yesterday's standup was to take this, so we've now merged the PR...
Code change:
"configuration.markdown.links.openLocation.currentGroup": "Open links in the active editor group.", "configuration.markdown.links.openLocation.beside": "Open links beside the active editor.", "configuration.markdown.suggest.paths.enabled.description": "Enable/disable path suggestions for markdown links", <del> "configuration.markdown.editor.drop.enabled": "Enable/disable dropping into the markdown editor to insert shift. Requires enabling `#workbenck.experimental.editor.dropIntoEditor.enabled#`.", </del> <ins> "configuration.markdown.editor.drop.enabled": "Enable/disable dropping into the markdown editor to insert shift. Requires enabling `#workbench.experimental.editor.dropIntoEditor.enabled#`.", </ins> "configuration.markdown.editor.pasteLinks.enabled": "Enable/disable pasting files into a Markdown editor inserts Markdown links.", "configuration.markdown.experimental.validate.enabled.description": "Enable/disable all error reporting in Markdown files.", "configuration.markdown.experimental.validate.referenceLinks.enabled.description": "Validate reference links in Markdown files, e.g. `[link][ref]`.  Requires enabling `#markdown.experimental.validate.enabled#`.",

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 <!-- 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.67.0 OS Version:mac os monterey 12.3.1 Steps to Reproduce: to settings (command+,) for markdown drop <img width="719" alt="Screen Shot 2022-05-20 at 11 55 58 AM" src="https://user-"
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Confirmed on latest insiders Version: 1.68.0-insider Commit: Date: 2022-05-16T05:30:27.563Z Electron: 17.4.3 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin arm64 21.4.0 <img width="636" alt="Screen Shot 2022-05-20 at 1 11 00 PM" src="https://user-"
Fixed as of
<img width="967" alt="image" src="https://user-"
Hey I see with the same fixes, already merged.
Yeah but it accidentally got reverted via This just brings your changes back in