~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

The iOS app links the pulls and issues Markdown names, as the pages do

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:ios/at-links

What changes

References show as on the pages. In the iOS app, a pull's or issue's body or comment that names one of the repository's pulls or issues by its bare at:// URI shows a link with its title, where it showed the raw URI. A URI in code, or one of another repository, stays as written, as on the pages.

Links to pulls and issues open in the app. Tapping that link, a [words](at://…) link to one, or a link to its page on knotless.dev (/<owner>/<repo>/issue/<did>/<rkey>) for the same repository, opens the thread in the tab's own navigation rather than in Safari. Each tab's stack now puts an openRoute in the environment for that, Explore's included.

just ios-look --tap @x,y taps a point on the screen, for a link inside text, which has no label to tap it by.

Why

The server already links these for the pages (written_naming), but the app draws Markdown from the source and only read the code colours from the HTML. The titles come from that same HTML, its <a href="/owner/repo/issue|pull/did/rkey">, so the answer stays as its lexicon says, and the app shows exactly the references the server resolved.

How it was checked

Built for the simulator. just ios-look issue-open with the body set to a bare URI, a [the other one](at://…) link, the URI in code and one of an unknown repository, with the HTML as the server makes it: the first shows its title, the second its own words, the last two as written (pictures attached, light and dark). Tapped the title with --tap @258,319, and it opened "Counts one line for an empty file" in the app.

Shortcomings

  • The title is read from the HTML's link text. Where the text both names a URI bare and links words to it, the words of a [words](uri) link aren't taken for its title. A body that links different words to it twice could still pick the wrong ones.
  • A knotless.dev link to another repository's pull still opens in Safari, as the app would need that repository's DID.
  • Inbox previews still show a bare URI as written.

🤖 Generated with Claude Code

refs-dark.png

opened.png

Approved

This makes the iOS app show the titles of pulls and issues named by bare at:// URIs, using the links the server already put in the HTML. It also opens those links, and knotless.dev links to the same repository, as in-app routes, and adds --tap @x,y to ios-look. The change is confined to ios/ plus a small tap option for ios-look. In the diff I found nothing that must change.

  • Links: Code spans and other repositories stay as written, and a [words](uri) link keeps its own words. Unlinked at:// URIs are discarded rather than sent to Safari.
  • Tabs: Each tab, Explore's included, now has its own path and openRoute.
  • Not checked: I did not build or run the app. I did not check that Route.thread(_, uri:) has that shape or that the server's <a href="…"> carries no extra attributes. The regex in MarkdownReferences.init needs exactly <a href="…">, so if the server adds a class or other attribute, no references are found and no titles show.
  • Cost: linked recounts backticks from the start of the text for each at:// match. That is quadratic, but only in the number of URIs, so it is fine for these sizes.
  • Known limits: The shortcomings the body lists are acceptable, in particular the title heuristic for the same URI both bare and linked.
Merged as 269616e