Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Nano 4.0

nano-editor.org

Post reply on HN
Print view View original

131–140 of 154 posts

Re: GNU Nano 4.0

#131

Post by Sniffnoy »

lexicality wrote: post #121
Sniffnoy wrote: post #100

Earlier quoted context omitted.

I mean, it ought to be possible to use a text editor to specify exactly what I want in a text file. If a newline is silently added at the end, then, well, that isn't happening. Edit: Which is to say, I don't think l24ztj is using "expect" in the sense of "anticipate" but rather, y'know, the other sense. (Using Wiktionary's definitions: "To consider obligatory or required" or "To consider reasonably due".)

What do you mean by "exactly" though? What is the "exact" value of "e"? 0x65? How about "é"? You expect your editor to take what you've written and provide a valid text file with that information in it, which can then be read by something else. Applying the correct text encoding (UTF-8?) and adding a 0x0A as the last byte are part of making it valid. If you want to specify the exact bytes on disk, you should use a he…

The correct text encoding is the one I specify. UTF-8 is a decent default. Where did that bit about 0x0A come from? That's just an extra byte. There's no text encoding that says "to decode this you should first remove the 0x0A at the end, which is not part of the text".

I should only need a hex editor if I want to make a file that can't be decoded as text under a known encoding, and no encoding I know (and certainly none that I use) has the encoding/decoding rule I mentioned above. I certainly shouldn't need one just to make a validly-encoded UTF-8 file that happens to end in a character other than a newline.

Basically, either it's part of the encoding or it's part of the text, and if it's part of the text, I ought to be able to control it. And it isn't part of the encoding.

Re: GNU Nano 4.0

#132

Post by harshreality »

savolai wrote: post #76
Too wrote: post #61

Earlier quoted context omitted.

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

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.

Re: GNU Nano 4.0

#133

Post by earenndil »

Scarblac wrote: post #20
nicoburns wrote: post #17

Earlier quoted context omitted.

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.

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, it seems we've already skipped to kilo[1], so it'll have to be mega.

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

Re: GNU Nano 4.0

#134

Post by Shorel »

harshreality wrote: post #132
savolai wrote: post #76

Earlier quoted context omitted.

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

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 th…

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.

Re: GNU Nano 4.0

#135

Post by nichos »

jonah-archive wrote: post #69
copperx wrote: post #46

Earlier quoted context omitted.

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.

Re: GNU Nano 4.0

#136

Post by bpye »

lexicality wrote: post #77
l24ztj wrote: post #56

Earlier quoted context omitted.

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

Just so you know, VSCode can do this too. You just have to set the user preference files.insertFinalNewline=true

Re: GNU Nano 4.0

#137

Post by h1d »

dehrmann wrote: post #104
spudlyo wrote: post #62

Earlier quoted context omitted.

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.

Re: GNU Nano 4.0

#138

Post by theonemind »

thom wrote: post #125
theonemind wrote: post #98

Earlier quoted context omitted.

In any large-ish organization, you probably don't do this on a production machine. You absolutely do not do it if you aren't the person (or on the team) who will get called/paged if it breaks, or you're probably risking your job if the package manager goes sideways or you flub it up and let the package manager throw in a couple of extra upgrades or whatever.

So you ask that team to install Emacs (because you're less likely to mess up config with a proper/familiar editor) and they just say no, forever?

Probably, yes. If you're lucky, it might get rolled into the next deploy/upgrade.

Luckily, you usually don't need to do extensive editing there, because you usually can't change much. Most of the changes you'd want to make to config files, etc. also have to go into the next deploy or through some change management process anyway.

You definitely get used to using vi, though.

Re: GNU Nano 4.0

#139

Post by enriquto »

Sniffnoy wrote: post #100
lexicality wrote: post #77

Earlier quoted context omitted.

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

I mean, it ought to be possible to use a text editor to specify exactly what I want in a text file. If a newline is silently added at the end, then, well, that isn't happening. Edit: Which is to say, I don't think l24ztj is using "expect" in the sense of "anticipate" but rather, y'know, the other sense. (Using Wiktionary's definitions: "To consider obligatory or required" or "To consider reasonably due".)

> I mean, it ought to be possible to use a text editor to specify exactly what I want in a text file.

I agree. But for me a text file that does not end in newline is badly formed. It is not a text file, it is a binary file that happens to contain some printable characters.

Re: GNU Nano 4.0

#140

Post by badsectoracula »

l24ztj wrote: post #56
lexicality wrote: post #42

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

This is a Unix thing, on Unix lines in text files are terminated and the terminator is supposed to always be there to mark the end of the line, as opposed to Windows where they are separated and a separator at the end of the file means that the text has an empty line at the end.

This is also why tools that have a Unix heritage tend to complain if there is no terminator/separator at the end of the file (even in Windows), like most C compilers.

Post reply on HN