slosh.git/docs/windows.md, branch docs-new

docs: less wordy

2026-08-29T18:25:39Z

windows release: a zip in dist/, built beside the linux tarballs

2026-08-28T13:38:27Z

make -f Makefile.windows dist stages slosh.exe as slosh--windows-.zip -- a zip, not a tarball, because Windows is the machine that will open it -- carrying the same licensing paperwork as the linux tarballs, with docs/windows.md riding along instead of the manpages. `make release` now builds both architectures via release-windows, so the windows zips land under the same SHA256SUMS as everything else.

ctrl_d_exits: Ctrl-D at a prompt, where the tty cannot do it

2026-08-28T12:41:42Z

Windows has no VEOF. The console driver does not know the character, so ^D arrives at cmd.exe and PowerShell as an ordinary keystroke and they ignore it -- it even echoes, which is how you find out: the line reads `echo hello^D`. The one key that closes a pane on every other platform does nothing at all, and closing a pane becomes a word you have to type. That you can type `exit` instead is the tell: the intent was never ambiguous, only unspoken. So slosh speaks it. What goes to the pane is the word, not a signal and not a close from outside -- the shell runs its own cleanup, returns its own status, and keep_dead decides what is left behind, all three of which reaching past it would skip. It is also what the user would have typed, so there is nothing new to explain. The knob is what makes it honest, because a wrong guess costs a pane. It fires only with the shell itself in the foreground (a program that is running may want the EOF for itself -- `cat` reading to end is the whole job), only on the primary screen (in an editor or a pager ^D is half a page down, and the alternate screen is the pane stating that rather than us matching process names), and only on an empty line (POSIX sends EOF there; what it does not do is discard what you typed). The line is an estimate. The shell's editor is on the far side of a pty, so pane_send_key counts what it forwarded since the last Enter. Editing it does not model -- a recalled history entry, ^U, completion -- leaves the count too high, which forgets to exit. That is the direction to be wrong in; the other one throws away a half-typed command. Default true on Windows, false on POSIX, where the line discipline already does this and does it properly: ^D there is also EOF for `cat` and every REPL, none of which is ours to intercept. A knob rather than an #ifdef so the guards are the same code everywhere and can be tested where the test suite runs -- test_ctrl_d.py turns it on and drives all four decisions, plus the case that does exit. Telling trapped from forwarded needs a program that reports what it received: on POSIX a forwarded ^D also ends an idle shell, and looking for the word `exit` cannot separate them either, because bash prints `exit` itself on EOF. Verified on the Windows box as well, where it is the default: ^D at an idle cmd.exe prompt takes the pane (and with it the session, having no panes left), `more` in the foreground keeps its own EOF, and a half-typed line survives with the line still on screen.

docs: the Windows build is a cross-compile, and only that

2026-08-28T12:22:57Z

The docs offered a native build as an equal alternative -- "the same command builds natively on the Windows box itself, with zig on PATH and a make" -- and it does not work. Makefile.windows needs sed, cat, mkdir -p and shell grouping, none of which cmd.exe has; and on ARM64 `zig cc` in zig 0.16.0 dies with an access violation on a one-line C file, so the compiler cannot run there at all. The zip that does it matches the published shasum, so this is upstream rather than a bad download. Nobody following those two sentences reached a binary. So they are gone, along with the "# host arch, native" usage line in the makefile and the "cross-compiles too" aside in the two install sections, which both implied that building on the box was the normal path and the cross-compile a bonus. It is the other way round, and now the pages say so once, in the same words each time. `builds and runs natively` on the doc's first line loses `builds`: what is native about slosh.exe is the binary, not where it was made.

windows: fall back to `edit`, not to a notepad window

2026-08-28T11:25:19Z

`C-a e` on a Windows with no editor installed opened notepad, which is a GUI program: the pane it was spawned in drew nothing, so the split sat there empty while the config opened in a window somewhere else. The toast said as much, but a pane you have to be told to ignore is still the wrong answer. Windows 11 24H2 ships Microsoft Edit as `edit`, and it is a console program -- it fills the pane like nvim or nano would, so the fallback now has the same shape as the thing it is falling back from, and a first-time user gets a usable editor without installing one. It goes last of the console editors rather than first. Having fetched nvim is a statement of preference; having been shipped `edit` says nothing about what you want, so anything you chose yourself outranks it. notepad stays behind it: `edit` is not on Windows 10, or on 11 before 24H2, and something that opens is better than nothing when the alternative is an empty pane. sl_which() already tries .exe, so it is found as installed; the search still only runs when neither EDITOR nor the config asked for anything.

docs: the Windows port, and what is different there

2026-08-27T22:23:19Z

An install subsection alongside macOS and Linux, and a page under Inside for the rest: how to build it, what changes about running it (%ComSpec% panes, sessions in %LOCALAPPDATA%), and the reasoning the code can only gesture at in comments. The three traps are written down in full, because each one presents as something other than what it is and cost real time: a pane with a title and no body (the child inherited slosh's stdout rather than the pseudoconsole), a pane that stays alive after `exit` (a ConPTY's output pipe belongs to the console, not the child, so the read never ends), and an editor refusing a path that plainly exists (cmd.exe and CommandLineToArgvW disagree about what \" means, and separately the CRT accepts a mixed-separator path where a GUI dialog will not).