jiebi/CodeConvo huggingface dataset:
Code change:
"command": "imagePreview.zoomOut", "when": "activeCustomEditorId == 'imagePreview.previewEditor'", "group": "1_imagePreview" <ins> }, { "command": "imagePreview.copyImage", "when": "false" } ], "webview/context": [ { "command": "imagePreview.copyImage", "when": "webviewId == 'imagePreview.previewEditor'" </ins> } ] }

Related discussion:
text: Basically in the core webview module (see ), three default context menu actions (cut, copy and paste) are to the menu, which are accessible throughout all webviews, and happens to be one of them, so after you right-click anywhere in a image previewer, you will be able to see these three actions. After you clicks one of these actions, the editor will post an message to the image previewer, telling it to cut, copy or paste. If there is a correspondent listener for this perpose, the image will be actually cut, copied, pasted, but unfortunately there is no such listeners defined. This problem has existed for quite a bit of time. The original modification that cause this problem is from here . It is origianlly meant to allow users to copy selected text within an extension's README page. There is also a closed issue that describe such issue in . Personally I think providing action cut, copy and paste for all webviews is a little bit hasty, since there are not universally required for each webview, and even some of them need, the subject to be copied may vary from different webviews, or even different places in a same webview. I can solve it by disabling the default actions first (there is a option to achieve this), then let image previewer to implement its own copy and cut functionality, but I think this is rather a quick and sloppy solution. There should be another better way to solve this issue.
What about adding a handler :
Here's what I tried VSC insiders without any extensions Open a folder with a .png file Open the png file in vscode Right click and select Paste into folder in vscode = does not work Paste into markdown cell in vscode = does not work What am i doing wrong?
Pasting image data into folders isn't supported by VS Code. Pasting into a notebook cells works fine for me though. To verify though you can also paste into an external image editor
Code change:
import 'vs/css!./media/explorerviewlet'; import { localize } from 'vs/nls'; import { mark } from 'vs/base/common/performance'; <del> import { VIEWLET_ID, ExplorerViewletVisibleContext, OpenEditorsVisibleContext, VIEW_ID, IFilesConfiguration } from 'vs/workbench/contrib/files/common/files'; </del> <ins> import { VIEWLET_ID, OpenEditorsVisibleContext, VIEW_ID, IFilesConfiguration } from 'vs/workbench/contrib/files/common/files'; </ins> import { IViewletViewOptions } from 'vs/workbench/browser/parts/views/viewsViewlet'; import { IConfigurationService, IConfigurationChangeEvent } from 'vs/platform/configuration/common/configuration'; import { ExplorerView } from 'vs/workbench/contrib/files/browser/views/explorerView';

Related discussion:
text: open explorer select a file press and to copy paste a file in place :bug: nothing happens, in the past I would get a copy of the file
Hmmm. I cannot repro this and am able to copy and paste. Do you have any custom keybindings? What is your setting?
It's the default, this is from the keybindings log
Hmmm I wonder what has happening with your keybindings. Here's mine triggering the explorer specific ones with the proper when clauses. Is your explorer in a non-default position (i.e. not the activity bar)
This gets more and more interesting... The keybinding is there and not (re)configured but it looks like something is wrong with context keys. The seems AWOL. Maybe that's because I moved the explorer around very much last endgame? <img width="2819" alt="Screenshot 2023-03-01 at 16 55 16" src="https://user-"
Think I found the bug. the folders view to the right sidebar the remaining explorer view container in the activity bar Can't copy and past in the explorer anymore
I know this is very early into the next release cycle, but could this be released in a patch to stable VSCode? I have been bitten by this in stable VSCode after the February 2023 update, by dragging Explorer over to the secondary sidebar. Or is there a workaround to restore functioning of these keys, other than resetting the user profile altogether? I've tried dragging the Explorer menu back, and also right-clicking and selecting "Reset Location". Neither seems to "restore" the functionality of these keys. This affects any command using in , such as deleting a file with the Delete key (hopefully people find this issue instead of creating a new one for every such broken key). The workaround I've managed to apply is to manually remove from every expression possible, which may have side effects, but it works in a pinch. Copy all the keybindings below (expand for details, grab bindings between the comments) into your to fix this in a pinch. <details</summary</details
Does the command in the command palette not fix it for you? This will reset all your views to their default positions.
My keybindings workaround bypassed the issue on my home computer yesterday.
Code change:
import 'vs/css!./media/explorerviewlet'; import { localize } from 'vs/nls'; import { mark } from 'vs/base/common/performance'; <del> import { VIEWLET_ID, ExplorerViewletVisibleContext, OpenEditorsVisibleContext, VIEW_ID, IFilesConfiguration } from 'vs/workbench/contrib/files/common/files'; </del> <ins> import { VIEWLET_ID, OpenEditorsVisibleContext, VIEW_ID, IFilesConfiguration } from 'vs/workbench/contrib/files/common/files'; </ins> import { IViewletViewOptions } from 'vs/workbench/browser/parts/views/viewsViewlet'; import { IConfigurationService, IConfigurationChangeEvent } from 'vs/platform/configuration/common/configuration'; import { ExplorerView } from 'vs/workbench/contrib/files/browser/views/explorerView';

Related discussion:
text: Now I'm at work (both are Windows machines, VSCode up to date), and I went to try your approach. However, I have a lot of menus in my secondary sidebar, so I didn't want to on my main profile, so I did the following: Ensure my workaround from before is commented out Export the profile as Import the profile Switch to that profile Verify that the key doesn't work First, try the less invasive, right-click on Explorer button in secondary sidebar and click key, and others, works again, even when putting the Explorer back in the secondary sidebar Curiously, switching back to the profile, the key, and others, works again, even when putting the Explorer back in the secondary sidebar Never had to go the nuclear option and So, some funny business related to one of the steps above, probably the settings profile shuffle, restored basic functionality of those keys, without having to manually tweak the expressions as before, and without having to go nuclear and . It's possible to work around this with some UI shuffling, but your mileage may vary. My initial request to backport the patch to stable VSCode is not so serious since there are a few workarounds documented here. Also, thanks for the quick work in the PR! I'm looking forward for this behavior to stabilize in future versions, since secondary sidebar Explorer view (without the compromise of moving the whole primary sidebar over) is great!
Code change:
import 'vs/css!./media/explorerviewlet'; import { localize } from 'vs/nls'; import { mark } from 'vs/base/common/performance'; <del> import { VIEWLET_ID, ExplorerViewletVisibleContext, OpenEditorsVisibleContext, VIEW_ID, IFilesConfiguration } from 'vs/workbench/contrib/files/common/files'; </del> <ins> import { VIEWLET_ID, OpenEditorsVisibleContext, VIEW_ID, IFilesConfiguration } from 'vs/workbench/contrib/files/common/files'; </ins> import { IViewletViewOptions } from 'vs/workbench/browser/parts/views/viewsViewlet'; import { IConfigurationService, IConfigurationChangeEvent } from 'vs/platform/configuration/common/configuration'; import { ExplorerView } from 'vs/workbench/contrib/files/browser/views/explorerView';

Related discussion:
text: mac select an entry in the explorer press to trigger rename the file is being opened, no rename log
tested on windows and this doesn't work for me - not sure if it's necessarily platform specific
Steps to verify explorer that keybindings still work for the explorer
Mac Pro (Intel 2019) user here. I also have the same problem. Before pressing can rename files but now it just navigates to the file editor window.
This will be fixed in the next release which comes out sometime this week. In the meantime -should fix it for you.
Thank you for prompt reply. Yes, it works fine now!!
Code change:
); this.acitivityBarPart = this._register(instantiationService.createInstance(ActivitybarPart, this)); <ins> this.rememberActivityBarVisiblePosition(); </ins> this._register(configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration(LayoutSettings.ACTIVITY_BAR_LOCATION)) { <del> this.updateTitleArea(); const id = this.getActiveComposite()?.getId(); if (id) { this.onTitleAreaUpdate(id!); } this.updateActivityBarVisiblity(); </del> <ins> this.onDidChangeActivityBarLocation(); </ins> } }));

Related discussion:
text: Steps to Reproduce: the Activity Bar Position as Hidden Command: View: Focus Activity Bar Then: ! Activity Bar still takes up screen space, but doesn't display the icons Version: 1.84.0 Commit: Date: 2023-11-01T11:29:04.398Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.84.0 Chrome/114.0.5735.289 Electron/25.9.2 Safari/537.36
Probably depends on
Probably
Not related to
!
Code change:
"type": "boolean", "default": true, "description": "%config.markdown.math.enabled%" <ins> }, "markdown.math.macros": { "type": "object", "additionalProperties": { "type": "string" }, "default": {}, "description": "%config.markdown.math.macros%", "scope": "resource" </ins> } } }

Related discussion:
text: It would be nice to have a entry in the configuration section of markdown-math extension. A place where users could put their custom math macros.
<!-- 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!
/verified
Code change:
.pipe(replace('@@ICON@@', product.applicationName)) .pipe(rename('usr/share/applications/' + product.applicationName + '.desktop')); <ins> const desktopUrlHandler = gulp.src('resources/linux/code-url-handler.desktop', { base: '.' }) .pipe(replace('@@NAME_LONG@@', product.nameLong)) .pipe(replace('@@NAME_SHORT@@', product.nameShort)) .pipe(replace('@@NAME@@', product.applicationName)) .pipe(replace('@@ICON@@', product.applicationName)) .pipe(rename('usr/share/applications/' + product.applicationName + '-url-handler.desktop')); </ins> const appdata = gulp.src('resources/linux/code.appdata.xml', { base: '.' }) .pipe(replace('@@NAME_LONG@@', product.nameLong)) .pipe(replace('@@NAME@@', product.applicationName))

Related discussion:
text: This may be useful as a hint: Please, take a two minutes to look into source, it may work only for :
I think adding a desktop file with that launches VS Code with is what's needed to implement this.
nice relevant gist:
VS Code has native support for opening it's own URL scheme via the hidden argument, I don't think there is a need for wrapper script shenanigans. I'm going to submit a PR.
I've not checked too far into it (Just subscribed to this to keep up to date) but the wrapper script is probably there because in the standard would include the "vscode://" prefix.
That's what should happen, that's what handles. :smiley: You can test if you like. Alternatively you can test this (Which is what the PR adds): For OSS: For release version: Drop it into or and run on that directory.
Code change:
useReplacePreview: boolean; showLineNumbers: boolean; usePCRE2: boolean; <ins> actionsPosition: 'auto' | 'right'; </ins> } export interface ISearchConfiguration extends IFilesConfiguration {

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:
useReplacePreview: boolean; showLineNumbers: boolean; usePCRE2: boolean; <ins> actionsPosition: 'auto' | 'right'; </ins> } export interface ISearchConfiguration extends IFilesConfiguration {

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:
dependencies: safe-buffer "^5.0.1" <ins> universalify@^2.0.0: version "2.0.1" resolved "https://registry.yarnpkg.com/universalify/-/universalify-2.0.1.tgz#168efc2180964e6386d061e094df61afe239b18d" integrity sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw== </ins> util-deprecate@^1.0.1: version "1.0.2" resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf" integrity sha1-RQ1Nyfpw3nMnYvvS1KKJgUGaDM8= <ins> uuid@^9.0.1: version "9.0.1" resolved "https://registry.yarnpkg.com/uuid/-/uuid-9.0.1.tgz#e188d4c8853cc722220392c424cd637f32293f30" integrity sha512-b+1eJOlsR9K8HJpow9Ok3fiWOWSIcIzXodvv0rQjVoOVNpWMpxf1wZNpt4y9h10odCNrqnYp1OBzRktckBe3sA== </ins> vscode-oniguruma@1.7.0: version "1.7.0" resolved "https://registry.yarnpkg.com/vscode-oniguruma/-/vscode-oniguruma-1.7.0.tgz#439bfad8fe71abd7798338d1cd3dc53a8beea94b"

Related discussion:
text: a folder in WSL and show logs the error log !
Are things broken in this case or just a bad stack trace. I'll take a look to see if I missed a module include somewhere
Just a bad stacktrace from what I see, though I didn't intentionally go test things thoroughly
Code change:
import { ITerminalConfigurationService, LinuxDistro } from './terminal.js'; import type { IXtermCore } from './xterm-private.js'; import { DEFAULT_BOLD_FONT_WEIGHT, DEFAULT_FONT_WEIGHT, DEFAULT_LETTER_SPACING, DEFAULT_LINE_HEIGHT, FontWeight, ITerminalConfiguration, MAXIMUM_FONT_WEIGHT, MINIMUM_FONT_WEIGHT, MINIMUM_LETTER_SPACING, TERMINAL_CONFIG_SECTION, type ITerminalFont } from '../common/terminal.js'; <ins> import { isMacintosh } from '../../../../base/common/platform.js'; </ins> // #region TerminalConfigurationService

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.75.1 OS Version: macOS 12.6 Steps to Reproduce: any CLI utility that displays a loader animation that uses braille, such as every step of the animation, you should see an array of dots that don't use up a full square space, but leave some blank space and look like a "snake" (this works fine in Windows) This is how it looks in other terminals such as iTerm2 or <img width="33" alt="image" src="https://user-"This is how it looks in VS Code (i've tried changing fonts, it doesn't help) <img width="31" alt="image" src="https://user-"This is the character: On Windows version of VS Code, this behaves correctly on macOS, instead of white space it shows circles with transparent filling
any news?
Hello, it's been half a year and it's been tagged many things, I'd love to know if this is being taked into consideration since it's very bad UX
Interesting that this works on windows but not mac.... This issue reproduces in the monaco editor
it looks like for we are using the python3.9 spinners
I found this - have you tried other fonts?
i found out that it's Chromium's fault, the issue happens in Chrome for macOS and every other child browser, but doesn't happen in Firefox nor Safari, so I opened a bug report there
Looking at it appears that whatever font is being fallen back to is adding the empty circles?
Code change:
import { ITerminalConfigurationService, LinuxDistro } from './terminal.js'; import type { IXtermCore } from './xterm-private.js'; import { DEFAULT_BOLD_FONT_WEIGHT, DEFAULT_FONT_WEIGHT, DEFAULT_LETTER_SPACING, DEFAULT_LINE_HEIGHT, FontWeight, ITerminalConfiguration, MAXIMUM_FONT_WEIGHT, MINIMUM_FONT_WEIGHT, MINIMUM_LETTER_SPACING, TERMINAL_CONFIG_SECTION, type ITerminalFont } from '../common/terminal.js'; <ins> import { isMacintosh } from '../../../../base/common/platform.js'; </ins> // #region TerminalConfigurationService

Related discussion:
text: If that's the case the fix here would be one of: Try falling back to something like in the font family setting, eg. Support custom glyph rendering for those characters, I really would rather not supporting this unless we absolutely had to though.
This bug is still present in Version: 1.84.2/macOS 14. I tried using Symbola, SF Mono, Menlo and Monaco as the main fonts, without success.
I double checked today and it looks like Chrome Version 127.0.6533.89 renders Braille characters without hollow circles on MacOS. <img width="952" alt="Screenshot 2024-08-02 at 10 50 29" src=""(I have a macOS app that's rendering the top bar differently)
So... I spent a bit too long today investigating what was happening here and here's how I've resolved this issue for myself: Before / After <img width="163" alt="Screenshot 2024-08-07 at 22 22 32" src=""<img width="163" alt="Screenshot 2024-08-07 at 22 22 42" src=""In case the diagnostic steps are useful to someone, here's the portion of my search tree that resulted in this solution / bodge.... I looked through my macOS font book for which fonts were providing symbols for (U+2879) and ended up finding "Apple Braille" and "Apple Symbols". "Apple Symbols" had the wrong amount of whitespace when I set that as the fallback font and the "Apple Braille" looked like a drop-in replacement. Turns out, Apple Braille looked different in the OS's Font Book vs in VS Code. The reason for this ended up being that Apple Braille has multiple variants and... for some reason... the version of Chromium being used in VS Code uses either Outline6Dot or Outline8Dot variants by default (these have the hollow/outline circles) instead of the Regular variant which does not have hollow circles. I assume this has to do with the font-renderer-level behaviour. None the less, the of the specific font variant within the "Apple Braille" family that I want to use was "AppleBraille" and adding that to the stack makes it use the correct-for-me variant of the OS-provided Braille symbols!
Code change:
import { ITerminalConfigurationService, LinuxDistro } from './terminal.js'; import type { IXtermCore } from './xterm-private.js'; import { DEFAULT_BOLD_FONT_WEIGHT, DEFAULT_FONT_WEIGHT, DEFAULT_LETTER_SPACING, DEFAULT_LINE_HEIGHT, FontWeight, ITerminalConfiguration, MAXIMUM_FONT_WEIGHT, MINIMUM_FONT_WEIGHT, MINIMUM_LETTER_SPACING, TERMINAL_CONFIG_SECTION, type ITerminalFont } from '../common/terminal.js'; <ins> import { isMacintosh } from '../../../../base/common/platform.js'; </ins> // #region TerminalConfigurationService

Related discussion:
text: Alternatively, you can also do what I did recently and change to a font that includes braille characters (like ).
I considered creating an issue for this for the editor as well, but the visualize progress isn't as important there and it's more possible people may want the filled/empty circle rendering in the editor to more easily identify which circles are filled.
This failed the macOS build when merged: