111–120 of 154 posts
There needs to be a console text editor installed by default with CUA keybindings, like notepad, sublime text, dos edit, and borland tools were back in the day. Nano can get partially there, micro is the current best though it has a few MacOS oddities around home/end but can be configured, in the past used ne.
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".
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/
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/
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…
It seems like nano has started to reach vi-like levels of ubiquity. Every fresh Debian install annoys me by dropping me into nano as the default editor at some point (until I update-alternatives and point it at vim.tiny). The edge still goes to vi, especially if you log into older/legacy things, or in very resource constricted environments. It looks like busybox, for instance, has a vi but not a nano: https://busybox…
Earlier quoted context omitted.
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
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…
Legacy, more than anything else. Nano has been a thing for decades, and it will likely be a thing for decades more. Are there better, more powerful editors out there? Sure. But just like vim, you can expect to find nano pretty much anywhere, and if you need to make a quick change, say to a configuration file on a bare-bones system, that's nice.
Earlier quoted context omitted.
if [ x$CMDSH = xshell ] ; then grep -qP $BLKLST
Is this a thing people do? I think I like the idea of it, but haven't heard about it before.
Checking for obvious problems should happen inside eg rm (see `rm --help | grep root`), not in a random shell script, but I didn't want to bother coming up with a better excuse to have rm -rf / inside a comment.
Usually the errors caused by syntax-unware text mangling are either obvious and harmless (so not as punchy of a example) or much more subtle than "destroys literally the entire system".
Earlier quoted context omitted.
One could reasonably expect that a user expects a POSIX system to behave according to the POSIX standards?
Not really, most users (even tech people) don't know that it is a POSIX standard, or what's a POSIX standard, or what's POSIX really