101–110 of 154 posts
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.
Easy to scp micro or nanorc over with one command.
Earlier quoted context omitted.
Genuinely curious, why do you see this as a good change?
There are programs that violate POSIX and are picky about it.
The reason why this is (and also why the lines should not be longer than LINE_MAX or contain \0) is that when you simply call fgets() in a loop with LINE_MAX sized buffer, all of these things cause perfectly logical, but wrong/surprising behavior. This is the reason why almost any modern small unix tool contains something called myfgets(), getline() or whatever which wraps fgets() in loop with realloc() and correctly distinguishes eof from other errors.
Earlier quoted context omitted.
There are programs that violate POSIX and are picky about it.
POSIX definition of what is text file actually requires the file to end with \n, so such programs are technically correct. The reason why this is (and also why the lines should not be longer than LINE_MAX or contain \0) is that when you simply call fgets() in a loop with LINE_MAX sized buffer, all of these things cause perfectly logical, but wrong/surprising behavior. This is the reason why almost any modern small un…
No, they’re not correct, since they make files without the newline.
Earlier quoted context omitted.
Being an Emacs user I use Zile for that since it's effectively a trimmed-down version of Emacs. Of course unlike nano it's not usually installed by default on most distros, so I still have to use nano or vi from time to time, but I can't say I enjoy it very much.
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.
Earlier quoted context omitted.
Vi is ubiquitous. Vim is not.
Nope. vi almost doesn't exist. Most distros just use vim in a vi mode (or vim.tiny, same thing). Just because the command is "vi" to invoke doesn't mean anything.
I agree, but if anyone is curious, the source is available and has a BSD style license: http://ex-vi.sourceforge.net
Earlier quoted context omitted.
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.
echo 'this is a test\n'
I'm sure nano/pico and the like are nice but to me there's two things a terminal editor can try to solve for: being nice, or bring ubiquitous. The nicest ones (say emacs) are way nicer than nano in terms of features, extensibility, etc. Now for being ubiquitous, nothing beats vi to date. I can't tell what nano is aiming for? EDIT I guess I had assumed that vi/vim was significantly more widespread than nano. Maybe tha…
Why nano? nano is sane. With Emacs/VI you need to bring a HUGE mental framework to just use it. And maybe, with luck or some years of pain training, to just EXIT it :) --- Vim/emacs are powerful. Nice? Never. Easy? never. Good for most common editing task in the terminal?. Nope. Claim that Vim/Emacs are good is like say "why people use Sublime Text when Eclipse is so much better?" Except, with eclipse, you know how e…
I know other people who aren't Vim fanatics at all but have occasional work in the terminal, and they too also just learned the most basic Vim commands and have the most basic Vim configurations, if at all.
>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
if [ x$CMDSH = xshell ] ; then
grep -qP $BLKLST 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.…
JOE (Joe's Own Editor)[1] is actually easier to use than nano, and it can emulate other editors (including nano/pico via jpico). It also has mouse support. It is installed by default in Slackware, and is in the package manager for most other OSes. [1] https://joe-editor.sourceforge.io/
>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