Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Textual Markdown – a Markdown “browser” in the terminal (github.com/willmcgugan)
254 points by willm on Dec 17, 2022 | hide | past | favorite | 29 comments
Hi HN,

This is a TUI app which displays interactive Markdown documents. Interactive in the sense that you can scroll code fences / tables / and click links. There's a Table of Contents extracted from the MD, and a very rudimentary browser like forward + back.

I'm thinking it could be the starting point for a variety of hypertext like applications in the terminal.

Very much a work in progress.




Somewhat relevant previous discussion: "We should have markdown rendered websites": https://news.ycombinator.com/item?id=33548134

I think a major pro of browsers serving content in a limited markup language (with Gopher being the extreme example) is that a variety of applications can realistically work with rendering them, without having to offload everything to a web browser.

I've been wanting to write a simple markdown renderer so that I can view my notes/todo in a nicer form without having to generate a PDF or open by browser, so I'm very excited to take a look at this codebase later.


> I think a major pro of browsers serving content in a limited markup language ..... is that a variety of applications can realistically work with rendering them.

I couldn't help but think of Gemini[0,1] and the number of applications already built for it[2] precisely because of the limited language. Gemini is an exciting space for lovers of a safer and lightweight internet.

It becomes clear that when rendering (and feature-bloat) are reduced, development begins to thrive. The Lagrange browser[3] is a great example of rendering not being an issue which gives developers time to build a great browser. For anyone curious, check it out to see what I mean: portable versions are available on Windows and Linux (appImage).

I have to admit that textual-markdown (OP) has me feeling the same way. I've been using command line browsers (on/off) for decades (since DOS). I don't know if I've ever seen a text-based browser look so beautiful. Wish the author the motivation and passion to keep this project going. I think it has great potential.

[0] https://gemini.circumlunar.space/

[1] https://en.wikipedia.org/wiki/Gemini_(protocol)

[2] https://gemini.circumlunar.space/software/

[3] https://github.com/skyjake/lagrange


A better solution is just committing to simple HTML which is already supported in browsers. You get all of the free functionality of modern HTML with zero extra work.

Markdown lacks the ability to support arbitrary names anchors so it's difficult to provide links to a portion of a document that isn't a heading. It also has no ability to build HTML forms so you don't have any interactivity. It's also extremely limited for embedding media.

An application (remote, localhost, or whatever) can spit out HTML5 and get a lot of free functionality with an unmodified browser. HTML5 forms support input types so you get some free input validation. It supports displaying multiple types of media. Browsers also have a lot of accessibility features just built in and available with the appropriate markup. No JavaScript required.

Basic HTML is very functional all by itself. Any application wanting to use functionality beyond reading just plain text will run into Markdown's limitations. If most of what people actually want to do is blocked by Markdown's limitations no one will use it which makes the effort a bit pointless.


I use Markdown a lot, and the renderers I’ve used support embedded native HTML, so you can mix MD and HTML in the same document (and even style tags if needed), but you wouldn’t necessarily use that to build an entire form.


Markdown as source that gets converted to HTML isn't the issue. The issue is the suggestion that browsers support native Markdown rendering and sites just deliver raw Markdown content because "it's simple".

To your point, delivering raw Markdown to the browser means the browser needs to implement a renderer that supports inline HTML. If you're doing that you might as well just deliver that Markdown pre-rendered as HTML. Then you can be sure the browser will get the inline HTML that way it was intended.

Markdown is great for writing "plain" text that's perfectly readable by humans but can be trivially converted to some delivery format. It's not really fit for purpose as a delivery format.


This. I am content with this. I’m interested in an extremely minimal browser for MacOS that is just a box that renders HTML and CSS just to view notes inside of. Min may foot the bill.


IME Obsidian.md has become almost an OS for markdown files; it's extraordinarily capable and ergonomic. Highly recommend checking it out before building your own; then even if you still want to DIY, I expect you'll come away inspired.


Likewise, I have been using Zettelkasten method for my own notes written in markdown on the terminal. Which are then later searched/consumed/linked via search tools like ripgrep and viewed in the terminal.

These notes contain diagram code like plantUML/graphviz and mermaid. I have been resorting to also rendering them in ascii to still gain value out of them if viewed from the terminal only.

This should complete my setup where diagrams/math rendering and all code could be rendered together.

Thanks for sharing!


Guess we'd need to reinvent all the accessibility that HTML brought us too.


Nice project. You can also do

    pandoc -i Readme.md | w3m -T text/html
if you need web links, etc., to work.

Or if you just want cool, colorful markdown rendering in the terminal, and some management of MD files, but without link following or other interaction, there is glow:

https://github.com/charmbracelet/glow


At what point does the terminal stops being terminal and becomes a GTK window? I guess now we can make full fledged GUIs within modern terminals.


Yes, so long as the pieces are made from whole characters and align with a character grid. ie you can't vary text size being a few tricks with unicode or figlet and you can't have a popup positioned on a pixel basis. But these aren't essential for a load of basic functionality.


There was another tool mentioned last week in this space: Glow: Render Markdown on the CLI - https://news.ycombinator.com/item?id=33925741

As I mentioned at the time, I normally just use Vim to look at markdown in the terminal - the point of markdown is that it's supposed to be easy to read as text, all the more so with syntax highlighting

On my wishlist for a tool like this is inline images in the terminal for terminal emulators that support it, eg iterm2


And your wish is granted: https://github.com/swsnr/mdcat mdcat can render images in iTerm2, Kiitty or WezTerm It has a few quirks but great piece of software nonetheless.


Thanks a lot for sharing, I had not seen this before!


It looks great.

I happen to like the styling you choose for the different elements (eg H1, H2 headers etc) but is it fairly straight forward to adjust that styling with Textual CSS?

From a quick peek in the widgets.py file it looks like there's a DEFAULT _CSS value set in a lot of them, so maybe there's a way to adjust via that?


Yeah, you could extend the app class, and provide your own CSS to customize just about anything.



Markdown supports images, so .md files may have them. What does it show when it finds an image? Does it show the image caption, or the full image link?


Good terminals support images, so I’d hope this would, too.


ASCII ART


Thanks for making this! I have been wanting to see something like this but too lazy to make on myself lol.


I like markdown but wanted a way to look at it in a termial. This looks to fit the bill perfectly, thanks!


Does anyone know what MacOS terminal is being used in the demo video and screenshots?


It looks like iterm2 with inline title.


That's iTerm


I'd love to see this living in the Obsidian.md space. If I could work on my documents in the terminal on some machines while in graphical OS's on others... why yes please.


Off topic: Wow clicking the video renders a sort of modal window after which my ios 15.5 is completely stuck, can only turn my screen off…and it won’t turn on again… after until 3 seconds. The modal is then closed and can use my device again.


That happened to me too, super strange because it looked like the native Safari video player and a plain old embedded mp4 so I don’t know what was going on there.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: