Skip to content

docs: join the Python build to the libtmux.org shared shell - #755

Draft
tony wants to merge 6 commits into
masterfrom
docs-site
Draft

docs: join the Python build to the libtmux.org shared shell#755
tony wants to merge 6 commits into
masterfrom
docs-site

Conversation

@tony

@tony tony commented Sep 5, 2026

Copy link
Copy Markdown
Member

Summary

  • Add docs/_static/libtmux-org.css, the design-token adapter mapping the shared --lt-* tokens onto Furo's own --color-* contract. tokens.css restyles nothing by itself; without this translation table a Sphinx page carries the variables unused in the cascade and still paints Furo's stock blue.
  • Load the shell's header, footer, and version switcher through /_shell/shell.js, so the Python build wears the same chrome as the other ports.
  • Redirect Sphinx's built-in search page to the shell's Pagefind search at /search/. Furo's search UI needs a client-side index this build does not emit at that path.
  • Pin sphinx-gp-llms to a fork carrying the fix for .md twin links on genindex and py-modindex, which have no twin — four dead links in the assembled site.

Blocked on the sphinx-gp-llms pin

[tool.uv.sources] resolves sphinx-gp-llms from ssh://git@github.com/tony/gp-sphinx.git, which is private. uv sync --all-extras --dev is the install step in both tests.yml and docs.yml, and it fails for anyone without a key on that repo:

git@github.com: Permission denied (publickey).

Every build leg of the tmux matrix fails at that install step, before a test runs.

The pin lives on this branch because libtmux.org's assembly reads docs-site directly; the package published to PyPI is unaffected. Merging to master needs the fix released or landed on the public gp-sphinx, and the [tool.uv.sources] and [tool.uv] override-dependencies blocks then dropped.

Changes

docs/conf.py: html_css_files gains libtmux-org.css, listed after css/custom.css so its overrides win the cascade at equal specificity; html_js_files gains a deferred /_shell/shell.js; templates_path is stated explicitly rather than inherited from gp_sphinx's identical default, so a later change to that default cannot silently stop the search override from loading.

docs/_static/libtmux-org.css: @imports the shared tokens.css and translates --lt-* onto Furo's --color-* for light, data-theme="dark", and prefers-color-scheme: dark. Its header carries the full rationale.

docs/_templates/search.html: replaces the theme's search page outright — no {% extends %}. The wording matches the rediraffe stubs already in this tree so the site audit's redirect check skips it instead of flagging an empty page.

pyproject.toml: declares sphinx-gp-llms directly in dev and docs so [tool.uv.sources] can redirect it — a source override does not reach a dependency that arrives transitively.

Design decisions

Import the tokens, never copy them. The values stay live at the CDN, so a chrome-color fix reaches an already-published build without a rebuild here. Only the mapping — which --lt-* name feeds which --color-* name — is fixed at build time.

Every var(--lt-*) carries Furo's own stock value as its fallback. This is what makes the file repetitive, and it is load-bearing: a var() naming an undefined custom property with no fallback resolves to the guaranteed-invalid value, so --color-background-primary would compute to unset rather than white. Any page whose cross-origin tokens.css fetch 404s would then render worse than the glitch this file closes. The fallbacks are Furo's stock colors rather than libtmux's, so a failed fetch degrades to plain Furo instead of vendoring the palette.

Override sphinx-gp-llms alone, not the gp-sphinx meta-package. Pinning the meta-package makes uv resolve its siblings from the fork too, and they are published at a pinned version the fork does not carry.

Test plan

Not run before opening; uv sync needs a key for the fork above.

  • uv sync --all-extras --dev resolves
  • cd docs && just html builds clean
  • Built pages list libtmux-org.css after css/custom.css, and load /_shell/shell.js
  • The built search.html redirects to /search/
  • With tokens.css unreachable, pages render as stock Furo in light and dark

tony added 6 commits September 5, 2026 03:42
Furo's own search.html needs a JS index this build doesn't serve at
this path; the shell already indexes every port at /search/. Overriding
the search.html template (rather than adding a page) works regardless
of the theme, and the redirect wording matches the existing rediraffe
stubs so scripts/audit-site.mjs's redirect check skips it.
Closes notes/status.md's "Python and C++ are unskinned islands" glitch:
without this file Furo has no --lt-* mapping and paints its own stock
blue. Imports https://libtmux.org/_shell/tokens.css and maps the shared
~25 semantic tokens onto Furo's --color-* contract. The html_css_files
and html_js_files entries wiring it (plus shell.js) into conf.py landed
in 7380cd478 alongside an unrelated search-page fix from concurrent work
in this worktree.
…hable

A var() on an undefined custom property with no fallback resolves to the
guaranteed-invalid value, so every remapped --color-* would compute to
unset until libtmux.org resolves (notes/status.md: never deployed) --
worse than the stock-Furo glitch this adapter exists to close. Fall back
to Furo's own stock color per property instead, so an unreachable
tokens.css degrades to unmodified Furo rather than a broken page.
Pagefind logs a missing html[lang] warning when indexing the assembled
site; the rediraffe-generated stubs in this tree have the same gap, but
there's no reason to match it here too.
An absolute https://libtmux.org/_shell/ URL resolves nowhere until the site
is deployed, so the injected chrome was invisible in every local preview and
the design-token bridge could not be checked at all. A root-relative path
resolves on both the deployed origin and a local preview server.
sphinx-gp-llms links a `.md` twin beside every generated page, including
genindex and py-modindex, which have no twin. That is four dead links in
every assembled libtmux.org build, and the last four the site had.

The fix is on the private fork's fix/md-twin-link-on-generated-pages.
Upstream gp-sphinx is public and takes no push from here, so the fork is
where it lives until a release carries it.

Three things this needed, none obvious:

- Only sphinx-gp-llms is redirected, not the gp-sphinx meta-package.
  Pinning the whole thing makes uv resolve its siblings from the fork
  too, and they are published on PyPI at a version the fork does not
  carry.
- It has to be declared as a direct dependency. It arrives transitively
  through gp-sphinx, and [tool.uv.sources] only redirects direct ones.
- gp-sphinx==0.1.0a37 pins sphinx-gp-llms==0.1.0a37 while the fork
  carries 0.1.0a38 — the fix plus its own bump — so the constraint is
  overridden. That is narrower than rewriting the fork's version to
  match a release it is ahead of.

Pinned in this worktree only. docs-site is what libtmux.org's assembly
reads; PyPI is what everyone else gets and this does not change it.

Verified by deleting .venv and re-syncing: 0.1.0a38 from git, fix
present. The previous state was a hand-patched site-packages that any
uv sync would have silently reverted.

Assembled site: 1872 pages, 403476 links checked, 0 broken.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant