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

Dany commented

2026-08-18 18:03:27 +00:00

Describe the bug
When pasting a indented bullet list from another text editor into the ocideck source editor the indentation levels are stripped and all bullets will now live on the same primary level.

To reproduce
Steps to reproduce the behaviour:

Create a text document in another editor with indented bullet lists, for example

Primary bullet level.
- Secondary bullet level.
- Another secondary bullet level.
  - A third bullet level.
  - etc.

Copy the bullet list.
Open ocideck enc choose new document
Choose to see the two-panel markdown editor
Paste from clipboard

Expected behaviour
The indentation levels will remain in the pasted text.

Screenshots / sample deck
If applicable, add screenshots or attach a minimal .md / .ocideck that
triggers the issue.

Environment

OciDeck version: 0.4.5
OS and version: MacOS 26.6.1
Flutter version (flutter --version): n/a install via Brew
Single or dual screen (if presenter-related): n/a

Additional context
The text was copied from the text editor in a Microsoft Copilot Notebook. That behaves like a markdown text editor, sort off. I cannot reproduce the issue on Fedora linux copying and paste from a known proper markdown editor.

For security vulnerabilities, do not open a public issue — see
SECURITY.md.

**Describe the bug** When pasting a indented bullet list from another text editor into the ocideck source editor the indentation levels are stripped and all bullets will now live on the same primary level. **To reproduce** Steps to reproduce the behaviour: 1. Create a text document in another editor with indented bullet lists, for example - Primary bullet level. - Secondary bullet level. - Another secondary bullet level. - A third bullet level. - etc. 2. Copy the bullet list. 3. Open ocideck enc choose new document 4. Choose <source> to see the two-panel markdown editor 4. Paste from clipboard **Expected behaviour** The indentation levels will remain in the pasted text. **Screenshots / sample deck** If applicable, add screenshots or attach a minimal `.md` / `.ocideck` that triggers the issue. **Environment** - OciDeck version: 0.4.5 - OS and version: MacOS 26.6.1 - Flutter version (`flutter --version`): n/a install via Brew - Single or dual screen (if presenter-related): n/a **Additional context** The text was copied from the text editor in a Microsoft Copilot Notebook. That behaves like a markdown text editor, sort off. I cannot reproduce the issue on Fedora linux copying and paste from a known proper markdown editor. > For **security vulnerabilities**, do not open a public issue — see > [SECURITY.md](../../SECURITY.md).

Dany added the

bug

label

2026-08-18 18:03:27 +00:00

brenno added the

needs-info

label

2026-08-18 19:37:45 +00:00

brenno referenced this issue

2026-08-18 19:53:05 +00:00

Documentmodus: een tab-ingesprongen opsomming wordt bij plakken een tabel #1557

brenno referenced this issue

2026-08-18 19:53:25 +00:00

Opsommingseditor knipt het derde niveau van een lijst met 4 spaties inspringing af #1558

brenno commented

2026-08-18 19:54:59 +00:00

Owner

Thanks for the detailed report — including the note that it does not happen from a proper markdown editor on Fedora. That turned out to be the decisive clue.

We checked the source editor's paste path and cannot make the indentation disappear there. Pasting your example keeps the 4- and 8-space indentation exactly: the editor has no paste handling of its own, and the one input filter it does have only acts on single characters. Parsing and rewriting the source is character-stable as well.

What OciDeck receives is the plain-text flavour of the clipboard, and that is all a text field can read. Our reading is that the Copilot Notebook editor puts an already-flattened list in that flavour, so the levels are gone before OciDeck sees them. We cannot confirm that from here.

Could you help us check? Paste the same clipboard content into a plain text editor — TextEdit in plain-text mode, or pbpaste | cat -A in a terminal. If the indentation is missing there, it never reached us. If it is present (as spaces or as tabs), we have a bug and we would like to see that output.

Two related defects did come out of checking this, both tracked separately: a tab-indented list pasted in document mode is mistaken for a table (#1557), and the visual bullet editor collapses the third level of a 4-space-indented list (#1558). Neither matches your steps, but if you were indenting with tabs rather than spaces, #1557 may be what you hit.

Thanks for the detailed report — including the note that it does not happen from a proper markdown editor on Fedora. That turned out to be the decisive clue. We checked the source editor's paste path and cannot make the indentation disappear there. Pasting your example keeps the 4- and 8-space indentation exactly: the editor has no paste handling of its own, and the one input filter it does have only acts on single characters. Parsing and rewriting the source is character-stable as well. What OciDeck receives is the plain-text flavour of the clipboard, and that is all a text field can read. Our reading is that the Copilot Notebook editor puts an already-flattened list in that flavour, so the levels are gone before OciDeck sees them. We cannot confirm that from here. Could you help us check? Paste the same clipboard content into a plain text editor — TextEdit in plain-text mode, or `pbpaste | cat -A` in a terminal. If the indentation is missing there, it never reached us. If it is present (as spaces or as tabs), we have a bug and we would like to see that output. Two related defects did come out of checking this, both tracked separately: a tab-indented list pasted in document mode is mistaken for a table (#1557), and the visual bullet editor collapses the third level of a 4-space-indented list (#1558). Neither matches your steps, but if you were indenting with tabs rather than spaces, #1557 may be what you hit.

brenno referenced this issue

2026-08-18 20:09:58 +00:00

Plakschoonmaak wist betekenisdragende witruimte: U+2009-inspringing en U+2028/29-regelscheiders verdwijnen #1560

brenno referenced this issue

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

Plakschoonmaak trimt de inspringing van de eerste geplakte regel weg #1561

brenno commented

2026-08-18 20:12:48 +00:00

Owner

A correction to our previous answer, and an apology for the premature conclusion.

We tested the wrong editor. The two-panel <source> view you reach from a new document is document mode, and that one does have its own paste handling — the deck source editor we checked does not. Re-testing the right path turned up several defects that can flatten a nested list:

Indentation made of thin spaces (U+2009) is deleted outright, putting every bullet on the primary level — literally what you described. Of eight kinds of space we tested, that is the only one that is discarded (#1560).
U+2028/U+2029 line separators are deleted rather than treated as line breaks, which joins every line into one (#1560).
If your copied selection starts on an indented line, that first line loses its indentation (#1561).
A list where each line happens to contain one comma or semicolon is mistaken for a table (#1557).

Your example with ordinary spaces still comes through intact, so we cannot yet say which of these you hit. The clipboard dump we asked for now answers a much sharper question: pbpaste | hexdump -C | head -20 would show us exactly which characters carry the indentation.

Thanks for pushing on this — the report turned out to be worth considerably more than the one bug it described.

A correction to our previous answer, and an apology for the premature conclusion. We tested the wrong editor. The two-panel `<source>` view you reach from a new document is document mode, and that one *does* have its own paste handling — the deck source editor we checked does not. Re-testing the right path turned up several defects that can flatten a nested list: - Indentation made of thin spaces (U+2009) is deleted outright, putting every bullet on the primary level — literally what you described. Of eight kinds of space we tested, that is the only one that is discarded (#1560). - U+2028/U+2029 line separators are deleted rather than treated as line breaks, which joins every line into one (#1560). - If your copied selection starts on an indented line, that first line loses its indentation (#1561). - A list where each line happens to contain one comma or semicolon is mistaken for a table (#1557). Your example with ordinary spaces still comes through intact, so we cannot yet say which of these you hit. The clipboard dump we asked for now answers a much sharper question: `pbpaste | hexdump -C | head -20` would show us exactly which characters carry the indentation. Thanks for pushing on this — the report turned out to be worth considerably more than the one bug it described.

brenno referenced this issue

2026-08-18 20:27:17 +00:00

fix(plakken): een geplakte opsomming houdt zijn inspringing #1562

brenno referenced this issue from a commit

2026-08-18 20:27:19 +00:00

fix(plakken): een geplakte opsomming houdt zijn inspringing

brenno commented

2026-08-18 20:34:50 +00:00

Owner

An update. Three of the four defects we found are now fixed on main (36bec4a2):

Indentation made of thin spaces (U+2009) is preserved instead of deleted. It still gets stripped mid-sentence, where it really is noise from a web page — but not where it carries the structure of a list (#1560).
U+2028/U+2029 are read as line breaks rather than discarded, so a pasted list no longer collapses onto one line (#1560).
A selection that starts on an indented line keeps that indentation; only blank lines at the edges are trimmed now (#1561).
A list indented with tabs, or one that happens to contain a single comma or semicolon per line, is no longer mistaken for a table (#1557).

Each fix has a test that fails if the fix is removed, and the seven other kinds of space are covered as a counter-check so the repair does not overreach.

We are leaving this issue open, because we still cannot say whether any of these is what you actually hit — your example with ordinary spaces came through intact both before and after. If you can still reproduce it on the next release, the clipboard dump would settle it: pbpaste | hexdump -C | head -20.

An update. Three of the four defects we found are now fixed on main (36bec4a2): - Indentation made of thin spaces (U+2009) is preserved instead of deleted. It still gets stripped mid-sentence, where it really is noise from a web page — but not where it carries the structure of a list (#1560). - U+2028/U+2029 are read as line breaks rather than discarded, so a pasted list no longer collapses onto one line (#1560). - A selection that starts on an indented line keeps that indentation; only blank lines at the edges are trimmed now (#1561). - A list indented with tabs, or one that happens to contain a single comma or semicolon per line, is no longer mistaken for a table (#1557). Each fix has a test that fails if the fix is removed, and the seven other kinds of space are covered as a counter-check so the repair does not overreach. We are leaving this issue open, because we still cannot say whether any of these is what you actually hit — your example with ordinary spaces came through intact both before and after. If you can still reproduce it on the next release, the clipboard dump would settle it: `pbpaste | hexdump -C | head -20`.

brenno commented

2026-08-19 10:01:44 +00:00

Owner

Zeer waarschijnlijk opgelost in 0.4.6.

brenno closed this issue

2026-08-19 10:01:47 +00:00

Dany commented

2026-08-19 19:19:45 +00:00

Author

Even een test gedaan met 0.4.6. Probleem is er nog steeds wanneer ik plak vanuit een Copilot Notebook. Maar het lijkt de manier te zijn waarop Copilot Notebook de tekst aanbied aan de copy API van MacOS, of MacOS die opmaak niet herkent. Onderstaand voorbeeld begint met een H1 (#) op de eerste regel, screenshot van de origineel gekopieerde tekst onderaan bijgevoegd.

pbpaste | hexdump -C | head -20 output

0000000  \n   O   c   i   d   e   c   k       B   u   l   l   e   t
0000010   i   n   d   e   n   t       t   e   s   t  \n   P   l   a   t
0000020   t   e       t   e   k   s   t       h   i   e   r  \n  \n   -
0000030       E   e   r   s   t   e       B   u   l   l   e   t       n
0000040   i   v   e   a   u  \n   -       T   w   e   e   d   e       B
0000050   u   l   l   e   t       n   i   v   e   a   u  \n   -       N
0000060   o   g       e   e   n       k   e   e   r       t   w   e   e
0000070   d   e       B   u   l   l   e   t       n   i   v   e   a   u
0000080  \n   -       D   e   r   d   e       B   u   l   l   e   t
0000090   n   i   v   e   a   u  \n   -       e   n   z   o   v   o   o
00000a0   r   t   s  \n   -       N   o   g       e   e   n   s       e
00000b0   e   n       e   e   r   s   t   e       B   u   l   l   e   t
00000c0       n   i   v   e   a   u       o   m   d   a   t       h   e
00000d0   t       k   a   n   .  \n   N   o   g       w   a   t       m
00000e0   e   e   r       p   l   a   t   t   e       t   e   k   s   t
00000f0   ,       g   e   s   c   h   r   e   v   e   n       o   p
0000100   e   e   n       N   o   t   e   b   o   o   k       p   a   g
0000110   e       i   n       M   3   6   5       C   o   p   i   l   o
0000120   t       N   o   t   e   b   o   o   k   .  \n
000012c

In screenshot:

Even een test gedaan met 0.4.6. Probleem is er nog steeds wanneer ik plak vanuit een Copilot Notebook. Maar het lijkt de manier te zijn waarop Copilot Notebook de tekst aanbied aan de copy API van MacOS, of MacOS die opmaak niet herkent. Onderstaand voorbeeld begint met een H1 (#) op de eerste regel, screenshot van de origineel gekopieerde tekst onderaan bijgevoegd. `pbpaste | hexdump -C | head -20` output ``` 0000000 \n O c i d e c k B u l l e t 0000010 i n d e n t t e s t \n P l a t 0000020 t e t e k s t h i e r \n \n - 0000030 E e r s t e B u l l e t n 0000040 i v e a u \n - T w e e d e B 0000050 u l l e t n i v e a u \n - N 0000060 o g e e n k e e r t w e e 0000070 d e B u l l e t n i v e a u 0000080 \n - D e r d e B u l l e t 0000090 n i v e a u \n - e n z o v o o 00000a0 r t s \n - N o g e e n s e 00000b0 e n e e r s t e B u l l e t 00000c0 n i v e a u o m d a t h e 00000d0 t k a n . \n N o g w a t m 00000e0 e e r p l a t t e t e k s t 00000f0 , g e s c h r e v e n o p 0000100 e e n N o t e b o o k p a g 0000110 e i n M 3 6 5 C o p i l o 0000120 t N o t e b o o k . \n 000012c ``` In screenshot: ![image](/attachments/98b11657-95c5-49da-afd3-a40c026d4574)

image.png

91 KiB

brenno reopened this issue

2026-08-19 19:35:15 +00:00

brenno commented

2026-08-19 20:41:49 +00:00

Owner

Dank voor de dump — die geeft uitsluitsel, en het antwoord is niet het antwoord
dat we hadden gehoopt te geven.

Wat er in je klembord zat. De 300 bytes die je stuurde bevatten geen enkele
inspringing: elke bullet begint op kolom 0 met - , en er staat nergens een
spatie of tab vóór. De # van je H1 ontbreekt ook — "Ocideck Bullet indent
test" staat er als kale tekst. Wat Copilot Notebook op de platte-tekstvariant
van het klembord zet is dus de gerenderde tekst van de pagina, niet de
Markdown-bron ervan. De niveaus zijn weg voordat OciDeck iets ziet.

En we hebben nagerekend dat wij ze niet kwijtmaken. We hebben jouw exacte
klembordinhoud — byte voor byte uit je hexdump gereconstrueerd, alle 300 —
door het plakpad van de documentbroneditor gehaald. Wat eruit komt is
identiek aan wat erin gaat, op de lege regel aan begin en eind na. Geen
inspringing erin, geen inspringing eruit.

Dat betekent dat de vier reparaties uit 0.4.6 jouw geval inderdaad niet konden
raken, en dat er in dit pad niets meer te repareren valt. Het spijt ons dat je
daarvoor twee keer hebt moeten testen.

Wat er wél zou helpen, en waarom het niet klein is. Een webtoepassing als
Copilot Notebook zet meestal méér dan één variant op het klembord: naast platte
tekst ook een HTML-variant, en dáár staat de nesting wel in (<ul><li><ul>…).
OciDeck leest vandaag alleen de platte-tekstvariant — dat is wat een tekstveld
kan. De HTML-variant lezen en naar Markdown omzetten zou jouw geval oplossen, en
meteen elk ander "geplakt vanuit een webeditor"-geval.

Klein is dat niet. Op macOS is die variant voor ons vandaag niet bereikbaar: het
klembordpakket dat we al gebruiken heeft hem alleen op Windows en Android
geïmplementeerd, dus er is platformwerk voor nodig. Daar bovenop komt een
HTML-naar-Markdown-omzetting, en klembord-HTML is invoer van buiten die we
zorgvuldig moeten behandelen.

We nemen dat op als een apart verzoek in plaats van het aan dit bugrapport te
blijven hangen, zodat het niet stil blijft liggen — maar we beloven er nog geen
termijn bij.

Tot die tijd houdt een echte Markdown-bron zijn niveaus wel: exporteren
vanuit Copilot als Markdown, of via een Markdown-editor plakken, komt intact
binnen (zoals je zelf al op Fedora zag).

We sluiten dit rapport als "niet in OciDeck te repareren", niet omdat het geen
echt probleem is. Het heeft ons vier defecten opgeleverd die wél van ons waren
(#1557, #1560, #1561) — dank daarvoor.

Dank voor de dump — die geeft uitsluitsel, en het antwoord is niet het antwoord dat we hadden gehoopt te geven. **Wat er in je klembord zat.** De 300 bytes die je stuurde bevatten geen enkele inspringing: elke bullet begint op kolom 0 met `- `, en er staat nergens een spatie of tab vóór. De `#` van je H1 ontbreekt ook — "Ocideck Bullet indent test" staat er als kale tekst. Wat Copilot Notebook op de platte-tekstvariant van het klembord zet is dus de *gerenderde* tekst van de pagina, niet de Markdown-bron ervan. De niveaus zijn weg voordat OciDeck iets ziet. **En we hebben nagerekend dat wij ze niet kwijtmaken.** We hebben jouw exacte klembordinhoud — byte voor byte uit je hexdump gereconstrueerd, alle 300 — door het plakpad van de documentbroneditor gehaald. Wat eruit komt is identiek aan wat erin gaat, op de lege regel aan begin en eind na. Geen inspringing erin, geen inspringing eruit. Dat betekent dat de vier reparaties uit 0.4.6 jouw geval inderdaad niet konden raken, en dat er in dit pad niets meer te repareren valt. Het spijt ons dat je daarvoor twee keer hebt moeten testen. **Wat er wél zou helpen, en waarom het niet klein is.** Een webtoepassing als Copilot Notebook zet meestal méér dan één variant op het klembord: naast platte tekst ook een HTML-variant, en dáár staat de nesting wel in (`<ul><li><ul>…`). OciDeck leest vandaag alleen de platte-tekstvariant — dat is wat een tekstveld kan. De HTML-variant lezen en naar Markdown omzetten zou jouw geval oplossen, en meteen elk ander "geplakt vanuit een webeditor"-geval. Klein is dat niet. Op macOS is die variant voor ons vandaag niet bereikbaar: het klembordpakket dat we al gebruiken heeft hem alleen op Windows en Android geïmplementeerd, dus er is platformwerk voor nodig. Daar bovenop komt een HTML-naar-Markdown-omzetting, en klembord-HTML is invoer van buiten die we zorgvuldig moeten behandelen. We nemen dat op als een apart verzoek in plaats van het aan dit bugrapport te blijven hangen, zodat het niet stil blijft liggen — maar we beloven er nog geen termijn bij. **Tot die tijd** houdt een echte Markdown-bron zijn niveaus wel: exporteren vanuit Copilot als Markdown, of via een Markdown-editor plakken, komt intact binnen (zoals je zelf al op Fedora zag). We sluiten dit rapport als "niet in OciDeck te repareren", niet omdat het geen echt probleem is. Het heeft ons vier defecten opgeleverd die wél van ons waren (#1557, #1560, #1561) — dank daarvoor.

brenno referenced this issue

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

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

brenno commented

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

Owner

Ter opvolging: het onderliggende verzoek — de HTML-variant van het klembord lezen zodat structuur uit een webeditor bewaard blijft — staat nu apart als #1595, met de bevindingen uit dit rapport als onderbouwing. Dit rapport sluiten we; #1595 draagt het verder.

brenno

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

closed this issue
added
declined
and removed
needs-info
labels

Rows
Columns

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