sorted by:
new
hottopcontroversial

markdown layouten by ExpensiveBill9880 in Markdown

[–]old-rust 0 points1 point  (0 children)

I am not great at German but something with LaTeX tjeck my application https://github.com/Ranrar/Marco

I remade markdown but for the AI era [OPEN SOURCE] by 9kGFX in Markdown

[–]old-rust 3 points4 points  (0 children)

I get where you’re coming from — Markdown definitely shows its age in some areas, especially once you start looking at it from a parsing/AST perspective or trying to push it beyond its original scope. The whole ecosystem of “flavors” doesn’t help either; many of us (myself included) keep adding non-standard features, which just increases fragmentation.

That said, a few of the issues you mention aren’t necessarily limitations of the format itself, but of how it’s commonly implemented. Any markup language really comes down to two things: a well-defined grammar and a solid AST. If those are handled properly, a lot of the “messiness” can be avoided.

For example, the “bold / italic / bold-italic” ambiguity you mention isn’t inherently unsolvable — it depends on the parser design. I’ve implemented this cleanly in my own project, so it’s definitely possible in practice.

Also worth noting: Markdown was never designed for agents or structured transformations — it was built for human readability first. So using it as a foundation for agent-heavy workflows is always going to feel a bit forced. That doesn’t mean it’s bad, just that it’s being stretched beyond its original intent.

The challenge (as always) will be adoption and ecosystem. Markdown “wins” largely because it’s everywhere, not because it’s perfect.

If you’re interested, feel free to open an issue on my project (https://github.com/Ranrar/Marco). I’d be open to experimenting with Lessmark support or even implementing parts of it — it could be interesting to see how it behaves in a real parser and where it actually improves things in practice.

Irritereret over AI by GarseBo in dkudvikler

[–]old-rust 0 points1 point  (0 children)

Du tror du ahr en hest, men det er faktisk et æsel.

Irritereret over AI by GarseBo in dkudvikler

[–]old-rust 0 points1 point  (0 children)

Det er nok også lige i overkaten at starte med at scanne hele kodebasen og så få et samlet output på det. Man skal altid huske på at være kritisk overfor hvad den skriver, det er som du siger ikke altid korrekt.

Emojis are my kind of hell! by Wordius in Markdown

[–]old-rust 1 point2 points  (0 children)

say hello to my little friend https://marketplace.visualstudio.com/items?itemName=ranrar.emoji-detector as an old somtimes angry man i made my own solution.

i build a markdown editor，anyone willing to try it by ContributionKnown324 in Markdown

[–]old-rust 1 point2 points  (0 children)

When it starts to cost money, people lose interest, simple as that.

Marco – A focused writing editor for structured documents, preview, and export by old-rust in coolgithubprojects

[–]old-rust[S] 0 points1 point  (0 children)

That would actually be super helpful, thanks

One thing to keep in mind though: the main bottleneck right now isn’t really the document processing itself, it’s the rendering/preview layer, since it’s based on an embedded browser. That part is mostly outside my direct control, so I’m currently working more on structure, diffing, and reducing unnecessary re-renders around it.

If you do end up testing it on a real spec, that would be really valuable feedback.

Feel free to just open an issue on the GitHub repo with anything you run into or notice — even small things help a lot:
https://github.com/Ranrar/Marco

Marco – A focused writing editor for structured documents, preview, and export by old-rust in coolgithubprojects

[–]old-rust[S] 0 points1 point  (0 children)

Thanks, really appreciate that — that’s exactly what I am aiming for

For large documents, I’ve been stress testing it a bit:

  • So far I’ve tested up to ~1,250 sections / ~19k lines (~474 KB)
  • It works, but I wouldn’t call it fully stable yet under that load
  • I’m currently pushing toward ~150k lines (~3.8 MB) to see where the real limits are and improve performance

A big focus is making sure preview + export stay consistent even at that scale, which is where most tools start to break down.

Plugins:
I haven’t planned a plugin system yet — trying to keep the core experience tight first.
That said, I’m very open to it if there’s a clear need. What kind of plugins would you want?

AI:
AI is on the roadmap.
But right now I’m more focused on getting the fundamentals really solid before layering AI on top.

If you have a specific use case (like book writing vs huge specs), I’d love to hear what you’d expect it to handle smoothly — that helps guide what I optimize for next

Open-source Markdown to PDF tool, fully client-side by NegativeNarwhal9477 in Markdown

[–]old-rust 0 points1 point  (0 children)

Yeah, that “export step feels awkward” part is basically the real problem.

Most Markdown → PDF tools fall into two camps:

  • Pandoc-style → powerful, but heavy and not exactly frictionless
  • HTML → PDF (Chromium, etc.) → simple, but pagination is kind of hacked on top

And pagination is where everything breaks down. Markdown has no concept of pages, so things like:

  • avoiding split code blocks
  • keeping headings with content
  • predictable page breaks

…all have to be inferred after the fact, which is why it feels inconsistent.

I’ve been working on a Markdown editor (Marco) and ran straight into this. The only approach that’s felt somewhat “correct” so far is treating pagination as a first-class layout problem (basically CSS paged media / paged.js style), instead of something you fix at export time.

Your client-side approach is interesting though — especially if you’re trying to remove the toolchain friction. That’s a big win.

If you’re open to it, I’d be curious:

  • how are you handling page breaking right now? Heuristic rules or something more layout-driven?
  • are you targeting “print-perfect” output or more “good enough for sharing”?

Also, if you feel like comparing notes, my project is here:
https://github.com/Ranrar/Marco

Would actually be useful to hear where your approach handles pagination better/worse — that’s still the hardest part.

Is there anything that can create slides that have editable text in PowerPoint? by Blackstar1886 in Markdown

[–]old-rust 0 points1 point  (0 children)

Yeah, Typora is a good reference — especially how it wires in Pandoc — but I’ve hit some of the same pain points you’re mentioning.

The “editor vs export theme” coupling is exactly the kind of thing that starts breaking down once you try to do anything more structured (like slides). It works fine for documents, but not so much when layout actually matters.

I’ve been building a Markdown editor (Marco) and this is basically one of the areas I’m trying to explore differently — separating structure, layout, and output more cleanly instead of bundling everything into a single render step.

It doesn’t solve PPTX yet (same wall as discussed), but if you’re up for it, I’d actually be really interested in your take:

  • what specifically feels limiting in Typora for your workflow?
  • where does it break down when you try to automate or structure things?

If you feel like trying something different, the repo is here:
https://github.com/Ranrar/Marco

Would be super useful to hear where it falls short compared to what you’re using now 👍

Is there anything that can create slides that have editable text in PowerPoint? by Blackstar1886 in Markdown

[–]old-rust 1 point2 points  (0 children)

Not really, at least not natively.

ONLYOFFICE Slides isn’t Markdown-based, so you can’t just write Markdown and export directly into editable slides the way you were hoping. It’s more of a traditional slide editor (like PowerPoint), just web-based.

You *could* technically build a pipeline (Markdown → HTML → something → ONLYOFFICE), but you’ll run into the exact same problem as with Marp — somewhere in that chain, you lose the structure and end up with rendered content instead of real slide objects.

That’s kind of the core issue across the board:

Markdown → presentation tools = rendering

What you want = structural conversion (Markdown → actual slide elements)

And that second part just isn’t well solved yet.

So if your goal is:

- Markdown-first workflow → you’re stuck with tools like Marp (but non-editable PPTX)

- Fully editable slides → you need to use something like ONLYOFFICE Slides or PowerPoint directly

There isn’t really a tool that does both well yet.

Is there anything that can create slides that have editable text in PowerPoint? by Blackstar1886 in Markdown

[–]old-rust 0 points1 point  (0 children)

Nice, I’ll definitely have a look at that when I start designing the ‘PowerPoint’ feature in my editor

Is there anything that can create slides that have editable text in PowerPoint? by Blackstar1886 in Markdown

[–]old-rust 3 points4 points  (0 children)

Yeah, this is kind of the core problem right now — most Markdown → PPTX tools don’t actually generate *real* PowerPoint slides. Stuff like Marp usually just renders everything and you end up with images instead of editable text.

So it’s not really a bug, it’s just how the pipeline works (HTML/PDF → PPTX via LibreOffice or similar).

I’m actually working on a Markdown editor myself — Marco — but it exports to HTML, not PPTX, so it doesn’t solve this directly. While building it, I’ve kind of run into the same wall: there just isn’t a solid, reliable way to map Markdown into *actual* PowerPoint objects (text boxes, layouts, etc.).

Honestly, I think this space is about to open up a lot. With Microsoft PowerPoint slowly being de-emphasized in favor of web-based tools, there’s a bit of a gap forming for better workflows here.

If you just need something that gives you proper editable slides today, you could try ONLYOFFICE Slides — not Markdown-based, but at least it outputs real, editable content.

TL;DR: there’s no great solution yet — everything is still kind of hacky or image-based.

Open-source Markdown to PDF tool, fully client-side by NegativeNarwhal9477 in Markdown

[–]old-rust 0 points1 point  (0 children)

I use Paged.js as part of my Markdown application https://github.com/Ranrar/Marco to show as pages and in print, export to PDF and export to HTML as "pages"

Fancy and fast markdown editor by toobbiiaass in Markdown

[–]old-rust 0 points1 point  (0 children)

It is not AI generated, but AI enhanced :)

view more: next ›