LibreOffice Writer krijgt ondersteuning voor Markdown-opmaaktaal

LibreOffice Writer voegt in de toekomst ondersteuning toe voor de Markdown-opmaaktaal. De ontwikkelaars werken aan de mogelijkheid om Markdown-bestanden zowel te importeren als te exporteren. Daarvoor zit nog geen ondersteuning in LibreOffice 25.8, dat in augustus uitkomt.

Ontwikkelaars hebben twee aparte commits op de LibreOffice-repository aangemaakt voor het importeren van Markdown-bestanden in Writer en het exporteren van Markdown-bestanden uit Writer. Beide functies resulteren nu nog in een leeg document. In juni werd ook een commit aan de git van LibreOffice toegevoegd om de MD4C-bibliotheek toe te voegen aan LibreOffice. MD4C is een in C geschreven parser voor Markdown-bestanden, die nodig is om de import- en exportfuncties te laten werken.

Op maandag is ook een commit gemaakt om ondersteuning voor Markdown-opmaak toe te voegen aan LibreOffice Writer. Zo kunnen teksten die in Markdown zijn geschreven daadwerkelijk worden omgezet naar de juiste opmaak in Writer. Alle commits zijn inmiddels opgenomen in de masterbranch van LibreOffice. Het is nog niet zeker of de functie beschikbaar komt in versie 26.2 van het programma, die volgend jaar uitkomt.

Markdown is een opmaaktaal die in 2004 geïntroduceerd is door John Gruber. Met Markdown kunnen gebruikers opgemaakte tekst maken met een editor voor platte tekst. Het doel is dat teksten in Markdown makkelijk in gebruik zijn en ook leesbaar zonder opmaak. In tegenstelling tot bijvoorbeeld HTML-code maakt 'platte' Markdown-tekst weinig gebruik van zichtbare tags en opmaakinstructies.

Reacties (49)

[Memori]

Ik heb nooit begrepen waarom je voor markdown twee spaties aan het einde van je zin moet zetten voor het creëren van een nieuwe paragraaf, en hetzelfde op een lege regel voor een nieuwe alinea. Een enter (\n of \r\n) is perfect te interpreteren in zowel input op de computer, als menselijk. Dit vind ik zelf echt het domste filosofie waarvoor ze gekozen hebben.

[GertMenkel]

Ik vind het juist handig. Zo kun je een alinea doortypen zonder word breaks in je editor te hoeven hebben. HTML en Latex doen hetzelfde, je moet ze met semantische informatie zoals een <br /> of een </p> aangeven dat je van de ene alinea naar de volgende gaat.

Je vertelt Markdown welke tekst je hebt en hoe die gestructureerd is, en Markdown geeft het voor je vorm. Door twee spaties te zetten vertel je Markdown de semantiek van je regelafbreking, en door twee enters te zetten vertel je Markdown de semantiek van je alineascheiding.

[Ablaze]

Echter een Enter genereert een newline karakter en onder Windows daarnaast een carriage return. Daar zou je van verwachten dat ze doen waar ze naar genoemd zijn.

[mr.paaJ]

Twee spaties en enter aan het einde is alleen een nieuwe regel toch?

Twee enters is nieuwe paragraaf

[SPee]

Ik begin nu een beetje te begrijpen waarom een collega dat in Word (!) doet. Een loze spatie aan het eind van elke paragraaf .

En als je tekst wijzigt dan moet je weer die dubbele spaties eruit vissen. Lekker bezig!

[Reactie gewijzigd door SPee op 8 juli 2025 16:35]

[Zeror]

Find and replace > Als invoer dubbele spatie > als uitvoer niks > OK op alles toepassen. En klaar. Alle dubbele spaties zijn weg. 5 seconden werk.

[Oon]

Heb je daar last van dan? Het hele idee van spaties is toch juist dat ze onzichtbaar zijn?

[StefanJanssen]

Het hangt er ook vanaf welke Markdown standaard je gebruikt.

[bwerg]

Of beter gezergd: markdown is geen standaard. Er zijn tig implementaties die op elkaar lijken maar allemaal verschillen hebben. "Markdown" is een verzameling implementaties. Commonmark komt het dichtste bij een standaard in de buurt, omdat het daadwerkelijk poogt om volledig te zijn, gebaseerd op zinnige design-keuzes, daar waar markdown-implementaties verschillende resultaten geven.

[GeroldM]

Dat was bij ons de reden om dan maar AsciiDoc te gaan gebruiken. Daar is namelijk maar 1 standaard, en vind deze beter/prettiger om mee te werken dan MarkDown.


Totdat ik de xWiki opmaak tegenkwam. Deze vind ik nog leesbaarder (source mode) dan AsciiDoc, en de editor van xWiki (in opmaak mode) laat je rechtstreeks werken zodat het lijkt alsof je met een online Wordpad werkt. Een opgevoerde versie, want je kan deze gewoon gebruiken voor het importeren/exporteren van RTF, PDF en zelfs Presentaties.

Daarnaast heb ik er een hekel aan dat je met MarkDown en AsciiDoc niet rechtstreeks in de gerenderde weergave kan werken en je dus (soms) 2 windows in je scherm moet openen om te zie of je inhoud van het tekstuele scherm correct blijft renderen in het renderscherm. AsciiDoc is niet anders in dit aspect. xWiki is dat wel.

[aikebah]

Daarnaast heb ik er een hekel aan dat je met MarkDown en AsciiDoc niet rechtstreeks in de gerenderde weergave kan werken en je dus (soms) 2 windows in je scherm moet openen om te zie of je inhoud van het tekstuele scherm correct blijft renderen in het renderscherm. AsciiDoc is niet anders in dit aspect. xWiki is dat wel.

Dat zit m echter niet in de opmaaktaal, maar in je keuze van edit tool. Als ik even op google kijk bestaan er ook wel wysiwyg-editors voor markdown.

Zelf code ik met alle liefde in plaintext (maar goed, ik ben dan ook zo'n nerd die vroeger de HTML spec erbij pakte en alle HTML in de teksteditor inklopte en de wysiwyg HTML editors links liet liggen... leverde veel cleanere website code op dan de bagger die op de vele met Frontpage gemaakte sites te vinden was).

Goed geschreven markdown/asciidoc heeft niet per se een gerenderde versie nodig, die leest al prima. Daar zijn de formaten juist voor ontworpen: iets dat in plaintext goed leesbaar is (en goed in delta-gebaseerd versiebeheer versioneerbaar is) voor techneuten en met software naar een visueel goed smoelende rendering over te zetten is voor de massa.

Mijn edits van gitlab/github flavored markdown gaan over het algemeen in een fullscreen text edit window.

[martijnvanegdom]

Dat heeft te maken dat niet iedere tekst editor netjes een word wrap doet als deze langer is dan 80 karakters (of 100, 120..). Door een enter niet te interpeteren als een nieuwe regel kun je er voor zorgen dat je in alle editors leesbare tekstbestanden hebt en dat het bestand altijd netjes gerendeerd word naar html.

Ik ben het met je eens dat het een drama is, omdat je de twee spaties lang niet altijd ziet. Een dubbele enter is wat ik altijd gebruik,

[84hannes]

Dat heeft te maken dat niet iedere tekst editor netjes een word wrap doet als deze langer is dan 80 karakters (of 100, 120..).

Als je Git (of een alternatief) gebruikt en tools als diff, blame en merge wilt gebruiken, dan zijn korte regels een stuk makkelijker dan lange regels. Ik probeer dus ook als mijn teksteditor wrapped zinnen van max 100 tekens te typen. Dat navigeert ook veel lekkerder (je kan met teksteditors heel makkelijk naar een specifiek regelnummer springen).

Vertrouwen op de uitlijning van je editor is meer iets voor wysiwyg-tools, zoals Word/LibereOffice/InDesign. Ongebruikelijk in markup-talen.

[Reactie gewijzigd door 84hannes op 8 juli 2025 19:20]

[deadinspace]

Als je Git (of een alternatief) gebruikt en tools als diff, blame en merge wilt gebruiken ...

Ik gebruik in Markdown en LaTeX source zoveel mogelijk één zin per regel, dat werkt erg goed samen met dergelijke vcs / text tooling! Een diff bevat dan alleen de zinnen die gewijzigd/toegevoegd/verwijderd zijn, en geen ongerelateerde zinnen.

[deadinspace]

Ik heb nooit begrepen waarom je voor markdown twee spaties aan het einde van je zin moet zetten voor het creëren van een nieuwe paragraaf, en hetzelfde op een lege regel voor een nieuwe alinea.

Huh? Dat is geen paragraaf. Een paragraaf is het kleinste stuk tekst wat nog zijn eigen nummer/index heeft, en bestaat uit één of meer alinea's (één of meer zinnen gescheiden door een witregel of door inspringing).

Een paragraaf maak je in Markdown met: #### Paragraaftitel

Een alinea maak je in Markdown met een lege regel in je tekst (wat visueel ook overeenkomt met hoe alinea's vaak uiteindelijk getoond worden).

Twee spaties aan het einde van een regel gebruik je in Markdown om binnen een alinea gedwongen naar een nieuwe regel te gaan. Dit is geen alinea of paragraaf. Het is ook iets dat je maar zelden nodig hebt.

[EraYaN]

In deze is het een <p> als je een lege regel hebt en een <br> voor de line break (twee spaties aan het einde van de regel). Dus wat jij daar een alinea noemt is wel gewoon een HTML paragraph element.

En '#### <tekst>' wordt gewoon een <h4>, <h5> en <h6> bestaan ook gewoon nog.

[deadinspace]

Dus wat jij daar een alinea noemt is wel gewoon een HTML paragraph element.

Paragraph is het Engelse woord voor alinea (en nee, niet voor paragraaf), dus dat klopt wel ja.

En '#### <tekst>' wordt gewoon een <h4>

En als h4 de kleinste heading in je document is, dan is dat een paragraaftitel.

<h5> en <h6> bestaan ook gewoon nog.

Fair enough, daar was ik wat kort door de bocht. Het gaat om het kleinste element in je document.

Overigens zie ik h4 en h5 maar zelden gebruikt worden in de praktijk, maar dat terzijde.

[Reactie gewijzigd door deadinspace op 9 juli 2025 11:41]

[MiKE_B]

Die twee spaties zijn alleen nodig als je expliciete regelafbreking wilt. Het is 'nodig' omdat markdown anders denkt dat je in dezelfde paragraaf aan het typen bent, voor 'reflow' van tekst. Voor een nieuwe paragraaf hoef je alleen maar twee keer enter te drukken.

Ik schrijf best veel Markdown en gebruik nooit die twee spaties aan het einde van de regel; ik zou niet zo snel weten wanneer je dat zou willen gebruiken terwijl alternatieven (code blocks of nieuwe alinea's) niet afdoende zijn.

[bwerg]

Als je dat nooit begrepen hebt had je gewoon de documentatie moeten lezen, want het antwoord op je vraag staat er sinds 2004 toch al vrij duidelijk, expliciet en vindbaar in.

Yes, this takes a tad more effort to create a <br />, but a simplistic “every line break is a <br />” rule wouldn’t work for Markdown. Markdown’s email-style blockquoting and multi-paragraph list items work best — and look better — when you format them with hard breaks.

Naast de redenen die andere tweakers al noemen heb ik er nog wel eentje: opmaaktalen "in platte tekst" (markdown, maar ook bijvoorbeeld latex) zijn perfect om te gebruiken in versiebeheersystemen als git. En als je paragrafen zonder newlines in de source code zet is dat een drama, twee wijzigingen in dezelfde alinea worden door git gezien als conflicterend. Elke zin op een eigen newline is dan een erg prettige conventie, en dan is het wel fijn als de resulterende opmaak daar niet allemaal losse paragrafen van maakt.

Iemand anders noemt een 'hard line wrap' waar iemand gewoon enters toevoegt (of zijn tekst-editor dat laat doen) in plaats van het line-wrappen over te laten aan de text-viewer, dat is trouwens nog een veel groter drama in git. Continu edits en merge-conflicts omdat de viewer de newlines weer alle kanten op heeft verplaatst puur omdat iemand nog in een viewer uit 1990 werkt, bedankt man.

[Reactie gewijzigd door bwerg op 8 juli 2025 16:30]

[The Zep Man]

Zo kunnen teksten die in Markdown zijn geschreven daadwerkelijk worden omgezet naar de juiste opmaak in Writer.

Dit gecombineerd met de exportfunctie kan LibreOffice een goed pakket maken om notities van het één naar het ander om te zetten met veel minder handwerk voor de opmaak. Als je nog oude notities met opmaak in bijvoorbeeld ee OneNote-achtig iets hebt, dan is een copy+paste + opslaan in LibreOffice wellicht de makkelijkste weg om deze conversie uit te voeren.

Dit zal zich op een dag terugvinden in Collabora Online. Dan is er geen aparte Markdown editor meer nodig in Nextcloud.

Een recent stukje over de toegenomen populariteit van Markdown.

[Reactie gewijzigd door The Zep Man op 8 juli 2025 14:19]

[Mars Warrior]

Ik verwacht daar nog wel wat hobbels: immers er zijn een ziljoen Markdown extenties om markdown bruikbaar te maken voor een beetje fatsoenlijke opmaak.

Het zou mooier zijn dat je gewoon tekst typed, en dat dit onderhuids wordt omgezet naar Markdown + de hele berg extenties.

Veel simpele dingen kunnen niet in plain markdown. Voor opmaak is het vaak enorm veel werk, waarbij spaties en <cr> tellen soms een must is om tot het gewenste resultaat te komen.

Terug naar de jaren 90

[The Zep Man]

Ik verwacht daar nog wel wat hobbels: immers er zijn een ziljoen Markdown extenties om markdown bruikbaar te maken voor een beetje fatsoenlijke opmaak.

Markdown gaat juist niet over opmaak. Dat is aan de interpreter om te bepalen.

Het zou mooier zijn dat je gewoon tekst typed, en dat dit onderhuids wordt omgezet naar Markdown + de hele berg extenties.

Dat is de omgekeerde wereld en niet waar Markdown voor bedoeld is. Er zijn wel editors die dit ondersteunen.

Veel simpele dingen kunnen niet in plain markdown. Voor opmaak is het vaak enorm veel werk,

Opmaak doe je dan ook niet in Markdown. Je geeft tekstkarakteristieken aan zoals dat deze tekst onderlijnd is, maar je geeft niet aan hoe het onderlijnen eruit ziet (zoals de hoogte en dikte van de streep, in welk lettertype de tekst getoond wordt, hoe groot de tekst is, etc.).

Markdown is geen exclusieve taal. Op sites zie je dan ook wel eens dat zowel Markdown als plain HTML ondersteund wordt voor zaken die missen. Markdown concentreert zich op inhoud. Andere talen (die je er soms mee kan mixen, naargelang de editor en interpreter) bekommeren zich (ook) om opmaak.

[Reactie gewijzigd door The Zep Man op 9 juli 2025 08:36]

[SPee]

Markdown gaat juist niet over opmaak. Dat is aan de interpreter om op te pakken.

Dat is niet helemaal juist. Met tabellen moet je bijvoorbeeld wel bezig houden met de opmaak. Of het wordt zo onleesbaar dat je weer een editor of viewer nodig hebt om het goed weer te geven. En daar was Markdown ook niet voor bedoeld.

Een simpele taal om opmaak mee te geven aan plain tekst. Hoofdstukken, paragrafen, bold, italic, onderlijnd. Meer zou het niet moeten doen. Maar nu gaan we een hele teksteditor gebruiken.

Misschien wordt dat iets teveel voor het originele doel. Keep It Simple of gebruik een ander formaat!

[The Zep Man]

Dat is niet helemaal juist. Met tabellen moet je bijvoorbeeld wel bezig houden met de opmaak.

Met het definiëren van een tabel in Markdown(-extensies) ben je bezig met de inhoud en de structuur. Niet de opmaak.

Inhoud: inhoud van een cel (tekst).
Structuur: de cel staat op de bovenste rij in de derde kolom.
Opmaak: celrand is groen en heeft lijndikte 2.

[Reactie gewijzigd door The Zep Man op 8 juli 2025 17:35]

[bzuidgeest]

Ik zie problemen hiermee. Libreoffice of eigenlijk elk office pakket kan veel meer opmaak specificeren dan markdown kan. En welke van de extensies gaan ze ondersteunen?

Voor zover ik het begrijp is het gebruik van markdown, iets dat bedoelt was voor simpele notities, helemaal uit zijn krachten aan het groeien.

[The Zep Man]

Ik zie problemen hiermee. Libreoffice of eigenlijk elk office pakket kan veel meer opmaak specificeren dan markdown kan.

Dat geldt ook voor een aantal andere formaten. Dan krijg je gewoon een dialoog dat aangeeft dat je probeert op te slaan in een suboptimaal formaat waarin opmaak verloren kan gaan. Lijkt mij niets mis mee.

Voor zover ik het begrijp is het gebruik van markdown, iets dat bedoelt was voor simpele notities, helemaal uit zijn krachten aan het groeien.

Markdown lijkt mij geschikt voor bijvoorbeeld boekschrijvers. Je kan toch gestructureerd zaken als hoofdstukken en tekstkarakteristieken (dit moet vet zijn, dit moet onderlijnd zijn, etc.) aangeven zonder dat je je zorgen hoeft te maken over opmaak. Dat is wel fijn als je puur schrijft.

Markdown is bijvoorbeeld ideaal om inhoud voor websites in te schrijven, inclusief lange artikelen. Voor de inhoud boeit de uiteindelijke opmaak niet. Dat wordt elders gedefinieerd. Inhoud is inhoud, en daardoor achteraf makkelijk aan te passen of om te zetten naar nieuwe opmaak.

[Reactie gewijzigd door The Zep Man op 8 juli 2025 15:05]

[bzuidgeest]

Inhoud is inhoud, en daardoor achteraf makkelijk aan te passen of om te zetten naar nieuwe opmaak.

En daar is markdown goed voor. Zeker. Ik heb niets principieels tegen markdown.

Dat geldt ook voor een aantal andere formaten. Dan krijg je gewoon een dialoog dat aangeeft dat je probeert op te slaan in een suboptimaal formaat waarin opmaak verloren kan gaan. Lijkt mij niets mis mee.

Ja, maar als je opslaat naar kale tekst verlies je alles. Als je opslaat naar markdown.... wat blijft er behouden, wat niet? Is er ondersteuning voor mermaid (diagrammen) of syntax colloring etc... Door welke extensions? En dan is er nog dat markdown weergave word bepaald door de eindbestemming zoals jij in ze voorbeelden aangeeft. Prima voor een boek, maar minder handig voor office documenten denk ik.

Markdown is niet bepaald een vastgelegde iso standaard of zo. Geen vast format. Er zijn zelfs verschillende variaties van. Ik denk dat ik liever een goede markdown editor zie dan markdown editing in een pakket dat zo ver van markdown zijn doel af staat.

[The Zep Man]

Ja, maar als je opslaat naar kale tekst verlies je alles. Als je opslaat naar markdown.... wat blijft er behouden, wat niet? Is er ondersteuning voor mermaid (diagrammen) of syntax colloring etc...

Syntax coloring wordt bepaald door de interpreter en is geen onderdeel van het formaat zelf.

Prima voor een boek, maar minder handig voor office documenten denk ik.

In de meeste organisaties zijn er (vaak brak geïmplementeerde) standaardsjablonen voor interne kantoordocumenten. Veel zaken zouden prima in Markdown geschreven kunnen worden. Dan kan je documenten achteraf makkelijk omzetten naar een nieuw sjabloon.

Ik denk dat ik liever een goede markdown editor zie dan markdown editing in een pakket dat zo ver van markdown zijn doel af staat.

Het één hoeft het ander niet uit te sluiten. Wellicht krijgt LibreOffice een "Markdown mode". Zo niet, dan kan je dit ook meer zien als een converter die een groot deel van het werk doet.

Ik hoor veel mensen klagen over dat Markdown geen standaard is. Terecht commentaar, maar het is niet iets waar de meeste personen die Markdown dagelijks gebruiken echt over struikelen. Die personen zijn meer bezig met de inhoud van tekst en minder met opmaak en wat waar exact moet staan ("typesetting"). Dat een aantal exotische extensies soms wel en soms niet ondersteund worden is geen factor voor (ik schat) 95% van de gebruikers.

[Reactie gewijzigd door The Zep Man op 8 juli 2025 16:06]

[SPee]

Syntax coloring wordt bepaald door de interpreter en is geen onderdeel van het formaat zelf.

Voor Markdown is er vaak geen coloring mogelijk. Maar in LibreOffice Writer wél. Dus wordt er een output formaat gebruikt die dat ook op een bepaalde manier ondersteund?

Er zijn wel meer punten van aandacht voor de conversie. Wat is de gebruikte regellengte? Gaat het alles per paragraaf in één regel zetten? Of wordt het op een (arbitraire) lengte afgekapt?
En hoe zit het met tabellen? En (naamgeving van) plaatjes?

[The Zep Man]

Voor Markdown is er vaak geen coloring mogelijk. Maar in LibreOffice Writer wél. Dus wordt er een output formaat gebruikt die dat ook op een bepaalde manier ondersteund?

Nee. Die informatie gaat verloren wanneer je naar Markdown converteert. Hetzelfde als dat bepaalde opmaakinformatie verloren gaat als je naar andere formaten anders dan ODF converteert.

[bzuidgeest]

Ik denk dat de gebruikers waar je het over hebt ook geen libre office gaan gebruiken voor hun werk. Omdat ze zich bezighouden met inhoud en niet design zijn ze eenvoudiger uit met een gespecialiseerde editor die ze al hebben.

Libreoffcie is een wysiwyg editor. Het is het tegenovergesteld van markdown. En als je een conversie goed veel doen op een manier die geen problemen oplevert is format afspraken heel belangrijk.

Je kan van png naar gif converteren, er is maar 1 officiele defintie van gif. Er is verlies maar iedereen weet wat omdat het format vast staat. Echter bij markdown weet niemand welke versie je volgt, welke eventuele extensies etc. Dus kan niemand van je export op aan. Dat is problematisch.

[Bux666]

Markdown lijkt mij geschikt voor bijvoorbeeld boekschrijvers. Je kan toch gestructureerd zaken als hoofdstukken en tekstkarakteristieken (dit moet vet zijn, dit moet onderlijnd zijn, etc.) aangeven zonder dat je je zorgen hoeft te maken over opmaak. Dat is wel fijn als je puur schrijft.

Daar bestaat al jaren (meer dan 40 jaar!) LaTeX voor. Dat wordt veel gebruikt in de wetenschappelijke wereld maar kan ook prima voor leesboeken gebruikt worden.

Markdown is daarmee vergeleken niet veel nieuws...

[The Zep Man]

Daar bestaat al jaren (meer dan 40 jaar!) LaTeX voor.

Ik ken LaTeX goed. Een atechnische gebruiker zou ik nooit LaTeX aandoen. De taal is brak en heeft ook iets van 40 jaar effectief stilgestaan. Maak een fout in de syntax en je krijgt een foutmelding die in de verste verte niets met de fout te maken heeft.

[Reactie gewijzigd door The Zep Man op 8 juli 2025 16:02]

[84hannes]

Ik ken LaTeX goed. Een atechnische gebruiker zou ik nooit LaTeX aandoen. De taal is brak en heeft ook iets van 40 jaar effectief stil gestaan.

Totaal offtopic, maar ik kan typst aanbevelen. Het combineert de kracht van LaTeX met de eenvoud van Markdown; een eenvoudig document kun je net als Markdown simpel schrijven, maar met een beetje moeite (minder dan LaTeX, maar het helpt als je software kunt ontwikkelen) kun je alle kanten op met de opmaak.

[youridv1]

Nog nooit een latex gebruiker ontmoet die het niet 4x per minuut vervloekt iedere keer dat hij daadwerkelijk iets moet schrijven erin.

Het is de standaard voor wetenschappelijke literatuur, maar dat is ook een beetje weerstand tegen verandering

[Reactie gewijzigd door youridv1 op 8 juli 2025 17:09]

[84hannes]

Het is de standaard voor wetenschappelijke literatuur, maar dat is ook een beetje weerstand tegen verandering

Er was ook nooit een alternatief. HTML is heel geschikt als je niets geeft om hoe het weergegeven wordt, Markdown te beperkt. Pas sinds typst heb ik een waardige opvolger gevonden.

[mbb]

Tekstverwerkers hebben daarvoor toch al decennia templates/profielen(Libreoffce )/ sjablonen (Word) voor?

En WordPerfect had een ' onderwater modus' waarin je kon werken. Lijkt me nuttiger dan Markdown - is een soort heruitvinding van BB-code, of HTML-light?

[jaenster]

Markdown is fantastisch maar ik merk wel dat iedereen het net anders implementeert, wat soms markdown beetje gaar maakt

[Llopigat]

Ja en het is vooral in een enkele niche echt populair, de ontwikkelaars (ook vanwege de .md files in github die het formaat hebben aangezwengeld).

Hierdoor zijn heel veel notetaking apps helemaal gek van MD omdat juist een personal knowledgebase voor die soorten functies erg belangrijk is.

Ik vind zelf markdown niet zo fijn omdat het tussen WYSIWYG en rauwe tekst in zit. De meeste apps ervoor hebben 2 representaties naast elkaar: eentje met de brontekst en een met de gerenderde. Dit vind ik enorm onhandig en verkwistend. Maar niet elke app gelukkig, zoals de notetaking app Obsidian die ik gebruik. Dan heb ik een stuk minder bezwaren tegen markdown.

[Reactie gewijzigd door Llopigat op 8 juli 2025 15:50]

[SPee]

Het is door ontwikkelaars omarmt, omdat je hierdoor een beetje markup kunt toevoegen aan simpele tekstbestanden. Die bestanden kun je in elke console of editor openen en bekijken en makkelijk een diff van maken.

Maar het is nu helemaal "Markdown goes wild!" geworden en gaat zijn doel voorbij. Als je echt complexere functionaliteit nodig hebt, dan moet je een ander type gebruiken die dat allemaal ondersteund. Bijvoorbeeld HTML of XML.

[The Zep Man]

Klopt. Markdown schittert in plain text, omdat de inhoud en structuur makkelijk te interpreteren is als mens. Zelfs zonder interpreter is een document in Markdown leesbaar.

[Reactie gewijzigd door The Zep Man op 9 juli 2025 06:29]

[The Zep Man]

Ik vind zelf markdown niet zo fijn omdat het tussen WYSIWYG en rauwe tekst in zit. De meeste apps ervoor hebben 2 representaties naast elkaar: eentje met de brontekst en een met de gerenderde. Dit vind ik enorm onhandig en verkwistend. Maar niet elke app gelukkig, zoals de notetaking app Obsidian die ik gebruik. Dan heb ik een stuk minder bezwaren tegen markdown.

Kijk eens naar de online editor Outline als je zoiets zoekt. Die heeft iets soortgelijks dat per regel Markdown wordt omgezet in WYSIWYG terwijl het op de achtergrond alsnog Markdown blijft. Er zullen ook wel andere soortgelijke editors zijn.

[Reactie gewijzigd door The Zep Man op 9 juli 2025 06:26]

[V_J]

Nu nog de markdown toelaten in de editor, en we gaan terug richting WordPerfect 5.1, waar een split-screen je ook toeliet om markup-codes te zien. :-)

[Soldaatje]

Ik moest even opzoeken wat je bedoelt. Mooi dat dat toen al bestond!

edit:
Link gemaakt.

[Reactie gewijzigd door Soldaatje op 9 juli 2025 06:05]

[V_J]

WordPerfect 6 en latere versies hadden een wysiwyg editor, maar nog steeds met de mogelijkheid om die markup codes te zien in een apart deel van de editor. Je kon perfect zien waar een bepaald font startte, waar een harde/zachte spatie stond, e.d. Je kon in dat mark-up venster tekst selecteren: zo kon je zelf beslissen of je vb. een start van een code (onderlijnen, italic, of ander font) mee nam in je selectie of niet. Je kon ook gewoon een mark-up code verwijderen, kopiëren of invoegen als ware het normale karakters (al bij al was het wat zoals LaTeX). Het gebrek aan die functionaliteit was iets waar ik lang heb aan moeten wennen bij Word.

[trab_78]

Als zelfs LibreOffice het gaat ondersteunen, kan Tweakers natuurlijk niet achterblijven! Ik zeg: Markdown in de editor, here we go!

[beerse]

Voor LibreOffice en de ondersteuning van mark-down zie ik meerdere mogelijkheden:

Om te beginnen zou ik een bestaande tekst wel als mark-down willen exporteren zodat het in een andere tool als markdown kan worden ingevoerd. Dat wordt dan een export-functie naast pdf en epub en zo.

Daarnaast zou ik een bestaand markdown willen kunnen inlezen (openen, imorteren) zodat het in het huidige document als zodanig wordt ingevoerd en opgemaakt. Niet alleen in writer maar ook in de tekst-velden van andere onderdelen.

En uiteindelijk zou ik de tekst-invoer op 'markdown' willen kunnen zetten, zodat ik markdown kan typen en dat het dan als een normaal libreoffice document wordt opgemaakt. Deze functie zal dan in zo ongeveer alle andere LibreOffice onderdelen gebruikt kunnen worden. Gewoon naast de huidige tekst invoer mogelijkheden.

[toevoeging]: Naast de invoer met markdown zou ook een copy-mogelijkheid handig kunnen zijn: Dat tekst in LO geselecteerd wordt en dan als markdown in het copy-paste buffer komt. Handig voor copy-paste naar websites die het kunnen behappen.

Daarbij zou ik (eventueel voor alle varianten apart) een eigen markdown tabel willen kunnen instellen. Dan kan ik daarmee libre office eventueel als markdonw-converter of markdown-merge tool gebruiken. Met verschillende tabellen (of modules of extenties of hoe je dat gaat noemen) kan je daar dan ook verschillende markdown varianten behappen.

Zomaar wat gedachten rond LibreOffice en MarkDown. Toegegeven, ik heb hiervoor alleen het bovenstaande artikel gelezen. Mocht zoiets als ik beschrijf dus ook de bedoeling zijn, dan had het mooi geweest als dit uit het artikel zou blijken.

[Reactie gewijzigd door beerse op 8 juli 2025 17:28]

[kuurtjes]

Ik snap dat er een MD import functie komt. Maar dat er ook een export naar MD komt? Gaat dat niet veel te veel problemen geven met de limitaties van Markdown?

[teek2]

Nice. Ik begin echt te vaak in markdown te schrijven in MS Word en raak dan geïrriteerd. Stiekem zit er echt veel markdown overal (Hugo website, Obsidian/Nextcloud notes, sommige chat apps)