Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
docs/_static/libtmux-org.css, the design-token adapter mapping the shared--lt-*tokens onto Furo's own--color-*contract.tokens.cssrestyles nothing by itself; without this translation table a Sphinx page carries the variables unused in the cascade and still paints Furo's stock blue./_shell/shell.js, so the Python build wears the same chrome as the other ports./search/. Furo's search UI needs a client-side index this build does not emit at that path.sphinx-gp-llmsto a fork carrying the fix for.mdtwin links ongenindexandpy-modindex, which have no twin — four dead links in the assembled site.Blocked on the
sphinx-gp-llmspin[tool.uv.sources]resolvessphinx-gp-llmsfromssh://git@github.com/tony/gp-sphinx.git, which is private.uv sync --all-extras --devis the install step in bothtests.ymlanddocs.yml, and it fails for anyone without a key on that repo:Every
buildleg 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-sitedirectly; the package published to PyPI is unaffected. Merging tomasterneeds the fix released or landed on the publicgp-sphinx, and the[tool.uv.sources]and[tool.uv] override-dependenciesblocks then dropped.Changes
docs/conf.py:html_css_filesgainslibtmux-org.css, listed aftercss/custom.cssso its overrides win the cascade at equal specificity;html_js_filesgains a deferred/_shell/shell.js;templates_pathis stated explicitly rather than inherited fromgp_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 sharedtokens.cssand translates--lt-*onto Furo's--color-*for light,data-theme="dark", andprefers-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: declaressphinx-gp-llmsdirectly indevanddocsso[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: avar()naming an undefined custom property with no fallback resolves to the guaranteed-invalid value, so--color-background-primarywould compute tounsetrather than white. Any page whose cross-origintokens.cssfetch 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-llmsalone, not thegp-sphinxmeta-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 syncneeds a key for the fork above.uv sync --all-extras --devresolvescd docs && just htmlbuilds cleanlibtmux-org.cssaftercss/custom.css, and load/_shell/shell.jssearch.htmlredirects to/search/tokens.cssunreachable, pages render as stock Furo in light and dark