text:
ColorTool needs CI fixing

We need to do one of two things:

Merge the ColorTool SLN in with the OpenConsole SLN and just have one SLN.
Add another CI pipeline for ColorTool's SLN (since the OpenConsole one runs that one only) and set both pipelines to only operate on changes that are relevant to themselves.

We can perhaps use the Azure CI "export existing pipeline as yaml" button.

authors: DHowett-MSFT miniksa

repo: microsoft/terminal


text:
When Terminal has focus, shift+drag on title bar does not trigger FancyZones

Windows Terminal version (or Windows build number)
1.9.1942.0
Other Software
PowerToys 0.43.0
Steps to reproduce
On a laptop+monitor setup using virtual desktops.
With FancyZones defined for a desktop.

Give the Terminal window focus (by opening it, or click or Alt+Tab on existing Terminal window)

Shift+Left-click+drag on Terminal title.  FancyZone borders / highlighted regions do not appear on screen as expected. Window does not move during drag as would be expected with NO shift modifier, but when drag is released, Terminal window moves to new position as if shift had not been pressed (i.e. normal window drag).

Same attempt (shift+drag to FancyZone) on any other (non-Terminal) window. This window snaps to FancyZone as expected.

Same attempt on Terminal window (which no longer has focus). This time, snaps to FancyZone as expected.

Without losing Terminal focus, try again. Fails again.

Give focus to any non-Terminal window.

Without giving Terminal focus, try again on Terminal. Succeeds.

Expected Behavior
Show FancyZone during shift+drag, snap to FancyZone on drag release.
Actual Behavior
Terminal window  is unresponsive during shift+drag, moves on drag release.

This is a dupe of #2905, which is actually a dupe of microsoft/PowerToys#209.
WAIT but that was fixed in 2019. So this must be some new regression. I'd follow up with PowerToys on their repo: https://github.com/microsoft/PowerToys/issues

Thanks @zadjii-msft -- While that was indeed fixed / closed, there were subsequent reports on that issue, which were referred to https://github.com/microsoft/PowerToys/issues/1466, which was labeled as Resolution-External. So ¯\_(ツ)_/¯

@crutkas can we get more context on this from the PowerToys side? I thought y'all took a fix for PT for the Terminal, but both microsoft/PowerToys#1466 and microsoft/PowerToys#209 are just kind of black hole issues right now, without any real guidance on why the Terminal doesn't work in this case. Is this a XAML Islands thing?
I'd rather get to the root cause of the issue (even if it's unsolvable) than just spiderman.png all day.

@zadjii-msft Ive gone into depth how to recreate the issue without FZ/ PT even installed in other bugs here. We amplify the issue since the behavior required for FZ.
Best of my knowledge we did not do a fix for it. I'd sync internal as I'm OOF until September 1 also.

source: gharchive/issue

authors: crutkas jdmarch zadjii-msft

license: MIT

license_type: permissive

license_source: github-api


text:
Unable to install new versions on Windows 10

Discussed in https://github.com/microsoft/terminal/discussions/15480

Originally posted by TheDevilDan May 30, 2023
Hello,
I can't install the terminal since the new versions 1.17 and 1.18.

I get this error message when I run msibundle:
The installation of this application package is not supported by the Application Installer, as it uses certain restricted features.
Unfortunately I'm in a professional enterprise context with GPO, so I'm afraid I'll be forced to stop updating these packages :/.
That's why I get the Windows Terminal from Git and not from the Microsoft store (store blocked).
I tried to install the terminal with Powershell, same problem, here's the screenshot:

DEEPL Trad french to english :
1.18
Add-AppxPackage : Deployment failed with HRESULT : 0x80073D19, An error occurred because a user logged out.
Windows cannot install the package Microsoft.WindowsTerminalPreview_1.18.1462.0_x64__8wekyb3d8bbwe, because this package depends on an infrastructure that could not be found. Specify the "Microsoft.UI.Xaml.2.8" infrastructure published by "CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with a neutral or x64 processor architecture and the minimum version 8.2305.5001.0, in addition to this installation package. Infrastructures with the name "Microsoft.UI.Xaml.2.8" ins
Windows cannot install the package Microsoft.WindowsTerminalPreview_1.18.1462.0_x64__8wekyb3d8bbwe, because this package depends on an infrastructure that could not be found. Specify the "Microsoft.UI.Xaml.2.8" infrastructure published by "CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with a neutral or x64 processor architecture and the minimum version 8.2305.5001.0, in addition to this installation package. The infrastructures with the name "Microsoft.UI.Xaml.2.8" currently installed are: {}
NOTE: for further information, search for [ActivityId] dd5fbd3c-78e8-0007-d9e0-81dde878d901 in the event log or use the command line Get-AppPackageLog -ActivityID dd5fbd3c-78e8-0007-d9e0-81dde878d901
To character Line:1 : 1

1.17
Add-AppxPackage : Deployment failed with HRESULT : 0x80073D19, An error occurred because a user logged out.
Windows cannot install the package Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe, because this package depends on an infrastructure that could not be found. Specify the "Microsoft.UI.Xaml.2.7" infrastructure published by "CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with a neutral or x64 processor architecture and the minimum version 7.2208.15002.0, in addition to this installation package. Infrastructures with the name "Microsoft.UI.Xaml.2.7" installed
Windows cannot install the package Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe, because this package depends on an infrastructure that could not be found. Specify the "Microsoft.UI.Xaml.2.7" infrastructure published by "CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with a neutral or x64 processor architecture and the minimum version 7.2208.15002.0, in addition to this installation package. The infrastructures with the name "Microsoft.UI.Xaml.2.7" currently installed are:
{Microsoft.UI.Xaml.2.7_7.2109.13004.0_x86__8wekyb3d8bbwe Microsoft.UI.Xaml.2.7_7.2109.13004.0_x64__8wekyb3d8bbwe Microsoft.UI.Xaml.2 .7_7.2203.17001.0_x64__8wekyb3d8bbwe Microsoft.UI.Xaml.2.7_7.2203.17001.0_x86__8wekyb3d8bbwe}
NOTE: to obtain additional information, search for [ActivityId] dd5fbd3c-78e8-0007-e3e0-81dde878d901 in the event log or use the command line Get-AppPackageLog -ActivityID dd5fbd3c-78e8-0007-e3e0-81dde878d901
To character Line:1 : 1

I use without problem the 1.16 and 1.17 on my computer with git releases :) and i use new tab menu in my json top !! but the new version won't install  since 1 week

That is great news, thank you!

authors: DHowett TheDevilDan


text:
Inconsistent terminal color (on startup)

Windows Terminal version
1.19.10573.0
Windows build number
10.0.22631.0
Other Software
> wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3296

Ubuntu 22.04.4 LTS
ZSH 5.8.1
Oh My Zsh version: master (0fed366)
ZSH_THEME="bira"

Steps to reproduce
I cannot reproduce it 100% reliably, but I do get it fairly regularly (at least once per day).
It typically happens for the first terminal I create after I boot my computer.
Expected Behavior
If I open multiple panes/tabs/windows, they should all have the same colorscheme (or render the colors the same way).
Actual Behavior
For the first terminal I create, I get colors that are slightly off. All panes/tabs/windows I create after that have correct colors:

In this example, the upper pane is the first pane and the lower pane was created later.
According to the color picker from PowerToys, these are the colors I get in the screenshot example:

Black
White
Green
Blue

Upper pane
#0c0c0c
#f0f0f0
#4be14b
#4040bd

Lower pane
#0c0c0c
#f0f0f0
#15b40c
#3b78ff

Node that there is some variation caused by aliasing, so I may have accidentally picked the wrong colors. But it's an honest attempt. 😅

Could you share your settings.json file/?

Of course! Here: settings.json

Thanks for filing! We took a look at the settings.json file and nothing stood out. Could you capture a Debug Tap of when the terminal launches with this unexpected configuration/? Be sure to hold both alt buttons when the terminal launches to get it to work.

I have so far been unable to reproduce the bug with the debug tap active. I will keep trying for a while longer, but maybe the bug does not show up with the tap active?

But it does show up relatively consistently without the debug tap? That would be.... extremely bizarre. Especially since the color values in the image don't actually look like they're coming from the color schemes, so that would seemingly suggest that there's something in your prompt that's manually emitting those colors?

Yes, it happens multiple times per day, but I have not yet figured out a way to reliably reproduce it. Mostly I think it's when I leave the computer on for a while and the screen goes dark after screen lock (e.g. during lunch). When I come back, it's very frequent that this problem occurs.
Next time I catch it, I'll try to echo a color (e.g. echo -e '\e[34m\e[1m\u25A0\e[0m') and inspect what color that is. That might give us a clue if this is the text output that goes wrong or if all colors are off. ¯\_(ツ)_/¯
I'll do my best to try and figure out the exact circumstances. Will keep you posted!

Thanks! If you don't have the rights to reopen it, let one of us know and we will!

I just had it occur again and was able to capture the output of echo '\e[34m\e[1m\u25A0\e[0m':

Upper pane: #5454ff
Lower pane: #3b78ff

The image you shared has a background color of #050505 but the settings.json you previously shared doesn't have such a color anywhere. The first screenshot you shared in the beginning has #0c0c0c which does exist in one of the themese. Couple related questions:

Did you change your settings.json since then?
Are you using an HDR display?
If you open the Settings app and go to System > Display > Color Management, do you have a display profile set up?
...and if you have a "Automatically manage color for apps" toggle there, is it turned on or off?

I think this may be a memory corruption of our color table(s).

Did you change your settings.json since then?

No.

Are you using an HDR display?

On the monitor I took the screenshot on (my external monitor): no. On my laptop: yes. And would that really matter when taking a screenshot or measuring with the color picker tool from PowerToys?

If you open the Settings app and go to System > Display > Color Management, do you have a display profile set up?

I didn't find "Color management". Is it the same as "Colour profile"? I've got a profile for my external monitor but not the built in one:

...and if you have a "Automatically manage color for apps" toggle there, is it turned on or off?

It's off for both displays.

I think this may be a memory corruption of our color table(s).

I always find the bizarre ones: 😂

And would that really matter when taking a screenshot or measuring with the color picker tool from PowerToys?

Yes, at least in my understanding. DWM composites all applications into a single surface which has a color format and space that fits the target display. Windows Terminal renders text into a BGR (reverse RGB) 8-bit surface, which DWM composites into for instance (I'm not actually sure which one specifically) RGB with 16-bit floats to later output it on a HDR display. When you take a screenshot, it'll take a copy from that DWM surface and then convert it back to 8-bit RGB.

I've got a profile for my external monitor but not the built in one:

GPUs should apply color profiles very late with a matrix or LUT transform, only when actually sending the image to the monitor. I was just wondering if it's possible that a color profile may get applied early by DWM and if so, if it may not be applied to all swap chains (= all panes/tabs). I don't think that's possible, but...
Well maybe it's indeed a memory corruption. But it'd definitely be the first and only report about it so far!

authors: DHowett carlos-zamora lhecker lindhe zadjii-msft


text:
Bug Report : Windows Terminal Crashes on Startup

Environment

Windows build number: [run [Environment]::OSVersion for powershell, or ver for cmd]
Windows Terminal version (if applicable): Latest from Github source, compiled 11am 8/28/2019 after git pull.
Any other software?
Visual Studio 2019
Steps to reproduce
Open Windows Terminal Dev build. This used to work, and stopped working about two weeks ago after a git pull and recompile. I have tried uninstalling and reinstalling using multiple methods, have deleted my source directory and re-downloaded and followed all the steps in the documentation in the README.
Expected behavior
Terminal should open, and used to open.
Actual behavior
Terminal crashes on launch every time. https://aka.ms/AA5yrsw
Faulting application name: WindowsTerminal.exe, version: 0.0.0.0, time stamp: 0x5d66be04
Faulting module name: ucrtbase.dll, version: 10.0.18965.1000, time stamp: 0xafa25d02
Exception code: 0xc0000409
Fault offset: 0x00000000000714ae
Faulting process id: 0x3dc0
Faulting application start time: 0x01d55dcc172dff9a
Faulting application path: C:\Temp\winterm\src\cascadia\CascadiaPackage\bin\x64\Release\AppX\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 06aba601-3041-4c3b-899b-432c97e7e44d
Faulting package full name: WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: APP

I am still seeing this, even with the latest code. Anyone on the MS side got any ideas?

I'm so sorry. Our bot went a little crazy for a second.

Hi Dustin - I got an automated email asking for a feedback link, which was included. Here it is again:
https://aka.ms/AA5yrsw

Update, I saw there were a lot of changes today. This still builds, installs and explodes on launch.

Hey, so, I can't actually look at any of your crash logs. Unfortunately, since you're running a locally-built dev build (and I'm sorry I missed this in the beginning) it's up to you to provide a stack trace from your development environment. My debugger cannot resolve the symbols produced on your machine. :smile:

I found this issue through a ~google~bing search and had a similar problem. My terminal (the windows store version) has been crashing for months immediately upon opening. I kept trying new builds when they were released but the problem persisted.
I eventually tracked it down to the settings file, I believe I had an default guid set for a profile (and maybe I deleted the other profiles, I can't remember) that may have become invalid after reinstalling WSL? This crashing behavior actually persisted through two OS reinstalls, so I assume the settings file is stored in the cloud somewhere? After resetting the app through the right click -> "app settings" pane, it works fine again.
Not sure if this is a separate is a separate issue from the OP's that should be tracked, but wanted to mention it.

For me, the solution was to run the application with the integrated graphics card, instead of my NVidia graphics card. There are two ways to do that:

I had three applications start doing this at the same time... Paint.NET, mRemoteNG, and Windows Terminal. I think they started failing when I connected a new Thunderbolt "docking station" with USB3 and DisplayPort monitors.

I tried doing that with the graphics settings. It did not improve the situation. I will get you a stack trace @DHowett. Do you want me to create a dump from the process as well, with it hung on crash?

Yes, please. Thanks!

Exception thrown at 0x00007FFEE4584F99 in WindowsTerminal.exe: Microsoft C++ exception: winrt::hresult_error at memory location 0x0000008E1CAFE518
KernelBase.dll!00007ffee4584f99()	Unknown
vcruntime140d.dll!00007ffeb71382f7()	Unknown

TerminalApp.dll!winrt::throw_hresult(const winrt::hresult result) Line 4367	C++
TerminalApp.dll!winrt::check_hresult(const winrt::hresult result) Line 4413	C++
TerminalApp.dll!winrt::get_activation_factorywinrt::Microsoft::Terminal::TerminalConnection::IConhostConnectionFactory(const winrt::param::hstring & name) Line 5295	C++
TerminalApp.dll!winrt::impl::factory_cache_entrywinrt::Microsoft::Terminal::TerminalConnection::ConhostConnection,winrt::Microsoft::Terminal::TerminalConnection::IConhostConnectionFactory::call<<lambda_4c3dc08770363e37251a9b4ac844b54d> &>(winrt::Microsoft::Terminal::TerminalConnection::ConhostConnection::<lambda_4c3dc08770363e37251a9b4ac844b54d> & callback) Line 5500	C++
TerminalApp.dll!winrt::impl::call_factory<winrt::Microsoft::Terminal::TerminalConnection::ConhostConnection,winrt::Microsoft::Terminal::TerminalConnection::IConhostConnectionFactory,<lambda_4c3dc08770363e37251a9b4ac844b54d>>(winrt::Microsoft::Terminal::TerminalConnection::ConhostConnection::<lambda_4c3dc08770363e37251a9b4ac844b54d> && callback) Line 5574	C++
TerminalApp.dll!winrt::Microsoft::Terminal::TerminalConnection::ConhostConnection::ConhostConnection(const winrt::param::hstring & cmdline, const winrt::param::hstring & startingDirectory, const winrt::param::hstring & startingTitle, unsigned int rows, unsigned int columns, const winrt::guid & guid) Line 229	C++
TerminalApp.dll!winrt::TerminalApp::implementation::TerminalPage::_CreateConnectionFromSettings(_GUID profileGuid, winrt::Microsoft::Terminal::Settings::TerminalSettings settings) Line 431	C++
TerminalApp.dll!winrt::TerminalApp::implementation::TerminalPage::_CreateNewTabFromSettings(GUID profileGuid, winrt::Microsoft::Terminal::Settings::TerminalSettings settings) Line 361	C++
TerminalApp.dll!winrt::TerminalApp::implementation::TerminalPage::OpenNewTab(std::optional profileIndex) Line 339	C++
TerminalApp.dll!winrt::TerminalApp::implementation::TerminalPage::Create() Line 85	C++
TerminalApp.dll!winrt::TerminalApp::implementation::App::Create() Line 158	C++
TerminalApp.dll!winrt::impl::producewinrt::TerminalApp::implementation::App,winrt::TerminalApp::IApp::Create() Line 723	C++
WindowsTerminal.exe!winrt::impl::consume_TerminalApp_IAppwinrt::TerminalApp::IApp::Create() Line 47	C++
WindowsTerminal.exe!AppHost::Initialize() Line 81	C++
WindowsTerminal.exe!wWinMain(HINSTANCE * formal, HINSTANCE * __formal, wchar_t * __formal, int __formal) Line 147	C++
[External Code]

Dump file in 7zip file: https://drive.google.com/file/d/1Y_gqlBMhX4LBC7IhfSDhxtLNgb1jMFZA/view?usp=sharing

Hold up, you’re using the preview release of VS aren’t you?

I am using 2019 Preview 3. I was using Preview 2 and it was broken before I updated as well. This used to work on Preview 1.

This is more than likely just #2625. Sorry!

@DHowett-MSFT This broke before I upgraded to preview 3. Do we know if there is a manual way to fix this for the time being?

authors: DHowett-MSFT Wallace-Kelly dyyylan xpwn3rx


text:
Scenario: The Command Palette

[Original issue: #2046] [Original Spec: #2193] [v2 Spec: #5674] [Spec Addendum 1: #6532]

TODO for initial PR

[x] The list view items should be clickable
[x] The list should be sorted by weight, then alphabetically
[x] There should be stronger weighting for consecutive chars. Case in point: the sett example below
[x] If you click on a list view item, focus enters the list view item, and then you can't hit enter to select it.
[x] tests tests tests tests.
[x] The auto gen names should probably only have the first letter capitalized - I bet if I do that I'll have to revert it during the PR... hmm...

v2.0 Follow-up work
Tasks

[x] Add nested commands to the Command Palette #3994
[x] Command palette entries should have optional icons #6644
[x] A nested cmdpal menu should show the parent command above the list of commands #7265
[x] Add support for commands iterable on color schemes #7329
[x] Command Palette: Add support for commandline mode #6677
[ ] Don't localize command names on the command palette #7039
[x] Make keys in the command palette look like actual keys, like in VS Code #6645
[x] Command palette search results should bold the matching text #6646
[ ] Add a setting to display Command Palette ActionMode entries in MRU order #6647
[ ] commandPalette keybinding should close the palette when it's open #6679
[ ] Add "recent commands' to Command Palette in commandline mode #8296

Bugs

[ ] _compareCommandNames should use locale-aware string comparisons #6953
[ ] NewTab won't leave the Command Palette #7441
[ ] Command Palette search algorithm needs to prioritize "longest substring" match, may need multiple passes #6693
[ ] #7915 [Visual requirement-Command Palette]-Luminosity ratio is 4.046:1 which is less than 4.5:1 for the shortcut text appended to the Commands.
[ ] #7914 [Functional-Command Palette]- User is not able to perform action using shortcuts when command palette is open.
[ ] #7913 [Screen Reader-Command Palette]-Narrator focus moves separately onto the shortcut text which is appended to the command.
[ ] #7912 [Usable-Command Palette]-Keyboard shortcuts are not included in the sub menu of New Tab list item.
[ ] #7911 [Screen Reader-Command Palette]-Narrator focus is not in sync while navigating using arrow keys in suggestion list after searching for any command.
[ ] #7910 [Functional-Command Palette]- User is not able to move back from the New Tab sub menu as there is no functionality provided to move out of Sub menu.
[ ] #7908 [Screen Reader-Command Palette]-Screen reader user will not be able to identify the purpose of New Tab control if role and state are not appropriate.
[ ] #7907 [Screen Reader-Command Palette]:-Screen reader is not announcing the suggestions when user searches for the commands.

Related, but indirectly

[x] Add a shortcut action for switching to a specific color scheme #5401
[x] Enable sending input to the Terminal with a keybinding #3799
[ ] Add an action that runs other actions (action chaining)? #5970
[ ] Megathread: Sometimes, focus moves weirdly #6680

[ ] Launching "Find" from Command Palette doesn't focus the search box #6662

[ ] New icons for UI elements #6867

Backlog work

[ ] Consider refactoring CommandPalette + Switcher => LiveFilteringListView #7285
[ ] Allow commands to be previewed in the command palette #6689
[ ] Allow commands with user-defined names to be hidden from cmdpal #7179
[ ] ~Keep the Command Palette around after executing a command #7011~
[ ] Provide realtime commandline parsing feedback in the commandline mode of the command palette #7284
[ ] Add auto-suggestion to the Command-Palette wt arguments #7570

Alright, so lets get some teaser images of what's in progress:

This is including the spec changes in review over in #6532.
There's also a shadow on the dialog that the snipping tool is conveniently leaving out.

Sorry if there is already an issue tracking this but I think it would be a good idea to show the profile names instead of index numbers.

@zadjii-msft - is there a plan to add a lazy loading for command palette. From my startup profiling, the load adds more than 0.5 sec on startup?

Not at the moment, but .5s is pretty bad 😬 Maybe we should be! Presumably, we don't need to expand iterable commands before displaying the UI, so that could be done on a background thread, and if the user does super quickly open the cmdpal, then we could wait for that background job to complete. Iterable commands won't have a keybinding set on them, so I'm not worried about that so much.
Out of curiosity, how are you profiling the startup? Are there any other hot paths in our startup that stand out? (Might be best to start a new thread for that discussion though)

Not at the moment, but .5s is pretty bad 😬 Maybe we should be! Presumably, we don't need to expand iterable commands before displaying the UI, so that could be done on a background thread, and if the user does super quickly open the cmdpal, then we could wait for that background job to complete. Iterable commands won't have a keybinding set on them, so I'm not worried about that so much.
Out of curiosity, how are you profiling the startup? Are there any other hot paths in our startup that stand out? (Might be best to start a new thread for that discussion though)

I am using intel's vtune profiler both in usual and kernel events modes.

authors: Don-Vito matthew4850 zadjii-msft


text:
Implement inheritance/layering behavior for settings lists/maps

Description of the new feature/enhancement
TSM Inheritance (Spec #7876 + Impl #7923 ) enabled an object model representation of layering JSON. Some settings that are saved to arrays/maps (i.e. actions, color schemes) still experience a special form of layering that is not represented in the object model.
Today, the object model std::moves the list of actions/schemes down child-by-child, and directly modifies those values. We need to restructure this system to...

track where an action/color scheme came from
layer actions over other actions

This blocks the following work items:

serialization for actions
Settings UI implementation for actions
serializing only new color schemes (ones not from defaults.json)

This also is partially related to...

#7175 Action IDs

Moved this to backlog because this is more related to #8991 and #6900. So it's not extremely urgent right now.

#9621 solves most of the problem here.
The remaining work to be done is for color schemes.

@DHowett So, I think #12800 closes out the last bit of this? This issue was written long before Leonard re-wrote the settings parser, so I don't think it's relevant anymore?

authors: carlos-zamora zadjii-msft


text:
How to change pane divider color and width?

Hi, the pane divider is ugly with dark mode, the divider is too wide and color is inconsistent with the dark theme, I cannot find a way to change it,  anyone can help？ Thanks!
Windows Terminal Preview Version: 1.5.3242.0

Unfortunately, due to a bug the pane divider will always match the system-wide application light/dark mode. More info in /duplicate #3917
Width is tracked in https://github.com/microsoft/terminal/issues/3063

authors: DHowett sweihub


text:
Crash on pressing cursor keys in command palette input box

Windows Terminal Version: 1.5.10411.0
Microsoft Windows [Version 10.0.19042.804]
After opening a sub-command list from command palette and erasing the > to go to wt command mode, if up or down cursor keys are pressed windows terminal crashes.
Steps:

Run wt.exe, press ctrl+shift+p to open command palette.
Open any item which opens its own sub commands list, e.g. "select colorscheme..." or "new tab..."
Now press backspace to delete the > from input box and to switch to wt commands mode.
Press up or down arrow.
wt.exe crashes and application stopped working dialog is shown.

When > is erased, the items from the sub-command list are removed, but it still shown the command title and button to go back to main view. Probably everything should be reset leaving just the input box as it does when we are in the main view.

Woah crazy, we just had another report of this over in #9241. This is already fixed in 1.6, and we believe it was fixed by #8422.
/dup #9241

authors: harig zadjii-msft


text:
Tree-shake the library link list

Summary of the Pull Request
This makes things nicer.
References
PR Checklist

[x] Closes #3477
[x] legal bases covered
[x] Tests added/passed/it builds
[x] Requires documentation to be updated/nah
[x] 5

Detailed Description of the Pull Request / Additional comments
It turns out that we don't need to link 300 things actually! Umbrella libs are the best.
Validation Steps Performed
build and dumpbin

/azp run

source: gharchive/pull-request

authors: DHowett-MSFT zadjii-msft


text:
a multi-line problem about layoutlm

Can layoutlm solve the problem of an entity scattered in multiple lines, such as in a table

It depends on how your labeled data looks like. For example, multi-line entities also exist in the form understanding task.

Do you mean concatenate multi-line of entities through tags？It seems that I need to modify the BIEO labeling method. There may be other tags in the middle of an entity, in the order of reading from top to bottom and from left to right.

Yes, depending on your applications, you might need to modify the labeling method.

whoaa, this is my problem too, thanks for the idea to modify the labelling method. But do you have any idea how to do that, I mean the best practice maybe?

also interest in the discontinuous entitiy tagging scheme

authors: hyybuaa nunenuh shihanmax wolfshow

repo: microsoft/unilm


text:
[gmp] Visual Studio 2019 version 16.7 breaks gmp:x64-uwp

Host Environment

OS: Windows
Compiler: N/A

To Reproduce
Steps to reproduce the behavior:
.\vcpkg.exe install gmp:x64_uwp
Failure logs
-Cut and past the appropriate build messages from the console output.
-Please attach any additional failure logs mentioned in the console output.
build-x64-uwp-rel-out.log
patch-x64-uwp-0-err.log
patch-x64-uwp-1-err.log
patch-x64-uwp-2-err.log
stdout-x64-uwp.log
x64-uwp.vcpkg_abi_info.txt
Additional context
This problem also occurs if one tries to build the gmp solution in Visual Studio

Confirming with msbuild team, that mixing configurations with different application types is not supported, and this has never been supported, not sure why it works before, I will try to contact the project owner.

authors: BillyONeal PhoebeHui

repo: microsoft/vcpkg


text:
[lua] cmake can not return on linux, while compiling, the cpu usage is 100%, and the task will never end

Describe the bug
when i use lua
cmake can not return on linux, while compiling, the cpu usage is 100%, and the task will never end
Environment

OS: Ubuntu20
Compiler: cmake 3.16

To Reproduce
vcpkg install lua
cmake .. "-DCMAKE_TOOLCHAIN_FILE=~/.vcpkg/scripts/buildsystems/vcpkg.cmake"
Expected behavior
compile complete successfully
Failure logs
-not any logs
Additional context
the same code can run perfectly on win10.
`# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(test)
include(FindLua)
find_package(Lua REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE ${LUA_LIBRARIES})
`

Confirmed. Thanks for reporting this issue!

Confirmed. Thanks for reporting this issue!

can anybody fix it?

can anybody fix it?

This issue is in my list to be fixed.

This issue is in my list to be fixed.

Why did you close this PR? It's not resolved yet.

now i can compile lua project, the problem might have been fixed

Why did you close this PR? It's not resolved yet.

authors: JackBoosY williamxin


text:
[New Port Request] tomlc99

Library name: tomlc99
Library description: TOML parsing library. Compatible with TOML v1.0.0., Provides very simple and intuitive interface.
Source repository URL: https://github.com/cktan/tomlc99
Project homepage (if different from the source repository):
Anything else that is useful to know when adding (such as optional features the library may have that should be included):

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

authors: PhoebeHui calloatti


text:
[check] checkShared produce broken binaries

Describe the bug
When check port is used in projects on Windows system, then resulting unit test binaries are not runnable due to missed DLL error.
Environment

OS: Windows
Compiler: MSVC 19.27.29112.0

To Reproduce
Steps to reproduce the behavior:

./vcpkg --triplet x64-windows install check
git clone https://gist.github.com/3e18a59b7c3ff88582b994ed9a730180.git cc (I've prepared minimal reproducible example)
cd cc
mkdir build
cd build
cmake .. -DBUILD_SHARED_LIBS:BOOL=on -DCMAKE_VERBOSE_MAKEFILE:BOOL=on -DCMAKE_TOOLCHAIN_FILE=C:\Users\User\vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TAR GET_TRIPLET=x64-windows -DCMAKE_BUILD_TYPE=Release
cmake --build .
ctest .

Then the following happens:
Test project C:/Users/User/checkcheck/build
    Start 1: check
1/1 Test #1: check ............................Exit code 0xc0000135
***Exception:   0.19 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.20 sec

The following tests FAILED:
          1 - check (Exit code 0xc0000135
)
Errors while running CTest
Output from these tests are in: C:/Users/User/checkcheck/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.

Expected behavior
ctest run without the failure

As a workaround, you could manually move the files from \vcpkg\installed\{triplet}\bin\manual-link to \vcpkg\installed\{triplet}\bin.

authors: Cheney-W matwey


text:
[qt5-base] Build Failed

Host Environment

OS: Windows 10
vcpkg-tool version: 2022-06-17-9268e366206712e38102b28dbd1617697a99ff2e
vcpkg-scripts version: 8eb76645c 2022-06-27

To Reproduce
Steps to reproduce the behavior:
./vcpkg install colmap --triplet=x64-windows --head
Failure logs
-- Configuring x64-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:83 (message):
    Command failed: C:/dev/cpp/vcpkg/buildtrees/qt5-base/src/5.15.5-451bf817fc.clean/configure.bat -confirm-license -opensource -verbose -system-zlib -system-libjpeg -system-libpng -system-freetype -system-pcre -system-doubleconversion -system-sqlite -system-harfbuzz -icu -no-angle -no-glib -no-sql-psql -no-sql-mysql --vulkan=no -opengl dynamic -nomake examples -nomake tests LIBJPEG_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/jpegd.lib ZLIB_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/zlibd.lib "LIBPNG_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/libpng16d.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/zlibd.lib" PCRE2_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/pcre2-16d.lib "FREETYPE_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/freetyped.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/bz2d.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/libpng16d.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/zlibd.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/brotlidec.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/brotlicommon.lib" "ICU_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icuind.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icutud.lib  C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icuucd.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icuiod.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icudtd.lib Advapi32.lib" QMAKE_LIBS_PRIVATE+=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/bz2d.lib QMAKE_LIBS_PRIVATE+=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/libpng16d.lib "QMAKE_LIBS_PRIVATE+=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icuind.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icutud.lib  C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icuucd.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icuiod.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/icudtd.lib Advapi32.lib" QMAKE_LIBS_PRIVATE+=ZSTD_DEBUG-NOTFOUND SQLITE_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/sqlite3.lib HARFBUZZ_LIBS=-lharfbuzz "OPENSSL_LIBS=C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/libssl.lib C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/libcrypto.lib ws2_32.lib secur32.lib advapi32.lib shell32.lib crypt32.lib user32.lib gdi32.lib" -debug -prefix C:/dev/cpp/vcpkg/installed/x64-windows -hostprefix C:/dev/cpp/vcpkg/installed/x64-windows/tools/qt5/debug -hostlibdir C:/dev/cpp/vcpkg/installed/x64-windows/tools/qt5/debug/lib -hostbindir C:/dev/cpp/vcpkg/installed/x64-windows/tools/qt5/debug/bin -archdatadir C:/dev/cpp/vcpkg/installed/x64-windows/tools/qt5/debug -datadir C:/dev/cpp/vcpkg/installed/x64-windows/share/qt5/debug -plugindir C:/dev/cpp/vcpkg/installed/x64-windows/debug/plugins -qmldir C:/dev/cpp/vcpkg/installed/x64-windows/debug/qml -headerdir C:/dev/cpp/vcpkg/installed/x64-windows/include/qt5 -libexecdir C:/dev/cpp/vcpkg/installed/x64-windows/tools/qt5/debug -bindir C:/dev/cpp/vcpkg/installed/x64-windows/debug/bin -libdir C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib -I C:/dev/cpp/vcpkg/installed/x64-windows/include -I C:/dev/cpp/vcpkg/installed/x64-windows/include/qt5 -L C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib -L C:/dev/cpp/vcpkg/installed/x64-windows/debug/lib/manual-link -platform win32-msvc
    Working Directory: C:/dev/cpp/vcpkg/buildtrees/qt5-base/x64-windows-dbg
    Error code: 3
    See logs for more information:
      C:\dev\cpp\vcpkg\buildtrees\qt5-base\config-x64-windows-dbg-out.log
      C:\dev\cpp\vcpkg\buildtrees\qt5-base\config-x64-windows-dbg-err.log

Call Stack (most recent call first):
  ports/qt5-base/cmake/configure_qt.cmake:127 (vcpkg_execute_required_process)
  ports/qt5-base/portfile.cmake:358 (configure_qt)
  scripts/ports.cmake:146 (include)

error: building qt5-base:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+qt5-base
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[qt5-base]+Build+error
Include '[qt5-base] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
    vcpkg-tool version: 2022-06-17-9268e366206712e38102b28dbd1617697a99ff2e
    vcpkg-scripts version: 8eb76645c 2022-06-27 (21 hours ago)

You can also use the prefilled template from C:\dev\cpp\vcpkg\installed\vcpkg\issue_body.md.

config-x64-windows-dbg-out.log
config-x64-windows-dbg-err.log

Fixed it by:

Adding _VCPKG_INSTALLED_DIR to my environment variables so that it looks like this:

Then running the following commands in order:

git pull
vcpkg update
vcpkg upgrade

Then restarting my computer

I think you just needed to update the already instalelled ports (in particular zstd). _VCPKG_INSTALLED_DIR is handled by vcpkg.


text:
Share chainload toolchain with triplets / build libraries with the  CMAKE_TOOLCHAIN_FILE settings

Is your feature request related to a problem? Please describe.
In our usecase, triplets are checked-in to the repository and, hence, common to all environments. However,
our toolchain files/locations (in particular, cross-compiling toolchain files) will typically depend on the environment.
Currently, it seems that the chainload toolchain needs to be specified by the triplet, so this means each developer
(and buildbot) needs to have the toolchain installed in the exact same location or patch the triplet before building.
Proposed solution
If we could pass the chainload toolchain location from the main CMakeLists.txt to the triplet
(or. even better, use the chainload toolchain specified by the main CMakeLists.txt or on the commandline when building
libraries --- this makes much more sense, but is backward incompatible).
Describe alternatives you've considered
Patching the triplets before building. This is frustrating, though.
Context
It says in the documentation that the toolchain can be shared (https://vcpkg.readthedocs.io/en/latest/users/buildsystems/cmake-integration/#using-multiple-toolchain-files), but doesn't say how.

, so this means each developer (and buildbot) needs to have the toolchain installed in the exact same location

You can use ${CMAKE_CURRENT_LIST_DIR} in the triplet file. So store the toolchain somewhere relative to the triplet and you are good to go (See e.g. https://github.com/Neumann-A/my-vcpkg-triplets/blob/master/x64-win-llvm.cmake)

, so this means each developer (and buildbot) needs to have the toolchain installed in the exact same location

You can use ${CMAKE_CURRENT_LIST_DIR} in the triplet file. So store the toolchain somewhere relative to the triplet and you are good to go (See e.g. https://github.com/Neumann-A/my-vcpkg-triplets/blob/master/x64-win-llvm.cmake)

Except that the toolchain will typically contain environment dependent things (compiler paths, sdk locations, etc.), so we don't really want to commit it to VCS. So there is really no "relative" path to put it...
More generally, when building, one wants to use the same toolchain for building the code as for building the dependencies.
So it doesn't seem right to specify the toolchain in the triplet, which only applies to the dependencies.

So it doesn't seem right to specify the toolchain in the triplet, which only applies to the dependencies.

Then reuse the toolchain from the dependencies for your build? What is stopping you from doing that?

Except that the toolchain will typically contain environment dependent things (compiler paths, sdk locations, etc.), so we don't really want to commit it to VCS

Don't use absolute paths. Use find_(program|file) to control the toolchain via typically CMake means. Your toolchain really shouldn't have absolute installation paths.

So it doesn't seem right to specify the toolchain in the triplet, which only applies to the dependencies.

Then reuse the toolchain from the dependencies for your build? What is stopping you from doing that?

Nothing really, just that it doesn't feel right :-) Also I want to keep as close to standard CMake as possible even when using vcpkg. I.e. I would like the CMAKE_TOOLCHAIN_FILE to behave the same way as it does when not using vcpkg. (I already need to hack around the fact that vpckg appropriates this variable for itself, but I can do that...)

Except that the toolchain will typically contain environment dependent things (compiler paths, sdk locations, etc.), so we don't really want to commit it to VCS

Don't use absolute paths. Use find_(program|file) to control the toolchain via typically CMake means. Your toolchain really shouldn't have absolute installation paths.

Using find_program is nice when you have toolchains which are located in predictable places (e.g. installed from system packages). However, when the toolchain is installed by the developers into arbitrary folders, this doesn't work very well. Of course, I can work around by mandating a specific location where the toolchains will be looked for, but it does remove flexibility.

(I already need to hack around the fact that vpckg appropriates this variable for itself, but I can do that...)

include(vcpkg.cmake) in CMAKE_TOOLCHAIN_FILE is also possible instead of setting CMAKE_TOOLCHAIN_FILE  to vcpkg.cmake.

Yes, but then the toolchain (which specifies the compiler, not the dependency handler) is tied to vcpkg. However, as I said, this I can work-around. I.e. my CMakeLists.txt looks for vcpkg and sets CMAKE_TOOLCHAIN_FILE appropriately, before calling project.

However, when the toolchain is installed by the developers into arbitrary folders, this doesn't work very well.

Define an environment variable for the base installation path and look for that. Error if it is not set. (Or let people set CMAKE_PROGRAM_PATH as a requirement?)

Yes, this is probably the way to go. However, I wanted to get as close as possible to the following developer experience:

A developer, that doesn't have (doesn't want to have) any custom settings, just wants to compile the
project:

git clone repo
mkdir build
cd build
cmake ../repo

A developer, who has his own custom toolchain file which he wants to use:

git clone repo
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=/home/user/mytoolchain.cmake ../repo

Currently, I don't see a way to get there. In particular, there is no way around hardcoding the set of available toolchains by specifying them in the triplets.

authors: Neumann-A jonathanverner


text:
[fontconfig] Disable install data files

Do not install data on *inx to avoid installation issue.
Fixes #14864.

@BillyONeal  No, only zh_CN is set in the source code of fontconfig.

Sounds great, thanks!

authors: BillyONeal JackBoosY


text:
Fix freebsd vcpkg-tool compilation issue

Adds an xml entry to cmake 3.20.4 for freebsd 13

Can you please attach the failure log? Did cmake-3.21.1-linux-x86_64.tar.gz not work?

Can you please attach the failure log? Did cmake-3.21.1-linux-x86_64.tar.gz not work?

Well, originally, when running the vcpkg bootstrap.sh script on freebsd, I would get :
Building vcpkg-tool...
eval: /usr/home/build/sllang/vcpkg/downloads/tools/cmake-3.9.6-freebsd/python.exe: Permission denied

but I'm not sure I get your point; we sure could use the freebsd linux compatibility and then just download the linux cmake archive but I don't think that's fair for all of the peeps that do not want to install the linux compatibility packages.
This would most likely also have lots of version mismatching.

Merging since this is good and paraview was my fault.

authors: InfRandomness JackBoosY strega-nil-ms


text:
[vcpkg-cmake] Fix windows toolchain chainloading for uwp

What does your PR fix?
Due to a wrong variable name, the windows toolchain file was not chainloaded for uwp. Note the empty VCPKG_CHAINLOAD_TOOLCHAIN_FILE passed here:
[1/2] "D:/downloads/tools/cmake-3.21.1-windows/cmake-3.21.1-windows-i386/bin/cmake.exe" -S "D:/buildtrees/libjxl/src/v0.6.1-bf1b66f693.clean" -B "../../arm-uwp-dbg" "... "-DCMAKE_SYSTEM_NAME=WindowsStore" ... "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=" "-DVCPKG_TARGET_TRIPLET=arm-uwp" ...
Without the chainloading, the VCPKG_C_FLAGS etc. are not added to CMAKE_C_FLAGS etc. This is even detected during cmake configuration:
CMake Warning:
Manually-specified variables were not used by the project:
 ...
 VCPKG_CXX_FLAGS
 VCPKG_CXX_FLAGS_DEBUG
 VCPKG_CXX_FLAGS_RELEASE
 VCPKG_C_FLAGS
 VCPKG_C_FLAGS_DEBUG
 VCPKG_C_FLAGS_RELEASE

This hurts twice on uwp because it often needs extra definitions or flags to turn of warnings/errors.
Current case: #21846 build https://dev.azure.com/vcpkg/public/_build/results?buildId=64141&view=results
I couldn't resist switching to the common definitions for targets in order to deduplicate target detection.

Which triplets are supported/not supported? Have you updated the CI baseline?
all (fixing uwp), no

Does your PR follow the maintainer guide?
yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
yes

as a testament to how much uwp is used… unfortunately

The x64_windows_static_md error is subject of #21840, or eventually #21846 (which led into this PR).

CC @BillyONeal @ras0219-msft for accelerated review, if uwp matters.

Related: https://github.com/microsoft/vcpkg/issues/19818.

Related: #19818.

@JackBoosY I don't think #19818 is related to this PR. Maybe you meant to add the comment to #21507?

@dg0yt  For uwp, there are some problems when using vcpkg-cmake, as my comment.
But for this PR, it is more like a "cleaning" job.

@dg0yt For uwp, there are some problems when using vcpkg-cmake, as my comment. But for this PR, it is more like a "cleaning" job.

Not just cleaning: f02227e678a7c6e596f5c8b1831ad8ce6ebef83a fixes a serious port bug.

(I do separate commits to facilitate reviews. Please make use of it while reviewing.)

@dg0yt  For uwp, there are some problems when using vcpkg-cmake, as my comment.
But for this PR, it is more like a "cleaning" job.

https://github.com/microsoft/vcpkg/commit/f02227e678a7c6e596f5c8b1831ad8ce6ebef83a
if with cleaning you mean enable, yes...

@BillyONeal Another vcpkg ci exception again on agent vcpkg-eg-mac-02, https://dev.azure.com/vcpkg/public/_build/results?buildId=64286&view=logs&j=7b75bd19-17d3-53d4-00fd-23f1a49a8ba4&t=a23dba4e-3a62-59dc-a73c-a7222676d7a4.

@BillyONeal Even worse, the other builds are green despite the build failing for qtinterfaceframework. This even happened in yesterdays run. Failure logs are uploaded for all triplets.

qt* failures in baseline has been fixed by https://github.com/microsoft/vcpkg/pull/21925.

Please merge to master first.

Ideally we would use the right _CRT_SECURE_NO_WARNINGS defines rather than disabling 4996 (which disables all library-emitted diagnostics)

Ideally we would use the right _CRT_SECURE_NO_WARNINGS defines rather than disabling 4996 (which disables all library-emitted diagnostics)

Well, do you want me to trigger another world rebuild for this PR, or do we want to address that for netcdf-c and possibly other ports in another PR?
Note that the flag was present before.

Note that the flag was present before.

:sigh: I would really like to see it fixed given that lots of validation tools will reject binaries built with /wd4996, but given that it was there before and doesn't seem to be the true focus of your PR I suppose it's OK if that's not addressed in this particular PR.

LGTM.

Thanks for your help and clear explanations, @dg0yt!

authors: BillyONeal JackBoosY PhoebeHui cenit dg0yt


text:
[scripts|cmake] use ENV{VisualStudioVersion} to switch cmake generator

pass -T{VCPKG_PLATFORM_TOOLSET} for VS generators.

…ninja cannot be used

Would it be possible for you to supply a minimal triplet where this change is required?

Would it be possible for you to supply a minimal triplet where this change is required?

Every port which uses WINDOWS_USE_MSBUILD requires the VS generator. If you have only VS 2022 installed with v142 toolset and additionally have set(VCPKG_PLATFORM_TOOLSET v142) in the triplet vcpkg will select Visual Studio 16 2019 as the generator which will fail. The same for the ClangCl toolset where vcpkg simply does not know what to select.

I also need it for https://github.com/Neumann-A/my-vcpkg-triplets/blob/c6ad1a8b5153c6ae88c6c4b0a128c69b6c7beb81/x64-win-llvm.cmake#L15

Would it be possible for you to supply a minimal triplet where this change is required?

Every port which uses WINDOWS_USE_MSBUILD requires the VS generator. If you have only VS 2022 installed with v142 toolset and additionally have set(VCPKG_PLATFORM_TOOLSET v142) in the triplet vcpkg will select Visual Studio 16 2019 as the generator which will fail. The same for the ClangCl toolset where vcpkg simply does not know what to select.

Rather than adding another triplet setting, we prefer fixing the underlying issue which seems to be determining the generator based on the VS version instead of the toolset.

Rather than adding another triplet setting, could we fix the issue by determining the generator based on the VS version instead of the toolset?

Switching on ENV{VisualStudioVersion} ? Requires a complete mapping and doesn't cover the case where the environment is manually setup without using vcvars.

Depends on #26564 #26574 #26567.

@JackBoosY this PR doesnt depend on these port. These PRs are just necessary for a clean baseline. This PR can be merged without a clean baseline since the effects of this PR are validated by a single port using MSBuild with cmake instead of Ninja.

@Neumann-A We need to wait for all checks are green.

/azp run

This PR can be merged without a clean baseline since the effects of this PR are validated by a single port using MSBuild with cmake instead of Ninja.

I'd like to confirm that all ports that are affected by this change build cleanly (so, all ports using cmake/MSBuild). While I agree that this should work for all if it works for one, if possible I'd like to follow our standard procedure.

@ras0219-msft: Still blocked by unrelated baseline regression ....

@ras0219-msft: Still blocked by unrelated baseline regression ....

Seems https://github.com/microsoft/vcpkg/pull/26564 didn't fix this issue completely, will have investigation and fix later.

Yeah green.... finally ready to be merged...

authors: JackBoosY JavierMatosD Neumann-A ras0219-msft


text:
[libclocale] Initial Port

[x] Changes comply with the maintainer guide.
[x] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[x] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
[x] The versioning scheme in vcpkg.json matches what upstream says.
[x] The license declaration in vcpkg.json matches what upstream says.
[x] The installed as the "copyright" file matches what upstream says.
[x] The source code of the component installed comes from an authoritative source.
[x] The generated "usage text" is accurate. See adding-usage for context.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is in the new port's versions file.
[x] Only one version is added to each modified port's versions file.

Pinging @eyalgolan1337 for response. Is work still being done for this PR? There are conflicts error on CI pipeline as below.
Installing 9/9 libclocale:x86-windows@20240414...
Building libclocale:x86-windows@20240414...
-- Downloading https://github.com/libyal/libclocale/releases/download/20240414/libclocale-alpha-20240414.tar.gz -> libclocale-alpha-20240414.tar.gz...
-- Extracting source D:/downloads/libclocale-alpha-20240414.tar.gz
-- Using source at D:/b/libclocale/src/a-20240414-f70f96bd93.clean
-- Using cached libyal-vstools-f412b5f4347839c31a6f7ff2a631990f84d81b40.tar.gz.
-- Extracting source D:/downloads/libyal-vstools-f412b5f4347839c31a6f7ff2a631990f84d81b40.tar.gz
-- Using source at D:/b/libclocale/src/0f84d81b40-78707ee12a.clean
-- Found external ninja('1.11.0').
-- Getting CMake variables for x86-windows
-- Building vs2022/libclocale.sln for Release
-- Building vs2022/libclocale.sln for Debug
-- Installing: D:/p/libclocale_x86-windows/include/libclocale/definitions.h
-- Installing: D:/p/libclocale_x86-windows/include/libclocale/error.h
-- Installing: D:/p/libclocale_x86-windows/include/libclocale/extern.h
-- Installing: D:/p/libclocale_x86-windows/include/libclocale/features.h
-- Installing: D:/p/libclocale_x86-windows/include/libclocale/types.h
-- Installing: D:/p/libclocale_x86-windows/include/libclocale.h
-- Installing: D:/p/libclocale_x86-windows/share/unofficial-libclocale/unofficial-libclocale-config.cmake
-- Installing: D:/p/libclocale_x86-windows/share/libclocale/copyright
-- Performing post-build validation
error: The following files are already installed in D:/installed/x86-windows and are in conflict with libclocale:x86-windows
Installed by libcerror:x86-windows
debug/lib/libcerror.lib
    lib/libcerror.lib

You can get the more logs from https://dev.azure.com/vcpkg/public/_build/results?buildId=102483&view=logs&jobId=878666d5-db33-5b27-9e7d-b0c7ee352005&j=878666d5-db33-5b27-9e7d-b0c7ee352005&t=dc897974-8f7e-5107-e5db-0a01be8e9d4f, could you please resolve this error?

Closing this PR since it seems that no progress is being made. Please ping us to reopen if work is still being done.


text:
VMSS Extension Resources - Value must be one of the following...

Adding Azure Monitor to my Service Fabric VMSS deployment and getting the following error. It seems that neither of the required VM extensions is in the list of available options.
The entire deployment code is a copy-paste from official documentation/template:
https://docs.microsoft.com/en-us/azure/azure-monitor/insights/vminsights-enable-at-scale-powershell#download-templates
I have recently opened a similar ticket that was subsequently tagged with "ported to language server." Let me know if there is a better place to report these!

@denious This is definition the correct place to enter these bugs, thanks!
I'll let @neilpeterson verify if this is fixed in the current master branch.

Hmm, this one seems like it might be legitimately schema related. @deniuos I'm curious, if you add "settings": {} inside of the properties section (second red box), does the issue resolve?

Yes 👍

Thanks @denious, there is still an issue here however looks schema related. I will open an issue over in that repo and will tag this one in it to track.

authors: StephenWeatherford denious neilpeterson

repo: microsoft/vscode-azurearmtools


text:
Deployment not work

Repro steps:

Action: azureFunctions.deploy
Error type: BadRequest
Error Message: Encountered an error (InternalServerError) from host runtime.
Version: 0.19.1
OS: win32
Product: Visual Studio Code
Product Version: 1.39.2
Language: en

Call Stack
a.pipeline extension.bundle.js:218:2797976
s extension.bundle.js:218:111766
s extension.bundle.js:164:25792
extension.bundle.js:164:27034extension.bundle.js:164:27034
o extension.bundle.js:164:668851
extension.bundle.js:164:24705extension.bundle.js:164:24705
$.t.headersOnly.t.streamedResponse.t.body.function.t.body.pipe.a [as _callback] extension.bundle.js:1:637004
$.t._callback.t.callback.t.callback extension.bundle.js:194:5590
$.emit events.js:182:13
$.EventEmitter.emit domain.js:442:20
$.<anonymous> extension.bundle.js:194:18450
$.emit events.js:187:15
$.EventEmitter.emit domain.js:442:20
IncomingMessage.<anonymous> extension.bundle.js:194:17282
Object.onceWrapper events.js:273:13
IncomingMessage.emit events.js:187:15
IncomingMessage.EventEmitter.emit domain.js:442:20
endReadableNT _stream_readable.js:1092:12
process._tickCallback next_tick.js:63:19

@piyushkacha7 please add repro steps

repo: microsoft/vscode-azurefunctions


text:
stocksChanged

Does this occur consistently?
Repro steps:

Action: azureFunctions.createFunction
Error type: Error
Error Message: Unable to write into workspace settings. Please open the workspace settings to correct errors/warnings in the file and try again.
Version: 0.24.0
OS: win32
OS Release: 10.0.18362
Product: Visual Studio Code
Product Version: 1.48.2
Language: en

Call Stack
D.reject workbench.desktop.main.js:5545:245
file:/workbench.desktop.main.js:5549:267
async D.doWriteConfiguration workbench.desktop.main.js:5542:403

@AlexSouzaSantos please add repro steps

Thank you very much Erich for the help me.

authors: AlexSouzaSantos EricJizbaMSFT


text:
Debugging not hitting breakpoint

Brief Issue Summary
I am just getting into C++ development and I am starting to learn about CMake. I am following Vscode Documentation CMake on linux and I was able to follow through, even though im on windows, and when I reach the debug point I set the breakpoint and run Cmake: Debug but the problem is that it opens up the file again in a weird way and doesnt hit the breakpoint yet the step through functions still work
This is the path of the file that gets open when debug is running. Going into the build folder then to the C drive back to the file

This is what it says about the file even though it does exist but the path is weird

CMake Tools Diagnostics
{
  "os": "win32",
  "vscodeVersion": "1.71.2",
  "cmtVersion": "1.12.27",
  "configurations": [
    {
      "folder": "c:\\Users\\Riprock\\Documents\\test",
      "cmakeVersion": "3.24.2",
      "configured": true,
      "generator": "Ninja",
      "usesPresets": false,
      "compilers": {
        "C": "C:/msys64/mingw64/bin/gcc.exe",
        "CXX": "C:/msys64/mingw64/bin/g++.exe"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "Debug",
    "buildTypesSeen": [
      "Debug"
    ],
    "requests": [
      "file:///c%3A/Users/Riprock/Documents/test/main.cpp"
    ],
    "responses": [
      {
        "uri": "file:///c%3A/Users/Riprock/Documents/test/main.cpp",
        "configuration": {
          "includePath": [],
          "defines": [],
          "compilerPath": "c:/msys64/mingw64/bin/g++.exe",
          "compilerArgs": [],
          "compilerFragments": [
            "-g"
          ]
        }
      }
    ],
    "partialMatches": [],
    "targetCount": 29,
    "executablesCount": 1,
    "librariesCount": 0,
    "targets": []
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": true
    }
  ]
}

Debug Log
No response
Additional Information
What im finding weird is the path is build/C/Users/Riprock/Documents/test/main.cpp
Its appending the full path to the end of the build directory

It sounds like something is wrong with the source mapping.  @WardenGnaw, is there something we can check to see what's going on here?

Is it possible to share the generated launch.json and the engine logs?

There is no launch.json as I am doing ctrl + Shift + P and typing CMake: Debug as described here Debug with Cmake. I can attempt to generate one.
I think that these are the logs that your looking for. If you need other information or if I got the wrong logs, please direct me to what I need to provide
variant] Loaded new set of variants
[kit] Successfully loaded 1 kits from C:\Users\Riprock\AppData\Local\CMakeTools\cmake-tools-kits.json
[proc] Executing command: C:\msys64\mingw64\bin\gcc.exe -v
[main] Configuring folder: test
[proc] Executing command: C:\msys64\mingw64\bin\cmake.EXE --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=C:\msys64\mingw64\bin\gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=C:\msys64\mingw64\bin\g++.exe -Sc:/Users/Riprock/Documents/test -Bc:/Users/Riprock/Documents/test/build -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: C:/Users/Riprock/Documents/test/build
[main] Building folder: test hello
[build] Starting build
[proc] Executing command: C:\msys64\mingw64\bin\cmake.EXE --build c:/Users/Riprock/Documents/test/build --config Debug --target hello --
[build] ninja: no work to do.
[build] Build finished with exit code 0
[proc] Executing command: C:\msys64\mingw64\bin\gdb.exe --version
[proc] The command: C:\msys64\mingw64\bin\gdb.exe --version exited with code: 1 and signal: null
[proc] Executing command: gdb --version
[main] Building folder: test hello
[build] Starting build
[proc] Executing command: C:\msys64\mingw64\bin\cmake.EXE --build c:/Users/Riprock/Documents/test/build --config Debug --target hello --
[build] ninja: no work to do.
[build] Build finished with exit code 0
[proc] Executing command: C:\msys64\mingw64\bin\gdb.exe --version
[proc] The command: C:\msys64\mingw64\bin\gdb.exe --version exited with code: 1 and signal: null
[proc] Executing command: gdb --version

The extension will log out the generated task if you set cmake.loggingLevel to Debug.  Look for "Starting debugger with following configuration" in the output window.
You can enable the debugger trace logging by adding the following setting:
"cmake.debugConfig": {
  "logging": {
    "engineLogging": true,
    "trace": true
  }
}

So Update, I set that value and ran these commands in MINGW64 and now Its running as expected
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
pacman -Syu

authors: Riprock WardenGnaw bobbrow

repo: microsoft/vscode-cmake-tools


text:
Convert issue form to yaml

The following changes are proposed:

Converts the issue form to yaml.
Improve issue reporting tool.

Please provide feedback on any changes to this form, such as wording of descriptions/titles, or any changes to any of the fields.

Can you also delete docs/issue_template.md?

Would you like the pull request template converted to yaml too?

I'm not sure how much we need the pull request template.  The thing I want most from it is the linked bug number.  I think everyone just deletes the rest.

authors: bobbrow michelleangela


text:
Unable to start debugging. No process is associated with this object when starts debugging

Type: Bug Report
OS and Version: Mac os 12.5.1
VS Code Version: 1.71
Embedded Tools Extension Version:v0.3.220909001
Target embedded device: Nucleo F446RE
Description:
When I launch program, I get this error. Next I get information: "ERROR: Unable to start debugging. No process is associated with this object." I'm so confused, because I can open arm-none-eabi-gdb file.

I don't think we've been able to replicate this yet. In discussions we suspect it is a signing issue. See section 5.1 of ST's STM32CubeIDE installation manual. The guide walks you through trusting the STM32CubeIDE.app either via macOS system preferences or the command line. Looking at the error message I would hope that is enough as gdb is within that path. This is the cli command from the docs.
xattr -c /Applications/STM32CubeIDE.app

@robotdad thanks for your reply. I executed this command and now everything works correctly. But when I start debugging without plugged in stm microcontroller I get the same information as above. Please change it to be correct when board is not connected to pc.

repo: microsoft/vscode-embedded-tools


text:
How to eslint javascript in html file for undefined variables without project?

Hi!
I installed vscode eslint addon. I want to eslint html file for undefined variables without having to create a project for this html file.
I added these lines to User\settings.json
    "eslint.validate": ["javascript", "javascriptreact", "html"],
    "extends":"eslint:recommended"

But it doesnt seem to care about unused variables. What should I do?

@rain1 does validation happen correctly in the terminal?

How do I test it in terminal?

Open a terminal on the workspace and type ./node_modules/.bin/eslint {file to validate}

Can I tell it to use VS Code configuration? Looks like command line does not see that I have already configured it on VS Code:

ESLint couldn't find a configuration file. To set up a configuration file for this project, please run:

eslint --init

The eslint command has a --config option to point it to an eslint config file.

My VSCode config file C:\Users\Rain\AppData\Roaming\Code\User\settings.json is this:
{
    "workbench.colorTheme": "Visual Studio Light",
    "terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
    "window.title": "${dirty}${activeEditorLong}${separator}${rootName}${separator}${appName}",
    "workbench.settings.editor": "json",
    "eslint.validate": ["javascript", "javascriptreact", "html"],
    "extends":"eslint:recommended"
}

This is what file > Preferences > Settings edits. Is this correct configuration file given that I wish to use eslint without project? I mean I want to open any html file anywhere in the disk and have it eslinted by VSCode.
I am asking this because after running:
eslint C:\extracted\snip\City\test.html --config C:\Users\Rain\AppData\Roaming\Code\User\settings.json
It complained:

Oops! Something went wrong! :(
ESLint: 7.27.0
Error: ESLint configuration in --config is invalid:
- Unexpected top-level property "workbench.colorTheme".
at ConfigValidator.validateConfigSchema (C:\extracted\node\node_modules\eslint\node_modules\@eslint\eslintrc\lib\shared\config-validator.js:273:19)
at ConfigArrayFactory._normalizeConfigData (C:\extracted\node\node_modules\eslint\node_modules\@eslint\eslintrc\lib\config-array-factory.js:644:19)
at ConfigArrayFactory._loadConfigData (C:\extracted\node\node_modules\eslint\node_modules\@eslint\eslintrc\lib\config-array-factory.js:609:21)
at ConfigArrayFactory.loadFile (C:\extracted\node\node_modules\eslint\node_modules\@eslint\eslintrc\lib\config-array-factory.js:475:40)
at createCLIConfigArray (C:\extracted\node\node_modules\eslint\node_modules\@eslint\eslintrc\lib\cascading-config-array-factory.js:171:35)
at new CascadingConfigArrayFactory (C:\extracted\node\node_modules\eslint\node_modules\@eslint\eslintrc\lib\cascading-config-array-factory.js:243:29)
at new CLIEngine (C:\extracted\node\node_modules\eslint\lib\cli-engine\cli-engine.js:563:36)
at new ESLint (C:\extracted\node\node_modules\eslint\lib\eslint\eslint.js:432:27)
at Object.execute (C:\extracted\node\node_modules\eslint\lib\cli.js:290:24)
at main (C:\extracted\node\node_modules\eslint\bin\eslint.js:132:52)

From that I read that it does not like to be in same configuration file with rest of VSCode options. From readme in this reposotory I did not find any better ideas. how to configure it  to run without having to create project.

@rain1 you need to point it to your .eslintrc.json file. See https://eslint.org/docs/user-guide/configuring/configuration-files

After doing some research it looks like it's not possible to get eslint to work  with html files.
Should I make feature request for plugin developers to make it so that vscode-eslint would auto-configure  eslint? I mean instead of every developer doing 2 months of research on their own to get eslint work with html files out of the box it would be better solution in my opinion of this plugin worked out of box.

For me setting up ESLint with HTML files was always easy  using this plugin. Can you explain why you think this is not enough: https://github.com/BenoitZugmeyer/eslint-plugin-html

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

repo: microsoft/vscode-eslint


text:
lsp-embedded-request-forwarding: Help wanted to generate syntax errors from embedded language

I embedded JavaScript in another language by using the "Request Forwarding" approach. It worked well for code completion. Now I want also to get the syntax errors from the embedded JavaScript, but I don't have clue how to get in there.
I did see a relevant sentence in the documentation of VSCode:
https://code.visualstudio.com/api/language-extensions/embedded-languages#conclusion
I assume the + sign should have been a - sign, since it says the "Request forwarding" DOES NOT work with diagnostics errors. I could also interpret that the + sign is correct, but the NOT shouldn't have been there. Did I understand correctly?
I tried the build-in HTML language server in VSCode, and I was able to see the syntax errors from the embedded JavaScript. However, it may be using a different approach.
My question: if diagnostics errors from embedded language server would be possible, how to do that and what VSCode extension APIs should be used to retrieve the errors and bring these errors to the containing language?
Any help is much appreciated! Thanks.

Assigning to @aeschli
One tip: LSP in 3.17 will provide a diagnostic pull model that will make this easier.

I fixed the doc.
The HTML language server does not forward, but embeds the TypeScript language service.
Once LSP 3.17 is shipped, we need an equivalent vscode diagnostics provider APIs and we need to update our language extensions (in particular css and TypeScript) to adopt it.

authors: aeschli dbaeumer tjroamer

repo: microsoft/vscode-extension-samples


text:
Gradle version

When vscode starts up, the project manager for java begins to build my multi-project repo in gradle. Starting several days ago, the builds were failing with a message:
"message": "Could not run phased build action using connection to Gradle distribution 'https://services.gradle.org/distributions/gradle-7.0-rc-1-bin.zip'.\r\n

...
Could not find method compile() for arguments
It seems this is occuring because compile is fully deprecated with gradle 7.
The thing is, I have gradle 6.4.1 installed but for some reason, the automated project manager build is kicking off with v7 and there are now 7k+ problems due to this.
Is this something that the extension is forcing? Any ideas

The project manager won't build/import your project, it's actually https://github.com/redhat-developer/vscode-java doing this.
But anyway, could you tell us which Gradle version is the one you want to enable in this project? If you want to force to 6.4.1, try to use this setting in your workspace: java.import.gradle.user.home

authors: TroyLDay jdneo

repo: microsoft/vscode-java-dependency


text:
Cannot render Matplotlib in VSCode with %matplotlib inline

Applies To

[x] Notebooks (.ipynb files)
[ ] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?
I suddenly have trouble rendering plots in Jupyter Notebook ouput in VSCode, even with %matplotlib inline. It only shows e.g. <Figure size 640x480 with 1 Axes>
I came across this issue and updated the ipympl package, but the problem still persists.
Thanks for helping!
VS Code Version
1.75.1
Jupyter Extension Version
v2023.1.2010391206
Jupyter logs
<Figure size 640x480 with 1 Axes>

Coding Language and Runtime Version
Python 3.10.8
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
Local

Thanks for filing this issue and sorry you are running into this issue.
Its possible you have version 8 of the ipywidgets package installed.
This has been fixed in the latest pre-release version

Please install latest VS Code Insiders
Open the extensions page, search for Jupyter and click the button Switch to Pre-Release Version
Similarly please install the latest Pre-Release version of the Python extension

If that does not work, please could you enable logging as follows:

Open settings & go into Jupyter->Logging
Change the value to verbose
Reload VS Code,
Attempt to repro the issue & then copy the output from the Jupyter output panel.

Thank you very much, that did it for me!

repo: microsoft/vscode-jupyter


text:
Feature Usability and Discoverability in vscode/Jupyter Notebooks: Menu Items

Environment data
Version: 1.56.0-insider (user setup)
Commit: b4816cfd1f4161a3bb272354d181a9947760ee26
Date: 2021-04-20T07:23:51.425Z
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: 8.9.255.24-electron.0
OS: Windows_NT x64 10.0.19042
Expected behaviour
A consistent menu navigation in classic Jupiter notebooks to notebooks in vscode, or an option to use a classic jupyter navigation menu.
Actual behaviour
The Jupyter nav menu is hard to find and the icons are not ubiquitous making it difficult to know what the menu item is without hovering over it.  This obfuscates the additional and useful tooling that running notebooks in vs code provides. It can cause users to go back to classic notebooks because their natural dev flow is fragmented.  The tooling in the vscode notebooks is amazing but it will not fully get adopted from the community if you have to drastically change your dev flow to use it.
Current vscode menu:

Current jupyter classic menu:

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

@cassieview  Thanks much for the feedback here. Currently the new notebook UI (toolbar locations in particular) is controlled by the core VS Code team and not specifically by the Jupyter extension. I think that we might need to move this issue or open up a new issue in vscode to discuss this. @claudiaregio how would you like to handle discussing this feedback with VS Code?

This is being tracked in vscode: https://github.com/microsoft/vscode/issues/121766

I think we can close this one since its being tracked in vscode. Thanks! :)

authors: IanMatthewHuff cassieview greazer


text:
Dbaeumer/workspace pull3

thank U Fix Pleas and put on

Closing PR. Assuming this was a mistake.

authors: ReenaSuoliman dbaeumer

repo: microsoft/vscode-languageserver-node

license: mit

license_source: bigquery


text:
Can't install release version of 'ms-python.isort' extension because it has no release version.

Issue Type: Bug

Behaviour
Expected vs. Actual
Can't install release version of 'ms-python.isort' extension because it has no release version.
Steps to reproduce:
Try to install the isort extension in the latest version of vscode.

Diagnostic data

Python version (& distribution if applicable, e.g. Anaconda): 3.9.7
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
Value of the python.languageServer setting: Pylance

User Settings

defaultLS: {"defaultLSType":"Pylance"}

envFile: "<placeholder>"

venvPath: "<placeholder>"

venvFolders: "<placeholder>"

condaPath: "<placeholder>"

pipenvPath: "<placeholder>"

poetryPath: "<placeholder>"

languageServer: "Pylance"

linting
• enabled: true
• cwd: "<placeholder>"
• Flake8Args: "<placeholder>"
• flake8Enabled: true
• flake8Path: "<placeholder>"
• lintOnSave: true
• banditArgs: "<placeholder>"
• banditEnabled: false
• banditPath: "<placeholder>"
• mypyArgs: "<placeholder>"
• mypyEnabled: false
• mypyPath: "<placeholder>"
• pycodestyleArgs: "<placeholder>"
• pycodestyleEnabled: false
• pycodestylePath: "<placeholder>"
• prospectorArgs: "<placeholder>"
• prospectorEnabled: false
• prospectorPath: "<placeholder>"
• pydocstyleArgs: "<placeholder>"
• pydocstyleEnabled: false
• pydocstylePath: "<placeholder>"
• pylamaArgs: "<placeholder>"
• pylamaEnabled: false
• pylamaPath: "<placeholder>"
• pylintArgs: "<placeholder>"
• pylintPath: "<placeholder>"

sortImports
• args: "<placeholder>"
• path: "<placeholder>"

formatting
• autopep8Args: "<placeholder>"
• autopep8Path: "<placeholder>"
• provider: "autopep8"
• blackArgs: "<placeholder>"
• blackPath: "<placeholder>"
• yapfArgs: "<placeholder>"
• yapfPath: "<placeholder>"

testing
• cwd: "<placeholder>"
• debugPort: 3000
• nosetestArgs: "<placeholder>"
• nosetestsEnabled: undefined
• nosetestPath: "<placeholder>"
• promptToConfigure: true
• pytestArgs: "<placeholder>"
• pytestEnabled: true
• pytestPath: "<placeholder>"
• unittestArgs: "<placeholder>"
• unittestEnabled: false
• autoTestDiscoverOnSaveEnabled: true

terminal
• activateEnvironment: true
• executeInFileDir: "<placeholder>"
• launchArgs: "<placeholder>"

experiments
• enabled: true
• optInto: []
• optOutFrom: []

tensorBoard
• logDirectory: "<placeholder>"

Extension version: 2022.7.11301007
VS Code version: Code 1.67.0 (57fd6d0195bb9b9d1b49f6da5db789060795de47, 2022-05-04T12:14:47.100Z)
OS version: Darwin x64 21.4.0
Restricted Mode: No

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebugcf:30475217
vsclangdc:30486549

@tekumara Please click on the dropdown next to the install button and select pre-release. We are still getting feed back on these extensions so there is no release version yet.

authors: karthiknadig tekumara

repo: microsoft/vscode-python


text:
Syntax Highlighting Error

Type: Bug
When I wrote a HTML text in VS Code with Python extension,
I found this line:
# Python 3

has some problems in highlighting syntax.
It expects red because it is in a read-only string.
But, in fact, it is green.
That means the extension thinks it is notes.
I am using Python 3.11.2 (64-bits)
This my code:
_html = r"""
        <!DOCTYPE html>

            <meta charset="utf-8">

                    # Python 3

"""

You should copy it into VS Code to see its effect.
Extension version: 2023.7.10901017
VS Code version: Code 1.77.0 (7f329fe6c66b0f86ae1574c2911b681ad5a45d63, 2023-03-29T10:02:16.981Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: Yes

System Info

Item
Value

CPUs
12th Gen Intel(R) Core(TM) i5-12400F (12 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
15.79GB (3.91GB free)

Process Argv
--crash-reporter-id fc004f5b-7ef2-45d0-a18a-09e9d61149a2

Screen Reader
no

VM
50%

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vstes627:30244334
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
vscccc:30610679
nodejswelcome1cf:30587006
2e4cg342:30602488
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
vsctsb:30677850
functionswalk:30687959
pythonms35:30701012

@Wang-Yile Can you provide a screen shot of the issue?

authors: Wang-Yile karthiknadig