Live data from Hacker News

GNU Nano 4.0

nano-editor.org

71–80 of 154 posts

Re: GNU Nano 4.0

#71
post #49
post #30

Earlier quoted context omitted.

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.

Re: GNU Nano 4.0

#72
post #61

Earlier quoted context omitted.

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.

Easy to scp micro or nanorc over with one command.

Re: GNU Nano 4.0

#73
post #47

>An overlong line is no longer automatically hard-wrapped. Finally. It was one of the most insane defaults in the history of text editors. Things like this are the reason why it's so hard to recommend nano to beginners.

I like the idea of hard wrap, line of code shouldn't be longer than 80 characters... sure it's confusing for beginners + sometimes data shouldn't be hard-wrapped, but in general (imho) it's better than worse

So error out in your parser that uses those files.

Re: GNU Nano 4.0

#74
post #50
post #2

>A newline character is no longer automatically added at end of buffer. yesssssssssss

Such an insane default. Currently programming a bittorrent client and was edited files to test some functionality. Was confused for a long time until I realized nano was turning my "echo 'this is a test' > test" into "echo 'this is a test\n' > test"

Pretty sure nano was changing your code to

    echo 'this is a test' > test\n
and then echo was adding the newline because you didn't specify -n.

Re: GNU Nano 4.0

#75

Earlier quoted context omitted.

For a stable piece of software the build script(s) somehow turn into a change hotspot. You might have not touched the core of the software in five years, but guess what, every couple months some change to the build script is necessary.

Depends on how much nonstandard stuff you’re using, and whether you have flags such as -Werror that can cause “new” build failures.

And on how many platforms the software is used. E.g. when people try to compile things on HP-UX, perhaps even an older version, things often get interesting.

Re: GNU Nano 4.0

#76
post #61

Earlier quoted context omitted.

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.

Re: GNU Nano 4.0

#77
post #56

Earlier quoted context omitted.

Genuinely curious, why do you see this as a good change?

Because if I type "hello" in a document, I expect the editor to save "hello", not "hello\n".

Where did you get that expectation? Every editor I've used up until Visual Studio Code did that by default.

(I was actually very surprised when vscode _didn't_ do this!)

Re: GNU Nano 4.0

#79
post #64

Earlier quoted context omitted.

The old behaviour is the sane default, at least for editing text files. POSIX defines a text file as a file consisting of a number of lines, each terminated by an LF character.

sane is what the user expects, not what POSIX demands.

One could reasonably expect that a user expects a POSIX system to behave according to the POSIX standards?

Re: GNU Nano 4.0

#80
post #50
post #2

>A newline character is no longer automatically added at end of buffer. yesssssssssss

Such an insane default. Currently programming a bittorrent client and was edited files to test some functionality. Was confused for a long time until I realized nano was turning my "echo 'this is a test' > test" into "echo 'this is a test\n' > test"

Running "echo 'this is a test' > test" produces a file with a newline at the end.
Post reply on HN