Software-update: Visual Studio Code 1.62.0

Visual Studio Code is een opensourcecode-editor met ondersteuning voor IntelliSense, debugging, Git en code snippets. Downloads zijn beschikbaar voor Windows, Linux en macOS. Ondersteuning voor de gangbare script- en programmeertalen is aanwezig en het kan daarnaast via extensies uitgebreid worden. Microsoft heeft versie 1.62.0 uitgebracht en uitgebreide informatie over die uitgave is op deze pagina te vinden; dit is de aankondiging:

October 2021 (version 1.62)

Welcome to the October 2021 release of Visual Studio Code. In addition to releasing a preview of vscode.dev, we announced in the October iteration plan that we would focus on housekeeping GitHub issues and pull requests (see our issue cleanup guide). Across all of our VS Code repositories, we closed (either triaged or fixed) 4163 issues. While we closed issues, you created 2222 new issues. The main vscode repository now has 2491 open feature requests and 1246 open bugs. In addition, we closed 194 pull requests.

Versienummer	1.62.0
Releasestatus	Final
Besturingssystemen	Linux, macOS, Windows 8, Windows 10, Windows 11
Website	Microsoft
Download	https://code.visualstudio.com/#alt-downloads
Licentietype	GPL

Reacties (8)

[thomas_24_7]

Ze hebben nu wel een beetje een flauwe manier van issues afhandelen op GitHub: overal een voting op gooien, krijgt je issue niet genoeg stemmen? Jammer dan, issue closed. En zo worden niet alleen feature requests geloosd, maar ook valide bugs/gebreken...

Dat je veel issues te verwerken krijgt lijkt mij geen reden om te doen alsof de bugs niet bestaan, dan moet je ze handiger of beter prioriteren/indelen.

Mocht iemand met GitHub account nog een stemmetje over hebben, het zou fijn zijn als ze deze zouden oppakken: https://github.com/microsoft/vscode/issues/116495 4/20 upvotes behaald en nog 8dagen te gaan.

[Reactie gewijzigd door thomas_24_7 op 24 juli 2024 08:19]

[rbr320]

Wat ik hier vreemd aan vind is dat het issue gelabeld is als een feature request, terwijl het duidelijk een bug is of in ieder geval een inconsistente manier van omgaan met omgevingsvariabelen. Ik zou dus aankaarten dat het issue verkeerd is gelabeld.

Ik ben geen VS code gebruiker maar zal toch even stemmen.

[smesjz]

Het kan nog steeds by design zijn, dus vandaar misschien feature request.

Wat ik raar vind is dat er geen user story bij staat. Bijv: ik als ontwikkelaar wil een environment variable gebruiken voor git path want ……

Anders krijg je straks feature requests in je backlog voor allerlei uitzonderingen.

[TheVivaldi]

Het kan nog steeds by design zijn, dus vandaar misschien feature request.

Dat zou kunnen, maar dan kunnen ze dat toch even melden? Kost een paar seconden om dat te typen (kan evt. zelfs geautomatiseerd worden).

[youri_ajax]

Dat is wel een rare manier van je backlog opbouwen haha.

Mijn vote heb je!

[beerse]

Niet om het een of ander, maar als ik het goed zie wil je in het voorbeeld dus de vscode variabele "git.path" vullen met de environment variabele 'GDIR' aka in batch-scripts %GDIR% en in powershell ${env:GDIR}. Hier wordt duidelijk de powershell repesentatie gebruikt.

Nu weet ik dat powershell case-aware is en niet case-sensitive. Maar probeer eens ${ENV:GDIR} en ${Env:GDIR}. Dat is wat ik namelijk in de meeste documentatie (van microsoft) zie.

Verder zie ik dat de rest van het path 'escaped' is: De backslash in de directory is steeds dubbel uitgevoerd. Moet er dan bij het gebruik van de environment variabele ook niet iets worden 'escaped'?
Een ruige gok zou zijn: "\${env:GDIR}\\.apps\\cmer....." of zo iets? Zodat de environment variabele bij de tweede slag wordt verwerkt en niet bij de eerste slag.

Daarnaast zou je kunnen beginnen door alleen een environment variabele te gebruiken, door jou git.path in je environment te maken. "${env:GPATH}".

Misschien is het gebruik van environment variabelen wel helemaal niet mogelijk en zien ze dit nu als de aanvraag om het in te voeren. Dat wordt dan een aardige kluif.

DrGoogle points me to https://git-scm.com/book/...als-Environment-Variables, where I read there are more ways to use environment variables.
Or even https://support.cloudbees...PATH-in-Git-Configuration

[Reactie gewijzigd door beerse op 24 juli 2024 08:19]

[thomas_24_7]

Dank (ook aan de anderen) voor je vote en dat je de tijd neemt om er op GitHub op te reageren.

Het issue is niet door mij gestart, maar ik probeer net als diegene een environment variabele te gebruiken om mijn (portable) GIT directory aan te duiden. Dat dit volgens mij zou moeten werken baseer ik op deze documentatie van VSCode. Daarnaast heb ik in mijn settings.json ook environment variables gebruikt om andere paden aan te duiden welke wél werken, bijvoorbeeld:

"terminal.integrated.env.windows": {
"PYTHONUSERBASE": "${env:PORTABLE_APPS}\\python\\user-home\\${env:USERNAME}",
}

Het probleem zit hem dus niet persé in de parsing van settings.json (anders zou geen enkele env var moeten werken), maar wat er ergens verderop (in een submodule/extension) mee gebeurt.

Interessante constatering van @rbr320 dat dit issue inderdaad gelabeld is als feature request i.p.v. bug...

[LordPan]

Ik was de 20ste in rij. Dus zou moeten opgenomen worden.

Wel spijtig dat het zo in een populariteits wedstrijd vervalt, ipv the voice van Vlaanderen of Nederland: "The bug van VSCode", wie is de afvaller deze week...