It makes me happy seeing nano being considered this way. Some of the features cited in the article were developed, improved, influenced or implemented by me; mainly macros and external commands.
It is possible to use the linter combined with macros as a "go to implementation" or "go to declaration". I think it is also possible to do the same so it can get completions from external commands.
I'd like to improve nano enough to make it a good IDE, but its main developer is against it.
I'm primarily a Vi user, but I respect and love nano. It's the first editor I try on any system I'm not familiar with.
I'd also argue against growing nano to a good IDE, because I think nano is in perfect form for its name and role.
Maybe there can be a fork (maybe called micro) which contains the features you want to see in nano.
"less is more, more or less."
I was hoping for the ability to record a macro, and then 'save' it somewhere for future reuse (possibly by binding a shortcut to it).
The link you point to seems very interesting to me for this reason. If that means what I think it means, then that is a good workaround for me, so I wanted to make sure: can you bind a shortcut to a string which uses ansi sequences to simulate keystrokes, and something like, e.g. "^R" to simulate pressing control+R?
If that's the case, while I cannot "record and save" per se, I could still use this technique to bind a key to a series of keystrokes, like I would with a macro inside the editor.
TBH, I wasn't aware of sophisticated features like automatically commenting/uncommenting. But I think putting effort into memorising those is less useful than putting effort into learning at least the basics of vi or emacs. -- There should be no shame in using nano.. I just can't agree that it's worth putting time in to memorise those keybindings.
Though now I wonder why there isn't a VSCode-equivalent (emphasis on "works out of the box" and "easy to use") for the terminal.
This used to be a fairly standard thing in the days of DOS, shame it is not more widespread - my memory for keyboard combinations is atrocious
The terminal is effective because you can combine all kinds of tools together. Or as some say, the shell is the IDE.
If you're searching for a single application that performs all these tasks out of the box, there is no longer sufficient benefit in using the terminal. A terminal variant of VSCode would be inferior to the GUI variant.
Another editor that works similarly to Nano, that most people don't seem to know about, is Micro (GNU) Emacs. Although it's not as small or common.
What surprised me is there are shortcuts like M-3 to comment/uncomment a line, or ^Q to search. These don't appear at the bottom.
By then end of a semester, the students will be running into the ceiling of nano as an editor and you can tell them about other more featureful editors.
Until you start editing files remotely through ssh, and then they will understand why the obvious thing (calling a graphical program from the command line) may not work as expected.
For example when I was taking my sysadmin class we used CENTOS which did not have gedit since it did not have a GUI. We used VI instead, but I learned nano was good for simple fixes and I did not have to google the method of saving and exiting.
For context, I just got my cs degree a year ago and most of my classmates only know a terminal as that bottom pane in vscode
If you want people to get up and running quickly, either require vscode or have people program in one of those browser based IDEs
I was disappointed when I got to grad school and many of my peers didn't even know how to invoke a compiler or interpreter from the command line. If you didn't give them a common IDE, they were absolutely lost.
A secondary advantage is that the tools are so wonderfully simple. On the first day we introduce ls, touch, nano, and cc. That's all you need to write your first program. The tool reference fits on one page. And that toolchain will do right by you for anything up to about a kiloline, and in an introductory course, that's about the biggest thing you'll write. So there's no more mussing with tooling. You can focus on algorithms and data structures.
A tertiary advantage is that it forces (and allows) the students to muck around with unix in a way that's oddly less threatening than a graphical user interface. Eventually they start rooting around in /etc and /var and /bin, and learn a whole lot about how computers are organized. So there's some serendipitous learning as well.
Anyhow, just tried gedit and you can press "^S" to save the file and "^Q" to close the window, which is pretty much all that you need to start editing text files.
In the late 90s/early 2000s I started encountering Unix machines that weren’t my family’s 486. I found that `joe` really wasn’t installed anywhere, so I endeavoured to figure out `vi`. This worked well as it was often the default editor on the systems I was attaching to. Some systems used `pico`, and later `nano`... and I found that annoying.
Fast forward a few years, and `nano` seemed to be the default everywhere. At first I found this very irritating, but over time I’ve come to realize that many have the same sort of feelings about `nano` that I did about `joe`. No, they’re not super-extensible mega-editors, but they’re fine for editing a few config files or a crontab. More than fine once I bothered to wrap my head around the feature set and stopped grumbling every time I was in a `nano` session. (Though I still set `vim` as my default when reasonable on servers.)
So, I’m sorry little `nano` for all the past grumbling. You may not be my first choice, but I respect you for the workhorse you are!
I personally use vim (as my console editor), but the feature set I can actively use without referring to documentation probably doesn't exceed by much what nano could do.
When "hard wrapping" is off and I move the cursor to the right beyond the screen, then the line on which the cursor is gets moved to the left - ONLY that line.
Is there a way to have the other lines move as well to the right?
Reason: sometimes I want to compare what I'm editing with what is present at the same position in the rows above/below - moving the cusor up/down to have those contents displayed is a bit annoying... .
Also, trying to evangelize a tool while being a weirdo is not going to help your case.
The filter to decide who to pay attention to works both ways...
It’s just being awkward for the sake of it.
> Capital initials are used to mark proper adjectives, while Toki Pona roots are always written with lowercase letters, even when they start a sentence.
I imagine they've deliberately carried this across to their English language writing too.
Whenever I speak to people casually about why they like vim over "e.g. nano", I find that people who think vim is far superior often fall into one of these categories:
- They like vim because it allows them to do things I think are bad software engineering practices which I would avoid anyway
- They like vim because it allows them to do things they are not aware nano can also do as easily (especially given you e.g. can run arbitrary shell commands on a selection).
- They've gone overboard and have added every single vim plugin in the book to convert it basically to an IDE or something that is no longer an editor.
- Nerd cred.
I only miss a couple of things when in nano, none of which are dealbreakers:
- "highlight all search results" (but search and replacement otherwise works extremely well, and I can always do the highlighted search in parallel in a less window)
- "shift all text to the right rather than only that line" (but again, one can simulate this in a less window trivially - it's just a bother to have to do so)
- Inability to create pre-recorded custom macros; you can only have one recorded macro live at any time.
But that's about it.
But having said that, I would not call myself a seasoned vim user. So I ask with full honesty. Persuade me to jump to vim. Can anyone argue specific points of things vim does better that nano can't do?
Does nano has a very rich movement system such as Vim has? I think that's one of the main selling point
If you mean stuff like "delete 5 characters", probably not. But I never really got the appeal of that over pressing delete five times. The time it takes me to count the characters to decide it's five of them is probably longer than the time it takes to press delete the appropriate number of times without thinking ...
(and the last four keys can be converted to a macro if "inside" is something you might use a lot).
I don’t use editors from the command line long enough to learn vi or emacs and I know how to quit nano (and it reminds me if needed).
And the colors are nice now, too.
Quite a lot of things are listed in the info manual.
Then one of our interns calls me cause they are stuck in Vim and I remember.
And the first hit teaches how to close vim. No need to know what is called.
I seriously find that the shortcuts hints being always present to be very helpful, great UX for occasional fiddling with dotfiles and files in /etc.
I'm not required to like, laud, or advocate for every piece of software. Conversely, I'm allowed to not like things as well.
I didn't know it had these features, sure. But... so what? I don't use nano, I don't like when things default to it as an editor, and I'd rather not have it on my system because it's just extra bytes used up on my disk.
If that makes me elitist, then so be it.
Then, let things know what editor you prefer;
$ export EDITOR='vi'
I strongly favour Vim myself, but I don't blame anyone for using Nano as a default editor. If the goal is to make a program (or distro) as approachable as possible then Nano is a sensible choice, much more so than Vim or Emacs.
I'm assuming you're talking about your development system/workstation.
Why would 2MB matter? It has no dependencies that aren't installed by default in every distro.
If I'm logging onto a server to change something small I'll use nano. I don't have any reason to learn vi or emacs.
I never have to do anything that requires me to need anything more than nano. If there ever is that requirement then it's gonna be hosted somewhere else and deployed to the server anyway, so I'll edit it on my machine in my ideal IDE.
What's next? "I don't like cp command, so I will always install thismagicommand on my servers..."
Having nano as a default crontab editor (on some distros) does not win popularity contest with more experienced admins, quite the opposite.