Not necessarily! I always run ln -s ‘/usr/bin/$EDITOR’ $(which $EDITOR) after a fresh install, so I have a valid executable on the path called $EDITOR.
Of course, then I have to make sure to add export EDITOR=$EDITOR to my .bashrc. (Obviously.)
Nano isn’t even that simple. Ctrl+X to quit? I guess if you use phonetic sounds to figure out how to exit a program. At least Vim uses the idea of “use what the words start with.”
I personally use micro in the terminal, and Kate if I want a GUI to write. Vim and Emacs are fine for those who want it, I have no stakes in the editor wars beyond “I just want my program to do what I want, and I want it to be simple to learn.”
Meanwhile I can just use the same shortcuts every other program made in the last 40 years uses. Ctrl+Q to quit, Ctrl+S to save, Ctrl+Z for undo. If I wanted to consult a cheatsheet to relearn keyboard shortcuts, I’ll use vim and emacs.
To be fair, you can easily rebind all the keys to be more normal by adding a .nanorc. Though, Ctrl-Z conflicts with suspend in many terminals, so I keep that one as Ctrl-U. A .nanorc also allows turning on mouse support, changing the color scheme, etc.
A text editor that doesn’t need a tutor because the interface is intuitive enough that someone who has been using text editors (as a concept) for years can more or less instantly pick it up and start working without needing a tutorial to simply edit a config file.
a text editor that has a tutor because it’s been around for so long and it’s had so many years to establish itself with an outside control interface that’s quite literally about as optimal as it can be. Vim basically allows you to never move your hands away from the homerow keys, even when navigating and doing bulk edits. The sheer amount of gained speed and productivity you get from this combined with the amount of times you’ll have to deal with text editing throughout your life is probably going to outweight any potential learned annoyances.
essentially a terminal modal editor (like vim), but instead of specifying the action to perform then what to perform the action on (like “yank 3 lines”), in helix you select first, then perform actions on the selection (like “these 3 lines, i want them yanked”). it’s slightly better (according to others) because you get to see what you’re going to change in the file so you don’t accidentally delete 5 lines instead of deleting 4.
on top of that many features are builtin, like tree-sitter and lsp support, so you don’t have to spend 5 hours looking for cool plugins and configuring everything to get started (my config file is only 50 lines of toml).
the downside is that there isn’t support for plugins (yet), but there’s already things like a file picker, more than 100 themes etc.
I gave it serious consideration when the death of Atom was announced and I was unsure where to move on to.
Looks like in the meantime a lot has been done (as far as I remember, TreeSitter and LSP weren’t built in back then…? Not sure though), but the lack of a plugin system is still killing it for me.
TBH it looks like it has 75% of the features you want from a codeditor, which is much more than the use-case for Nano, but no way to go the remaining 25% of the way.
Helix’s editing model is so much better than vim’s. I would probably use it if it was be closer to a drop-in replacement for vim. I really hope this neovide issue gains some traction because I don’t think I can daily drive anything that isn’t as smooth as neovide again.
I used it for a while. The flipped mode of thinking with it was weird at first but I liked it once I got used to it.
I don’t remember the specifics, but I vaguely recall encountering an issue with its LSP implementation that drove me toward thinking the whole LSP approach is insane and I went back to neovim.
100% Micro. Unless you’re only - and mean ONLY - living in the terminal, why would you want all your desktop and terminal shortcuts different from one another?!
lemmy.fosshost.com
Oldest