Submitted via IRC for TheMightyBuzzard
A new major release of open source text editor GNU nano is here. GNU nano 3.0 reads files 70% faster and brings several other features.
GNU nano is one of the most popular terminal based text editors. Those who keep forgetting how to exit Vim, seek refuge with GNU nano. It's a godsend for beginners who have to deal with editing in the command line while the experienced nano fans just swear by it.
I wouldn't normally consider a new version of a text editor really newsworthy but a 70% read speed increase is interesting to investigate even if only for an example of how not to do things from the prior versions.
Source: https://itsfoss.com/nano-3-release/
This discussion has been archived.
No new comments can be posted.
Nano 3.0 Released! Reads Files 70% Faster
|
Log In/Create an Account
| Top
| 59 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 4, Funny) by MichaelDavidCrawford on Sunday September 16 2018, @01:26AM (4 children)
"We use vi, son. They use emacs."
Yes I Have No Bananas. [gofundme.com]
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @02:58AM (3 children)
Funny!
Vi is everywhere, while others - not so much - so, which one you should learn?
(Score: 3, Interesting) by MichaelDavidCrawford on Sunday September 16 2018, @03:21AM (2 children)
I was once heavily into it; that I hate Emacs therefore represents a considerable evolution in my thinking.
My hatred for it stems from its desperate struggle to convince me not to run _any_ other program at all - not eMail, not a debugger, not even M-X psychologist.
This hatred of mine took root the first time I read a GNU Man Page that said "Go look at the Info documentation for this command".
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by jmorris on Sunday September 16 2018, @04:39PM
You can always install pinfo of course. Then you can view info pages without emacs or its strange ways.
(Score: 2) by darkfeline on Tuesday September 18 2018, @03:42AM
>its desperate struggle to convince me not to run _any_ other program at all - not eMail, not a debugger, not even M-X psychologist.
That's odd, considering Emacs uses external programs for fetching email (fetchmail), sending email (sendmail) and debugging (gdb).
Join the SDF Public Access UNIX System today!
(Score: 5, Insightful) by Subsentient on Sunday September 16 2018, @01:54AM (23 children)
I use it primarily on config files etc. I know enough vim to get around, but I don't like how vim and emacs make things work differently than how literally every other text editor on every other OS does. A text editor is a simple thing. You shouldn't need to read the manual to operate it. Nano does this pretty well.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by coolgopher on Sunday September 16 2018, @02:40AM (1 child)
Something about being designed for the lowest common denominator, or put together in a hurry (notepad.exe anyone?). Both vim and emacs are written by power users, for power users. While I'm firmly in the vi camp myself, I'm really glad there's also emacs. Monoculture is death.
(Score: 1) by shrewdsheep on Sunday September 16 2018, @10:04AM
:behave mswin
There you go.
(Score: 2) by Arik on Sunday September 16 2018, @03:15AM (13 children)
Hmm? Then you should dislike the other editors for changing things, surely.
Vi(m) is pretty close to the original editor interface.
Emacs has that new-fangled 'modeless' thing. Some people love it, some people hate it, I almost manage to not care.
The rest of them are just muddled or poor implementations of one of those two.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @03:29AM (10 children)
I pretty much exclusively use vi or its friend vim these days. But I will be damned if I do not find a new 'mode' to put the thing into every once and awhile. Then have to either back out whatever the hell I did or googling for a way to undo that thing. It is a very useful editor but lets not mince words here. It is a major PITA to use. It is a editor that you basically have to know exactly what you are doing before you can use it very well. Whenever I walk someone new through it I get pretty much the same reaction "how do you remember how to do all of that?" "not because it is good but because I do it a lot and here are some resources how to learn it" is the answer. It is a product of its time. It shows.
(Score: 3, Insightful) by Arik on Sunday September 16 2018, @04:22AM (9 children)
This was the main criticism of the early editors. Modes are very powerful and very useful, but they can be confusing. Emacs was supposed to save us from all that, but in order to make all the functions available without using modes it wound up using modifier keys so heavily that some people decided they liked modes better.
And that really is the choice, if you want to control a complex, powerful program you should expect some complexity in the controls. If the controls are dumbed down, well, get ready to find out you don't actually have access to all the power you thought you did.
"not because it is good but because I do it a lot and here are some resources how to learn it"
But it *is* good. And it's almost disturbing that you would answer that way, because clearly at some level you must know you're wrong, or you wouldn't be doing it.
It's good because it puts the power in your hands. Yes, it takes some mental work to figure out exactly what it is you really want to do, and yes you might have to do a little research to figure out the correct keystrokes, but isn't it better to do that, to do the work on your end to figure out exactly what you want done - and then leave the computer to do what it does best, carry out those instructions quickly and efficiently? When the alternative is to spend all day drag-and-dropping things mindlessly, in particular.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @06:01PM (6 children)
My point is the interface sucks. It *works* for a teletype interface. But we have much better interfaces now. An interface that lets you totally fuck up your doc if you type a few commands in is not a good one. You know you have backed out hundreds of times to undo some command you did not know exists. It is 'powerful' but a very silly interface. If I (who has 30+ years in this industry) cannot sit down at your interface and figure out what to do you did something *very* *very *very* wrong. Intuitive interfaces save everyone a lot of time. This sort of program is little more than good for ego boosting. I am not going to tell some 22 year old 'hey use this archaic POS'. That is little more than hazing.
yes you might have to do a little research to figure out the correct keystrokes, but isn't it better to do that
I strongly disagree. Why should I have to continue to be stuck in the limitations of 1970s tech? They did what they did for a reason. Those reasons are pretty much gone. There are a dozen editors that do the job much better now. I use them too. I am stuck with VI currently because of my current job.
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @07:37PM
Not really.
Choose two.
The trouble with "intuitive" interfaces for complex functionality is that no matter how often you use them, they remain slow. Not as slow as having to browse a manual for the right key combination, but much slower than hitting a key combination you know. An expert can be faster with a non-intuitive interface.
The obvious counter is that even "experts" using a powerful piece of software frequently tend to only regularly use, and thus truly be expert with, a certain subset of its capabilities. So an intuitive interface saves even experts a little time whenever they need to do something they don't often do -- but by definition, they don't do that often, so it's wrong to say it saves them a lot of time; in fact, it will almost certainly cost them more time on the routine than it saves them on the unusual.
The standard solution, these days, is to combine two interfaces. Usually (including modern vim and emacs) a menu and/or toolbar system (intuitive and powerful) with a keyboard shortcut system (fast and powerful), with the idea that you'll learn the keyboard shortcuts for anything you use regularly. But it's important to realize that that's two distinct interfaces superimposed, and while the combination does prevent experts from being weighed down by the intuitive interface during the routine, it still only saves them a little time.
(Score: 2) by Arik on Sunday September 16 2018, @10:41PM (4 children)
Really? Name one.
"An interface that lets you totally fuck up your doc if you type a few commands in is not a good one."
Why not?
The alternative is a program that *does not* let you do what you want to your document.
You may want your computer to spend all it's time second-guessing and correcting you, fine, but don't pretend that's anything other than your own preference for absolute laziness.
I want a program that will do exactly what I tell it to do, when I tell it to, without any backtalk. Not one that's programmed to protect me from myself by refusing to do anything the slightest bit unusual.
And so what if you messed up your document by issuing the wrong command? You know every modern editor has checkpoint files and undo functions, right? They'll save you from yourself even if you aren't smart enough to save a copy before trying something you don't know how to do.
"It is 'powerful' but a very silly interface."
Sounds more like a silly user to me.
"If I (who has 30+ years in this industry) cannot sit down at your interface and figure out what to do you did something *very* *very *very* wrong. "
See above.
Having used them for decades in no way makes it impossible for you to be misusing them, and blaming them for your failures.
Which of course is the entire point of your rant. You want programs with training wheels. You want programs that won't let you make mistakes. Because you don't actually do anything that you'd need a PC for in the first place, and you don't like being reminded that you're stupid.
Sounds like computers just aren't for you, really.
"Intuitive interfaces save everyone a lot of time."
Name one.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by urza9814 on Monday September 17 2018, @02:09PM (3 children)
...are you some kind of perfect AI? Because generally, humans are capable of recognizing that we all do occasionally make mistakes. A well-designed interface MUST at the very least prevent small mistakes from cascading into larger problems. Hell, even the humble 'rm' command does this -- I can't just say "Remove this file", I have to either add confirmation in the form of additional command-line switches (ie, -f) or I have to wait for rm to give a confirmation prompt and then tell it that yes, I really do want to delete that file.
"It does what you tell it without getting in your way" is an argument which is at least fifty years out of date. We can do both. If you have to choose between power and safety or you have to choose between power and discoverability, it probably means your interface sucks from the ground up. It's not some fundamental law of physics forcing that choice; it's being stuck in a bad UI paradigm.
Once upon a time, computers were so expensive and difficult to get access to that it made sense to force the human to perform some of the work that the computer was capable of doing itself. Today that is no longer true; certainly not for something as simple as a text editor at least.
(Score: 2) by Arik on Monday September 17 2018, @06:25PM (2 children)
AIs do not feel pain. Your stupidity pains me. Therefore I am not an AI, perfect or otherwise.
"Because generally, humans are capable of recognizing that we all do occasionally make mistakes."
Which is why we have both manual and automatic backups, as well as undo functions. Your point?
"A well-designed interface MUST at the very least prevent small mistakes from cascading into larger problems."
The only thing the interface MUST do is make the function available to the user. Of course a well-designed interface manages to do much more than that - but it must do the essentials first, or it fails.
It is not the function of the interface to prevent small mistakes from cascading into larger problems. That sounds like something a process overseer would do.
"Hell, even the humble 'rm' command does this -- I can't just say "Remove this file", I have to either add confirmation in the form of additional command-line switches (ie, -f) or I have to wait for rm to give a confirmation prompt and then tell it that yes, I really do want to delete that file"
Or you can create an alias or you can patch and recompile. That's the point. Power is in your hands. The function of the interface is simply to put it there.
"It's not some fundamental law of physics forcing that choice; it's being stuck in a bad UI paradigm."
And that's something I've been saying for years. The PARC-APPLE-MS-GNOME style GUI was a bad idea. It's fundamentally bad, rotten to the core, based on a number of falsehoods, and it has never worked as advertised. Recent 'developments' have only made it worse, as they amount to regressions aimed at transforming the point and drool interface into the new and fashionable fingerpaint interface.
"Once upon a time, computers were so expensive and difficult to get access to that it made sense to force the human to perform some of the work that the computer was capable of doing itself. Today that is no longer true; certainly not for something as simple as a text editor at least."
And this is where you're fundamentally wrong. Expense may have had something to do with it but that was not the primary reason for it. The reason it makes sense for the human to perform some work in order to learn to use the computer is because the computer is a complex machine which requires knowledge and skills to use properly. THAT has not changed one bit as prices have come down, despite all the untold millions (billions? trillions?) that have been spent over the years polishing the GUI turd.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by urza9814 on Monday September 17 2018, @07:36PM (1 child)
Agreed, that's why I use Enlightenment and a couple thousand lines of custom shell scripts to get the interface exactly how I like it. That includes a number of features designed to prevent me from doing something stupid, because I've made the mistake in the past and I don't want to do it again. I'll take the half second to press "Yes, I really want to delete that" over the five minutes of digging a copy out of my backups. Plus the backup is nightly, not instant, so it won't save the work I did in the past six hours. My git repo helps a bit too, but I don't always want to check in twenty times in one hour just because I was testing something. Easier to pull it local, fuck around for a bit, and push it back once you've got something that actually works.
That's not what I said. I absolutely agree that you should learn what the hell the computer is doing before you use it. But it's like my car -- I sometimes give up direct control over my acceleration to the cruise control. I know that it means I have less control; I also know that it means the car will react faster in case it starts losing traction because it's got a much better reaction time than I do and it already knows the most appropriate *immediate* reaction to that event. I give over control not because I don't want to know how it works, but because I do know that it works better that way.
(Score: 2) by Arik on Monday September 17 2018, @07:54PM
That's fine. YOU put those limitations on yourself, that's still how it's supposed to work, it's doing exactly what you told it to do (even when it second-guesses you.) No problem with that at all.
"Plus the backup is nightly, not instant, so it won't save the work I did in the past six hours."
What program are you using that doesn't keep checkpoint files? Emacs has done that since the 70s IIRC, it was an old feature before I ever saw it at any rate.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by darkfeline on Tuesday September 18 2018, @04:00AM (1 child)
>Modes are very powerful and very useful, but they can be confusing. Emacs was supposed to save us from all that
That's interesting, because Emacs main feature is all of its modes. Emacs has a lot of modes. Emacs even has different types of modes: major modes, minor modes, and transient modes. Emacs also has a lot of dynamic state beyond just modes, such as recursive editing, which allows you to be in a nested control loop, with its own set of modes. You can add more layers onto the recursive editing stack and pop them back out.
Emacs is extensible enough that you can even add orthogonal types of modes on top. For example, the Evil package adds Vim emulation to Emacs, which adds its own custom type of modes called states. So alongside of all of the major, minor, and transient modes you could be in, you could also be in one of some number of states.
I don't think any other piece of software has more modes than Emacs.
Join the SDF Public Access UNIX System today!
(Score: 2) by Arik on Tuesday September 18 2018, @05:06AM
But in this context ed and vim and similar editors were called 'modal' editors because you had two basic modes - you're either in typing mode, or you're in command mode. So you don't need, for instance, to hit ctrl-s to save, it's just 's' by itself. When you're in command mode. But wait, let's type something in first so there's something to save! Good idea... oh... oops. Forgot to switch to insert mode, try again.
And despite all the 'modes' that Emacs has to extend its functionality, it's still the classic modeless editor in that sense. It did away with command mode/insert mode stuff, well aside from viper/vim mode of course. Kind of a tribute to how extensible it is that you can extend it to add the one design feature that it was originally written to eliminate.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by HiThere on Sunday September 16 2018, @04:51PM (1 child)
FWIW, I almost exclusively use geany, but nano is what you use in restricted situations...restricted in RAM or in storage. Those occur to fewer people these days, and to nearly everyone less often, so I rarely use it, but it's in my toolkit.
I've never bothered to understand EMACS, because the keyboard commands required to use it were painful. I used to use vi(m) frequently. For awhile I preferred kate, but geany is generally better (there are a few exceptional cases). OTOH, the environment I use them in is a full desktop usually running KDE, but occasionally Mate or Xfce, so it's not a resource restricted environment.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Interesting) by urza9814 on Monday September 17 2018, @02:27PM
More likely these days to be restricted in admin rights or physical access IMO. Geany is a GUI tool, so you probably won't have access to something like that if you're logging in to a headless server via SSH. Nano is also a lot more standard (although not as much as vi, but more than emacs IME) so it's more likely to be installed on a server where you might not be the one with admin rights. I use vi and nano literally every single day on systems far more powerful than my gaming laptop.
(Score: 1, Insightful) by Anonymous Coward on Sunday September 16 2018, @03:22AM (3 children)
to be fair, vi was written when the primary interface for its user was a slow teletype and the keyboard didn't have actual arrow keys
and then emacs predated a lot of user interface conventions common today (and it was the editor that invented (or at least popularized) a few still seen today)
both remain as they are for those who got used to 'em and those who find something worthwhile in how they operate, especially since there are so many other editors that operate in what's now considered the "normal" way
vi remains the standard editor for hysterical raisins though :P
namely, it's in both the Single Unix Specification and POSIX
Ah well. At least a lot of distros ship nano by default, it's common enough that I can reasonably expect to be able to use it on whatever *nix-like boxes I see.
(Score: 2) by jmorris on Sunday September 16 2018, @05:13PM (2 children)
And a cut down version of vi is in busybox. If you ever have to deal with small systems (OpenWrt or even smaller embedded machines) knowing vi is mandatory. Once you accept that vi is a universal constant, and you have to learn it anyway it makes sense to adopt it as a primary tool.
(Score: 1) by pTamok on Sunday September 16 2018, @09:58PM (1 child)
Cough.
Before vi, there was ed [wikipedia.org]. That is for really low memory systems. It has also been called ""the most user-hostile editor ever created".
(Score: 2) by jmorris on Sunday September 16 2018, @10:04PM
More like ed was designed for machines where standard out was paper. Ed was well adapted to that environment but today even embedded systems talk over a serial port to a terminal emulator, and usually at a pretty good bit rate as well.
(Score: 2) by DarkMorph on Sunday September 16 2018, @01:45PM (2 children)
I suppose that's why you're alienated from the vim crowd. Like the shell itself, it's quite powerful, and absolutely requires a manual (many manuals, actually) to harness even a fraction of the capabilities. Surely you wouldn't dismiss the usage of the command line for the same reason, would you?
Nano is good at being a simple editor, no doubt about it. But what can be done with vim goes so far beyond the severely limiting GUI approach of a "modern" editor... it's self-evident why vim users and vim script writers are still rather numerous. I've learned much in the last year working with vim as my primary (and only) editor. I doubt I know even 10% of what it can really do yet; nevertheless I can get work done so much more rapidly than ever before.
(Score: 2) by jmorris on Sunday September 16 2018, @05:17PM (1 child)
Yes they would. Where do you think the UNIX Haters come from, what their goal is? What RedHat and Pottering's goal is? They openly tell us they dream of a day when you can boot to a desktop and live a happy productive life without any shell installed, nor a terminal emulator. Believe them, they mean it.
It is like the people who watch the "Allah Akbar" types declare their intent to cut our infidel necks and they simply can't process such an alien idea, so support importing a few million more of them into Western countries. Pottering doesn't want to cut our neck, but he WILL erase UNIX culture just as completely if allowed.
(Score: 2) by Subsentient on Monday September 17 2018, @02:01AM
I love UNIX. I love the shell. I agree that it should be possible to use Linux without a shell, but I would never want that for myself. I live in the shell. I have several open at all times.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 4, Funny) by Anonymous Coward on Sunday September 16 2018, @02:43AM (2 children)
The key to remember how to get out of vi for me was thinking 'colon' was the perfect command key for an ass program
(Score: 1) by Arik on Sunday September 16 2018, @03:18AM
If laughter is the best medicine, who are the best doctors?
(Score: 1) by pTamok on Sunday September 16 2018, @09:51PM
The key to remember how to get out of vi for me was thinking 'colon' was the perfect command key for an ass program
If you are a Kurt Vonnegut fan, the obvious key for that would be ✳.
(Score: -1, Redundant) by Anonymous Coward on Sunday September 16 2018, @05:09AM (5 children)
you mean it displays the text 70% faster.
because the reading is done by the OS.
(Score: 2) by The Mighty Buzzard on Sunday September 16 2018, @05:23AM
Never underestimate a noob with a new idea's ability to fuck something simple entirely up.
My rights don't end where your fear begins.
(Score: 2) by jasassin on Sunday September 16 2018, @05:59AM
This is just a guess but maybe it reads in larger chunks of data at once like increasing the MTU on a NIC.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 1, Informative) by Anonymous Coward on Sunday September 16 2018, @06:14AM (2 children)
Looks like it locks the whole file at once, before reading it byte-by-byte (according to the commit message). It appears to have previously been using the locked read variant instead.
http://git.savannah.gnu.org/cgit/nano.git/commit/?h=v3.0&id=b2ff57467874e1c0cfad146a76acf0d9f3a0084c [gnu.org]
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @04:04PM (1 child)
Why the fuck is it reading files byte-by-byte in the first place? That's so fucking stupid. It'd be way faster if they'd just fread() into a buffer as needed and scan through the buffer. Good grief. Damn kids.
(Score: 2) by jmorris on Sunday September 16 2018, @05:20PM
Because it didn't matter. It was a toy editor for quick jobs, mostly replacing the Pico editor in the PINE email client that ran into licensing stupidity awhile back and went away for a bit to get rewritten around the parts that couldn't be relicensed. Think it is Alpine now.
(Score: -1, Offtopic) by Anonymous Coward on Sunday September 16 2018, @05:31AM (2 children)
So I'm setting a timer with Nano 3 as the guinea-pig.
Released 16 Sep 2018
In Debian repos / updates ___/___/_____ (10 Dec 208)
In Ubuntu repos / updates ___/___/______ (12 Feb 2019)
in Mint repos / updates ___/___/_____ (only with 19.2 when that is ready)
Gentlemen, place your bets... (my bets).
Rolling releases like Manjaro - as early as mid-week or be next weekend.
(Score: 1, Informative) by Anonymous Coward on Sunday September 16 2018, @06:53AM
It was already in Debian (unstable) last Monday.
http://metadata.ftp-master.debian.org/changelogs//main/n/nano/nano_3.0-2_changelog [debian.org]
(Score: 2) by KritonK on Sunday September 16 2018, @10:13AM
In OpenSUSE Tumbleweed repos on 2018-09-12, built two days before.
(Score: 4, Interesting) by pvanhoof on Sunday September 16 2018, @06:16AM (1 child)
What the hell did they do before for the original to possibly be 70% slower at reading a text file?!
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @08:34PM
? somewhere buried in the assembler, the equivalent of:
while this.second == last.second
NOP
after every buffer read of 512 bytes. How else would you slow it down?
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @06:54AM (3 children)
Uh-huh. "Experienced" users wouldn't be using nano.
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @08:32AM
Not true. I use nano (natural text) and vim (code, config files), I also still use pico (realpine as my mail client).
(Score: 3, Insightful) by The Mighty Buzzard on Sunday September 16 2018, @10:27AM (1 child)
Experienced doesn't preclude lazy. Administer enough differently configured boxes and it can start seeming like it's not worth the bother to put vi(m) on each and every one.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @08:19PM
isn't vi included in the unix definition?
(Score: 2) by shortscreen on Sunday September 16 2018, @08:19AM (2 children)
My text editor opens a 100MB file in about 2 seconds. I figured that was good enough and didn't try to optimize that aspect of it any further. My editor also builds an index of pointers to the beginning of each line so I can scroll to the bottom and start rendering from the first line that is visible on the screen.
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @05:40PM (1 child)
And how well does it perform when that 100mb is all on one line? Most editors can't handle things like that, which are becoming more and more common as web resources are white space stripped and lazy programmers directly export program data as single lined json.
(Score: 2) by shortscreen on Sunday September 16 2018, @06:41PM
Interesting test case. Opening the file is fine, editing the long line is a bit painful, as expected. Some other operations also became sluggish for reasons that are not immediately clear...
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @12:00PM
* Many other keybinding changes
(Score: 3, Informative) by stretch611 on Sunday September 16 2018, @12:39PM (1 child)
I've been using linux since the late 90's... and exclusively for the last 10 years.
As a developer, I learned to use vi, and back in the 80's I even learned how to use EDLIN on dos (almost as archaic as vi).
I use nano... frequently. I find it easy to alter the text without trying to remember command sequences. The fact is even though I learned vi, I always used other (easier to use) text editors because they worked better for me, and hence, I never learned all the vi command by rote. Today, I usually use Sublime Text [sublimetext.com] which works well with large files (and is quite speedy too).
I use nano when I don't need to use a full feature programmer's editor, generally when making one or two line changes to config files. It is quick and easy as well to run a CLI editor when needing root permissions than dealing with gui tools on those files.
That being said, I doubt I will notice a 70% improvement in the speed nano reads my sub 5k configuration files.
Now with 5 covid vaccine shots/boosters altering my DNA :P
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @05:37PM
i don't know why you're promoting a slaveware text editor.
(Score: 3, Informative) by engblom on Sunday September 16 2018, @12:43PM (4 children)
Why is Joe almost never mentioned as an easy to use alternative to Vim or Emacs? Joe is so much more powerful than Nano, but still the same easy to use. Joe was the editor I used for many years before I switched over to Vim myself.
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @03:24PM (1 child)
"mc" and "joe" are indispensable for linux users that are ...uhm ... just normal computer users.
some, like joe, just sit in a bar with a cigi in the corner of the mouth and a beer on the piano and some are dressed in a tuxedo, bow and dazzle the auditorium for an hour :]
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @03:29PM
the other day joe told me that "vi" is just a english bastardization of the german "wie?" (adverb).
(Score: 2) by RS3 on Sunday September 16 2018, @07:15PM
Huge joe fan here too. I love the syntax highlighting. I can use vi/vim if I have to. Fired up emacs once. Okay, I get it, great if someone likes it. Nano is natural for me because I use pine/alpine. Joe is always one of the first packages I install on a Linux system.
(Score: 0) by Anonymous Coward on Sunday September 16 2018, @08:03PM
The one thing about joe that bothers me sometimes is its weird search/replace syntax. Fortunately, if I want regex, ^k/sed is right there.
Honestly, the more I think about it, the more I think powerful all-in-one editors were a mistake, and we should have simpler editors that would focus on display (e.g. syntax coloring), basic visual editing, and various ways of selecting text for filtering through external programs, combined with a suite of standalone programs (in addition to the standard ones like fmt, fold, tac, tr, etc.) for such filtering.
(Score: 2) by srobert on Monday September 17 2018, @02:30AM
Does nano have an evil mode? Cause if it doesn't behave just like vim, it'll mess me up. I need an editor that's just like vim. What should I use?