github.com
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...
Out of curiosity, have you seen glow[0]?
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?
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
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
* http://jdebp.info/Softwares/nosh/guide/commands/console-docb...
Elinks -dump google.comYou might consider Sixel support as a way of doing images. There are a number of excellent libraries that support it.
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.
https://github.com/cronvel/terminal-kit
Sort of a document model for the terminal https://github.com/cronvel/terminal-kit/blob/master/doc/docu...
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.
Does anyone know a VSCode extension to do this?
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...
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)
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.
Unix is an IDE. CLI (and GUI) tools are the plugins.
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.
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.
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
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.
- 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.
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.
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 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.
To me, it's the flexibility, composability, automation, etc, like may have said in the thread.
Can't install right now, does it have vim keybindings ?