1/3
La communauté libriste/geek/nerd et pas que, dont moi, comprend bien l'intérêt de #Markdown pour prendre des notes ou faire du web, mais c'est, à mon avis, surtout son utilisation dans le processus d'écriture, pour remplacer les (mauvais-)traitements de texte, pour reprendre le contrôle du processus de rédaction, que la simplicité de Markdown acquiert tout son sens.
1/
GitHub extended the Markdown file format. For example, they added: tables, task lists, etc.
These Markdown extensions that GitHub popularized are so popular that I think most people, by default, now expect them to work anywhere that uses Markdown.
...
2/
Apparently, Claude Code added an extension to Markdown, too. A way to import a file's contents into a Markdown file.
That is something that is quite useful. (And, something that, for example, HTML should have added decades ago! — but didn't.)
Given how popular Claude Code seems to be — I wonder if its usage will become common, too.
Will people also, by default, expect this Claude Code Markdown extension to work anywhere that uses Markdown.
1/
GitHub extended the Markdown file format. For example, they added: tables, task lists, etc.
These Markdown extensions that GitHub popularized are so popular that I think most people, by default, now expect them to work anywhere that uses Markdown.
...
Neil Brown
boosted
I've got a little "toolchain" to convert #Markdown documents to PDF using #Pandoc and a custom LaTeX template. It generally works like a charm, but I'm now struggling with some #legal documents, where paragraphs are typically expected to be numbered and ideally nested/indented across multiple levels.
I can sort of handle it with my toolchain if I hardcode the numbers in the Markdown, although that feels a bit brittle.
Anyone has any tricks for creating legal docs in Markdown+Pandoc+LaTeX?
I've got a little "toolchain" to convert #Markdown documents to PDF using #Pandoc and a custom LaTeX template. It generally works like a charm, but I'm now struggling with some #legal documents, where paragraphs are typically expected to be numbered and ideally nested/indented across multiple levels.
I can sort of handle it with my toolchain if I hardcode the numbers in the Markdown, although that feels a bit brittle.
Anyone has any tricks for creating legal docs in Markdown+Pandoc+LaTeX?
devSJR :python: :rstats:
boosted
Found a powerful markdown tool for the terminal! 🔥
📚 **ekphos** — A markdown research TUI inspired by Obsidian.
💯 Supports Vim keybindings, inline images, wiki links, graph view, fuzzy search & more!
🦀 Written in Rust & built with @ratatui_rs
⭐ GitHub: https://github.com/hanebox/ekphos
#rustlang #ratatui #tui #markdown #notes #research #devtools #terminal #obsidian
Found a powerful markdown tool for the terminal! 🔥
📚 **ekphos** — A markdown research TUI inspired by Obsidian.
💯 Supports Vim keybindings, inline images, wiki links, graph view, fuzzy search & more!
🦀 Written in Rust & built with @ratatui_rs
⭐ GitHub: https://github.com/hanebox/ekphos
#rustlang #ratatui #tui #markdown #notes #research #devtools #terminal #obsidian
If you are an author who uses #markdown, what app do you use for your #writing ? I am relatively new to Markdown and have begun using #Joplin for my note-taking, mainly because it works best across all platforms (iOS, MacOS, Android, Linux) via my #NextCloud server.
My needs are relatively simple because I currently only write short articles and social media posts. I'm thinking of using Joplin for everything because I am enjoying it so much. I also have some experience with Obsidian and Ghostwriter for markdown writing. Any thoughts from more experienced markdown users than me?
Obsidian update adds Markdown link support to text and list properties! Praise the devs and save the game!
조내일
liked this activity
Hongdown 0.2.0 is out! Hongdown is an opinionated #Markdown formatter written in #Rust, and this release brings #WebAssembly support, so you can now use it as a library in #Node.js, #Bun, #Deno, and browsers.
New features:
- Smart heading sentence case conversion with ~450 built-in proper nouns
- SmartyPants-style typographic punctuation (
"straight"→“curly”) - External code formatter integration for code blocks
- Directory argument support for batch formatting
Try it in the browser: https://dahlia.github.io/hongdown/
Release notes: https://github.com/dahlia/hongdown/discussions/10
洪 民憙 (Hong Minhee)
boosted
Hongdown 0.2.0 is out! Hongdown is an opinionated #Markdown formatter written in #Rust, and this release brings #WebAssembly support, so you can now use it as a library in #Node.js, #Bun, #Deno, and browsers.
New features:
- Smart heading sentence case conversion with ~450 built-in proper nouns
- SmartyPants-style typographic punctuation (
"straight"→“curly”) - External code formatter integration for code blocks
- Directory argument support for batch formatting
Try it in the browser: https://dahlia.github.io/hongdown/
Release notes: https://github.com/dahlia/hongdown/discussions/10
Hongdown 0.2.0 is out! Hongdown is an opinionated #Markdown formatter written in #Rust, and this release brings #WebAssembly support, so you can now use it as a library in #Node.js, #Bun, #Deno, and browsers.
New features:
- Smart heading sentence case conversion with ~450 built-in proper nouns
- SmartyPants-style typographic punctuation (
"straight"→“curly”) - External code formatter integration for code blocks
- Directory argument support for batch formatting
Try it in the browser: https://dahlia.github.io/hongdown/
Release notes: https://github.com/dahlia/hongdown/discussions/10
My article about " #Markdown Is a Disaster: Why and What to Do Instead" from https://karl-voit.at/2025/08/17/Markdown-disaster/ was listed on the entry page of #HackerNews yesterday.
It hurts me to read through the comments. One part of the people who commented obviously didn't read the article they're commenting on.
And another part of the commenters does mix up #Orgmode, the Elisp implementation within #Emacs, with orgdown, the lightweight syntax which is actually the topic of this article. This part of the discussion is totally missing the whole point of my article: practical issues related to Markdown; choosing any other #LML which doesn't come with those downsides. #Orgdown was just one example of many which I wanted to mention because it is one of the least known alternatives outside the Emacs bubble.
🤷
RE: https://graz.social/@publicvoit/115875810144458821
I really do like how #SilverBullet is explaining the consequences of using their version of #Markdown on https://silverbullet.md/Markdown ( #CommonMark).
With statements like that, people learn about the consequences of using that tool.
They can either accept this or think about the negative effects before investing too much energy and data.
I really urge any ( #MD-)tool to include such a warning statement on their project page. It's for the benefit of your users.
One of the reasons why I most probably would recommend switching to SilverBullet if you - for some reason - can't use #orgmode with #Emacs which is IMO the optimum tool for many set of requirements: https://karl-voit.at/2021/01/18/tool-choices/
I'll migrate my wife's #PKM from #logseq (recent changes are a no-go to me) to SilverBullet or preferably Emacs. My upcoming #GLT26 Org-mode workshop (no recording) will tell her.
My article about " #Markdown Is a Disaster: Why and What to Do Instead" from https://karl-voit.at/2025/08/17/Markdown-disaster/ was listed on the entry page of #HackerNews yesterday.
It hurts me to read through the comments. One part of the people who commented obviously didn't read the article they're commenting on.
And another part of the commenters does mix up #Orgmode, the Elisp implementation within #Emacs, with orgdown, the lightweight syntax which is actually the topic of this article. This part of the discussion is totally missing the whole point of my article: practical issues related to Markdown; choosing any other #LML which doesn't come with those downsides. #Orgdown was just one example of many which I wanted to mention because it is one of the least known alternatives outside the Emacs bubble.
🤷
Ferrite – Markdown editor in Rust with native Mermaid diagram rendering
https://github.com/OlaProeis/Ferrite
#HackerNews #Ferrite #Markdown #editor #Rust #Mermaid #diagrams #OpenSource
@elettrona I was also running things directly on a VPS for years, but those cheap ones (and I am VERY cheap) just fall over with any significant load
@morgan Let me know if you have written something interesting. Now I am just playing, experimenting, I've got a couple interesting apps I'm playing with. Lemmy and WriteFreely. And of course WordPress. And castopod for audio. My key feature is federation, interaction, accessibility and data portability. Including the idea of writing in #markdown and having the post published when I decide to. I guess you have something like a raspberry pi installed at home
How Markdown took over the world
https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/
#HackerNews #Markdown #MarkdownRevolution #ContentCreation #TechTrends #WritingTools
alcinnz
and 1 other
boosted
As Markdown has become the standard for LLM outputs, we are now forced to witness a common and unsightly mess where Markdown emphasis markers (**) remain unrendered and exposed, as seen in the image. This is a chronic issue with the CommonMark specification---one that I once reported about ten years ago---but it has been left neglected without any solution to this day.
The technical details of the problem are as follows: In an effort to limit parsing complexity during the standardization process, CommonMark introduced the concept of "delimiter runs." These runs are assigned properties of being "left-flanking" or "right-flanking" (or both, or neither) depending on their position. According to these rules, a bolded segment must start with a left-flanking delimiter run and end with a right-flanking one. The crucial point is that whether a run is left- or right-flanking is determined solely by the immediate surrounding characters, without any consideration of the broader context. For instance, a left-flanking delimiter must be in the form of **<ordinary character>, <whitespace>**<punctuation>, or <punctuation>**<punctuation>. (Here, "ordinary character" refers to any character that is not whitespace or punctuation.) The first case is presumably intended to allow markers embedded within a word, like **마크다운**은, while the latter cases are meant to provide limited support for markers placed before punctuation, such as in 이 **"마크다운"** 형식은. The rules for right-flanking are identical, just in the opposite direction.
However, when you try to parse a string like **마크다운(Markdown)**은 using these rules, it fails because the closing ** is preceded by punctuation (a parenthesis) and it must be followed by whitespace or another punctuation mark to be considered right-flanking. Since it is followed by an ordinary letter (은), it is not recognized as right-flanking and thus fails to close the emphasis.
As explained in the CommonMark spec, the original intent of this rule was to support nested emphasis, like **this **way** of nesting**. Since users typically don't insert spaces inside emphasis markers (e.g., **word **), the spec attempts to resolve ambiguity by declaring that markers adjacent to whitespace can only function in a specific direction. However, in CJK (Chinese, Japanese, Korean) environments, either spaces are completly absent or (as in Korean) punctuations are commonly used within a word. Consequently, there are clear limits to inferring whether a delimiter is left or right-flanking based on these rules. Even if we were to allow <ordinary character>**<punctuation> to be interpreted as left-flanking to accommodate cases like **마크다운(Markdown)**은, how would we handle something like このような**[状況](...)は**?
In my view, the utility of nested emphasis is marginal at best, while the frustration it causes in CJK environments is significant. Furthermore, because LLMs generate Markdown based on how people would actually use it---rather than strictly following the design intent of CommonMark---this latent inconvenience that users have long felt is now being brought directly to the surface.
Why #Markdown's emphasis syntax (**) fails outside of Western languages: A deep dive into #CommonMark's “delimiter run” flaws and their impact on #CJK users.
A must-read for anyone interested in #internationalization and the future of Markdown:
https://hackers.pub/@yurume/019b912a-cc3b-7e45-9227-d08f0d1eafe8
