Why a previewer rather than an editor that updates as you write?
Do you have a specific use case?
It seems to me that markdown is for writing with the ultimate output supposedly being html. Having a viewer of the markdown doesn't seem to add anything.
Whereas making it an editor makes it more of a rich text editor.
I'm not particularly saying youre wrong, more posing a philosophical question.
There are both "open in editor" and "watch" modes.
The idea is not to replace an editor, but to complement it:
- "open in editor" lets you edit the file with your preferred editor
- "watch" automatically refreshes the preview when the file changes
So you can keep your usual workflow while having a fast, structured preview directly in the terminal.
If this project doesn't have open issues going back a year that are unanswered, it's doing better than glow. I forked glow to fix this one specific rendering bug, because the maintainers didn't respond to my bug report. I can't say that my fork is any better maintained, because no one is using it, but glow isn't maintained and has bugs so I wouldn't hold it up as anything other than abandonware.
Like... why are we doing this. What is the purpose of having a bunch of green checkbox emojis in the already bulleted list of features. The only thing it tells me is that an LLM was probably used extensively in building this project.
I don't think the em-dashes are particularly out of place in a list like this, though it's not the style I use.
I didn't realize ARCHITECTURE.md was an LLM thing (though I suppose I would've if I'd opened it); I'll have to keep my eyes open for that one in the future too.
This is an interesting approach - I guess you did not move away to a gui - but tried to have a guy-like experience in the terminal only - in https://voiden.md/ we do have a gui with blocks for api testing.
Thanks for the feedback! You're absolutely right. The goal was to create a GUI-like experience directly in the terminal. Your project looks really interesting too.
I built leaf, a Markdown previewer that runs entirely in the terminal.
It supports keyboard/mouse navigation, syntax highlighting, tables, checkboxes, clickable links, search, table of contents, local Markdown links, inline images, Mermaid diagrams, and LaTeX-to-Unicode rendering.
It works on Linux, macOS, Windows, and Termux.
GitHub: https://github.com/RivoLink/leaf
I’d appreciate feedback on the UX, missing features, and performance on large Markdown files.
Also maybe a single paragraph at the top describing the project rather than jumping into `install`.
Do you have a specific use case?
It seems to me that markdown is for writing with the ultimate output supposedly being html. Having a viewer of the markdown doesn't seem to add anything.
Whereas making it an editor makes it more of a rich text editor.
I'm not particularly saying youre wrong, more posing a philosophical question.
The idea is not to replace an editor, but to complement it: - "open in editor" lets you edit the file with your preferred editor - "watch" automatically refreshes the preview when the file changes
So you can keep your usual workflow while having a fast, structured preview directly in the terminal.
`cargo audit` finds 3 vulnerabilities, you should fix them.
Blazing safe.
https://github.com/charmbracelet/glow
> <bullet> <checkbox> description 1
> <bullet> <checkbox> description 2
> ...
Like... why are we doing this. What is the purpose of having a bunch of green checkbox emojis in the already bulleted list of features. The only thing it tells me is that an LLM was probably used extensively in building this project.
I didn't realize ARCHITECTURE.md was an LLM thing (though I suppose I would've if I'd opened it); I'll have to keep my eyes open for that one in the future too.
https://github.com/bahdotsh/mdterm
I opened an issue to test the “open in editor” feature:
- Shift+E should select/configure the editor
- Cmd+E should open the current Markdown file in the selected editor
Tested on Linux/Windows/Android so far.
Feedback from macOS users would be really helpful: https://github.com/RivoLink/leaf/issues/51