I would recommend micro. It's simple like nano, but has full mouse support. The only real downside is that it's not installes by default.

Nano also has mouse support, it's just disabled by default.

/etc/nanorc is worth a look, at least on Debian it's well commented

I'm confused. The only reason one uses nano is because you ssh'ed into some random machine and you are stuck with whatever is on it. If you got enough bother to install micro or fiddling with the settings of nano you might as well setup something more proper.

I'm a GUI dev/UX/education designer. Nano/pico to me are the only cli editors remotely suitable for ordinary human cognition. I have faint interest in the Emacs ecosystem, but wish it took basic ergonomics into account more seriously. I do understand I could get used to the lack of affordances but life's too short, perhaps. I understand keyboard usage wins you speed but not sure it's worth the general unpleasantness. I suppose I'm in the minority here though.

It is not a human cognition problem. It's a motivation problem. Lack of motivation to take a few minutes to learn a keyboard command that will save you orders of magnitude more time in the future than you spend learning it.

With the GUI version, what do you have to learn in emacs? In gvim, you have to learn how to switch between normal and insert mode, but I can't think of anything else basic that can't be done in the menus.

You can pick a new keyboard shortcut to learn every day or two, or whenever you get tired of digging through menus to use a feature. In a year you'll wonder why the hell you let negative bias/emotion keep you from learning a real editor for so long.

I believe this discussion is a part of a wider cultural gap and differences in understanding. I have been researching these differences for a decade or two now, and would like to understand them better.

That's why I would like to understand where you're coming from.

First, I'd like to verify: Do you think motivation isn't a human cognition problem?

Second, it appears to me you are making a wide array of assumptions about my preferences and my goals, as well as about what I find difficult or easy.

For example, you appear to assume that were I to choose rationality (?, i.e. not carrying "negative bias/emotion") I should value speed over of a host of other qualities of interaction design.

You seem to imply that committing to a specific kind of interesting, but very quaint visual/interaction style, i.e. the interaction constraints of a terminal UI, are a price worth paying for the speed of operation gained. Am I correct that you are implying this?

Keyboard shortcuts are not an exclusive feature of terminal UIs. I have a strong preference for UIs that comply with, for instance, the well-researched heuristics from the field of human-computer interaction. Terminal UIs are generally a lot more challenging to design to comply with them (for general audiences). Also visual hierarchy and a host of other beneficial properties are harder to achieve.

https://www.nngroup.com/articles/ten-usability-heuristics/

Yet, certain types of expert users tend to prefer - in my point of view - extremely arcane UIs, as they fit those users' style of operation.

They do not seem to fit mine. I want to emphasize that these are my current preferences, and you may well be right that I would enjoy the speed of emacs/vim usage. So far though, no one has bothered to sell them to me in a way that I personally would find convincing.

Arcane cursor moving commands have never saved me orders of magnitude more time. They are in fact a quickly forgotten inconvenience.

Now, things like Emmet and the possibility of having hundreds of simultaneous editing cursors, these things really save time, and work in an intuitive editor like SublimeText.

I'm not convinced this is true. I have spent a few weeks getting used to both emacs and vim and did end up going back to an IDE for proper development and nano for small editing. I'm not convinced that those two editors are worth the time investment that they require to be even remotely usable, even for the average software developer.

JOE (Joe's Own Editor)[1] is actually easier to use than nano, and it can emulate other editors (including nano/pico via jpico). It also has mouse support. It is installed by default in Slackware, and is in the package manager for most other OSes.

[1] https://joe-editor.sourceforge.io/

Thirding the recommendation for JOE. And as someone who started programming in the '80's, I especially enjoy its WordStar mode which feels like coming home again!

From the screenshots that seems to have fewer, not more, immediately visible affordances tho?

Seconding the recommendation for JOE. It was what I used before I learned vim.

Easy to scp micro or nanorc over with one command.

Or use a local editor and scp the edited file.

> The only real downside is that it's not installes by default.

This is why I recommend to anyone wanting to try a -nix like OS to learn the basic commands in both vi and nano. One or the other is shipped with every -nix like OS I've ever used. Once they get more used to the OS, go ahead and install whatever editor they want to. But logging into a fresh install of pretty much any system, one can get by with either of the two.

So one day someone will write the improvement and call it milli, but then what? Is there a prefix for 10^0? Do these people not plan ahead?

Well you can use some of the convenience steps around 1, e.g. centi and deci and then skip the 1.0 and go straight to deca and hecto.

You can call it one, or alternatively:

How about uno

Well, it seems we've already skipped to kilo[1], so it'll have to be mega.

1: https://github.com/antirez/kilo

EINE [1]

[1]: https://en.wikipedia.org/wiki/EINE_and_ZWEI

unit

It's still a bit buggy. It sometimes freezes over ssh and randomly misinterprets keypresses/mouse signals if done too fast.

What happened to pine, by the way? It was absolutely fantastic because it was minimalistic. I like mutt, but it's not the same.

The UW no longer wanted to support Pine but they were unable to release it under the existing license. It was mostly rewritten as Alpine ( https://www.washington.edu/alpine/overview/story.html ), and is now sort of maintained by other folks: http://alpine.x10host.com/alpine/

I still use it regularly and it still works well, but I should probably be looking for something else.

Not at all similar, but mutt is a fantastic replacement. Like Vim, very powerful once you get in to it.

There was a fork/successor called alpine, I recall having to setup for my wife. But beyond that I think that mutt eventually "won". (Especially when development started picking up again with mutt-ng, etc.)

I wrote a console-based mail-client with lua-based scripting, over at https://lumail.org/ but I don't think I have more than 50 hard-core users. It seems like most people use mutt, and work around its annoyances, or use web-browser for their mail.

(I realize at some point notmuch came out and became popular, but I've never had a strong feeling for how popular. I think I'm a little biased since I read of people using it, but nobody "local" to me does.)

I was used to pine and pico so I migrated to alpine and nano. Alpine works fine for me, alpine is very much like pine. I have spamassassin tagging mail as spam, and I have an alpine filter that moves those tagged messages to a possible spam folder.

I was used to pine when mutt came out, so I always used pine or alpine. You can check both out and see which you prefer.

There's alpine, but I haven't use it yet, so can't say if it's as good ;)

Being an Emacs user I use Zile for that since it's effectively a trimmed-down version of Emacs. Of course unlike nano it's not usually installed by default on most distros, so I still have to use nano or vi from time to time, but I can't say I enjoy it very much.

I often reach for

  emacs -nw -Q

It boots up quickly and the basic editing defaults are all there. Has the advantage of being everywhere Emacs already is as well

I like mg as an emacs-like editor that is simple and quick. Made by the great OpenBSD folks and is of great quality with good documentation.

Actually made by David G Conroy while he was at Mark Williams, and open sourced. I kicked around to various folks and ended up in the gnu fold.

If I want a light version of emacs (like on OpenWRT, or a constrained embedded device) I reach for JOVE, or Jonathan's Own Version of Emacs. JOVE was actually the version of emacs I first learned on back in the late 80s.

JOVE is tiny, and has implemented a huge amount of emacs. After you spend 15 minutes or so tweaking your .joverc file you won't even notice it's not GNU.

When I'm not using an IDE, I'm a vi user because it's always there. When my /usr on FreeBSD has issues, vi is in /bin. OpenWrt ships with vi. I honestly have no idea if Emacs is any better, but not being a default makes it a non-starter for me.

Do you really have that many occasions to work in an environment where you can't ask for/install a package?

Limiting yourself for such rare occasions just sounds wrong.

Production corporate environments are often firewalled/locked down. To change anything you have to go through layers of dis/approval. You are generally stuck with the defaults till the end of time.

I also used nano quite a bit for quick editing tasks, but that changed after I learned Vim.

Yup same here. It's not any slower IMO.