Plakken leest alleen platte tekst: structuur uit een webeditor gaat verloren

brenno commented

2026-08-19 20:42:21 +00:00

Owner

Wat er nu gebeurt

Plakken uit een webeditor verliest de structuur van de tekst. OciDeck leest
alleen de platte-tekstvariant van het klembord (Clipboard.kTextPlain), en veel
webtoepassingen zetten daar de gerenderde tekst neer: zonder inspringing,
zonder #, zonder lijstniveaus.

Vastgesteld in #1556 (M365 Copilot Notebook op macOS). De indiener leverde een
pbpaste | hexdump van 300 bytes: elke bullet op kolom 0 met - , geen enkele
spatie of tab ervoor, en de # van zijn H1 ontbrak ook. Diezelfde 300 bytes
door ons plakpad (parseClipboardTable + sanitizeMarkdownPaste) komen er
byte-identiek uit, op de rand-witruimte na. Er valt in dat pad niets te
repareren: de niveaus bestaan al niet meer als wij ze krijgen.

Wat het zou oplossen

Zo'n toepassing zet doorgaans óók een HTML-variant op het klembord, en dáár
staat de nesting wel in (<ul><li><ul>…). Die variant lezen en naar Markdown
omzetten lost niet alleen Copilot Notebook op, maar elk geval van "geplakt
vanuit een webeditor" — een terugkerende klasse, geen randgeval.

Plaats in de keten: de plakvolgorde in document_editor_screen.dart is nu
afbeelding → tabel → platte tekst. De HTML-variant komt er vóór platte tekst
tussen, met platte tekst als val. Eén naad, in de bestaande volgorde.

Wat het kost — de reden dat dit een apart issue is

Platformwerk op macOS. pasteboard: ^0.5.0 staat al in pubspec.yaml en
heeft een html-getter, maar die is alleen op Windows en Android
geïmplementeerd; op macOS, Linux en iOS geeft hij null
(lib/src/pasteboard_platform_io.dart). Voor macOS — het platform waarop dit
gemeld is — moet er dus een NSPasteboard-lezing van
NSPasteboardTypeHTML bij, ofwel als eigen methodekanaal, ofwel als bijdrage
stroomopwaarts. Geen nieuwe afhankelijkheid alsjeblieft: een eigen kanaal
houdt de toeleveringsketen zoals hij is.
Een HTML-naar-Markdown-omzetting. Begrensd houden: koppen, lijsten met
niveau, nadruk, links, code, tabellen. Géén stijlen, géén klassen, géén
ingesloten HTML.
Klembord-HTML is invoer van buiten. Die wordt ontleed naar Markdown,
nooit gerenderd. Er mag geen pad ontstaan waarlangs klembord-HTML bij een
renderer komt; markdown_safety.dart blijft de grens.

Reikwijdte-voorstel

Eerst macOS + de documentbroneditor, achter de bestaande plakvolgorde, met de
platte-tekstvariant als val zodra er geen HTML is of de omzetting niets bruikbaars
oplevert. Windows en Linux daarna, want daar is het gedrag per platform anders
en het is beter één keer goed dan drie keer half.

Toetsing

De omzetting zelf is zuiver en headless, dus tafeltests per constructie:
geneste lijst → inspringing per niveau; kop → #; een <table> → GFM-tabel; en
een tegenproef dat stijl- en klasse-attributen niets opleveren. De
platformlezing zelf valt buiten flutter test — noem dat expliciet in de PR in
plaats van te doen alsof er een test onder zit.

Herkomst

#1556, gemeld door Dany, met de klemborddump die het uitsluitsel gaf. Dat issue
is gesloten als "niet in het plakpad te repareren"; dit is het verzoek dat
eronder bleef liggen.

## Wat er nu gebeurt Plakken uit een webeditor verliest de structuur van de tekst. OciDeck leest alleen de platte-tekstvariant van het klembord (`Clipboard.kTextPlain`), en veel webtoepassingen zetten daar de *gerenderde* tekst neer: zonder inspringing, zonder `#`, zonder lijstniveaus. Vastgesteld in #1556 (M365 Copilot Notebook op macOS). De indiener leverde een `pbpaste | hexdump` van 300 bytes: elke bullet op kolom 0 met `- `, geen enkele spatie of tab ervoor, en de `#` van zijn H1 ontbrak ook. Diezelfde 300 bytes door ons plakpad (`parseClipboardTable` + `sanitizeMarkdownPaste`) komen er byte-identiek uit, op de rand-witruimte na. Er valt in dat pad niets te repareren: de niveaus bestaan al niet meer als wij ze krijgen. ## Wat het zou oplossen Zo'n toepassing zet doorgaans óók een HTML-variant op het klembord, en dáár staat de nesting wel in (`<ul><li><ul>…`). Die variant lezen en naar Markdown omzetten lost niet alleen Copilot Notebook op, maar elk geval van "geplakt vanuit een webeditor" — een terugkerende klasse, geen randgeval. Plaats in de keten: de plakvolgorde in `document_editor_screen.dart` is nu afbeelding → tabel → platte tekst. De HTML-variant komt er vóór platte tekst tussen, met platte tekst als val. Eén naad, in de bestaande volgorde. ## Wat het kost — de reden dat dit een apart issue is 1. **Platformwerk op macOS.** `pasteboard: ^0.5.0` staat al in `pubspec.yaml` en heeft een `html`-getter, maar die is alleen op Windows en Android geïmplementeerd; op macOS, Linux en iOS geeft hij `null` (`lib/src/pasteboard_platform_io.dart`). Voor macOS — het platform waarop dit gemeld is — moet er dus een `NSPasteboard`-lezing van `NSPasteboardTypeHTML` bij, ofwel als eigen methodekanaal, ofwel als bijdrage stroomopwaarts. Geen nieuwe afhankelijkheid alsjeblieft: een eigen kanaal houdt de toeleveringsketen zoals hij is. 2. **Een HTML-naar-Markdown-omzetting.** Begrensd houden: koppen, lijsten met niveau, nadruk, links, code, tabellen. Géén stijlen, géén klassen, géén ingesloten HTML. 3. **Klembord-HTML is invoer van buiten.** Die wordt *ontleed naar Markdown*, nooit gerenderd. Er mag geen pad ontstaan waarlangs klembord-HTML bij een renderer komt; `markdown_safety.dart` blijft de grens. ## Reikwijdte-voorstel Eerst macOS + de documentbroneditor, achter de bestaande plakvolgorde, met de platte-tekstvariant als val zodra er geen HTML is of de omzetting niets bruikbaars oplevert. Windows en Linux daarna, want daar is het gedrag per platform anders en het is beter één keer goed dan drie keer half. ## Toetsing De omzetting zelf is zuiver en headless, dus tafeltests per constructie: geneste lijst → inspringing per niveau; kop → `#`; een `<table>` → GFM-tabel; en een tegenproef dat stijl- en klasse-attributen niets opleveren. De platformlezing zelf valt buiten `flutter test` — noem dat expliciet in de PR in plaats van te doen alsof er een test onder zit. ## Herkomst #1556, gemeld door Dany, met de klemborddump die het uitsluitsel gaf. Dat issue is gesloten als "niet in het plakpad te repareren"; dit is het verzoek dat eronder bleef liggen.

brenno added the

enhancement

label

2026-08-19 20:42:21 +00:00

brenno referenced this issue

2026-08-19 20:42:28 +00:00

[Bug] Indented bullet lists lose indents when pasting into the source editor #1556

brenno added the

in-progress

label

2026-08-20 18:39:22 +00:00

brenno commented

2026-08-20 18:39:22 +00:00

Author

Owner

Opgepakt. Tak: feat/clipboard-html-paste. Verwachte reikwijdte: native HTML-lezing op macOS (methodekanaal), html-naar-Markdown-omzetting, de bestaande plakvolgorde in de documentbroneditor. Geen nieuwe klembordaflankelijkheid.

brenno referenced this issue from a pull request that will close it,

2026-08-20 19:10:55 +00:00

Plakken houdt structuur uit webeditor-HTML (#1595) #1622

brenno referenced this issue from a commit

2026-08-20 19:25:22 +00:00

Merge pull request 'Plakken houdt structuur uit webeditor-HTML (#1595)' (#1622) from feat/clipboard-html-paste into main

brenno closed this issue

2026-08-20 19:25:22 +00:00

brenno commented

2026-08-20 19:25:29 +00:00

Author

Owner

Op main in 2d3c373d9a. HTML-variant van het klembord wordt gelezen (macOS/Windows/Linux/web) en naar Markdown omgezet; de HTML zelf wordt niet gerenderd. Native NSPasteboard/GTK-lezing valt buiten flutter test. Niet in: iOS/Android.

Op main in 2d3c373d9a8335099585df301142414b2f06ab96. HTML-variant van het klembord wordt gelezen (macOS/Windows/Linux/web) en naar Markdown omgezet; de HTML zelf wordt niet gerenderd. Native NSPasteboard/GTK-lezing valt buiten flutter test. Niet in: iOS/Android.

Rows
Columns

Plakken leest alleen platte tekst: structuur uit een webeditor gaat verloren #1595

Wat er nu gebeurt

Wat het zou oplossen

Wat het kost — de reden dat dit een apart issue is

Reikwijdte-voorstel

Toetsing

Herkomst