Show HN: Frogmouth – A Markdown browser for the terminal(github.com)
github.com
Show HN: Frogmouth – A Markdown browser for the terminal
https://github.com/Textualize/frogmouth
70 comments
Nice idea! I’m excited to check it out. I write a lot of docs in Markdown and this could be a great way to browse them.
Out of curiosity, have you seen glow[0]?
[0] https://github.com/charmbracelet/glow
Out of curiosity, have you seen glow[0]?
[0] https://github.com/charmbracelet/glow
Since we're talking alternatives:
- https://github.com/swsnr/mdcat
- https://github.com/sharkdp/bat
- https://github.com/swsnr/mdcat
- https://github.com/sharkdp/bat
Wow, glow looks awesome. Thanks for sharing!
Yup. Glow looks pretty cool.
It's probably only me but isn't Markdown's main "selling point"/feature the raw files are human readable?
Looking at the screenshots, the only thing the "rendering" provides seem to be: 1) syntax highlights on code blocks; and 2) don't need to count the ordered bullets?
I guess if you need to verify that your markdown can be rendered (e.g no syntax errors), this would be helpful, but for that use case maybe a markdown linter is better?
Looking at the screenshots, the only thing the "rendering" provides seem to be: 1) syntax highlights on code blocks; and 2) don't need to count the ordered bullets?
I guess if you need to verify that your markdown can be rendered (e.g no syntax errors), this would be helpful, but for that use case maybe a markdown linter is better?
Just because something is human readable doesn't mean there isn't value in making it even more readable? I would certainly prefer to read a markdown file rendered like this than completely raw.
It also renders headers, horizontal rule, bold, emphasis, strike through, underline, links, inline code, block quotes, and tables.
Markdown can also contain inlined HTML, which is not human readable.
Don’t let the semantic HTML people hear you </sarcasm>
I recently needed to render markdown to view some notes. Thought opening chrome w/ a plugin or VSCode felt similarly sluggish options to do such a simple task. Now a few weeks after playing with textualize this pops up! Neat tool.
The Textualize crew appears to be making some cool stuff. I'm looking forward to the Web browser.
Semi related, but are there any good options for terminal rendering of HTML? I would be fairly accommodating of a best-effort dump of human visible body content.
I've found elinks to be really good. It preserves colors and has really nice navigation controls for interactive use (you can press dot to toggle numbered links). Here is a screenshot of this page: https://i.imgur.com/mP1T0H3.png
If you're just looking to format a page, it has a -dump option. If you want to preserve colors as well, use -dump-color-mode 4
If you're just looking to format a page, it has a -dump option. If you want to preserve colors as well, use -dump-color-mode 4
There's a few terminal browsers like w3m, browsh and links that should work for many basic HTML pages.
A full terminal web browser is a bit more than I was looking for, but this is definitely an option. Was thinking more something I could pipe text into to get an extraction and/or a simpler pager interface.
The browsh repo front page is just insanely impressive[0]. `links` is impossible to query the web for the project, so if you had more guidance on that one, it would be appreciated.
[0] https://github.com/browsh-org/browsh
Edit: Noted I was querying for something more feature anemic, plus Browsh link
The browsh repo front page is just insanely impressive[0]. `links` is impossible to query the web for the project, so if you had more guidance on that one, it would be appreciated.
[0] https://github.com/browsh-org/browsh
Edit: Noted I was querying for something more feature anemic, plus Browsh link
Well if you don't find anything, I wonder how easy it would be to adapt my DocBook XML reader to do HTML (sans any sort of script, dynamic content, or remote content). It's pretty much as you describe, little more than a pager for stuff that one can pipe into it, or files named on the command line. I pretty much aimed at just under pg(1) for DocBook XML.
* http://jdebp.info/Softwares/nosh/guide/commands/console-docb...
* http://jdebp.info/Softwares/nosh/guide/commands/console-docb...
http://links.twibright.com is the website, but the easiest way to try it is probably to search your preferred package manager.
Elinks -dump google.comI like it. Let's see how it feels over time.
You might consider Sixel support as a way of doing images. There are a number of excellent libraries that support it.
You might consider Sixel support as a way of doing images. There are a number of excellent libraries that support it.
This is neat. I recently wanted something similar so this is what I did:
1. Zellij split panes
2. Left pane: Helix editor with built-in Marksman (markdown LSP) support.
3. Right pane: watchexec (re- runs commands when watched files change) running Glow (Terminal markdown renderer) on the last modified markdown file (‘ls’ gives you that)
Then you can use ‘gd’ and whatnot to move between references from one markdown file to another.
This is easily composed of smaller parts, so you can use vim instead of helix, tmux instead of zellij, mdcat instead of glow.
It’s really the same process I might use to edit code on the left and re run tests or compiler checks or linting on the right. Since I was already doing those things, turning my terminal into a markdown viewer was trivial.
1. Zellij split panes
2. Left pane: Helix editor with built-in Marksman (markdown LSP) support.
3. Right pane: watchexec (re- runs commands when watched files change) running Glow (Terminal markdown renderer) on the last modified markdown file (‘ls’ gives you that)
Then you can use ‘gd’ and whatnot to move between references from one markdown file to another.
This is easily composed of smaller parts, so you can use vim instead of helix, tmux instead of zellij, mdcat instead of glow.
It’s really the same process I might use to edit code on the left and re run tests or compiler checks or linting on the right. Since I was already doing those things, turning my terminal into a markdown viewer was trivial.
Some things in common with Cronvel Terminal Kit?
https://github.com/cronvel/terminal-kit
Sort of a document model for the terminal https://github.com/cronvel/terminal-kit/blob/master/doc/docu...
https://github.com/cronvel/terminal-kit
Sort of a document model for the terminal https://github.com/cronvel/terminal-kit/blob/master/doc/docu...
《Browser》 made me think of hypertext, which makes me wonder if it supports, or plans to support, [[wikilinks]] between Markdown files?
It supports normal Markdown links right now. As an Obsidian user I have been thinking wikilinks would be nice to add too. No firm plans but something I’d like to add.
Nice! Is there a story behind the name Frogmouth?
We're using bird names as a convention for our projects. Which may or may not be the name of the apps. Frogmouth felt more memorable than "mdbrowser" or "markdown-view"
This may just be a personal quirk, but many of these sorts of names to me seem to be one-way memorable. Like, if I see a future reference to "frogmouth" I probably will think "Oh yeah, I've heard of that." I may or may not remember that it's a markdown browser. But if I'm trying to remember "that markdown browser I saw a while ago", I can rarely pull out the name "frogmouth".
/one-way memorable/ - recognisable, but not memorable.
Could Frogmouth display Markdown cells in Jupyter Notebooks on the CLI?
FWIW, IPython is built with Python Prompt Toolkit and Jupyter_console is IPython for non-python kernels; `conda install -y jupyter_console; jupyter kernelspec -h`. But those only do `%logstart -o example.out.py`; Markdown in notebooks on the CLI is basically unheard-of.
FWIW, IPython is built with Python Prompt Toolkit and Jupyter_console is IPython for non-python kernels; `conda install -y jupyter_console; jupyter kernelspec -h`. But those only do `%logstart -o example.out.py`; Markdown in notebooks on the CLI is basically unheard-of.
I would like to run VSCode with a TUI like this in a terminal via SSH.
Does anyone know a VSCode extension to do this?
Does anyone know a VSCode extension to do this?
FWIU coc.vim works with vim and nvim and works with VSCode LSP support: https://github.com/neoclide/coc.nvim
There are many LSP implementations: https://langserver.org/
awesome-neovim Ctrl-F "DAP": https://github.com/rockerBOO/awesome-neovim#lsp
mason.nvim: https://github.com/williamboman/mason.nvim :
> Portable package manager for Neovim that runs everywhere Neovim runs. Easily install and manage LSP servers, DAP servers, linters, and formatters.
conda-forge
DAP: Debug Adapter Protocol https://microsoft.github.io/debug-adapter-protocol/implement...
There are many LSP implementations: https://langserver.org/
awesome-neovim Ctrl-F "DAP": https://github.com/rockerBOO/awesome-neovim#lsp
mason.nvim: https://github.com/williamboman/mason.nvim :
> Portable package manager for Neovim that runs everywhere Neovim runs. Easily install and manage LSP servers, DAP servers, linters, and formatters.
conda-forge
DAP: Debug Adapter Protocol https://microsoft.github.io/debug-adapter-protocol/implement...
COC has been mostly deprecated for native LSPs also. I run ~same pyright I'd use in VSCode in my neovim.
I'm a big fan of the Markdown Preview feature in VS Code
Honest question: why do developers insist so much on using command line based tools? What's the advantage over using an IDE? (e.g. VS Code or PyCharm)
Honest question: why do developers insist so much on using command line based tools? What's the advantage over using an IDE? (e.g. VS Code or PyCharm)
You get an endlessly customizable setup with a single interface. Build, write, read docs, test, lint, debug, troubleshoot, admin. Same interface. All keyboard driven, so I don't have to switch between keys and mouse.
It's extremely portable, works exactly the same on my machine as it does on any OS with bash and vim, it's easy to use on a remote machine.
It's easily scriptable as well which makes customization simple. It's way faster for me to write a quick script to do something I need then dig through an endless list of marginally verified plugins to do something.
I guess my question is what can you do with an IDE that can't be done at the CLI?
I've tried code, pycharm, eclipse and really never found a value add.
And all of that applies to other tasks beyond coding. Notes, email, chat, it's right there, hey what's the price of that stock my buddy was talking about? Yep, right there. Hey look also my music.
It's extremely portable, works exactly the same on my machine as it does on any OS with bash and vim, it's easy to use on a remote machine.
It's easily scriptable as well which makes customization simple. It's way faster for me to write a quick script to do something I need then dig through an endless list of marginally verified plugins to do something.
I guess my question is what can you do with an IDE that can't be done at the CLI?
I've tried code, pycharm, eclipse and really never found a value add.
And all of that applies to other tasks beyond coding. Notes, email, chat, it's right there, hey what's the price of that stock my buddy was talking about? Yep, right there. Hey look also my music.
> Honest question: why do developers insist so much on using command line based tools? What's the advantage over using an IDE? (e.g. VS Code or PyCharm)
Unix is an IDE. CLI (and GUI) tools are the plugins.
Unix is an IDE. CLI (and GUI) tools are the plugins.
Reasons vary by tool, but some include: Speed, composability (see the "Rule of Composition" from the Unix philosophy), and the ability to be run in a remote terminal
IDEs are often big, slow, costly, inconsistently featureful, subject to the vagaries of personal taste and fluctuating support, difficult or impossible to automate, and not always available (either not installed, not possible to install, or just expecting a graphical interface that is not local to the operator)
TUIs/CLI programs are (generally) small, composable, consistent, reliable, fast, well-supported, installed by default or easily obtained, predictable, have good keyboard shortcuts, and they work great remotely.
TUIs/CLI programs are (generally) small, composable, consistent, reliable, fast, well-supported, installed by default or easily obtained, predictable, have good keyboard shortcuts, and they work great remotely.
I used to prefer Vim but moved to using IDEs. In professional development, you want to use the best tools - a forklift vs. a shovel. I don’t think text editors are the best tool for that, but why do programmers insist on using worse tools?
From my previous experience, I’d guess it’s these psychological factors:
1. IDEs have more cognitive overhead, and programmers have to keep a lot of state in their heads. So using a text editor gets out of their way initially to get started developing. In the long-run, though, it’s worse for cognitive overhead because you have to keep more state in your head due to having worse code completion. You also have the additional effort needed to set up plugins with text-based tools to provide additional features that are helpful for daily tasks.
2. IDEs tend to have more knobs - big menus, dropdowns etc. Those can reduce your ability to focus when you’re not used to them. Many of the available options likely aren’t applicable to what you’re working on, and can be distracting.
3. A lot of programmers have a sense of elitism, and using text-based tools looks retro and more intimidating to those not familiar with it. In so doing, this validates the view of oneself as a member of a priestly class of text-slinging wizards.
4. Programmers love to yak-shave. Using more primitive tools gives a reason for us to customize the experience, even or especially if it’s an inefficient waste of time. Programmers love opportunities for self-expression through code and customizing the experience of using their coding environments for its own sake.
From my previous experience, I’d guess it’s these psychological factors:
1. IDEs have more cognitive overhead, and programmers have to keep a lot of state in their heads. So using a text editor gets out of their way initially to get started developing. In the long-run, though, it’s worse for cognitive overhead because you have to keep more state in your head due to having worse code completion. You also have the additional effort needed to set up plugins with text-based tools to provide additional features that are helpful for daily tasks.
2. IDEs tend to have more knobs - big menus, dropdowns etc. Those can reduce your ability to focus when you’re not used to them. Many of the available options likely aren’t applicable to what you’re working on, and can be distracting.
3. A lot of programmers have a sense of elitism, and using text-based tools looks retro and more intimidating to those not familiar with it. In so doing, this validates the view of oneself as a member of a priestly class of text-slinging wizards.
4. Programmers love to yak-shave. Using more primitive tools gives a reason for us to customize the experience, even or especially if it’s an inefficient waste of time. Programmers love opportunities for self-expression through code and customizing the experience of using their coding environments for its own sake.
> 3. A lot of programmers have a sense of elitism, and using text-based tools looks retro and more intimidating to those not familiar with it. In so doing, this validates the view of oneself as a member of a priestly class of text-slinging wizards.
That's usually what I hear from people finding out I like/use Vim. It's like they can't come to peace with the fact that I like it for its bindings and plugins, no, it has to be because I want to be a snob about it. And those judgements only start once they find out I am using vim, before that I am just a regular guy but as soon as they see me type `vi`, blam, I am an elitist asshole. Fuck that.
Turns out I use vscode (debugging so much nicer) AND vim (quick notes and configuring stuff so much faster) (and Kate).
Once, I was debugging a config file in a video meeting with a colleague. I was frustrated because I had difficulties making the config file works and was mumbling "goddamitthingofhelltheresalwasysomething" and that colleague jumps at me "ah ! you are frustrated because you are using vim and can't paste the buffer (or saving the file or something)."
/rant
That's usually what I hear from people finding out I like/use Vim. It's like they can't come to peace with the fact that I like it for its bindings and plugins, no, it has to be because I want to be a snob about it. And those judgements only start once they find out I am using vim, before that I am just a regular guy but as soon as they see me type `vi`, blam, I am an elitist asshole. Fuck that.
Turns out I use vscode (debugging so much nicer) AND vim (quick notes and configuring stuff so much faster) (and Kate).
Once, I was debugging a config file in a video meeting with a colleague. I was frustrated because I had difficulties making the config file works and was mumbling "goddamitthingofhelltheresalwasysomething" and that colleague jumps at me "ah ! you are frustrated because you are using vim and can't paste the buffer (or saving the file or something)."
/rant
vi is a pretty effective byte-code for communicating what is in my brain into what is on the screen. Kind of like a protobuf for text editing.
>...worse code completion
Have you tried LSP, say like in a LunarVIM or AstroVIM setup? These are self-contained packagings so you don't have to fiddle around with plugins (though you can also achieve the same results through plugins), and as I understand it you get the same code completion and intelligence you get in VSCode.
Have you tried LSP, say like in a LunarVIM or AstroVIM setup? These are self-contained packagings so you don't have to fiddle around with plugins (though you can also achieve the same results through plugins), and as I understand it you get the same code completion and intelligence you get in VSCode.
Had this discussion recently with someone advocating IDE debuggers over CLI debuggers. I'm like, don't you realize that the CLI debugger is used underneath inside your IDE? And by using it from the CLI you get an entire HISTORY of your debug sessions you can refer to.
I use Vim because:
- works at the speed I think. It renders text quickly, responds to my keystrokes quickly, and lets me work my will quickly. That's nice when I have a lot to do or am inspired, which covers most of the time I'm coding
- It's open source and trustworthy. I'm not gonna wake up one day and find out a critical plugin I use is closing the source and making a change I hate, or that Vim itself was uploading my code to copilot, etc.
- It's basically a platform. You can do whatever you want in Vim, remap all the keybindings, make a music player, whatever.
- It's respectful of my computer's resources. It starts up almost instantly, and generally uses very little CPU and RAM.
- works at the speed I think. It renders text quickly, responds to my keystrokes quickly, and lets me work my will quickly. That's nice when I have a lot to do or am inspired, which covers most of the time I'm coding
- It's open source and trustworthy. I'm not gonna wake up one day and find out a critical plugin I use is closing the source and making a change I hate, or that Vim itself was uploading my code to copilot, etc.
- It's basically a platform. You can do whatever you want in Vim, remap all the keybindings, make a music player, whatever.
- It's respectful of my computer's resources. It starts up almost instantly, and generally uses very little CPU and RAM.
- most programmers in general are really fast with keyboard , like maybe 80-90 avg most of them so using the keyboard most is a good way for speed & consistency
- another example i can give is maybe you have some error on your ide that you can't debug for some reasons, most probably you can't copy text from that window, (it's just an example maybe you'll similar issue in other ways)
having cli means you can copy whatever the program is throwing at your, theres not limit
- another thing is aesthetic: you know you can do a lot.of stuff from cli, all will have the same color scheme & consistency across every cli programmes which someone may prefer.
- lightweight
Speed, consistency, customization.
Reusability is another factor for me. Often used solutions are converted to aliases, functions, shell scripts, etc.
I get all three of those w/ my VS Code setup...could you explain in more detail?
Your hands almost never have to leave the keyboard.
There is often not telemetry.
You can remotely connect from a different machine and you your development environment.
The cross-platform story is much better. For example, supporting BSDs.
It exposes you to a lot of details hidden or abstracted away by GUI applications.
Also, its a matter of preference.
There is often not telemetry.
You can remotely connect from a different machine and you your development environment.
The cross-platform story is much better. For example, supporting BSDs.
It exposes you to a lot of details hidden or abstracted away by GUI applications.
Also, its a matter of preference.
I use VSCode daily. In my experience, 1) nearly every day VSCode wants me to update some extension, which I find annoying, 2) there is a teeny typing lag in VSCode when compared to my terminal. It is nothing you would typically notice and doesn't bother me, but typing in my terminal feels instantaneous, which makes it very pleasant.
VSCode isn’t much different from vim or emacs in terms of functionality: basic text editor that is configured for various tasks by plugins. Especially with the rise of LSP, the difference between VSCode and vim/emacs is basically preference.
> VSCode isn’t much different from vim or emacs in terms of functionality: basic text editor that is configured for various tasks by plugins.
Ease of extensibility is a big deal and vscode is much less easy to configure.
VSCode doesn't work uniformly throughout the application. In emacs, you'll quickly start to depend on all the places you can use M-r, M-n, and M-p to reverse search history for instance. This is one of many many examples where it's keyboard driven UX is superior.
Another big thing is that you can get help for every keybinding, click a link to it's function, and start modifying the implementation.
There was a recent podcast I can't recall that gave a good example of this... I'll look for it and post back if I find it.
I'm curious, how would you do what I describe here using isearch to query replace in vscode: https://old.reddit.com/r/emacs/comments/126w8xb/what_are_the...
Ease of extensibility is a big deal and vscode is much less easy to configure.
VSCode doesn't work uniformly throughout the application. In emacs, you'll quickly start to depend on all the places you can use M-r, M-n, and M-p to reverse search history for instance. This is one of many many examples where it's keyboard driven UX is superior.
Another big thing is that you can get help for every keybinding, click a link to it's function, and start modifying the implementation.
There was a recent podcast I can't recall that gave a good example of this... I'll look for it and post back if I find it.
I'm curious, how would you do what I describe here using isearch to query replace in vscode: https://old.reddit.com/r/emacs/comments/126w8xb/what_are_the...
My argument was the opposite, I use emacs for everything because its extensions are more composable and it’s a lot easier for me to write my own as I need them.
My point is just that the “why would anyone use a ‘text editor’ instead of an IDE” argument makes a little bit of sense when you’re comparing vim/emacs to IntelliJ, but VSCode is just as much a text editor out of the box as vim/emacs. And, despite being newer, it’s relatively uninspired compare to emacs.
My point is just that the “why would anyone use a ‘text editor’ instead of an IDE” argument makes a little bit of sense when you’re comparing vim/emacs to IntelliJ, but VSCode is just as much a text editor out of the box as vim/emacs. And, despite being newer, it’s relatively uninspired compare to emacs.
VSCode is my main tool from day to day - I use it extensively for coding, documenting, writing papers, drafting e-mails, writing my work log/diary. However I was intrigued by this tool as I've already have open 4-6 tabs in my VSCode, so I think this would be neat to reduce the resource use a bit.
I feel like you shouldn't be downvoted, it seemed like a genuine question with no snark.
To me, it's the flexibility, composability, automation, etc, like may have said in the thread.
To me, it's the flexibility, composability, automation, etc, like may have said in the thread.
For me, it's focus.
Looks nice !
Can't install right now, does it have vim keybindings ?
Can't install right now, does it have vim keybindings ?
I did add some vim-friendly bindings for switching the navigation panes on the left, but thinking about it not for the main viewer. Feels like an oversight now, good call. I’ll add that to the todo list.
Latex math rendering would be awesome
Textual looks really cool. But is there something similar in e.g. go instead of python?
The closest thing in Go I know of is bubbletea:
https://github.com/charmbracelet/bubbletea
https://github.com/charmbracelet/bubbletea
Soon, browse the web and watch youtube vidoes inside your terminal.
You mean like with brow.sh?
You can browse the web with lynx or w3m, and (kind of) watch videos with yewtube.
Could one use this for epubs?
Baca might interest you: https://github.com/wustho/baca
[deleted]
Frogmouth is a TUI to display Markdown files. It does a passable job of displaying Markdown, with code blocks and tables. No image support as yet.
It's very browser like, with navigation stack, history, and bookmarks. Works with both the mouse and keyboard.
There are shortcuts for viewing README.md files and other Markdown on GitHub and GitLab.
License is MIT.
Let me know what you think...