807aa83e5813d2c33beba7e98048daec0109333f
21
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 kristianwindandClaude Opus 5
|
b497b76be4 |
fix(noter): monotype tager hele markeringen, og farvelægningen taber ingen linjer
Meldt ind: "kun den øverste sætning af det jeg markerede blev lavet om til monotype". Det førte til en anden fejl, der var værre. --- den meldte --- Monotype går uden om execCommand, fordi formatBlock pakker et <p> ind i <pre>'en i stedet for at lave den om. Den vej spurgte efter `currentBlock()`, og det er ét blok — markørens. Så af en markering over ti linjers terminaludskrift blev den første linje til kode og resten stod tilbage som brødtekst. `selectedBlocks()` læser hele markeringen, og de markerede blokke lægges sammen til ÉN blok. Ikke én pr. linje: en udskrift, man indsætter, er ét stykke kode, og tre blokke ved siden af hinanden ser næsten ens ud på skærmen og bliver til tre hegn i filen. Vejen ud af monotype tager nu også hele markeringen. `swapTag()` bytter tagget uden at røre markøren — tekstknuderne flytter med over, så den range browseren holder på stadig peger på noget i dokumentet, og formatBlock kan klare resten bagefter. --- den anden, som prøven fandt --- `watchForTrouble` meldte "ReferenceError: codeText is not defined" fra et rekursivt kald, jeg havde glemt at omdøbe. Ved siden af det lå en KOPI af "hvad er teksten i en blok", inde i editoren, med præcis den <br>-fejl, der blev rettet i #91: `textContent` på et <br> er den tomme streng. Den kopi bruges af farvelægningen, som maler resultatet TILBAGE ind i blokken. Så en kodeblok skrevet med shift+retur fik sine linjer skrevet sammen i det øjeblik, man klikkede væk fra den — på skærmen, ikke kun i filen, og uden at nogen havde rørt teksten. Målt mod den gamle kode: "echo enecho to". Kommentaren over kopien sagde ordret, at de to læsninger skulle være ét sted, FORDI en uenighed ville ende i noten. Den var sand, da den blev skrevet; kopien kom senere. `blockText` i richtext.js er nu det ene sted, eksporteret og brugt begge steder. Begge prøver er efterprøvet mod den gamle kode. Fuld chromium-suite kørt to gange: 94 bestået, 0 fejlet, begge gange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
f34690f41a |
fix(noter): niveauer i lister, flere linjer i en blok, og en søgning man kan vælge i
Tre ting meldt ind sammen. De to første manglede; den tredje var i stykker. --- man kunne søge og ikke vælge --- Regression fra #84. Siden holdt op med at SKRIVE adressen, men blev ved med at læse den ved hver ændring: let asked = $derived($page.url.searchParams.get('note')); $effect(() => { if (!asked || selectedId === asked) return; … }); Kom man fra ⌘K med `?note=<id1>`, stod `asked` fast på id1 for altid. Hvert klik på en anden række satte `selectedId`, effekten så uenigheden og åbnede id1 igen. Man blev trukket tilbage til den første træffer. En adresse, der ikke følger med, er ikke en tilstand at holde sig enig med. Den læses nu ved ankomsten — og der er TO ankomster, hvilket den første udgave af rettelsen ikke tog højde for: layoutet tegner ingenting, mens kontoen hentes, så siden monteres efter den første navigation er forbi, og en lytter registreret der hører den aldrig. `/noter?note=<id>` tastet eller fulgt udefra åbnede så ingenting. `onMount` og `afterNavigate`, samme funktion, med `id === selectedId` som værn mod at begge fyrer. --- en blok kunne ikke gemme flere linjer --- Shift+retur bliver i blokken, men det browseren lægger ind er et <br>, og `textContent` på et <br> er den tomme streng. Blokken blev skrevet til Markdown som én linje: "first linesecond line". Usynligt indtil en genindlæsning, for på skærmen står linjerne rigtigt hele tiden. `codeText()` læser blokken rekursivt og gør <br> til et linjeskift. Rekursivt, fordi indholdet ligger i et <code> inde i <pre>: en filtrering over <pre>'ens egne børn spørger det ene element om en textContent, der allerede har tabt linjeskiftet. --- lister havde ingen vej til niveau to --- Tab var ikke bundet til noget uden for forslagslisten, så den gjorde det, Tab gør: flyttede fokus ud af noten. Den rykker nu ind og shift+Tab ud, og kun inde i en liste — ellers er noten en boks, man ikke kan tabbe ud af. Og skriveren ville have tabt resultatet: `list()` læste kun en underliste, der ligger INDE i sit punkt. Lægger browseren den som søskende, og de gør det uens, blev grenen sprunget over uden lyd. At binde Tab uden den her halvdel ville have lavet en fejl, hvor indrykkede punkter forsvandt ved gemningen. Begge nye prøver måler EFTER en genindlæsning. Før den ser begge dele rigtige ud på skærmen; det er turen gennem Markdown, der afgør, om det blev skrevet ned. Fuld chromium-suite kørt to gange: 92 bestået, 0 fejlet, begge gange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
ff0447317b |
feat(noter): et indsat billede kan ses helt og kopieres videre
I arket er et billede skaleret ned til spaltens bredde — et foto fra en telefon er fire tusind pixels bredt — så det, man kigger på, er et miniaturebillede, der ikke ser ud som et. Der var ingen vej fra det til billedet selv. Et klik åbner det nu i fuld størrelse, med en knap, der kopierer det, og et link, der åbner det i sit eget faneblad. Escape lukker og sætter markøren tilbage i teksten — ellers står fokus på en knap, der ikke findes længere, og den næste tast går ingen steder. Klikket ligger i onEditorClick ved siden af notelinket, som er det andet, man kan klikke på inde i et felt, man ellers skriver i. Billedet bliver stadig markeret af klikket, og det skal det: det er sådan, det slettes. To ting, der ikke er til at gætte: Udklipsholderen tager kun PNG i de fleste browsere, og et foto fra en telefon er en JPEG. Så et billede, der ikke allerede er PNG, tegnes om over et lærred — ellers lykkes skrivningen enten ikke, eller den lykkes med noget, ingen kan indsætte. Prøven indsætter derfor med vilje en JPEG; med en PNG var den kørt forbi netop den kode. Og løftet gives videre til ClipboardItem frem for at blive ventet af først. Safari kræver, at clipboard.write kaldes i selve klikket, og en hentning imellem gør klikket til fortid. Ruden ligger uden for .wrap: editoren har sin egen rulning og sin egen stablingskontekst, og et lag inde i den ville blive klippet af netop det ark, det skal lægge sig over. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
d8f5f6e236 |
feat(noter): nævn en person i en note, og den er delt med dem
At skrive nogens navn i en note *er* at ville have dem til at læse den. Indtil nu var det to handlinger — skriv navnet, åbn panelet, find personen, del — og den anden blev glemt, så noten stod med en besked til en, der ikke kunne se den. Nu deler `@Navn` noten med den, der bliver nævnt, og siger det til dem. Editoren foreslår personer efter `@`, ligesom `#` foreslår projekter. Slået op i navnene frem for tolket ud af teksten. Et navn kan have mellemrum i sig, og et udtryk, der skulle fange dem alle, ville også fange sætningen bagefter: `@Sofie i morgen` ville blive til en person, der hed noget i den retning. Her er der ikke noget at gætte — der står et navn, eller der gør ikke. Det er også dét, der gør det forsvarligt at dele på: adgang må ikke afhænge af, hvor langt et regulært udtryk valgte at læse. En mailadresse er ikke en omtale, det længste navn vinder, og ejefaldets s hører til sætningen. Kun nye omtaler, sammenlignet med teksten før gemningen på samme måde som links: en note gemmes ved hver tastepause, så uden sammenligningen var hver gemning en ny deling og en ny besked om det samme navn. Kun ejerens omtaler deler. En medredaktør må skrive i noten, men ikke give den videre — ellers kunne den, ejeren har delt med, skrive et navn og dermed dele ejerens note med en, ejeren aldrig har hørt om. Det er den samme regel, panelet følger. Læser, ikke medredaktør: en omtale siger "se på det her", og det mindste, der opfylder sætningen, er det rigtige at give. En rolle, ejeren har hævet i panelet, sænkes ikke igen af en omtale. Og én besked pr. handling: den, der lige er blevet nævnt, får "nævnte dig" og ikke også "rettede en note" om den samme gemning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
08d703e3af |
fix(noter): følg note-links i en delt note, og lad </> være kode
To ting meldt af en, der havde en note delt med sig. Note-linkene i den delte note gjorde ingenting. Opslaget faldt tilbage på det første søgeresultat, når ingen titel passede — og i en delt note er det første resultat næsten altid noten selv, fordi den nævner den titel, den peger på. Så åbnede linket den note, man allerede stod i. Kun en titel, der passer helt, tæller nu; og rammer den forbi, siger beskeden den rigtige grund: en note, der deles, deler ikke de noter, den peger på, så modtageren kan se linket uden at kunne åbne det. Og `</>` sad på kildevisningen med teksten "Vis som kode" på. Tegnet betyder inline kode i ethvert andet program, så et markeret ord plus et tryk gav hele noten som Markdown. Nu gør `</>` det, det siger — ⌘E, en kontakt, og ordet under markøren når der ikke er markeret noget — og kilden har fået Markdown-mærket og sin egen tekst. Kode indsættes som en node frem for med execCommand: Chromium renser den HTML gennem indsætningsvejen og gav et <span> med skrifttypen skrevet ind i sig, som htmlToMarkdown ikke kan skrive ned som kode. To e2e-prøver, som begge fejler på koden før den her. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013r4DxpUZcSShxfCZZaeMGZ |
||
|
kristianwindandClaude Opus 5
|
8022502015 |
feat(notes): [[note]] is an inline link, not bracketed text
Choosing a note from the [[ completion wrote [[Title]] as plain text. It made a real link behind the scenes — it showed in the panel under the note — but in the note itself it stayed brackets, and "it doesn't become a link" is exactly how that reads. A wiki link is a link where it is written. Now a [[note]] renders inline as the title, in the accent colour, and a click on it opens the note it points at. It is atomic — contenteditable="false" — so it moves and deletes as one thing and a click is a click, not a caret landing mid-word. And it appears the moment it is chosen: the completion drops the finished link in, brackets and all swallowed, rather than text waiting to become a link when the note is next opened. The seam holds both ways: markdownToHtml lifts [[title]] into the link the same way it already lifts an image, and htmlToMarkdown reads the link back to [[title]] by the title it carries — so what is on disk is still the same Markdown, and a note opened, saved and reopened is unchanged. e2e: choosing a note writes an inline link, it survives the round-trip through Markdown and a reload, and clicking it opens the note it names. Full suite green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
6116ed2e21 |
fix(notes): [[ completes a note link, the way # completes a project
Typing [[ did nothing. The toolbar hint offered "[[ another note" and the parser turned a fully-typed [[Title]] into a link on save, but the completion that makes it usable — the one # has for projects — was never there, so you had to know and type a note's title exactly, brackets and all. Now [[ opens the same picker # does, over the notes the page has loaded: the current note is left out (a note linking to itself is a loop nobody meant), and one without a title yet cannot be pointed at. Choosing a note closes its own brackets — the opener is already in the text — and leaves a space, so the next word is a word and not more of the tag. On save the link is real and shows in the note's links, not merely as text. The picker's two kinds are told apart where a project wears its colour: a note suggestion wears the brackets that open it. e2e: [[ offers a note by title, choosing it writes [[Title]] into the note, and the link lands in the note's links. Full Chromium suite green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
f0d18bb800 |
fix(notes): let a monospace line be left — on return and through the menu
A <pre> is preformatted, so the browser answered Enter by inserting a <br> and
keeping the caret inside it. A monospace last line therefore trapped everything
typed after it in monospace, with no way back to body by typing — and the style
menu could not get out either: `formatBlock('p')` on a line inside a <pre> nests a
<p> *inside* the block (`<pre>…<p>body</p></pre>`), so the text stayed monospace
and the note was left malformed. Reported as "monospace keeps going and I can
neither delete it nor switch to body".
Two fixes, both in the editor:
- Plain Enter in a <pre> now steps out: the tail after the caret becomes a
paragraph below the block, and that is where the caret lands. Shift+Enter is
untouched, so a soft line break still writes multi-line code inside the block —
Enter to leave, Shift+Enter to stay.
- The style menu converts anything touching a <pre> by hand, replacing the element
rather than reformatting inside it, so a monospace line goes cleanly back to body
(or to a heading) instead of nesting.
The split can leave an empty text node in the new paragraph, and a block with no
element and no text is not a caret host in Chromium — the next keystroke falls back
into the block above. So an empty paragraph is given a <br> to stand in, which was
the difference between the caret landing in the new line and the text reappearing
in the code.
e2e: a monospace line left on Enter is body after it, Shift+Enter stays monospace,
the menu returns it to body, and the whole thing survives the round-trip through
Markdown and a reload.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Kristian WindandClaude Opus 5
|
ce1d27f8ca |
fix(notes): én note, der ikke kunne tegnes, låste hele ruden
Release / Build and publish image (push) Failing after 9m53s
Meldt ind som "jeg kan ikke skifte mellem noter — uanset hvilken jeg trykker på, åbner de ikke". Editoren indlæste med `note.body.trim()` uden værn. `body` er en streng fra serveren hver eneste gang — indtil den ikke er, og så kaster den her inde i et `$effect`. En effekt, der kaster, tager komponentens opdateringer med sig: den forrige note bliver stående, og *ingen* note kan åbnes bagefter. Klikket kan ikke engang lande, hvilket er derfor det ikke ligner en fejl i noten, man klikkede på, men i hele ruden. To ting, ikke én. Værnet, så en manglende krop er en tom note. Og en ramme om tegningen, så det næste, der en dag ikke kan tegnes, heller ikke bliver til det her: en note, der fejler, viser sin egen tekst uden formatering, og resten af ruden virker videre. `loadedId` sættes nu før tegningen frem for efter. Ellers ville effekten prøve igen ved hver eneste ændring bagefter og kaste hver gang. `textContent` og ikke `innerHTML` i faldbakken: teksten er ikke tegnet, og at lægge den ind som markup ville være at køre præcis det, tegningen nægtede. Gemningen er ikke i fare — den skriver `draft`, som kommer fra svaret og ikke fra det, der står i editoren, indtil nogen taster i den. Prøven tvinger formen frem i stedet for at vente på den nyttelast, der gjorde det. Hvad der end fik `body` til at mangle, er svaret det samme: én note må ikke kunne låse de tolv hundrede andre ude. Den er set fejle uden rettelsen — med netop den fejl, konsollen viste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
8ecefbbdc2 |
fix(notes): rullebjælken svævede midt i arket
Det er `.page`, der ruller — og det var også `.page`, der blev smallere for at holde linjelængden nede. Så bjælken fulgte med ind til tekstsøjlens kant og stod med en håndflade tom rude til højre for sig, en tredjedel inde i ruden. Grænsen sættes som polstring i stedet for som bredde. Elementet er lige så bredt som ruden — bjælken bliver ved kanten, hvor den hører til — og teksten er nøjagtig lige så bred som før. `max()` mod nul, fordi en smal rude ellers ville få negativ polstring, og `border-box` er sat globalt, så bredden er hele boksen og ikke boksen plus polstringen; uden det ville det give en vandret rullebjælke. Kildevisningen deler `.page` med editoren og havde samme fejl. Den følger med. Målt: elementet slutter nu på rudens indholdskant i stedet for 74 px inde, og `scrollWidth - clientWidth` er nul. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
035d079a8e |
fix(notes): teksten fulgte ikke med, når ruden blev bred
Release / Build and publish image (push) Failing after 9m59s
46rem var sat for at holde linjelængden i skak, og det er stadig det rigtige hensyn — men det blev sat som ét tal, og på en skærm halvanden gang så bred stod teksten i en smal søjle med en håndflade tom plads ved siden af. Kodeblokke og billeder, som er de to ting i en note, der *vil* have bredde, blev klemt sammen uden grund. clamp frem for et tal: en smal rude får det hele, en bred får en linjelængde, øjet kan finde tilbage i. På 1920 er tekstsøjlen nu 1088 px af arkets 1304 i stedet for 736. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
aadfb197b6 |
feat(notes): arkiv, flere ad gangen, og en kopiér-knap på koden
Release / Build and publish image (push) Failing after 9m55s
**Arkivet, fordi papirkurven er det forkerte redskab.** Den siger "det her var en fejl, og om tredive dage er det væk" — så alt, der er værd at beholde, kan ikke komme i den. Et arkiv på tolv hundrede importerede noter er præcis det tilfælde, hvor de fleste er værd at beholde og næsten ingen er værd at kigge på; uden et sted at lægge dem er listen hele arkivet for evigt, og at finde ugens note betyder at læse forbi et årti. En kolonne, ikke en mappe. Noterne afviste et andet hierarki i 0018, og arkivering er ikke arkivering i den forstand: det er én oplysning om, hvorvidt en note er aktuel, og den skal kunne besvares ved siden af `deleted_at`, som er den anden af samme slags. `updated_at` røres ikke — at rydde op er ikke at skrive. **Flere ad gangen.** ⌘-klik lægger til, skift-klik tager intervallet i den rækkefølge, listen faktisk står i — ikke notens egen, som er en anden, når der er sorteret eller søgt. Trækker man en note, der er markeret, følger hele markeringen med; trækker man en, der ikke er, er det den ene, for ellers ville et træk i en tilfældig række flytte halvtreds noter, man havde glemt var markeret. Ét kald frem for et pr. note: efter en import af tolv hundrede er det at vælge halvtreds det almindelige tilfælde. Hver note kontrolleres stadig for sig — et sæt er en bekvemmelighed for den, der kalder, og aldrig en vej til noget, de ikke kunne have rørt én ad gangen. En kant *og* en tone på det markerede: `--accent-sunken` er meget lys i lyst tema, og tre markerede rækker var svære at skelne fra tre, der ikke var — en dårlig ting at være i tvivl om lige inden man trykker Slet. **Kopiér-knappen spiste næsten den kode, den skulle kopiere.** Den ligger inde i `<pre>` for at kunne stå i hjørnet af blokken, og `colourCode` læste `pre.textContent` og malede resultatet tilbage — så et klik på "Kopiér" skrev "Kopieret" ind i koden, og næste gemning lagde det i filen. Nu ét sted, der siger hvad en kodeblok indeholder, brugt af både farvelægningen og oversættelsen til Markdown: var de to uenige, ville forskellen ende i noten. Prøven klikker, læser udklipsholderen og læser filen bagefter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
3991ec9445 |
feat(notes): et billede kan indsættes og trækkes ind i en note
Rapporteret fra brug: man kunne ikke indsætte billeder eller trække filer ind i noter. Det passede — importen kunne tage billeder med, og intet andet kunne. Indsætningen tog kun `text/plain` og smed resten væk, og der var slet ingen håndtering af et træk. At indsætte et skærmbillede er det mest almindelige, der findes i et noteprogram, og det gjorde ingenting overhovedet. Der manglede også et sted at lægge filen. Vedhæftninger på en note fandtes i databasen, siden migration 0021, men kun importen kunne skrive dem; der var ingen rute. Nu er der en, med editor-rettigheder på noten og samme svar for "findes ikke" og "ikke din", så et id ikke kan afprøves. Skrevet ind som `` og ikke som en data-URL: en note er Markdown i en database, og et fotografi fra en telefon som base64 midt i teksten ville gøre noten til fire megabyte tekst, der skal læses hver gang listen tegnes. `execCommand` frem for at bygge noden selv, fordi det er dét, der lægger handlingen i browserens egen fortryd-historik — ⌘Z tager billedet ud igen, ligesom det tager et ord ud. `preventDefault` på både dragover og drop. Uden den første kommer der intet drop; uden den anden åbner browseren filen i stedet, og man mister det, man var i gang med at skrive, til en fane med et billede i. Kun filer: et træk inde fra appen selv bærer vores egen nyttelast og skal falde igennem til den, der lyttede. Prøven går begge veje ind, ser at billederne bliver hentet og tegnet, og læser filen bagefter for at sikre, at der står to bilagsadresser og ingen data-URL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
9b4e7686f9 |
feat(notes): datoerne følger med, billederne bliver tegnet, og listen kan sorteres
Release / Build and publish image (push) Failing after 9m54s
Fire ting, som en rigtig import af tolv hundrede noter fandt på en time. **Billederne blev vist som ord.** `markdownToHtml` havde ingen regel for `` overhovedet, så en note fra Apple Noter viste sin egen billedadresse som tekst. Filen var hentet, gemt og hæftet på noten; det eneste, der manglede, var at nogen tegnede den. Kun vores egen adresse bliver til et billede — et `` fra en indsat tekst ville ellers hente fra en fremmed vært, når noten åbnes, og en note er det sidste sted, man vil have en sporingspixel. Og vejen tilbage skulle med: uden `IMG` i inlineToMarkdown ville den første gemning have taget hvert billede ud af noten igen. **Titlen blev revet i stykker.** Noter deler en linje op i så mange stumper, den har brug for — "Aalborg Kommune" står som `<h1>A</h1><h1>alb</h1><h1>org Kom</h1><h1>mune</h1>`, fordi der er en attributkørsel bag hver stump — og eksporten læste et linjeskift ved hver af dem. Noten kom ud som fire overskrifter oven på hinanden, altså ødelagt på den mest synlige måde der findes: i sin egen titel. Samme rod gav `**M****øde**` for fed og `*M**øde*` for kursiv, hvor de to stjerner i midten læses som fed. Nu brydes der kun, når blokken skifter, og et mærke, der lukkes og straks åbnes igen, er ingenting. **Datoerne fandtes ikke.** Eksporten læste dem aldrig, og Markdown havde ingen plads til dem — så en flytning af tolv hundrede noter blev en bunke, der alle var skrevet samme aften. Rækkefølgen er halvdelen af, hvad et arkiv er. Nu står de i et YAML-hoved, som Obsidian og Bear allerede skriver, og importen læser det. `SetNoteTimes` frem for gennem SaveNote: `updated_at` betyder "hvornår skrev *dette* program noten sidst", og lod man enhver kalder sætte den, ville kolonnen betyde det, den sidste skriver havde lyst til. **Og listen kan sorteres** — senest rørt, oprettet, navn. Favoritter står øverst uanset hvad; det er hele meningen med at gøre en note til favorit. Eksporten henter nu i klumper. Ét kald pr. note tog halvanden time for tolv hundrede, ikke fordi Noter er langsom, men fordi hvert kald er en proces, der skal startes — og det gjorde det umuligt at rette en fejl i oversættelsen og se resultatet, for hver runde var en frokostpause. Antallet af bilag kom med i klumpen af samme grund: ni ud af ti kald var en proces startet for at få svaret nul. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
f6c6bdccbb |
fix(notes): projektmenuen står ved det # der bliver skrevet
Den var lagt fast øverst i ruden, med den begrundelse at en menu, der følger markøren, rykker sig et par pixels for hvert bogstav. Det er rigtigt, og det var alligevel forkert: i en note på en skærmfuld skriver man `#` nederst og får en menu i toppen — fire hundrede pixels fra det, øjet ser på, og langt nok væk til at man ikke opdager, at den er der. Begge dele kan lade sig gøre. Positionen måles, når menuen åbner, og ikke igen mens listen snævres ind: den står ved tegnet, og den står stille. Målt på `#term` frem for på markøren, fordi et sammenfaldet område ikke har nogen kasse på en tom linje. Klemt inden for ruden, og vendt op over linjen, når der ikke er plads under — ellers ville en note, der er skrevet helt ned i bunden, lægge menuen uden for skærmen. Og pak-noter-i-portioner.py, fordi en Apple Noter-eksport er hundrede og enoghalvfems megabyte, hvoraf teksten er fire: importen tager 64 MB ad gangen, og tunnelen foran den tager mindre. Delt efter hvad en note vejer med sine billeder, og altid med billederne i samme portion som den note, der peger på dem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
9e687185fb |
feat(notes): vis noten som kode, og giv teksten en margen at ånde i
Release / Build and publish image (push) Failing after 9m59s
Kildevisningen, fordi den rige flade ikke kan tage imod Markdown. Indsat i den er "## Overskrift" fem tegn og ikke en overskrift, og der var ingen vej ind for tekst skrevet et andet sted — hvilket er en mærkelig mangel i et program, hvis hele lager er Markdown. Knappen </> viser filen, som den ligger i databasen, og det, man skriver der, går tilbage gennem den samme oversætter som altid. Fyldt fra kilden og ikke fra note.body, når man går tilbage: gemningen venter på sin pause, så den vej ville kaste det nyeste væk. Og kildevisningen hører til den note, den blev slået til på — skifter man note, er det den rige flade, man møder. Margenerne. Teksten lå helt ude ved kanten, og på en bred skærm blev linjerne hundrede og fyrre tegn — dér mister øjet hvilken linje det var på, når det springer tilbage. Arket har nu marginer, der vokser med ruden, og teksten en grænse på 46rem. Kun teksten: værktøjslinjen og foden hører til ruden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
8229800767 |
fix(notes): lister overlevede ikke en gemning, og tallene blev klippet af
Seks ting fundet ved at bruge appen, i den rækkefølge de gjorde ondt. En liste inde i en blok blev læst som tekst. htmlToMarkdown havde én gren for ul og ol og lod alt andet falde ned i inlineToMarkdown, som samler efterkommere til én streng — så et blokcitat med en liste i kom tilbage som "> PunktPunkt 2", og en note fra Apple Noter, der er fuld af citater, mistede hvert punktmærke ved den første gemning. Ingen havde rørt de linjer. Nu læses en blok, der rummer blokke, igennem frem for flad, og et citat sætter "> " foran det, der kommer indefra. Indlejrede lister fandtes ikke. Den flade `list`-variabel kunne kun beskrive ét niveau, så et indrykket punkt blev lagt ved siden af sit ophav. Nu en stak, og underlisten lægges inde i sit <li> — det er den forskel, der kan læses tilbage. En liste, der begyndte ved ti, begyndte ved ét bagefter. `start` skrives nu med og læses med, så en gemning uden ændringer ikke gør noten om. Tallet blev klippet af. Mærket sættes uden for tekstkanten, og 16px rakte til et punkttegn og ikke til "10." — resten hang ud over kanten, hvor .page beskærer. Renden er nu 2.2em og deles af begge slags, så punkter og tal flugter. # viste seks vilkårlige projekter ud af tyve og så færdig ud. Loftet er væk, listen kan rulle, og det, der begynder med det tastede, står øverst. Og to ting om, hvordan det ser ud. Noteruden har fået sin egen flade, fordi et ark, der holder op et sted, skiller det, man skriver, fra det program, man skriver det i — `--surface` frem for `#fff`, så de fem temaer hver får deres. Noter stod for sig selv over en streg, hvilket sagde det rigtige og kostede halvfjerds pixels; den står nu i rækken med de faste visninger og bærer et ark i stedet for en prik, hvilket siger det samme gratis. Prøven skriver de fem listeformer, gemmer gennem den rigtige editor og læser filen bagefter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
43ad60a84a |
feat(notes): formateringen overlever, og monospace bliver til en terminal
Konverteringen læser nu Apple Noters HTML frem for at flade den ud med textutil. Overskrifter, fed, kursiv, understreget, lister og monospace kommer med. En note er ikke kun sine ord — et referat med overskrifter er ikke det samme referat som en klump — og ti prøvenoter viste hvad det kostede. Skrevet om til Python, fordi HTML skal læses og ikke gættes med regulære udtryk. Den alvorligste fejl, prøvekørslen fandt: navn og krop blev hentet i hvert sit kald, og Noter sorterer listen efter ændringsdato. Flyttede noget sig imellem de to kald, fik en note én titel og en andens indhold. På ti noter er det synligt; på tolv hundrede ville det være ubemærket rod. Der hentes nu ved id, og navn og krop kommer i samme kald. Sammenhængende monospace-linjer bliver til én blok. Hver linje i Noter er pakket ind i sin egen div, hvis starttag tømmer den forrige — så mellem to tt-linjer kom der altid en tom flush forbi, og hver linje i en terminaludskrift blev sin egen blok. Og i editoren ser en kodeblok ud som en terminal: mørk flade, monospace, sproget i hjørnet, farver på strenge, tal, kommentarer, nøgleord og prompten. Monospace ER kode i praksis, og en mørk flade siger det på afstand. Farverne lægges på de blokke, markøren IKKE står i. At farve mens nogen skriver betyder at bygge indholdet om ved hvert tastetryk og sætte markøren tilbage bagefter — det virker ni gange ud af ti og flytter markøren midt i en sætning den tiende. Et API-token er ét ord, der er bredere end skærmen. Uden min-width: 0 skubbede en sådan note hele listen bredere og klemte editoren sammen — på en note, man ikke engang havde åben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
5e670119db |
feat(notes): titlen er første linje, og # foreslår projektet
Release / Build and publish image (push) Failing after 9m59s
Titlen var udledt én gang og derefter ladt i fred, så den gik i stå i det øjeblik nogen skrev begyndelsen om — en note med overskriften "Ny note" stod i listen som "fdgfgfgh", hvilket var, hvad dens første linje havde været nogle rettelser tidligere. Den udledes nu ved hver gemning, og ingen kan sætte den ved siden af teksten: kolonnen er en kopi af kroppen, ikke et felt derudover. Feltet er væk fra både HTTP-fladen og MCP-værktøjerne, for et felt, serveren ignorerer, er et løfte, den ikke kan holde. Skriver man #Kaf, foreslås #Kaffebaren. Ordet læses fra den tekstknude, markøren står i, og ikke fra hele dokumentet — en note kan nævne tyve projekter, og kun det under markøren er ved at blive skrevet. Listen ejer piletasterne og retur, mens den er åben, som enhver anden fuldførelse. Og under feltet står nu, hvad teksten forstår: # projekt, [[en anden note]], ⌘B, ⌘U. Samme idé som linjen under hurtig tilføjelse — en note er det andet sted i programmet, hvor det, man skriver, bliver læst for betydning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
3223989a9d |
feat(notes): første linje er titlen, resten er brødtekst
Release / Build and publish image (push) Failing after 9m57s
En ny note åbner på sin titel, og linjen efter er brødtekst — uden at man vælger noget. Det er det, Apple Notes gør, og det er også hvad listen har brug for: første linje bliver notens navn, så en note, der begynder i brødtekst, hedder sin egen første sætning. To ting undervejs. Reserven for en tom note blev aldrig brugt, fordi en tom tekst ikke gengives som ingenting men som ét tomt afsnit — den prøves nu på teksten og ikke på resultatet. Og Chromium svarer på retur med et bart <div>, som læses som brødtekst men ikke er formateret som det: afstanden mellem afsnit forsvandt stille i det øjeblik, man trykkede retur frem for at vælge Brødtekst i menuen. Listen viste desuden den rå Markdown i forhåndsvisningen — "# Møde med Anders" og "**fed**" — hvilket er præcis det, editoren blev bygget for at holde op med at vise. Den viser nu sætningen frem for notationen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kristian WindandClaude Opus 5
|
1b02eecdab |
feat(notes): rich text, med Apple Notes' egne stilarter
Man skriver nu i formateret tekst frem for i Markdown-kildekode. Titel, Overskrift, Underrubrik, Brødtekst, Monotype, Blokcitat, punkt- og talliste, plus fed, kursiv, understreget og gennemstreget — samme ordforråd som Apple Notes, for det er det, en, der kommer derfra, allerede kan. Filen under er stadig Markdown. Det er ikke et kompromis, nogen skal leve med i stilhed: det er grunden til, at eksporten er til at stole på — filen, en note bliver til, er den fil, den allerede var. Understregning er den ene undtagelse; den findes ikke i noget Markdown-dialekt og gemmes som <u>, som enhver læser sender uændret igennem. Det er bedre end at fjerne en stilart, kilden har. contenteditable med execCommand. Den er forældet og også det eneste, alle browsere er enige om; at skrive en markeringsmodel fra bunden er ugers arbejde og en ny slags fejl netop dér, hvor tabt tekst er utilgiveligt. Tre ting, prøverne fandt, som alle ville have kostet tekst: Værktøjslinjen stjal markeringen, når man klikkede — knapperne tager ikke fokus længere. Browseren skrev <span style="font-weight: normal"> for en ophævet fed, hvilket en oversætter, der læser tags, taber; der bedes nu om tags, og styles læses alligevel, fordi det ikke honoreres alle steder. Og markeringen med Shift+Home tog hele dokumentet, ikke linjen. Favoritter er stjernen på hver note. Noteoversigten har fået luft mod venstre kant, og Gem og Slet er knapper frem for bare ord. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |