I enjoyed reading the following article which portraits its author pondering what he likes about the “build your own IDE” approach (Vim, Neovim + Lua + LSP + Treesitter, Kakoune…) and what he enjoys when “using a consistent productivity platform” (Emacs + org-mode + magit…).
Lots of good insights that I also share. The section about “CLI vs TUI vs GUI” puts in perspective a quote I’ve seen recently, that emacs is great “2D CLI”. The “Line” in “Command Line Interface”, could therefore be replaced by “Grid” in “Command Grid Interface”. (which unfortunately ends up being “CGI”, an acronym already pretty popular for something else).
I don’t think his argument for avoiding logic in config files makes any sense. If you’re using something designed to be scripted then not configuring it through that same scripting language would seem to me to only complicate things. You read .Lua files for extensions but can only configure those extensions via something static like JSON? What if I want to extend or modify the plugin? Seems like the end result would be people either circumventing the static config or worse, embedding Lua statements in json strings. I’ve seen enough Turing complete XML in my lifetime thanks.
In general I agree that the Linux ecosystem is heavily undermined by the bash sucking for scripting and byte streams being very limited. Much easier to create a cohesive environment when your glue language, programming language and, very importantly, data are all ELisp lists in the same interpreter.
Currently I’m trying out GNU guix as an OS. Guix is like NixOS but everything is scheme. My hope is this approach makes my system more cohesive. It’s definitely made package and service management much better but I haven’t been able to explore the scripting side of things as much.
I think his remarks on using on GUI vs TUI are interesting:
[In a] GUI, you get access to much more possibilities:
Proper “pixel scrolling.”
Use several fonts, of different sizes, for things like Markdowns, note taking, etc.
Proper pop-up windows.
Pixel-perfect annotations, marks, hints and signs in your buffer.
Images, rasterized or vector graphics.
One of the most important part to me: proper UI elements! No more hacks!
Even though it is not implemented yet, since we can have images, and especially vector graphics, we should be able to render git branches with pretty links and not the /|* ASCII art mimics we see in all CLIs / TUIs.
What would be built if it was easy to put kakoune clients in a GUI?
I feel like lazy* (lazycli, lazydocker, lazygit) do an amazing job of implementing a CGI (and I wonder if it would solve his issues with kube control).
Neovim is fine with Lua, but it’s still a bit split. Interacting with the CLI (allegedly half the reason people use Vim/Neovim) is very…ugly. Lua is also not the most feature-ful of languages. And you still have to interact with ugly Vimscript, even if you are using Lua.
Kakoune does it far better. It seems to unify with the UNIX system more.
But Emacs has Org-Mode, which is just too good. AsciiDoc, reStructuredText, and Markdown just don’t compare. Again, due to how unified Emacs is with Emacs Lisp. I am looking to allow my workflow to be able to easily work with Kakoune or Emacs. Though part of it is moving away from Doom Emacs to my own configuration, and adding some more complex extensions to Kakoune.
I don’t know what exactly the problem is with the ability for scripting to configure the editor, because, with both Vim and Emacs, it can be as complicated as you’d like it to be. It doesn’t really need to if you want it to, but if you want to get really complex it’s entirely up to you.