| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Last input wins, canvas size is adjusted to active connection.
|
| |
|
|
|
| |
brew auto-resolves GitHub taps, so the explicit URL is no longer
needed: 'brew tap sl0p-foo/slosh' is all users type.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
'With Homebrew (macOS or Linux)' followed by a source build made every
reader parse which half was theirs; now macOS and Linux each have a
heading, and you read yours. macOS is the tap; Linux is the same tap
under Homebrew on Linux, or the source build, which the docs landing
page had never mentioned brew at all.
Also fixes the README telling people to run bare 'make', which prints
the help text (the default goal) and builds nothing. install.sh had
this figured out and commented on it; the README had not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some 230 sentences hung their qualifications between dashes, and at that
density the tic reads as the writing's signature rather than a tool it
occasionally picks up. Each one is now the punctuation the sentence
actually wanted: a colon where the aside defines, parentheses where it
whispers, a comma where it barely pauses, a full stop where two thoughts
were pretending to be one. Definition lists and reference tables take
colons throughout.
Two double hyphens remain on purpose, both literal: the argv separator
in a shell example, and a table cell that means 'takes nothing'.
|
| |
|
|
|
|
|
|
|
| |
The 'Why another one' section was two paragraphs of case-making against
other multiplexers, and a landing page that defends its existence reads
as unsure of it. What the section said truthfully -- the vendored core,
recompute-not-remember, scriptable to its depth -- design.md already
says where it belongs. The one-line closer stays: 15k lines of C and no
dependencies is a fact, not a defence.
|
| |
|
|
|
|
| |
Same reasoning as the README's (24a6db01): the sketch says nothing the
first paragraph did not, and on the rendered site it sat where the
reader was deciding whether to keep reading.
|
| |
|
|
|
|
|
|
| |
splash_ms and the project settings join the knobs table, the pane-state
ranking gains the floating it was missing, contrib/themes' seventh file is
named for what it is, the shader table's numbers are called examples with
the real omitted-value defaults beside them, the index links workspaces,
and the verb table learns splash.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sl0p + pty was error-prone to type and the zero made it worse; slosh
(slop + sh) is one syllable, impossible to typo, and slosh.foo is ours.
Mechanical rename everywhere it appears: binary, env vars (SLOSH,
SLOSH_SESSION, SLOSH_BIN, SLOSH_CONFIG), socket dir (/tmp/slosh-<uid>,
$XDG_RUNTIME_DIR/slosh), config path (~/.config/slosh), header guards,
src/sl0ppty.h -> src/slosh.h, contrib/sl0ppty-dev -> contrib/slosh-dev,
the driving-slosh skill, docs and tests. The sl0ppi fork references and
the sl0p theme stay: one is history, the other is the brand.
The rename surfaced a latent bug in test_osc5577: the hello-reply
answer always appeared on screen twice (ECHOCTL echo plus cat -v), but
a seven-character implementation name happened to wrap the second copy
across the 60-column boundary, so counting substrings in wrapped text
found one and passed for the wrong reason. A five-character name moved
the wrap and exposed it. The loop guard itself is correct -- with echo
off before the request there is exactly one reply -- so the test now
counts on de-wrapped text and tolerates the pane's own echo.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Audited every page against the source and the binary rather than against my
memory of it. Eight pages changed; the lists were all fine and the *numbers* were
all wrong.
Checked mechanically, and each of these came out complete: all 37 action names,
all 28 control verbs, all 9 shader names, the expression language's 10 variables,
2 constants and 7 functions, the 8 pane states, every knob the dump prints, every
OSC verb, every internal link and anchor, and every page's place in `docs/nav`.
Every fenced `kdl` block was run through `--check`; every `{"cmd":...}` in an
example is a verb that exists.
What was stale:
- **`make` does not build.** The default goal is `help`, so the install block --
`make vendor`, `make`, `make test` -- never produced a binary. It says `make
all` now, timed at 5.5s from clean rather than "about a second".
- **700-odd checks in about eight seconds** is now 1,500-odd in about thirteen,
plus 260 from the C unit tests, which the sentence did not count at all.
- **About 10k lines of C** is 15k. (10,799 of those are neither blank nor a
comment, which is presumably where the old figure came from.)
- **Seven chrome presets** are thirteen, and the six new ones use `sin` and `TAU`
-- so the perimeter section gained the angle idiom it now depends on, and its
"two things fall out of it" became three.
- **`--check`'s example transcript showed two errors nobody can produce any
more**: `bad prefix: C-a` and `bad key: ←`. Both inputs became *valid* -- `C-a`
when the chord parser learned the notation the cheatsheet prints, and `←` when
it learned the arrow glyphs, precisely so a chord copied off the screen parses.
Replaced with a transcript I generated, and a note that the problems go to
stderr, which matters for the pre-commit hook the page suggests.
- **`bell_indicator`** was a real knob documented nowhere.
- **"There is no key for this yet"** about moving a pane between tabs, two commits
after the keys and the drag landed.
- The cheatsheet's `+N more` line, the finder's `C-u`, and `tab_id` in a pane
report were all real and unmentioned.
Verified: the whole suite green, `make docs` builds nine pages, and the changed
pages read correctly in a browser -- including the new transcript and the `>` `<`
row of the key table.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contrib/gen-docs renders docs/ into a static site: one file of stdlib
Python and one stylesheet, no toolchain, no package manager, no npm. Same
argument as src/kdl.c being a hand-rolled KDL subset rather than a
library -- the input is ours, we know exactly which constructs it uses,
and a docs build that needs a lockfile is a docs build nobody runs.
What the Markdown subset understands is what docs/ actually contains:
headings (with anchors), paragraphs, fenced code, pipe tables, lists one
level deep, blockquotes, rules, `code`, bold, italic, links. Anything
else is escaped and passed through as text. A construct nobody uses is
not supported on purpose: it would be untested code pretending to be a
feature.
The layout is a sidebar of sections from docs/nav, the page, and its own
headings down the right; prev/next chains the nav order; a link to
another page is rewritten to its rendered page, so the same Markdown
reads correctly on a forge and on the site. The colours are the session's
own default theme, so the docs look like the thing they document, and the
light variant follows the reader's system preference rather than a toggle
nobody would find. Zero JavaScript -- the narrow-screen menu is a
checkbox.
Two things came out of looking at it in a browser rather than trusting
the HTML.
The hero diagram was hand-drawn and its lines were 78 and 79 columns
long, which is visible. It is generated from a real session now -- three
panes, a layout file, a text snapshot -- so it is exactly what the
program draws. Terminal art also needs tighter leading and a font whose
box drawing joins, so a fence with box characters in it and no language
is emitted as art rather than code and styled for that. Detected rather
than declared, because the alternative is a marker on every fence and one
of them getting forgotten. (Vertical rules still break between lines in
a browser: the glyph does not fill its em box, and no amount of CSS
changes that. Widths line up, which is the part that matters.)
The narrow-screen menu opened over a page that showed through underneath
it: as a grid child taken out of flow it kept its content height, so
`bottom: 0` did nothing. It has an explicit height now.
tests/test_docs.py checks both jobs. The site: every page in the nav is
rendered, carries the whole sidebar, is marked as current on its own
page, chains prev/next, and no internal link in the output points at a
file that is not there. The subset: each construct, and the one that
matters most -- markup inside a code span is not markup, because half of
these docs are shader expressions full of asterisks. A page missing from
docs/nav fails the build, and so does a nav entry with no file: an
unreachable page whose only symptom is its absence is the failure mode a
hand-written nav has.
|
|
|
The README was 331 lines and had become a manual with a title. Everything
in it was true and most of it was the wrong thing to hand somebody who
has just arrived: five pages of shader expression semantics before they
have split a pane.
So the front page is 60 lines -- what it is, install, run, where the docs
are, and six bullets on what is actually different about it -- and the
detail moved into docs/, nine pages that each answer one question:
index.md what it is, install, run, where to go
keys.md the leader, every default, rebinding, direct binds
panes.md splitting, resizing, the mouse, dead panes, small terminals
config.md the file, live reload, include, themes, the knobs
shaders.md the passes, the built-ins, the expression language
chrome.md where="chrome", channel, since, the perimeter trick
layouts.md a session as a file, and writing one back out
scripting.md the control socket, OSC 5577, headless
design.md the two decisions, and a map of the source
docs/nav holds the order and the grouping and nothing else -- titles come
from each page's own heading, so a renamed page cannot end up with two
names. It is what the site generator will read.
Reference material that only existed in code comments is written down for
the first time: every action that can be bound (including the two with no
default key, which is what the palette is for), every control verb, the
built-in shaders with what each takes, the pane-state ranking, and the
layout file's shape.
Two things I got wrong on the first pass and fixed before committing: the
docs linked repo files through github.com URLs for a project whose remote
is a private git server, so those are inline paths now; and the README
advertised `make docs`, which does not exist yet. It will in the next
commit, and it can be advertised then.
|
