Nano 5.0
lists.gnu.org
lists.gnu.org
I loved using Nano for a long time before I picked up Vim. I don’t get the elitism either, Nano is a great editor.
Ctrl+c, ctrl+v, ctrl+x, ctrl+a, shift+arrow/home/end/pgup/pgdn/etc. etc to select text. It would completely eliminate the learning curve to edit text on linux, which seems like it could only be a good thing.
set nocompatible
behave mswin
Btw, 'set nocompatible' is never necessary in a vimrc file. When Vim detects a user vimrc file, it automatically sets nocompatible.
Edit: Oh, I see it's been recommended in this thread already.
weird right
Not in the repo though, which can be a no deal for many.
In other terminal editors I sometimes have to do a slight pause, to work out whether I'm using the editor-in-built yank chain, or pasting from operating system clipboard using the not-as-standard-as-Ctrl-V terminal emulator binding, Ctrl-Shift-V.
Isn't this something that benefits mainly developers, at the expense of everyone else? Most people don't use the terminal, so they don't have any use for control-x/c/v. At the same time super-x/c/v is less ergonomic than control, at least for me. With control I can use my pinky + index finger, which is much more comfortable than using super, which requires me to awkardly use my thumb + index.
[edit] every default layout for English, I mean. I wouldn’t expect a default layout for another language to be great for composing English text, obviously.
I'm not sure what you mean by "stretch down to ctrl". On a standard keyboard, with the control key in the bottom left corner, all you need to do is rotate your left hand slightly and use your pinky to press it. Doing so also puts your index finger in position to press the x/c/v keys. On a mac keyboard this is less doable because the control key is swapped with the fn key, but it also doesn't make pressing the command key any easier, as you still have to bend your left thumb to reach the command key (this is most apparent with c/v).
>The rest of the layout is wildly better than any other I know of for composing text in English
is this on non-US layouts? Looking at this https://store.storeimages.cdn-apple.com/4982/as-images.apple... or https://store.storeimages.cdn-apple.com/4982/as-images.apple..., the rest of the keyboard looks pretty close to standard ansi layout.
Again, I did the standard Linux/windows thing for like 15 years before switching to Mac, so I don’t think I prefer it just due to familiarity.
[edit] the key to their layout being so good for writing is how Option/Alt is used. Option plus a character will often get you a common modified version of that character that’s very useful (so you can type, say, façade, or a —, quickly and easily). Holding option changes practically every key on the keyboard, and shift+option does it again to a different set of chars. They’re not perfectly discoverable and some are compose keys (but visible on the screen, not hidden as a key that seems to do nothing!), but if you forget where the cent sign or euro or or pound are it’s easy to remember they’re in the numbers somewhere near dollar and find them again in a second or two.
[edit edit] the international layout can be better for some people but is basically obsoleted by Mac’s “hold a key and see accented versions to choose from” functionality, and alt-gr is similar to what Mac’s standard English layout does, except worse.
As a daily Vim user I find this to be a huge mistake in terms of user friendliness; Vim provides ways to set the clipboard as default register and other quality of life improvements, but until then a beginner has to figure out some of the weirdest keybindings to make it work, or even recompile the program because that specific distro didn't include xclip support for some reason. It is infuriating.
But in general I just install gvim (even if I only use Vim in the terminal) since it normally means that it'll have proper X support.
In my humble opinion expecting good X integration for a terminal application is bound to result in frustration. I use vim in the terminal but I also never use the mouse and I configure Vim not to interact with the X selection unless I specifically instruct it to using "*. If you want better integration with the graphical environment why not just use gvim? That's what it's for.
Recent versions of vim hijack this by default (`set mouse=a`). This makes the middle click paste the default vim register instead of the X selection. To paste from X, you must shift+click.
Personally, I can't understand why anyone would want this, but anyway. The best part is that you can't easily disable this globally, i.e. by putting `set mouse=` in /etc/vim/vimrc. Because if a given user does not have a ~/.vimrc of their own, then defaults.vim gets loaded after /etc/vim, overriding anything set there.
I install GVim, since it tends to be compiled with the most features enabled. You can still use the vim executable in a terminal and ignore the gvim one. Then it's just "+y / "+p to copy/paste, or add this to vimrc to map it to \y, \p:
noremap <Leader>y "+y
noremap <Leader>p "+p
set clipboard=unnamedplusI believe on Alpine OS I could get it working fine by installing some dependencies and recompiling Vim manually.
Others here have suggested to install the gvim package which seems to enable proper clipboard support in every case, I will try that next time I am in that situation again.
The Windows version also works very well.
Micro is great.
Most liked features: kut lines, page up/down, easy search, syntax highlighting, editing long lines
But as I've spent more and more time with Unix systems, Vim was become by go to choice. The customizability and power of Vim is great, but there is a steep learning curve if you've never used a Unix machine before and you're just trying to get WiFi working.
With that said, use what you like, all text editors do the same job in the end: edit text.
Thanks for making me feel old! My first experience with editing text on a *nix system was vi on my older borther's AT&T SVR4 workstation in the 1980s when I was junior high (my apologies if that reference makes anyone else feel old!).
Not to say they couldn't edit their own source in their own editor, I'm sure it's quite up to the task. But I am curious to know.
It’s like expecting the maintainers of notepad.exe to use notepad itself during development and not Visual Studio.
That said, it probably happens.
After learning vim for a bit, I find nano quite superior for my use case mainly editing files inside terminal on remote servers.
While vi comes with all installs
> is very easy to use. It has all the shortcut listed on page so it is quite user friendly out of the box
Tell that to the users that don't know what ^ stands for
> After learning vim for a bit, I find nano quite superior for my use case mainly editing files inside terminal on remote servers.
I just don't understand how this is possible, except if you're doing very basic edits (even in that case...)
As such, I almost always just grabs nano for these things, and use an IDE when working on code.
Unfortunately, for me when I googled that exact phrase just now it gives a "Featured Snippet" saying it means "the beginning of a line", which is about regexen and and also only sort of right in that context. The wikipedia page is the first real result though.
Edit: I was spelling caret wrong. oops.
Edit: Also there are a lot of stories of "this old system that is central to our operation that nobody except that one guy 10 years ago knew how to set up" in companies.
But the person I replied to said 'all' which is incorrect. If he said 'most' or something I wouldn't have replied :)
I use nano as my daily driver, and here is how:
- I have a nanorc I copy around but am quite comfortable without. Here it is. You can use it under WTFPL-1. Feel free to fork it, but I'm not accepting pull requests.
set multibuffer
set nohelp
# Defaults for older versions
set nowrap
set smooth
set morespace
unset boldtext
- If I need to edit multiple files, I use ^R
- If I need to find and/or replace, I use ^W (find), optionally with ^R (replace) and/or M-R (Regexp).
- Sometimes I need to go to a specific line/col, so I use ^_
Basically there's nothing else I want my text editor to do. I want minimal magic.
When vi/vim aren't available, I usually just end up using sed.
If there's no nano available like on busybox, I'll default to vi, but I don't prefer it.
Which is why I prefer Nano over vim, I don't edit _that_ much from the console so I only have one easy thing to remember.
If you run `nano` it shows a message that you can get help using 'Ctrl-G'. In the second paragraph it tells you what '^' stands for. It will be a problem if you somehow ended in nano unintentionally. Even then someone can figure that it means either 'Alt' or 'Ctrl', that is the modifier keys.
>I just don't understand how this is possible, except if you're doing very basic edits (even in that case...)
Some people prefer or/and find easier to work with a modeless editor.
I think also I was on a real Linux box a few weeks ago (can’t remember what distro, sorry) that only came with ed by default. That was interesting, at least until I gave up and installed vi.
Most edits I do if I'm not on my daily driver is basic edits. Making adjustments to config files, etc. Doesn't require all the magic of Vim. Still prefer Vim though. Not having my Vim keybindings in an editor is like using a keyboard with a different layout.
The users who have already figured out how to open a terminal, find their file, know what nano is and how to launch it?
But yeah, editors are just a preference, especially when every single one of them works in 90% of cases. I actually forked nano a long time ago (back in college) just to implement some niche multi-cursor hack because one guy said it was one thing vim could do that nano couldn't. I know there's plenty that <any editor> can do that <some other editor> can't, but nano's always Just Worked and occupied a very special, reliable, spot in my heart.
To someone new to the command-line, Vim is not at all approachable. Once you know your way around Vim, it's a fantastic editor, and frankly Nano just doesn't compare, but you can't expect a newbie to be able to use Vim effectively. Without a tutorial and a deliberate effort to learn it, Vim is rather baffling.
To the question of what should be the default, I suppose it depends on the context. A power-user distro wouldn't have much use for Nano, the choice would be between Vim and Emacs.
- New to vi(m)? Close the editor by typing :q!
- Learn vi(m) by running the following program: vimtutor
VIM - Vi IMproved
version 8.2.814
by Bram Moolenaar et al.
Vim is open source and freely distributable
Help poor children in Uganda!
type :help iccf<Enter> for information
type :q<Enter> to exit
type :help<Enter> or <F1> for on-line help
type :help version8<Enter> for version info
That's why I think it makes total sense for nano to be the default editor in this day and age, even it if means that I'll have to remember to set EDITOR properly if I want to use vi(m).
I have used the IdeaVim plugin for IntelliJ, and honestly it was so bad it was worse than not having the plugin at all. Maybe 20% of commands actually behaved consistently with vim. And IIRC, a decent chunk of my preferred vim functionality was outright unimplemented.
Perhaps ironically, I didn't have any such problems with the (commercial) plugin for Visual Studio. It worked very well. It cost $100, but my employer paid for that.
I've basically given up on IDEs after that and just use vim itself. If you know of any that have a really good vi-mode plugin, I'd love to try one!
I guess they are being accommodative to people who don't know any editor to use, since those who have their favorite editor don't need to be told.
That being said, for new users without bias, nano definitely seems easier.
"You can't figure out how to get out of the editor? I'm busy, stop asking me stupid questions. Look for the answer on Stack Overflow. Make sure to leave your mark there by up-voting the answer."
On topic: It's weird that nano is so beloved, but good that GNU just keeps pushing out things as long as they are used.
Type :qa! and press <Enter> to abandon all changes and exit Vim
Maybe not quite what the user was looking for. But I guess it does get you out of Vim.
ETA: Also, that answer on Stack Overflow at one time was the answer with the most traffic on the site. Reading must be a common problem for trapped Vim users.
So if I can't keep muscle memory of Vim keybindings, and I have never found a Vim configuration I've been happy with, why was I so stubbornly holding onto the idea that Vim was the right editor of choice for me? I don't know, but I finally changed my mind and looked for another editor. A dead simple one with sane defaults.
It came down to Nano vs Micro for me. Both are great. I ended up liking Micro a bit better, although I'm very glad to see that Nano development is still active.
vi/vim is difficult for newbies. And the crowd that uses vi/vim will know how to install their editor of choice while the newbie doesn't necessarily
Not a disaster, but I don't personally have those arcane vi keyboard shortcuts memorized so even a small tweak to the config is unnecessarily painful
ah yes. That explains why my mind was so fuzzy & I couldn't place what specific distro I encountered this on.
I don't think nano is unique in this respect.
It appears to be the default with emacs — at least, hard-wrap off appears to be the default. Soft-wrap is on, but … I can't imagine that you dislike soft-wrap, do you?
>>> nano --version
GNU nano version 2.0.6 (compiled 14:41:52, Apr 17 2020)
Also:
>>> ls -l /usr/bin/pico
lrwxr-xr-x root wheel 4 B Thu Jan 23 17:02:12 2020 pico ⇒ nanoVim's 'return me to the last location in this file'[0], however, is great when repeatedly editing large config files in this same place.
Nano should try to implement it, if it hasn't already.
[0] https://stackoverflow.com/questions/8854371/vim-how-to-resto...
## Remember the cursor position in each file for the next editing session.
set positionlog
Nothing beats plain old 'vi' (NOT vim!).
Of course, ed beats that, and the combination of cat and echo with redirection beats that (for a very limited definition of ‘editor’)
I just discovered that it supports syntax highlighting, multiple buffer support, macros, a file browser and auto-indentation. It's only a matter of time before it gets Python scripting support. I'm sure its great if you like the editor but for something that's called "nano" it definitely reeks of feature creep, actually I just checked that the nano binary on my system is actually bigger than vi.
That being said when the most popular code editor these days is an Electron app, I suppose that "nano" is not technically false advertising.
This has been the case for at least ten years. I started using Linux in 2009 and the first time I opened vim, I tried using ctrl-c to quit and saw that message.
However having Nano as default is the better choice. You as an expert know how to change the default. Newbies who don't likely will prefer a discoverable editor like Nano.
That's precisely when nano is the least adequate: "sudo -e" or "crontab -e" won't pass the "-w" flag to nano, and without that flag, the automatic hard line wrapping can easily corrupt config files which depend on line breaks for their semantics (a crontab being a great example, where each line is a separate entry).
Speak for yourself. It's not better for me and I had to do some googling to figure out how to change the default when it was changed to Nano. I'm not an "expert" in any sense, but I'm sure a lot more comfortable with VIM than Nano.
Also, I'm not sure most people setting up VMs newbies, at least in the way you're using the word. I have no problems with Nano being installed as the default on some distros. I just wish it weren't on the one I use!
$ time emacs -nw -q --eval '(save-buffers-kill-terminal)'
emacs -nw -q --eval '(save-buffers-kill-terminal)' 0.06s user 0.01s system 99% cpu 0.077 total
I helped some guys there, shown them how to use nano. And then could move on with the ES demo.
But some !@$ in some distros or programs set the defaults of nano to not show the "help lines." So I know it's Nano, but as I don't use it all the time I don't remember how to do anything but typing the text.
Not a good configuration.
And still, at least after the Esc was pressed it should show the help lines, and not pretend nothing's happened! That's a missing feature! Even decades ago the user friendly text based editors had that.
And the help is still talking about the "Meta" key -- when have you the last time seen the physical keyboard with the key labelled as "Meta"?
Occasionally I've been taken to vi or vim and I wouldn't know how to cut/save the file. So I appreciate Nano for exposing those actionsore clearly.
Maybe the alternative would be to ask user what editor they want to use whenever they try to edit a file - yet suggest Nano as the default for those who have no experience on any other editor.
Debian's has `set nowrap`.
It was a long time ago, back in the 90s; it probably was either Debian or Slackware or Conectiva.
Edit: it probably was Debian, I found contemporary bug reports complaining of that, for instance https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=127634 and according to https://metadata.ftp-master.debian.org/changelogs/main/n/nan... the default /etc/nanorc was changed to disable wrapping only many years later in 2.0.9-2; even then, you're still depending on nobody commenting that line on /etc/nanorc. Removing the whole package is much safer.
Compare that to Vim: it's a great tool for coding, very powerful, you can easily customize it, optimize it to your needs, but you actually need to spend time learning to use it, and then tweaking it to your work.
Nano, on the other hand, works properly as an editor.
However, I just realised that if I think of micro as a notepad alternative, the keybindings make total sense.
> For the color names red, green, blue, yellow, cyan, magenta, white, and black, the prefix 'light' gives a brighter color.
Catching up to the Nineteen...eighties, I think? :-P
I think it's the default editor on some BSDs.
Leaves GNU in 2016 June 17, rejoins GNU in 2016 September 1
Some past HN insight (Misleading information in my HN thread? It's more likely than you think): https://news.ycombinator.com/item?id=11953044
Blog post by Chris: https://www.asty.org/whats-up-with-nano
"Request to move nano from gnu to nongnu" https://savannah.nongnu.org/support/?109076
"[Nano-devel] nano to remain in GNU" https://lists.gnu.org/archive/html/nano-devel/2016-08/msg000...
That's a beautiful website.
I get stuck in nano like other people get stuck in vim. I definitely prefer vi as the default editor. But I understand that this does not apply to everyone.
More importantly, while for instance ^S for "save" might seem more natural than ^O for "writeOut", remember that dumb terminals over slow lines were still very much a thing in 1989 and ^S was already used as a terminal control code for XOFF (software flow control) -- which is why nano throws that "XOFF ignored, mumble mumble" message when it catches ^S.
But I always change the default editor to something more emacs-y:
export EDITOR=/usr/bin/mg