windows: Kommentare in PowerShell-Skripten auf das Mindestmass reduziert

1 files changed, 13 insertions, 62 deletions

diff --git a/bootstrap-win/neovim.ps1 b/bootstrap-win/neovim.ps1
index 77abf83..32e2db7 100644
--- a/bootstrap-win/neovim.ps1
+++ b/bootstrap-win/neovim.ps1
@@ -1,29 +1,14 @@
 #Requires -Version 5.1
 <#
-  Windows-natives Pendant zu bootstrap/neovim.sh (macOS/FreeBSD).
-  bootstrap/neovim.sh bleibt unveraendert - dieses Skript ist bewusst
-  eigenstaendig, da sich die Paketquellen (winget/npm statt brew/pkg) und
-  das Fehlerverhalten zu stark unterscheiden fuer ein gemeinsames Skript.
+  Windows-natives Pendant zu bootstrap/neovim.sh - nutzt winget/npm statt
+  brew/pkg, daher eigenstaendiges Skript ohne Git-Bash-/WSL-Abhaengigkeit.
 
-  Nutzt ausschliesslich native Windows-Werkzeuge (winget, npm, pwsh/
-  powershell.exe) - keine Git-Bash- oder WSL-Abhaengigkeit.
-
-  Aufruf (PowerShell, keine Admin-Rechte noetig):
+  Aufruf (keine Admin-Rechte noetig):
     .\bootstrap-win\neovim.ps1
 
-  Hinweis: yamlfmt, gawk und xmllint/libxml2 sind bewusst NICHT enthalten -
-  im Praxistest (24.07.2026) bestaetigt, dass es dafuer keine winget-Pakete
-  unter den urspruenglich vermuteten IDs gibt. Siehe Install-Formatters und
-  neovim-windows-setup.md fuer manuelle Alternativen. mvdan.shfmt und
-  astral-sh.ruff liefen im Test erfolgreich durch.
-
-  Schlaegt eine winget-Installation trotzdem fehl, meldet das Skript das
-  als Warnung (bricht nicht ab) und zeigt die letzten Zeilen der winget-
-  Ausgabe zur Fehlersuche an.
-
-  C-Compiler fuer nvim-treesitter: kein winget-Paket enthalten, da MSVC auf
-  den Zielsystemen bereits vorhanden ist. Neovim muss dafuer aus einer
-  "Developer PowerShell for VS" gestartet werden (siehe Install-Tools).
+  yamlfmt, gawk und xmllint sind bewusst nicht enthalten (siehe
+  neovim-windows-setup.md). Fehlgeschlagene Installationen werden als
+  Warnung gemeldet, das Skript bricht nicht ab.
 #>
 
 $ErrorActionPreference = "Stop"
@@ -51,10 +36,8 @@ function Test-CommandExists([string]$Name) {
 }
 
 function Find-BinaryDirectory([string]$Binary) {
-  # Sucht nach "<Binary>.exe" unter den ueblichen Installationswurzeln.
-  # Deckt den Fall ab, dass ein winget-Paket (v.a. im --silent-Modus)
-  # die PATH-Registrierung ausgelassen hat, obwohl es korrekt installiert
-  # wurde - beobachtet bei LLVM.LLVM/clangd.
+  # Deckt den Fall ab, dass winget (v.a. --silent) korrekt installiert,
+  # aber die PATH-Registrierung ausgelassen hat (beobachtet bei LLVM.LLVM).
   $searchRoots = @(
     $env:ProgramFiles,
     ${env:ProgramFiles(x86)},
@@ -98,12 +81,7 @@ function Install-WingetPackage([string]$Binary, [string]$Id) {
     $lastLine = ($output | Select-Object -Last 3) -join " / "
 
     if ($text -match "bereits ein vorhandenes Paket|already installed|No applicable update") {
-      # Paket ist laut winget installiert, aber die Binary steht trotzdem
-      # nicht im PATH - z.B. weil der Installer (im --silent-Modus) die
-      # PATH-Registrierung uebersprungen hat. winget search hilft hier
-      # nicht weiter, da das Paket ja gefunden wurde - stattdessen selbst
-      # danach suchen und den User-PATH ergaenzen (dauerhaft + fuer diese
-      # Sitzung).
+      # Installiert, aber nicht im PATH - Binary suchen und PATH ergaenzen.
       $dir = Find-BinaryDirectory $Binary
 
       if ($dir) {
@@ -155,11 +133,7 @@ function Test-Prerequisites {
 }
 
 function Update-SessionPath {
-  # winget/npm-Installer tragen PATH-Aenderungen in die Registry (User-
-  # und/oder Machine-Scope) ein, aber der laufende PowerShell-Prozess
-  # bekommt das nicht automatisch mit. Ohne diesen Refresh wuerde z.B.
-  # "npm" gleich im Anschluss an die Node-Installation als "nicht
-  # gefunden" gemeldet, obwohl es gerade erst installiert wurde.
+  # Registry-PATH-Aenderungen durch winget/npm wirken erst nach diesem Refresh.
   $machine = [Environment]::GetEnvironmentVariable("PATH", "Machine")
   $user = [Environment]::GetEnvironmentVariable("PATH", "User")
   $env:PATH = "$machine;$user"
@@ -178,14 +152,7 @@ function Install-Formatters {
   Install-WingetPackage -Binary "shfmt" -Id "mvdan.shfmt"
   Install-WingetPackage -Binary "stylua" -Id "JohnnyMorganz.StyLua"
 
-  # yamlfmt, gawk, xmllint: im Praxistest bestaetigt, dass es unter diesen
-  # IDs kein winget-Paket gibt ("Es wurde kein Paket gefunden, das den
-  # Eingabekriterien entspricht"). Kein verifizierter Ersatz gefunden,
-  # deshalb bewusst nicht automatisiert - siehe neovim-windows-setup.md
-  # fuer manuelle Alternativen. conform.nvim faellt bei fehlendem
-  # Formatter fuer die jeweilige Dateiart einfach auf LSP-Formatierung
-  # zurueck (default_format_opts.lsp_format = "fallback"), betrifft also
-  # nur awk/xml/xsd/yaml-Dateien.
+  # yamlfmt, gawk, xmllint: kein winget-Paket gefunden, siehe neovim-windows-setup.md.
 }
 
 function Install-Tools {
@@ -193,24 +160,8 @@ function Install-Tools {
   Install-WingetPackage -Binary "fd" -Id "sharkdp.fd"
   Install-NpmPackage -Binary "tree-sitter" -Package "tree-sitter-cli"
 
-  # C-Compiler fuer nvim-treesitter: kein winget-Paket noetig, MSVC (cl.exe)
-  # ist auf diesen Systemen bereits vorhanden. nvim-treesitter findet cl.exe
-  # automatisch, ABER nur wenn INCLUDE/LIB gesetzt sind - das passiert nicht
-  # in einer normalen PowerShell, sondern nur in einer "Developer PowerShell
-  # for VS" bzw. "x64 Native Tools Command Prompt". Neovim also immer aus
-  # so einer Shell heraus starten, sonst schlaegt die Parser-Kompilierung
-  # mit "cannot find <header>.h" o.ae. fehl, obwohl cl.exe selbst gefunden wird.
-
-  # opt.makeprg = "gmake" (nvim/lua/config/options.lua) - Alias liegt in
-  # windows/bin/gmake.cmd, reicht an "make" durch. Einmalig windows\bin
-  # zum PATH hinzufuegen (PowerShell, User-Scope, nicht setx mit %PATH%
-  # verwenden - das wuerde den gesamten Prozess-PATH inkl. System-Anteil
-  # dauerhaft in den User-PATH kopieren):
-  #   $userPath = [Environment]::GetEnvironmentVariable("PATH", "User")
-  #   [Environment]::SetEnvironmentVariable("PATH", "$userPath;$env:USERPROFILE\dotfiles\windows\bin", "User")
-  # GnuWin32.Make ist im Praxistest fehlgeschlagen (Paket 2006er-Stand,
-  # unklar ob im winget-Repo ueberhaupt noch gepflegt). ezwinports.make
-  # ist ein aktiver gepflegter GNU-Make-Port fuer Windows.
+  # MSVC (cl.exe) ist bereits vorhanden, kein winget-Paket noetig - Neovim
+  # dafuer aber aus einer "Developer PowerShell for VS" starten.
   Install-WingetPackage -Binary "make" -Id "ezwinports.make"
 }