Windows Terminal Preview
A preview of the end of Windows???
The Windows Terminal gang has got back into its preview groove with an update for the open-source command-line front-end. Version 1.1 now allows fans to launch the app in the context of a selected folder with a right click from File Explorer as well as having it open at startup (unless disabled by organisation policy). The …
You can add a program to that menu. It's a little tricky, and usually the program will add the shortcuts for you, but if you enable it to launch a program with the selected folder or file name, it can do that. It looks like the shell included with Git for Windows will open in a directory if it's provided, so I'm guessing Cygwin will too.
Aha! That is in fact what I was griping about. Both procexp and the Start Menu shortcut had shown me a WindowsTerminal.exe; had I dug deeper into the image properties in procexp I would've seen the wt.exe symlink (meaning I can remove the one I created myself, which is embarrassingly enough called wt.exe). Have a beer or other beverage of your choosing.
This is one of the reasons I just don't get this obsession over the last few years to adopt JSON everywhere for config files. Microsoft is at it in .net too.
Technically comments aren't in the spec, and config files without comments is absurd.
There was nothing wrong with XML. This whole JSON thing is just because it's fashionable.
They're using JSONC aka "JSON with comments" - which is basically a non-specification that is entirely dependent on the implementation as to what features it supports. In VS Code the functionality is provided by MS's own library https://github.com/Microsoft/node-jsonc-parser while in Terminal it's provided by the library https://github.com/open-source-parsers/jsoncpp ... The fact that both tools support comments and trailing commas means that - in theory, if the Terminal config file has a ".jsonc" extension - VS Code should have no problem editing it with correct syntax/error highlighting. But that's more of a coincidence that both tools implemented the same extensions to JSON, none of which are standardized or even part of any formal specification. It's a shame they didn't just go with https://json5.org from the get-go, which would have probably saved them a bunch of effort, alone just in terms of amount of discussion needed.
I seem to remember the very early JSON spec did support comments, but then various ne'er-do-wells decided that comments were an excellent place to encode unofficial parser extensions, breaking compatibility between implementations. So Douglas Crockford felt forced to remove them entirely. This is why we can't have nice things...