kristianwindandClaude Opus 5
b18d9a26e6
Retur-handleren udskyder rettelsen ét hak, fordi der før delingen ikke er nogen ny blok at rette. Men rettelsen spurgte, hvor markøren stod *nu*, og et hak er nok: skriver man hurtigt, er næste retur nået igennem først, og så stod markøren i den NÆSTE blok. Så rettede den den — to gange — og lod den blok, rettelsen var ment for, stå tilbage som browserens bare <div>. En <div> læses som brødtekst og er ikke formateret som en, så afstanden mellem afsnit forsvandt stille, hos netop de brugere der skriver hurtigst. Målt frem for gættet: "flere markerede afsnit bliver til én monotypeblok" faldt på en CI-runner med alle tre linjer skrevet rigtigt, hvor "linje et" var en <div> og "linje to" og "linje tre" var <p>. Rettelsen er delt efter hvad der er sikkert at røre: * Der hvor markøren står, gør execCommand det fortsat. Det er den, der lægger ændringen i browserens fortryd-historik, og filen vælger den bevidst andre steder af samme grund — ⌘Z skal tage afsnittet tilbage, ligesom den tager et ord tilbage. * Den blok, delingen lige skabte, får samme regel uden markør at låne. Den dækker overskriften: retur for enden af en overskrift efterlader endnu en overskrift i de fleste browsere. * Og hver <div> i noten bliver fejet op. En <div> er altid browserens egen beholder og aldrig nogens valg, så den kan rettes hvor som helst. En <h1> bliver IKKE fejet: menuen har en Titel-stil, så en overskrift midt i en note kan være en linje, nogen selv har valgt, og den er deres at beholde. Fejning frem for et håndtag til blokken, og det er målt: når den første udskudte rettelse bytter tagget, peger den næstes håndtag på en node uden for dokumentet, og blokken midt i kæden bliver aldrig rettet. Prøven planter to efterladte blokke og er kontrolleret i tre retninger — ingen rettelse: 2 efterladte <div>, håndtag til blokken: 1, fejning: 0. Co-Authored-By: Claude Opus 5 <[email protected]>