I think there are a lot of people who are not comfortable with vi. Its much the same reason that some Linux distros default to nano.
I spend a fair bit of time on Linux command lines, but I use a mix of different TUI and GUI editors (including ones that work over ssh for editing files on servers), and none of those are vi. I can manage vi if I must, but its an effort and distracts from the task because I have to think about how to do things in vi.
It's funny because I learned enough vi to be useful specifically because of NetBSD forcing you to change "rc_configured=NO" to "rc_configured=YES" in rc.conf.
You can ask Claude to cross-complie, prepare an image (aka install) and run an emulator. I tried exactly this yesterday and in about an hour I could attach to tmux and run tests on emulated riscv64 board.
Oh no! What does that mean for using Wine to play games? From what I understand a lot of Windows games (especially older ones) require 32-bit Wine, which requires 32-bit libs (which I assume requires 32-bit Kernel support). It's the sole reason I run 64- and 32-bit multilib on my Arch box: playing Windows games.
64 bit Linux can run 32 bit programs just like Windows. Modern Wine is using a WoW64 model where the 64 bit host code loads 32 bit DLLs when some app needs them.
NetBSD is IMHO the most beginner friendly nix out there. It's small, lean, and well documented. You could know almost nothing about nix, read their handbook, and come the other side half competent. Linux (my daily driver) by comparison is a constantly moving target with no single source for coherent documentation and where anything goes. FreeBSD is better, but when I last used the handbook it had plenty of outdated chapters, and it seemed like everything had so many different ways of doing things. NetBSD had small elegant solutions, and recompiling your entire system from scratch was a pleasant experience that didn't have me trapped in dependency hell or even needing to consult documentation after I got started.
> NetBSD is IMHO the most beginner friendly nix out there.
I'd argue that OpenBSD would be worthy of that title, too. It is incredibly easy, elegant, and simple. The thoughtfulness that goes into all the base system utilities in OpenBSD is so appreciated.
FreeBSD is kinda somewhere in between Open/NetBSD and Linux in my opinion. Their docs are OK, but the handbook leaves a lot to be desired, and they don't seem to have nearly nice little quality of life utilities that OpenBSD has out of the box.
> Perhaps all that needs to be known to use atto at a basic level is that holding the control key, pressing x, then pressing w will write the currently open file, and holding the control key, pressing x, then pressing c will exit the editor.
Very beginner friendly lol. These people have no idea.
Micro is a beginner-friendly console text editor. This isn't.
Nothing in the README file says the point is to be "beginner-friendly"; as far as I can tell, that's something that Hacker News or whoever submitted this used as a description. Neither the word "beginner" nor the word "friendly" appear in the README; its goal is to "be the smallest fuctional Emacs in less than 2000 lines of C."
tl;dr: I think somebody incorrectly described Atto as comparable to nano/pico, and these comments are dragging it because it's not the thing that it was never meant to be.
>making it suitable for inclusion in the rescue system
People seem to be missing the point. Also NetBSD has what I call a "read single user mode". Last time I had to boot single user, ed(1) was the only editor available without some work. My guess is this new editor will be useful for people who do not want to deal with ed(1).
I have not seen it yet, but I guess it will be includes in 11.1.
Why are they using weird key combinations instead of traditional Ctrl + S, Ctrl + A, Ctrl + C used in desktop applications? Why every console program wants to be a special snowflake and not use standard key combinations, please explain. I do not care that 40 years ago someone used Ctrl + C to send SIGINT, it is 2026 now.
For many, it is indeed about what they call "muscle memory". Almost impossible to change after so many years. And therefore I hope everyone would provide keybinding alternatives generally (shouldn't be that hard).
These key combinations have been used for 50 years, so I'm not sure why you call them non-standard. They're just a different standard from what you're used to.
To promote this to a top-level comment, because I think it's important context: nothing in the README file says the point is to be "beginner-friendly". As far as I can tell, that's something that Hacker News or whoever submitted this used as a description. Neither the word "beginner" nor the word "friendly" appear in the README; its goal is to "be the smallest functional Emacs in less than 2000 lines of C."
I think somebody incorrectly described Atto as comparable to nano/pico, and these comments are dragging it because it's not something that it was never intended as.
> To ease the transition for new users, #NetBSD -current now includes an alternative editor to vi(1) and xedit(1) in its base system, atto(1). https://man.netbsd.org/atto.1
> It is a modeless screen-based editor similar to nano, pico, xedit, or emacs. It is only 48 kilobytes, making it suitable for inclusion in the rescue system.
I think it's fair to call it beginner-friendly, in context of BSD and vi, but maybe indeed it shouldn't be part of the title.
I can't imagine a beginner really knowing what is going on in nano.
Every time I get launched into nano/pico on a new system I find it very confusing. To use the help menu you need to know that ^-X means Ctrl-X and M-X means Alt-X. Why "Write Out" and not "Save"? And when I "Write Out" I'm offered DOS format or Mac format, and options to Append or Prepend (not even sure what that does).
It's completely bizarre if you're used to something like Notepad or Word.
> I can't imagine a beginner really knowing what is going on in nano.
When you launch nano without a file loaded, there's a notice at the bottom of the screen: [ Welcome to nano. For basic help, type Ctrl+G. ]
Press 'Ctrl + G' and it takes you to a help page that says, among other things, "Shortcuts are written as follows: Control-key sequences are notated with a '^' and can be entered either by using the Ctrl key or pressing the Esc key twice. Meta-key sequences are notated with 'M-' and can be entered using either the Alt, Cmd, or Esc key, depending on your keyboard setup."
You can't force a user to read docs or learn how the programs they're using work, but this is a reasonable attempt.
Just FYI, they did try to improve that a bit. Release notes for nano v8.0:
> Command-line option --modernbindings (-/) makes ^Q quit, ^X cut, ^C copy, ^V paste, ^Z undo, ^Y redo, ^O open a file, ^W write a file, ^R replace, ^G find again, ^D find again backwards, ^A set the mark, ^T jump to a line, ^P show the position, and ^E execute.
> Above modern bindings are activated also when the name of nano's executable (or a symlink to it) starts with the letter "e".
So if you symlink nano to /usr/bin/editor and make it the default $EDITOR, then you now do get CUA-like bindings by default.
There’s still a lot of more things they perhaps should enable by default. I don’t know whether you’ve looked into .nanorc, but you can turn on stuff like syntax highlighting and line numbers, it’s just all off by default.
I don’t actually use nano myself, but I was really taken aback by how featureful it is when you look closely. Not st the level of Vim or Emacs, but more than expected. I basically stumbled upon someone on Reddit /r/unixporn that "riced" their nanorc and it piqued my curiosity.
For most people though, I think micro is a better fit than nano if you want a terminal CUA-style editor.
Well nano pico atto ... the name makes it comparable. Why would you expect people to not draw that connection?
I think the main take-away is that vi/vim is too complicated for many folks. I use nano a lot on the commandline. For quick editing it is so much more convenient than vim.
> nothing in the README file says the point is to be "beginner-friendly"
"for users who are not accustomed to text editors with separate insertion and editing modes"[0] could be construed as "beginner-friendly" (albeit with some squinting, I'd concede.)
Who knew a little emacs-like editor would be so controversial.
I think it looks great. Syntax highlighting, multi-buffer, splits, standard emacs commands... For new users in the emacs camp, this seems like a nice editor to include in the base install. Even as a vi user, I'd be pretty happy being stuck with this in a rescue system.
I've used mg and find it generally useful. It's my default editor pretty much everywhere.
However, the code is a mess, with deliberately cryptic identifiers (e.g., `w_doto` for `cursorOffset`), redundant functions (e.g., `vtputc()` is a strict subset of the behavior of `vtpute()`) and a bunch of other weird choices (e.g., deeply-baked assumptions that one byte == one char == one column, even thought Big5 and ShiftJIS were already a thing when it was written).
I tried adding UTF-8 support to mg a couple years ago and basically gave up.
I always thought the essential feature of an emacs was its extensibility. I never felt that emacs was just a collection of keybinds and split buffer windows.
Note, I'm not talking about Lisp per se, just some kind of mechanic within the editor to allow the user to make extensions to it.
I guess it has poor (or nonexistent) unicode support in 48kb. My only gripe with NetBSD was its lacking UTF-8 support for many core tools (eg. wscons, vi when I used it as daily driver)
102 comments
[ 0.20 ms ] story [ 16.6 ms ] threadI spend a fair bit of time on Linux command lines, but I use a mix of different TUI and GUI editors (including ones that work over ssh for editing files on servers), and none of those are vi. I can manage vi if I must, but its an effort and distracts from the task because I have to think about how to do things in vi.
My favourite editor is mcedit, which you get by installing mc (midnight commander)
Like nano but (IMO) easier to use with a lot more features
I'd argue that OpenBSD would be worthy of that title, too. It is incredibly easy, elegant, and simple. The thoughtfulness that goes into all the base system utilities in OpenBSD is so appreciated.
FreeBSD is kinda somewhere in between Open/NetBSD and Linux in my opinion. Their docs are OK, but the handbook leaves a lot to be desired, and they don't seem to have nearly nice little quality of life utilities that OpenBSD has out of the box.
Very beginner friendly lol. These people have no idea.
Micro is a beginner-friendly console text editor. This isn't.
https://github.com/micro-editor/MICRO
I do think Micro is a nice editor, but we need a tiny, BSD licensed pico/nano for true beginners
Atto has a great man page that would give a user everything they needed to know if they were unfamiliar with emacs keybindings.
By this I mean, a beginner to NetBSD is already a far more competent user than a beginner in many other contexts of OS introductions.
How someone jumped to beginner-friendly from that is the real question.
tl;dr: I think somebody incorrectly described Atto as comparable to nano/pico, and these comments are dragging it because it's not the thing that it was never meant to be.
Linux:
per the link, atto(1) is 48 kilobytes.People seem to be missing the point. Also NetBSD has what I call a "read single user mode". Last time I had to boot single user, ed(1) was the only editor available without some work. My guess is this new editor will be useful for people who do not want to deal with ed(1).
I have not seen it yet, but I guess it will be includes in 11.1.
Edit: apparently it requires /usr to be mounted though
You are welcome!
https://github.com/hughbarney/atto
[1] https://github.com/microsoft/edit
Or ARM? It's from the 1980s! So old!
For many, it is indeed about what they call "muscle memory". Almost impossible to change after so many years. And therefore I hope everyone would provide keybinding alternatives generally (shouldn't be that hard).
That's… not what "standard" means.
Not "40 years ago". Non-stop all day every day for 55 years.
The fact that you personally don't use it today is as irrelevant as if you were ranting about "why doesn't Linux have a Start menu!? It's 2026!!!"
I think somebody incorrectly described Atto as comparable to nano/pico, and these comments are dragging it because it's not something that it was never intended as.
> To ease the transition for new users...
So I would consider it for beginners ("new users") and friendly ("to ease").
> To ease the transition for new users, #NetBSD -current now includes an alternative editor to vi(1) and xedit(1) in its base system, atto(1). https://man.netbsd.org/atto.1
> It is a modeless screen-based editor similar to nano, pico, xedit, or emacs. It is only 48 kilobytes, making it suitable for inclusion in the rescue system.
I think it's fair to call it beginner-friendly, in context of BSD and vi, but maybe indeed it shouldn't be part of the title.
Every time I get launched into nano/pico on a new system I find it very confusing. To use the help menu you need to know that ^-X means Ctrl-X and M-X means Alt-X. Why "Write Out" and not "Save"? And when I "Write Out" I'm offered DOS format or Mac format, and options to Append or Prepend (not even sure what that does).
It's completely bizarre if you're used to something like Notepad or Word.
When you launch nano without a file loaded, there's a notice at the bottom of the screen: [ Welcome to nano. For basic help, type Ctrl+G. ]
Press 'Ctrl + G' and it takes you to a help page that says, among other things, "Shortcuts are written as follows: Control-key sequences are notated with a '^' and can be entered either by using the Ctrl key or pressing the Esc key twice. Meta-key sequences are notated with 'M-' and can be entered using either the Alt, Cmd, or Esc key, depending on your keyboard setup."
You can't force a user to read docs or learn how the programs they're using work, but this is a reasonable attempt.
Nano was a (bloated as usual) GNU clone of Pico.
Pico was not developed as a standalone editor; rather it was the builtin editor for the Pine email reader.
Pico stood for PIne COmposer.
It became a simple universal editor because vi and emacs sucked and for some reason no one felt it necessary to invent something better.
Users repurposed the editor from a mail client because it was already there.
Fun fact it was written by the same guy that invented IMAP at the University of Washington.
People that do that are weirdos, and yes, I'm one. But I don't expect regular people to learn that way.
> Its only reason for existing is GPL freedumb nonsense that was popular back in the day.
These days we need more GPL, not less. We need AGPL and apparently, soon, AntiLLM-GPL.
> Command-line option --modernbindings (-/) makes ^Q quit, ^X cut, ^C copy, ^V paste, ^Z undo, ^Y redo, ^O open a file, ^W write a file, ^R replace, ^G find again, ^D find again backwards, ^A set the mark, ^T jump to a line, ^P show the position, and ^E execute.
> Above modern bindings are activated also when the name of nano's executable (or a symlink to it) starts with the letter "e".
So if you symlink nano to /usr/bin/editor and make it the default $EDITOR, then you now do get CUA-like bindings by default.
There’s still a lot of more things they perhaps should enable by default. I don’t know whether you’ve looked into .nanorc, but you can turn on stuff like syntax highlighting and line numbers, it’s just all off by default.
I don’t actually use nano myself, but I was really taken aback by how featureful it is when you look closely. Not st the level of Vim or Emacs, but more than expected. I basically stumbled upon someone on Reddit /r/unixporn that "riced" their nanorc and it piqued my curiosity.
For most people though, I think micro is a better fit than nano if you want a terminal CUA-style editor.
I think the main take-away is that vi/vim is too complicated for many folks. I use nano a lot on the commandline. For quick editing it is so much more convenient than vim.
"for users who are not accustomed to text editors with separate insertion and editing modes"[0] could be construed as "beginner-friendly" (albeit with some squinting, I'd concede.)
[0] https://man.netbsd.org/atto.1
I think it looks great. Syntax highlighting, multi-buffer, splits, standard emacs commands... For new users in the emacs camp, this seems like a nice editor to include in the base install. Even as a vi user, I'd be pretty happy being stuck with this in a rescue system.
https://man.openbsd.org/mg
Just noting for completeness, as I didn’t catch any mention of it.
However, the code is a mess, with deliberately cryptic identifiers (e.g., `w_doto` for `cursorOffset`), redundant functions (e.g., `vtputc()` is a strict subset of the behavior of `vtpute()`) and a bunch of other weird choices (e.g., deeply-baked assumptions that one byte == one char == one column, even thought Big5 and ShiftJIS were already a thing when it was written).
I tried adding UTF-8 support to mg a couple years ago and basically gave up.
I'll probably be an atto convert.
Well, sometimes we call the cursor "the dot."
https://docs.moodle.org/400/en/Atto_editor https://github.com/moodlehq/moodle-editor_atto
I feel like most people who even know about NetBSD would be technical enough to at least function at a basic level in something like vi or nano.
> atto is not the standard editor.
Hah. That is clearly a reference to https://www.gnu.org/fun/jokes/ed-msg.en.html
Note, I'm not talking about Lisp per se, just some kind of mechanic within the editor to allow the user to make extensions to it.
unless someone can offer a custom keybinding mechanism.. and custom dynamic functions the user can bind to..
> atto is not the standard editor