
Nano 5.0 - doener
https://lists.gnu.org/archive/html/info-gnu/2020-07/msg00010.html
======
picodguyo
Thank you for you work on Nano! I'll never understand the elitism around text
editors in the Linx world but am glad a user-friendly option like Nano exists.

~~~
jasonkester
Indeed. I kinda wish they would go the rest of the way and implement the
standard keyboard commands that every other editor in the world (apart from
vi/emacs) uses though.

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.

~~~
signal11
vim works quite well with standard keyboards. Put this in your .vimrc:

set nocompatible

behave mswin

~~~
gpanders
Or use `evim`.

Btw, 'set nocompatible' is never necessary in a vimrc file. When Vim detects a
user vimrc file, it automatically sets nocompatible.

------
BiteCode_dev
A bit of a plug, but micro has been a nice alternative. Mouse support is
enabled by default, ctrl+c/v works as expected, you only need to remember
ctrl+e for other commands, as it opens a prompt where you can just type
save/quit/etc.

Not in the repo though, which can be a no deal for many.

~~~
orra
Oh right, it uses the operating system clipboard? That's kinda handy.

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.

~~~
alpaca128
And then there's Vim which, depending on how it was built for the respective
distro, doesn't seem to accept any way to copy or paste text.

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.

~~~
simias
I understand your practical frustration, but it can be very tricky with
terminal apps to reliably interact with the X display. It's basically a
completely foreign interface that requires the environment to be setup
properly.

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.

~~~
kevin_thibedeau
Middle click paste should "just work" and be transparent to terminal apps.
It's not encouraging that vim is willing and able to break this in its default
settings.

~~~
simias
I could be misremembering but I believe that middle-click paste just makes the
terminal feed the contents of the X selection to stdin of the running process.
I could be wrong (because there's so much arcane knowledge in terminal
emulators that I won't even pretend to have scratched the surface) but I'm not
sure if Vi(m) can even tell where the input comes from. Well, maybe it could
by using the speed at which the characters come in I suppose, although even
that might end up being unreliable over remote connections and the like.

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.

~~~
boring_twenties
> middle-click paste just makes the terminal feed the contents of the X
> selection to stdin of the running process.

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.

------
pavelevst
Thanks to nano team for great work. It’s my favorite terminal editor for last
10 years. Too bad many systems has vi as default editor

Most liked features: kut lines, page up/down, easy search, syntax
highlighting, editing long lines

------
jjice
When I was in high school and used my first Linux machine (a Raspberry Pi),
Nano was always the recommended editor when I had to edit config files while
not knowing what I was actually doing. Nano is great for those use cases for
sure.

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.

~~~
mikece
> When I was in high school and used my first Linux machine (a Raspberry
> Pi)...

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!).

~~~
boring_twenties
Actually you just made me feel really young! My first taste of Unix was a
dialup shell account in the early 90's. IIRC, vi was the only editor
available.

------
HeckFeck
I wonder which editor the Nano devs use. It would make for an ironic anecdote
if any used Vim or Emacs.

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.

~~~
true_religion
I would imagine they use a full feature IDE, not a minimalist editor.

It’s like expecting the maintainers of notepad.exe to use notepad itself
during development and not Visual Studio.

------
pawnednow
Nano has always been my go to editor. It comes natively with most install and
is very easy to use. It has all the shortcut listed on page so it is quite
user friendly out of the box.

After learning vim for a bit, I find nano quite superior for my use case
mainly editing files inside terminal on remote servers.

~~~
RMPR
> Nano has always been my go to editor. It comes natively with most install

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...)

~~~
EE84M3i
>I just don't understand how this is possible

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
    

\- I use ^K and ^U to cut and paste lines of text.

\- 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.

~~~
innocenat
I know it's not the point you were answering too, but this is exactly why I
don't think I will be comfortable in nano, ever. I already know vim, and I
don't really bother to remember another set of shortcut just for nano.

When vi/vim aren't available, I usually just end up using sed.

~~~
magicalhippo
The only thing you need to remember with Nano is that ^ means Ctrl. The rest
you can find by reading the menus or the built-in help.

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.

------
Havoc
Really wish all linux systems had it installed out of the box.

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

~~~
EE84M3i
What systems don't come with nano these days?

~~~
easton
CentOS/RHEL didn’t ship with it forever (at least to 7), I don’t know if that
changed with 8 but it was one of the reasons I learned enough vi to be
dangerous, as I had to debug a bunch of weird networking stuff on VM guests
that were CentOS 5.5.

~~~
mindwok
You might be happy to know that Fedora recently changed Nano to the default
editor, which means it will likely land in RHEL as the default eventually.

------
112233
"nano -w" is a great editor. "nano" without -w should be banned like "rm -rf
/" and require some long DWIM switch to even start.

~~~
mac01021
Not wrapping should be the default for every editor. AFAICT, it is not the
default for any editor.

I don't think nano is unique in this respect.

~~~
zeveb
> Not wrapping should be the default for every editor. AFAICT, it is not the
> default for any editor.

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?

~~~
mac01021
I do! It makes it difficult to see what's going to happen when I invoke
operations on lines. And it encourages my colleagues to create long lines that
would play better with diff tools like git diff if broken out.

------
nxpnsv
Checked what came with osx

    
    
        >>> nano --version
        GNU nano version 2.0.6 (compiled 14:41:52, Apr 17 2020)
    

comfortingly my freshly brewed 5.0 looks identical when editing...

Also:

    
    
        >>> ls -l /usr/bin/pico
        lrwxr-xr-x root wheel 4 B Thu Jan 23 17:02:12 2020 pico ⇒ nano

~~~
Lammy
And of course here's why:
[https://git.savannah.gnu.org/cgit/nano.git/commit/COPYING?id...](https://git.savannah.gnu.org/cgit/nano.git/commit/COPYING?id=d0035b4ab28c061c6ecabfd2945e05d55d6f3f70)

~~~
teddyh
Related, for more context: [http://meta.ath0.com/2012/02/05/apples-great-gpl-
purge/](http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)

------
sdan
I started using Nano because of the Digital Ocean blogs. I still use it 4
years later, everywhere from side projects to firefighting in production. It's
so simple and easy to use and I'm looking forward to 5.0 changes!

------
tarkin2
For config file editing, nano is great.

Vim'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...](https://stackoverflow.com/questions/8854371/vim-how-to-restore-the-
cursors-logical-and-physical-positions)

~~~
throwdbaaway
That would be:

    
    
        ## Remember the cursor position in each file for the next editing session.
        set positionlog
    

The flag was there since 2011, but I only started to enable it a few months
ago. Pretty nifty feature, although it took me some time to get used to the
new flow.

------
qubex
Nano is my dog in the Vim-vs-Emacs holy war.

------
nephrite
Nano is great as an idea - a editor with almost no features which is small,
fast and is everywhere. Howerer, it suffers from the same as all open source
projects. Working on it is fun, so they add new feautres with each version.
Now 'nano' is not nano anymore. It even has had syntax highlighting for some
time already.

~~~
zvrba
> Now 'nano' is not nano anymore.

Nothing beats plain old 'vi' (NOT vim!).

~~~
marcocampos
Do distros still come with original vi? My understanding is that when you type
'vi' you get a minimal version of vim on most (all?) distros theses days.

~~~
zvrba
'vi' is still 'vi' in OSX, and I believe the "original" 'vi' is accessible as
'nvi' on the usual Linux distros. (e.g.,
[https://packages.ubuntu.com/focal/nvi](https://packages.ubuntu.com/focal/nvi))

~~~
fanf2
nvi is new vi, released as part of 4.3BSD-net2. The only place I have
encountered original vi is on Solaris. Solaris vi does horrible things like
crashing if you maximize your xterm too big...

------
seemslegit
I wonder how many people here know about mc (as in midnight commander) and its
builtin viewer/editor.

~~~
BaldricksGhost
I love Midnight Commander. It's the first thing I install on any Linux system.

------
AlchemistCamp
I despise Nano. I support the effort of anyone working on open source, but
really don't like using the editor personally. As a result, it's really
frustrating when setting up a new box and VIM isn't the default.

~~~
magicalhippo
> As a result, it's really frustrating when setting up a new box and VIM isn't
> the default.

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.

~~~
greyman
I agree. And if you only occasionally need text editor on a linux server, like
when you change some config file or update cronjob and nothing more, nano is
perfectly adequate, without needing to learn all the vim shortcuts.

~~~
cesarb
> And if you only occasionally need text editor on a linux server, like when
> you change some config file or update cronjob and nothing more, nano is
> perfectly adequate

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).

~~~
greyman
Thanks, I check that flag. Anyway, I never encountered the problem you are
mentioning...

------
james_s_tayler
nano is the best.

~~~
logicchains
But it's not standard. Ed is the standard editor.

~~~
james_s_tayler
It's the standard of how my brain operates.

------
karmakaze
I was always been annoyed whenever an editor other than vi opened in a
console/terminal. Recently I've been learning an alternative keyboard layout
which has gone well--except that my vi muscle memory is completely broken. I
think I'll appreciate this now and accept it gladly even when my new vi
memories are formed.

------
einpoklum
Wow, those are useful improvements... especially the toolbar. A bit slow in
arriving, but still good.

> 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

------
ChicagoDave
Nano is the singularly greatest tool for Windows users to be productive
administrating a Linux implementation. I love this editor and have been using
it since it’s first release.

------
varbhat
I am currently using vis editor[0] and I am liking it.

[0] [https://github.com/martanne/vis](https://github.com/martanne/vis)

------
jason_slack
I've often thought about contributing to the nano project. Having written a
few editors myself I still have a passion for it. I use nano for quite a bit.

------
panpanna
If you are an emacs person but need something like nano for quick edits on
remote machines, try "mg".

I think it's the default editor on some BSDs.

------
mikece
I don't do a ton of editing in a non-graphic environment but enjoy confusing
the other C# coders at work by editing a code file in vim with ConEmu from
time to time. I never thought to see if Nano was also in ConEmu until reading
the linked announcement and these comments -- and it is! I'll have to play
with Nano a bit more but it seems like the difference between editing in
Notepad versus VS Code: good for really simple stuff but the power of vim is
needed if you're doing something non-trivial.

------
haolez
Once, as a little personal challenge, I've used solely nano + fzf as my IDE
and programming editor. I went pretty far with it :)

~~~
interactivecode
how far can you go? I've been on the lookout for a friendly vim like editor.
at the same time I really like a IDE features

------
orra
Interesting — I did not realise Nano was a GNU project again. In fact, Nano
apparently did not leave GNU for very long.

~~~
__s
For details: [https://nano-editor.org/news.php](https://nano-
editor.org/news.php)

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](https://news.ycombinator.com/item?id=11953044)

Blog post by Chris: [https://www.asty.org/whats-up-with-
nano](https://www.asty.org/whats-up-with-nano)

"Request to move nano from gnu to nongnu"
[https://savannah.nongnu.org/support/?109076](https://savannah.nongnu.org/support/?109076)

"[Nano-devel] nano to remain in GNU" [https://lists.gnu.org/archive/html/nano-
devel/2016-08/msg000...](https://lists.gnu.org/archive/html/nano-
devel/2016-08/msg00045.html)

~~~
garbagetime
>For details: [https://nano-editor.org/news.php](https://nano-
editor.org/news.php)

That's a beautiful website.

------
imode
This editor is my daily driver. Has been for years and years. Glad it's still
kicking!

------
SomeoneFromCA
mcedit is what use instead of nano. Similar to the editor in Far Manager and
Norton Commander.

------
elchin
I'm bothered by the UI design of this webpage.

------
mlang23
The first thing I uninstall on a new system is nano.

~~~
Barrin92
I don't uninstall it but I don't really get the love, mostly because of the
keybindings. Maybe I'm too young and don't know its legacy but they seem super
esoteric to me and I've never seen them anywhere else. Emacs navigation
bindings are similar to terminal bindings, and well vi is its own world but at
least fairly widespread today.

~~~
einr
nano is a GPL-licensed clone of pico, which in turn was originally conceived
as the integrated message editor in PINE, the popular UNIX e-mail client first
released in 1989. If you look at the overall interface of PINE you will
recognize that it is consistent with pico/nano, but other than that there
really wasn't much consistency in terms of keyboard commands between apps in
1989.

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.

