kristianwindandClaude Opus 5
70d7398d5a
API-dokumentationen har fulgt med hele vejen — der er en prøve, der fejler, hvis en rute ikke står i openapi.yaml, og den fangede mig fire gange i går. Brugervejledningen har ikke fulgt med, og det er den, folk læser. Nyt: en side om beskeder — hvad der udløser en, hvorfor gentagne rettelser bliver slået sammen, push pr. apparat og mærket på ikonet. En om at åbne links i en anden browser, som mest af alt handler om, hvad en webside ikke kan: hverken se hvilke browsere der findes eller vælge mellem dem. Og en om tællingen af installationer, som ikke stod nogen steder overhovedet — en melding, der er slået til som udgangspunkt, har en pligt til at være skrevet ned, også når ingen har spurgt. Rettet: AI-siden beskrev to funktioner, hvor der nu er syv, og listen over hvad der sendes hvorhen var derfor forkert som en påstand om noget privat. Noter-siden manglede deling med en e-mailadresse og hvad `@Sofie` gør. Mail-siden manglede den anden vej ind i indbakken. Konfigurationen sagde stadig, at versionstjekket kun kunne se efter. Og tagbeskeden når nu frem. Den ER annonceringen — skrevet på produktets eget sprog til dem, der bruger det — og udgivelsen på GitHub blev fyldt med en autogenereret liste over commit-overskrifter i stedet, som er skrevet til dem, der læser koden. Nu står teksten øverst og listen under den. Linjen med linket til udgivelsen selv tages af: en side, der linker til sig selv, hjælper ingen. Dokumentationen bygges nu også på en PR. `mkdocs build --strict` fejler på et link til en side, der ikke findes, og at bygge først efter merge er at få det at vide på main. Co-Authored-By: Claude Opus 5 <[email protected]>
2.2 KiB
Opening links
A link in a task or a note opens in whichever browser your system opens links in. Settings → Links can try to change that — and the honest description of what it does is try.
What a web page cannot do
Two things, and they set the limits of this feature:
- It cannot see which browsers are installed. The list is deliberately closed: it would be a fingerprint, distinctive enough to follow somebody from site to site.
- It cannot ask the system to use a particular one. A link goes to the default browser, and there is no API that says otherwise.
The only handle that exists is the URL schemes browsers register for themselves —
firefox://open-url?url=…, googlechrome://…, microsoft-edge:… — and there is no
way to ask whether one exists. You can only try it.
So the setting is an attempt
Pick Safari, Chrome, Firefox or Edge, or write your own scheme. When you click a link, that scheme is tried first; if nothing has happened within about half a second, the link opens the ordinary way.
The fallback is the whole reason this is safe to turn on. Without it, a setting that works on your phone would leave links doing nothing on your desktop.
In practice: it works on a phone, where browsers register these schemes, and rarely on a Mac or a PC, where Chrome and Firefox do not. Edge on Windows is the usual exception. There is a Prøv det button for exactly this reason — you cannot ask whether a scheme exists, so it is better to find out on example.dk than on a link you meant to follow.
Writing your own
Three placeholders, because browsers disagree about the shape they want the address in:
{url} |
The address as it is — x-safari-https://example.dk |
{encoded} |
The address as a parameter value — firefox://open-url?url=https%3A%2F%2F… |
{stripped} |
The address without the https:// — googlechrome://example.dk |
It belongs to the machine, not the account
The choice is kept in the browser you are sitting at, not on your account — the
same rule the sidebar's width follows. firefox:// works on the phone and does
nothing on the Mac, so a choice that followed the account would be wrong in one of
the two places every time.