[HN Gopher] Show HN: Frogmouth - A Markdown browser for the term...
___________________________________________________________________
Show HN: Frogmouth - A Markdown browser for the terminal
Hi HN, 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...
Author : willm
Score : 185 points
Date : 2023-04-30 13:05 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bpshaver wrote:
| 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.
| wcerfgba wrote:
| <<Browser>> made me think of hypertext, which makes me wonder if
| it supports, or plans to support, [[wikilinks]] between Markdown
| files?
| kjs3 wrote:
| I 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.
| [deleted]
| minroot wrote:
| [dead]
| kossamums wrote:
| Can you add support for Obsidian markdown?
| sakekasi wrote:
| this. I would love to have a cli-based barebones obsidian vault
| browser
| sitkack wrote:
| Could one use this for epubs?
| davepdotorg wrote:
| Baca might interest you: https://github.com/wustho/baca
| johnchristopher wrote:
| Looks nice !
|
| Can't install right now, does it have vim keybindings ?
| davepdotorg wrote:
| 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.
| fishywang wrote:
| 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?
| willm wrote:
| It also renders headers, horizontal rule, bold, emphasis,
| strike through, underline, links, inline code, block quotes,
| and tables.
| dharmab wrote:
| Markdown can also contain inlined HTML, which is not human
| readable.
| bjornasm wrote:
| 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.
| DaOne256 wrote:
| 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?
| pigsinzen wrote:
| 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
| submeta wrote:
| Wow, glow looks awesome. Thanks for sharing!
| willm wrote:
| Yup. Glow looks pretty cool.
| wendyshu wrote:
| Latex math rendering would be awesome
| jlowin wrote:
| Nice! Is there a story behind the name Frogmouth?
| willm wrote:
| 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"
| linsomniac wrote:
| 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".
| midland_trucker wrote:
| 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.
| fbdab103 wrote:
| 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.
| PhilipRoman wrote:
| 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
| rodgerd wrote:
| elinks is my fave as well.
| fbdab103 wrote:
| That screenshot is incredibly impressive.
| dharmab wrote:
| There's a few terminal browsers like w3m, browsh and links that
| should work for many basic HTML pages.
| fbdab103 wrote:
| 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
| dharmab wrote:
| http://links.twibright.com is the website, but the easiest
| way to try it is probably to search your preferred package
| manager.
| alex_smart wrote:
| Soon, browse the web and watch youtube vidoes inside your
| terminal.
| zeromomentum wrote:
| You can browse the web with lynx or w3m, and (kind of) watch
| videos with yewtube.
| saulpw wrote:
| You mean like with brow.sh?
| sureglymop wrote:
| Textual looks really cool. But is there something similar in e.g.
| go instead of python?
| cristoperb wrote:
| The closest thing in Go I know of is bubbletea:
|
| https://github.com/charmbracelet/bubbletea
| the-printer wrote:
| The Textualize crew appears to be making some cool stuff. I'm
| looking forward to the Web browser.
| StarlaAtNight wrote:
| 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)
| bjornasm wrote:
| 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.
| jtmlis wrote:
| Speed, consistency, customization.
| asicsp wrote:
| Reusability is another factor for me. Often used solutions
| are converted to aliases, functions, shell scripts, etc.
| StarlaAtNight wrote:
| I get all three of those w/ my VS Code setup...could you
| explain in more detail?
| fiddlerwoaroof wrote:
| 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.
| pigsinzen wrote:
| 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.
| dr_kiszonka wrote:
| 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.
| kbd wrote:
| 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.
| manaskarekar wrote:
| > 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.
| abroadwin wrote:
| 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
| puttycat wrote:
| For me, it's focus.
| dmeybohm wrote:
| 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.
| linsomniac wrote:
| >...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.
| johnchristopher wrote:
| > 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
| linsomniac wrote:
| 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.
| tambourine_man wrote:
| 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.
| wahidislam wrote:
| - 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
| quesera wrote:
| 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.
| jethro_tell wrote:
| 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.
___________________________________________________________________
(page generated 2023-04-30 23:00 UTC)