I'm all for choice but... The author is, of course, free to do whatever they like, and I'm free to say that using nano is almost certainly not an optimal workfl

I'm all for choice but... The author is, of course, free to do whatever they like, and I'm free to say that using nano is almost certainly not an optimal workflow. The beautiful irony of this post - some of the most common commands in nano (C-a, C-e, C-f, C-b, C-n, C-p, M-g, C-k, and more!) are taken from Emacs. If the author uses nano and bash (readline) to do work they are 80% of the way to using Emacs, the editor they supposedly don't like. And all the other commands are easily rebound to work like nano. The author could be working in an environment that's nearly identical to their current one, but that also has support for: * A toolbar, scrollbars, pulldown menus, etc. * Displaying multiple files side-by-side * LSP * Automatic refactoring/type-checking/code formatting/etc. * Advanced movement (jump to definition) * Mouse-over to see documentation * Macros/multiple cursors/batch renaming * Automatically detect missing dependencies/namespace errors/etc. * Calling external programs & handling their output * and more... If you write code like this I can only assume you either work like I did in high school when I used nano (alone, on small projects, with only specific languages, spending 95% of my time debugging) or that you work at 1/10th the speed of a typical programmer.