The thesis of this post is roughly that nano, when configured, is enough of an editor for the author. Which is totally fine! People should be happy with their tools and not feel pressured by popularity to use what others use (vim, emacs being prime competitors in this case).
Alas, nano (and pico before it) have a certain stigma among more "experienced" Unix users that more or less boils down to gatekeeping and snobbery. Which is a shame.
That said... it is worth considering that learning tools like editors is an investment in one's self and pushing through preference to genuinely try to use what others find value in can, if nothing else, help you better understand what you value and adjust your tooling to fit (much like the author adjusted Nano to be more like vim).
That's a pretty nuanced distinction though and I am glad that the author feels comfortable owning their preference and not feeling pressured by peers to conform to more "acceptable" choices while still having tried and learned from them.
The thing about that “snobbery and gate keeping” is that it’s not at all that.
Maybe not everyone’s experience mimics mine but I felt like people looked down at me a bit when I was 16 for using nano on the command line.
But, and here’s the kicker, if I hadnt been pushed into vim I would not be nearly as productive now.
There have been countless times in my career as a sysadmin/devops/SRE where I’ve been stuck with horrible latency to machines half a world away (or, a few miles away but the network is crappy) and being able to send just a few keystrokes and get a lot of power out of it is helpful.
That’s not counting all the “repeat” patterns or complex search and replace.
I remember still when I got my first job as a junior sysadmin, I spent a really long time logging in to each machine, updating a config file, logging out then going to the next one.
I didn’t need to be told that “ssh and nano is fine”, I needed to be told “there are better tools that you should invest in learning, because they will repay you back thousandfold”.
What I thought were people looking down on me were in fact people looking at me with hopeless pity, because I fought the idea of learning vim.
> What I thought were people looking down on me were in fact people looking at me with hopeless pity
Or maybe they actually were looking down on you. When we feel bad in response to someone else, we're not usually misinterpreting the emotional cues.
It's not just what they say -- it's the way they say it.
Which is why the term "constructive criticism" exists. If you want to help them, then make them feel good by expanding their knowledge. But support them in their own choices and autonomy.
>> But support them in their own choices and autonomy.
I mean yeah, sorta, sometimes. But other times u get back that vibe of “I just don’t care to learn something new, I’d rather do the bare minimum and I’m not really hungry to learn new things”. And recognizing the presence of this attitude is what causes the looking down upon.
I don't know if they're taught these days-- they weren't when I was in school-- but sed & awk are two tools I'd recommend to pretty much everyone.
I remember stumbling on to them in my first job and thinking an very much appreciating their power over having to write a small program to iterate through an arbitrary # of files to do something... and another small program if I wanted to do something slightly different, etc.
If numbers can be imaginary, why not people? Many imaginary numbers are extremely useful, so there's no reason you can't lead a perfectly productive career as an imaginary person.
Maybe not everyone’s experience mimics mine but I felt like people looked down at me a bit when I was 16 for using nano on the command line.
…
What I thought were people looking down on me were in fact people looking at me with hopeless pity, because I fought the idea of learning vim.
People need to check how they encourage other people or promote things. You probably weren’t wrong about feeling looked down upon. Even if they really thought you would benefit.
He said he might switch to nano. It's not currently his editor of choice (unless there's something more recent). If I recall correctly he has been using uEmacs/PK (https://github.com/torvalds/uemacs).
> I really need to switch over to something that is actually maintained and does utf-8 properly. Probably 'nano'.
It also depends what you use an editor for. Back when was doing more programming, I used something more powerful for the DOS environment--yes this was a while back.
I tend to use nano because I'm mostly making changes to config files and the like so I mostly want simple.
> But, and here’s the kicker, if I hadnt been pushed into vim I would not be nearly as productive now.
It's interesting how the winds have changed toward Vim advocacy in a quarter century or so.
I switched to Vim around 1994, amidst a definitely anti-vi climate. In the university environment, almost nobody used vi. I remember nothing but vi trash talk.
The computing environment was proprietary Unix without a whole lot of freeware at all. Free Unix was just beginning to rise in the word. Only in the freeware world surrounding the Linux kernel and GNU utilities did I begin to discover alternative programs like Vim, still far from any sort of mainstream at that time.
I saw all this trash talking as weakness; by making fun of trivialities like the command sequence to get out of a program, you're just showing you're a moron. I looked into it and found it wasn't difficult at all.
Until then, all editors I ever used were fundamentally modeless: type characters to insert. I was curious about what it's like to use the modal editor after training oneself in its use.
I was quite pleasantly surprised; the naysayers were bigger morons than I thought. There are all these useful commands that can be touch-typed without any modifier keys!
Taking every key that produces a printable character and turning it into a command which inserts that character is an incredibly ill-considered decision. I mean, the machine can do anything you want, and you're insisting that it behave like a typewriter.
Because the computer/terminal keyboard traces its inspiration to the ancient typewriter, whose keys are mechanically linked to hammers that produce the characters those keys are labeled with, it must be so in a computer's editing program also. That is parochial thinking.
I don't understand how someone can go from, say, playing a game of Tetris where the unmodified keys ijkl control the falling pieces, to editing text, and suddenly insist that in this editing context, it must be that ijkl simply insert their image into the buffer. Like keys being commands is just something for games; editing is typewriter-like, so we simulate a typewriter, end of story.
Moreover, to be so vehement about this, so dead-set against the idea that an editor might be driven somewhat like a Tetris game, so as to not even give it a chance, in spite of relying on editing for enough years to become a programmer.
> by making fun of trivialities like the command sequence to get out of a program, you're just showing you're a moron.
I still laugh at the word vi being the translation from Aztec of "how do I get out of this shit"
For context, I started with Linux in 1993, by making changes to the kernel. Vi was the editor of choice and I took it like I do with cultures of the countries I visit: I keep the comments to myself.
So I suffered in silence until I discovered joe (an editor based on Wordpress key bindings) and that was a great change.
I know 3 or 4 commands in vi, enough to make the changes five times a year when I have to use it somewhere
When I was coming up, Solaris was as popular as Linux at the time. There was no option to install nano on production machines for Solaris. It was vi or find a new job.
> Alas, nano (and pico before it) have a certain stigma among more "experienced" Unix users that more or less boils down to gatekeeping and snobbery.
You know, after a number of years in the industry, I've largely stopped caring about what others think and wouldn't lose my sleep over it - the best tools are the ones that you're familiar with and that solve your problems.
For me, that's using nano, for someone else that could be vim. I might want to use some of the JetBrains IDEs, use something like Java liberally because of its verbosity and not even scoff at older software like Lazarus/FreePascal in some circumstances (their approach to GUI is still superior to most modern ones). For someone else that could be Visual Studio Code, a language like Python, or generally looking in the direction of the bleeding edge of languages, such as Rust.
As long as you reach your goals, i think it's perfectly reasonable to dismiss peer pressure or criticism, unless it's constructive (like the person who suggested that vim is better for replace operations over slow connections, which was a good point but also something I've never needed).
That said, the author's approach to customizing nano made me appreciate how nice having proper configuration files and options within them is!
Well, I'd put some limits on this. If a coworker cobbled together something that still let them program by punch card then I'd 1) probably be frustrated with their level of output and 2) impressed at the setup. 3) asking for their extra set of eyes on my own code because if they had the patience for punch cards they would probably be better than me at catching errors.
As funny as the mental image is, that's a fair point. Clearly pick whatever suits the needs of the team, if you're developing something together with others.
But just in general, don't scoff at technologies just because they're not currently popular: there are a few problems out there that can be fixed really nicely within something like Prolog, Lisp or another seemingly dated language. Admittedly, nowadays there's perhaps too much focus towards using walled gardens, as opposed to piping some data through a few Bash scripts or maybe embedding Lua in a larger executable for some more dynamic functionality.
Of course, those are just some overly general examples, but getting discouraged from a good solution just due to peer pressure isn't exactly optimal. Having technologies that don't have good documentation due to never having been popular in the first place, or that are difficult to run or utilize nowadays, however, is a different story entirely.
Where punch cards would fit into all of that, however, i'm not sure as of yet. :)
I would probably be wondering where the machine is kept that reads punch cards. And how to use it. And how do I make punch cards. Then, after all that, your list seems like it would suffice.
In my mind I envisioned in on their desk in the next office over that looked like something out of the movie "Brazil" and machines on the desks during the Central Services scene [0]
It’s not really gatekeeping or snobbery to say that knowing vim is more useful simply because I can log into any Linux machine on the planet and edit a text file without having to install an editor.
They probably meant snobbery that vim is superior because it's more capable, not because it's more ubiquitous. Nano is also very widely installed, so the latter point isn't even particularly true.
Every Unix machine (Mac or Linux) that I've ever tried to use nano on has had it preinstalled. I'm sure not all of them have it preinstalled, but it's common at least in mainstream distros
In the late aughts, I found myself at the keyboard of a Solaris system that only had ed. I was there to get the network configured and it didn't have an optical drive, so there was no way but forward.
More recently, I've found myself inside a container which didn't have any editors. I got the job done with echo, head and tail. Delightful.
If you’ve never logged into a Linux machine without nano installed, then you probably haven’t logged into that many flavours of Linux machine.
I agree this is pretty much a non issue for the average developer, but those of us who work on network infrastructure, as red-team hackers, or do any work on embedded systems can attest to how much of a pain it would be to not know how to use vi/vim.
There is definitely something to be said about having minimalistic container images for security and smaller sizes...
But not having a basic text editor that is probably a few hundred KB feels a bit silly, especially given how many environment dependencies usually get packaged into containers anyways.
That's like not including any sort of a shell in your container and wondering why people are having troubles with debugging.
Personally, i think that just basing container images on something like Alpine, Debian or even Ubuntu images is good enough because those are stripped down enough already for the most part.
Most non-copyleft (permissive free software and proprietary software) tries to stay as far away as possible from the GPLv3 license. Because of this, macOS ships gnu nano 2.0.6 whereas the latest is 5.8. FreeBSD doesn't even have nano installed by default.
Here's a good example: The article's author is actually the security team chair of a lightweight Linux distro called Alpine Linux. A base installation of Alpine includes BusyBox vi but no nano.
I've never worked with distros targeting enterprise, but I've never encountered a distro that didn't include nano.
Even if Vim is "better", I think it's important for all distros to include a text editor that is easy to use out of the box, and nano fits that bill perfectly.
In my experience, the DEB distributions (Debian, Ubuntu, ...) usually have nano by default, whereas the RPM ones (RHEL, CentOS, Oracle Linux, ...) don't.
That said, i immensely enjoy how small the install size for nano is and how there's no actual work that you need to do to get started with it (unless you need/want customization, like the author of the original article).
That said, i immensely enjoy how small the install size for nano
I used to install lynx web browser for the same reason, especially because at the time it was the age of countless popups and swf everywhere. I should check to see how it is these days, but I stopped using it when webdev made many pages unusable in it.
Aren't casual vim users really vi users? I use emacs primarily but years ago created an extremely minimal (~20 lines) .vimrc to be installed by default on every server I work on. Some color, maybe indentation, I don't even know because I usually just use Emacs/TRAMP these days, but I'm nearly 100% sure that every config there works in vi. I would consider myself a casual vim/vi user in that I don't know the differences.
I may be misremembering, but the biggest differences I remember between vi and vim as a semi-casual user is vi defaults to not supporting arrow keys, and doesn't tell you the mode it's in.
I can't remember the last time I used vi and was unable to use arrow keys. That includes typical Linux installations (Vim, Busybox), Solaris (default is Vim, oddly, but I just confirmed arrow keys work in /usr/xpg4/bin/vi), and various BSDs (nvi).
I'm not a power vi user, though. I usually use JOE (thanks/blame to '90s Slackware education), but occasionally vi is more convenient. It wouldn't be nearly as convenient without the arrow keys as I never learned proper typing technique.
Just tested FreeBSD vi and BusyBox vi - arrows work in both, but I rarely use them (only in insert mode), so can may not notice if they are not supported somewhere. The biggest difference for me is lack of visual mode in vi.
vi is specified by POSIX, but (at least currently) it's marked as a User Portability Utilities (UP) extension, which is optional. It is required for XSI conformance, which mandates other extensions like C-Language Development Utilities (CD). But XSI itself is mostly legacy SysV stuff; the more widely supported parts were rolled into POSIX proper and either made a requirement or grouped into their own optional extension.
In general, most utilities and functions primarily used interactively are optional in POSIX.
But your containers may be a bit weird if their environment isn’t POSIX.
Like if you removed the “cd” command or the ability to read environment variables. “Containers” is any definition you want, but surely they’re built to some standard.
PS: I do make “from scratch” images a lot, I know you don’t “need” to have any utilities at all, but I’m fairly certain that a lot of software expects the “OS” to be POSIX.
I don't know what you mean. Linux containers don't contain operating systems. They contain processes. POSIX describes operating systems.
Every Linux process can read environment variables. They are contained in its address space. "cd" is a shell built-in. When there is no shell, there is no "cd". Not providing access to a shell sounds like great security practice tbh. Your applications shouldn't be using it anyway (they should create new processes directly).
This is just being obtuse for the sake of it. Yes, technically nothing in the notion of a container necessitates that; containers are just a form of namespacing. Have a gold star for understanding that. But the fact is: the vast majority of containers in use are going to be based on some minimal OS image, which is what the commenter was referring to.
People use minimal OS images when they absolutely have to, but the ideal case is just your binary sitting there all alone. (Sometimes you need the tzdata files, SSL certificates, and other support files. But rarely a shell.)
I agree that the ideal case is just a single binary with minimal supporting data, but people using OS images is certainly the norm not the exception. To suggest otherwise is ludicrous.
Despite having 7 years of back end experience, I've never learned vim. Is there any other editor that hits these requirement (being able to login to any server to edit text) or does every server engineer need to learn vim?
(I mostly use a mix of sublime, intellij, and vscode to edit text)
In "linux embedded", absolutely. You take what's there. At some point I even had a debugging session through TeamViewer connected to a Windows machine which had Terraterm open connected to serial port of a linux box. Unfortunately, there was a lot of spam on the serial port, so even using vi was impossible, because the screen got garbled pretty fast. So I printed the files with cat, worked out a set of sed commands to get those files to the desired state and typed them back in. Crazy. But real.
(Add to that communicating with a guy on-site over notepad.exe. Mr. Robot vibes.)
Yes, because your sysadmins won't give you sudo, so you must scp a copy of nano into your home dir. Surprise, it's an AIX server running on Power, so your x86 nano won't run. Does building one from source count as hardship?
This is my favorite comment. You have stated facts which I totally agree with
Learning tools is an investment when you master tools you can achieve so much in short amount of time.
If a person knows his tools pretty well he can get work done faster and I have experienced this by learning vim and forcing my self to use it for writing code. It has improved my workflow significantly
I too was bullied from nano onto vi/vim. I still dont think I 'get it' but the brainwashing is complete, I cant even type the word nano into a terminal.
I too applaud the author for their bravery in coming out as a proud nano user, not that there is anything wrong with it.
I will judge your ability to code by your preference of editor
If someone is turning out high quality code in what seems an awful choice of dev environment then I'd just shrug my shoulders and move on. I don't have the mental energy to work up disappointment or frustration at how another person might, counterintuitively, be just as productive using tools I don't like.
I think R is far superior to SPSS but really don't care if someone decides to use SPSS and produces quality analysis, especially if a lifetime of experience in it made them highly efficient in its use.
Many of the things you mention are absolutely in nano :) Like highlighting, jumping to a line, importing.. I don't have the time to do a point by point comparison but trying nano for 5 minutes doesn't equate knowing it, just like with vim.
I'm not big into coding anymore and nano is handy for my muscle memory, coming from DOS :) It's good enough for my purposes. Sure vim is more powerful but it's not as accessible to the casual user. It's a good tool for its job just like vim is. They're just different jobs.
Absolutely. I use loads of those features including regexp in nano all the time and it works fantastically well. For me it's the fact that it's small (so available on nearly every platform) and the command interface is so quick. It's light, fast, and snappy to drive - no context "shifts" to get to commands, and I can do "power user stuff" with just a simple key shortcut _which is written on the screen so you can see it_ most of the time. It's easy, and that's worth more than a thousand vims. See also the success of Visual Studio Code.
>And if you have an especially strong opinion, I'll consider you even more experienced, even if your strong opinion differs from mine; simply by virtue of having of strong opinion it means you likely have been using it for years and have found other tools inadequate for your skills.
If you really think strength of opinion indicates experience, then clearly you don't have a lot of experience with people...
Jumping to line numbers can be done with mouse.
Refactoring and search/replace can be either sed or grep and copy/paste.
Filtering text through a command can be done in your shell.
Nano has syntax highlighting.
Importing from a file is copy and paste.
Not sure when you really need column numbers.
Split pane editing is tmux or multiple windows.
Now I'll take my customized and plugin-full neovim setup over that any day, but that does not mean a developer cannot be fully competent with nano. I've worked with large projects where I didn't have access to neovim or my setup and just zsh and vi were enough to get the job done. Having to use nano would have been more of an inconvenience but it would have not been in any way undoable. Understandably, a dev would be more productive with their preferred setup, but if a dev couldn't work without it, that would be a red flag.
It's kind of a misnomer then, isn't it? He's not preventing anybody from doing anything, just forming a preconception based on what I think a lot of people would agree is sound logic:
That on average, people whose first instinct is `nano` to edit a file in Linux have less experience than people whose first instinct is `vi(m)` (or, selfishly `emacs`).
> When someone uses a hobby or interest as a means of elevating themselves above others to give oneself a sense of being superior transforming their passion or knowledge about a particular subject into an ugly tool of self-inflation.
The shoe fits.
First editor I used was vi/vim.
For years it was the only editor I could use. (My CS education and school server use predates Pine/Pico/Nano and later on, it was a long time before nano was an option on more restrictive/specialized machines)
I still prefer nano.
In the end, I don't give a fuck what you use as long as you can get the job done.
Passing judgement on what people prefer to use is the de-facto definition of 'gatekeeping.'
The fact that you don't know that nano can jump to line numbers calls into question your judgement. (As can notepad.exe for the past two decades or so)
> The thesis of this post is roughly that nano, when configured, is enough of an editor for the author. Which is totally fine! People should be happy with their tools and not feel pressured by popularity to use what others use (vim, emacs being prime competitors in this case).
My advice to the author would be to give emacs an other shot. It can be configured to behave a lot like nano (and isn't modal), and runs in the terminal. But there's an ecosystem of plugins around it and has a lot of stuff that's built-in. But one day one of the journey it'll behave almost exactly as nano.
What's the point in making Emacs behave roughly like another editor when you can just use the original? Also, Emacs has about a million lines too much bloat for the target audience of Nano. Which is the one thing you can't fix by adding tons of plugins.
I doubt that there is any ongoing vim vs. emacs flamewar. Most people are probably arguing about VSCode vs. JetBrains these days. My impression as an Emacs user is that if someone says they use Vim, I think "hey, one of us". (nano I guess falls into that category, but I bet nano users are missing out on some timesaving innovations from the last few years, and nothing frustrates me more than people that have inefficient workflows because they eschew learning new things.)
> Emacs Lisp is not really a particularly fun language to use simply for customizing the behavior of an editor — as they say, Emacs is a nice operating system, it just needs a good editor.
I doubt one would like an OS where the SDK only supports a language they don't like. I know this was an attempt to reuse a quote, but I think they actually like the editor and dislike the OS, which is the opposite of what sentiment that quote conveys. (Here's another tired meme: "eighty megs and constantly swapping".)
Emacs Lisp is actually very interesting in its staying power. It was designed from the ground up to write programs that the programmer is in front of all day, and that's very different than the enterprise / systems programming use cases that modern languages optimize for (where tens of thousands of copies of your program need to run unattended). The API and tooling matter more than the actual programming language, and I've looked around at other editor platforms and they're just not there yet. You can't C-M-x to run the line of code you're currently editing. You have to write HTML and CSS to supply preferences to your plugin. It's so weird to me how actively extension-hostile the popular editors are these days, and how hard they make manipulating the contents of the editor.
It's a bit twee to compare Emacs to a Lisp machine, as those machines could do lots of incredible things that are still difficult in Emacs.
But dammit, Emacs brings many Lisp Machine advantages to your editor, including live-coding your editor's configuration. If there's a task you need done, or a change you need to make to how the editor works, you can code it up in Emacs Lisp right in the running editor (or even record a macro as a starting point), test it, debug it, and save it off if you like the results. Without leaving your editing session.
The huge advantages this brings outweighs my complaints with Emacs Lisp the language (which are many).
100%. If I understand correctly. to change a single line (say some behaviour that is wrong for your workflow) of a VSCode plugin you have to fork it on Github.
In Emacs it would probably be a short snippet, tested in your scratch buffer and added to the end of your init.el:
(add-hook 'vscode-todoist-xxx-hook ...)
This is what I miss the most about Emacs - what I don't miss is the endless configuration/tweaking...
I think you're referring to multiple cursors? Visual-Multi [0] is an amazing Vim plugin for this with advanced features like searching by regex, alignment by regex, transposition, duplication, auto-numbering, and more.
You can ignore the advanced features at first, it's very intuitive: just `C-n` to find the next occurrence of the word or `\\a` to find all, and then whatever editing operation you want like `cfoobar<esc>`. Or to just get another cursor on the line below, `C-<down>`.
The difference is hitting Ctrl+k five times will put all those lines into a buffer. And Ctrl+u will paste those five lines.
In vim, this is complicated. You could do 'y5' requiring to know/calculate the number of lines in advance. But more often then not you are going into visual mode, selecting everything, then y, then p. This is complicated series of distinct commands.
It's a matter of preference, but I personally prefer Ctrl+k/u of nano over the vi/vim method.
Edit: This is the closest behavior I could get to how nano seems to do it:
let @k=""
let @l=""
nnoremap <silent> <C-k> "ldd:let @k=@k.@l \| let @l=@k<cr>
nnoremap <silent> <C-u> :if @l != "" \| let @k=@l \| end<cr>"KgP:let @l=@k<cr>:let @k=""<cr>
The bigger point I'd like to make is that it's a bit silly to complain about vim's default behavior not being as you'd like it. This is the beauty of vim (and emacs): it's a solid foundation upon which to build your ideal workflow. Few people find vim's defaults to be entirely satisfactory, but with a bit of creativity, you can make just about anything happen (and luckily, thanks to many thousands of plugin developers, you can probably find it ready-made).
It isn’t silly nor did it require you to jump to the defense of vim’s behavior.
It was a simple statement that vim’s functionality can be clunky and with all of its flexibility, it cannot handle something as simple as nano/pico’s method for keyboard copy/paste.
It’s literally the one functionality I would love to become available in vim that exists in nano/pico which would make mine (and likely many others’) lives and efficiency better.
But it can handle it with a very small bit of configuration, as I’ve shown above. I am not trying to defend vim here, the editor you use or prefer has no effect on me. I’m just trying to point out that if you want it to work in a certain way, it’s almost always possible.
The only thing that keeps me from using it as my daily editor is the clipboard functionality in WSL (using Windows Terminal). The first problem was clipboard not working at all, after some updates and tweaks (aliasing xclip to a custom bash script) the clipboard worked. The second problem is yet to be resolved: copy/cut and paste ignores new lines, I haven't found a solution ... Any advice is appreciated!
So I have a question and I'd like to understand if possible.
To me programming isn't text editing. Granted, we use text to write most code outside of say Pike but effectively most programming is working with symbols right? Like .subst is meaningless as an operation on a string but .substring(0, 1) is meaningful.
So I don't really get the advantage of such, to my mind, rudimentary text editors. At a minimum surely being given contextual information about the symbols you are working with (type, fields, methods, etc) is helpful? Perhaps there are languages or domains that are better suited? I can see that there's not much difference between an ide and editor for new languages but why do people prefer text editing and prioritize typing speed where IDEs exist? Does an editor create a sort of flow or deeper state since lack of tooling requires deeper mental context?
To me, programming is a mental task that requires overview and easy text manipulation.
Most IDEs get in the way of me effectively navigating the code as it was originally organized, while still maintaing my overview. "Big" IDEs that clearly sacrifice text area for widgets, or shift text around to pop up distracting inline "help" are the worst offenders. I'm looking at you, Visual Studio.
Common IDE tools like ho-to-definition usually leads to poor understanding of the code structure (and in turn doesn't train for good structures). My best anology being navigating by gut vs. being told where to go by an app - you never learn the route and scenery if you're always busy following the route instructions. And if you never start navigating by gut, you never learn to find your way in general.
I always get frustrated by how slow go-to-definition users are compared to those that just... Open the file in the tree that would logically contain that part.
This is just one example of course - another is that IDE are usually not very versatile when writing in many languages. Also, a good text editor can have IDE-like features in a non-intrusive way, but the difference between "IDE" and "enhanced text editor" would to me be the intrusiveness.
> I always get frustrated by how slow go-to-definition users are compared to those that just... Open the file in the tree that would logically contain that part.
Maybe you're not frustrated with go-to-definition users so much as people who are inexperienced with their tool. I'm having a hard time imagining navigating a file tree being faster than control clicking on a function call or opening "find anywhere" and typing the name of a symbol.
The important aspect to consider is that F12 does not usually answer your immediate question, but just dumps you somewhere closer to what you are looking for in a disoriented state. You now need to figure out what that place is and start looking for the actual thing you needed there.
When I click twice in my sidebar to open a folder and file, I am already fully aware of what is going to show up - e.g. "implementation XYZ of interface ABC".
There are some cases where F12 is faster - specifically when you needed to just read a few primitive lines of the method body you opened, which requires no additional context. That's rarely the case though.
Thanks for your answer, out of interest what languages are you primarily working with and what sort of team and codebase size? It sounds like being forced to consider navigability would offset the tendency for codebase 'melt' in larger IDE assisted projects.
Also one area I lean heavily on an IDE is I can switch codebases up to 4 times in a day between JS and Java, so I'm not going to remember structure most of the time and being able to have all kinds of crutches helps me maintain velocity. Do you find your sense of navigation when swapping is enhanced because you have a deeper understanding of the structure from memory?
I'd say VS Code kind of straddles that middle ground, like an enhanced text editor++. But then full IntelliJ is where I feel most at home so obviously we have different preferences and that's fine. I just worry I'm missing out and heavily dependent on IDEs.
Through a standard work week I code in Go, C, C++, JS (React), Java and Groovy. Odd jobs add Rust, C#, Kotlin (Android) and Swift (iOS).
There are several backend-heavy Go services, React web applications, kernel and user-space driver work, browser work, Jenkins plugins and pipelines, Gradle plugins. It's very varied based on the specific customer we develop for.
Privately I mostly code C and Rust for open source stuff. Not that I mind Go, but I only find it to be the proper tool for network services, not local code.
When you swap around this much, bad code structure goes from something you write on a tech debt ticket and brute force your way around to being absolute top priority, blocking any review immediately.
Of course, memory enhances navigation speed, but the thing is that a painfully obvious structure requires no real memory of it to understand.
Likewise, maybe one can cope with switching between 2 IDEs, but it doesn't scale.
VSCode is decent, but it's still slow and clunky in my opinion. I'm more of a neovim and sublime text type for speed. An open sourced sublime text thing would be awesome in my opinion.
(The sheer number of projects I work with is an outlier due to our company structure, but I believe the experience is universal)
I get the sentiment that having features like "go to definition/implementation" can encourage poor code structure, but that is still ultimately a self-discipline issue more than a UI issue. There are tools for enforcing good code structure that work with many of these fancy IDEs (Visual Studio included).
Just hitting F12 over an identifier to go to it's declaration will always be faster than manually navigating to it, no matter how fast you are with Vim, and I find these features particularly indispensable when learning someone else's codebase.
> Just hitting F12 over an identifier to go to it's declaration will always be faster
Nope - even if you need only one hit, you are now mildly disoriented and need to re-establish mental context in order to correctly interpret what you are reading[0]. Often, you need multiple hits to reach what you needed, in which case you are completely lost outside the single method body you're starting at.
This cost is hidden, and not there during active navigation.
Granted, the action is fast, but I have yet to see it make a productivity improvement.
---
0: an exception would be when you only needed a single methods implementation details, and it's nothing but primitive code that makes use of nothing else and requires no context. In this special case, being disoriented is inconsequential. However, you are usually looking for more than just what F12 throws at you.
Multiple hits? Maybe in a dynamically typed language, but in a statically typed language a good IDE will know exactly what definition to go to 99% of the time. I mostly only have to pause and look at options when using the feature on an interface with more than one implementation.
> the difference between "IDE" and "enhanced text editor" would to me be the intrusiveness.
I feel exactly the same. I hate it when IDEs pop up some autocompletion suggestions that cover up exactly the part of the screen I was reading. Or reformat the code while I'm still typing, making the cursor jump around like crazy.
Automating such features means they're counterproductive in at least 5-10% of cases. I prefer having nothing automated but everything accessible in an efficient way. And that's why I don't care when people say their favorite IDE has a Vim plugin. That plugin won't remove the distractions, fix the tab behaviour or clean up the UI. The controls are only a fraction of what makes Vim the editor it is.
> I can see that there's not much difference between an ide and editor for new languages but why do people prefer text editing and prioritize typing speed where IDEs exist?
That's not why I use a text editor (Geany most often). I find the IDE to be complex and to bring on complexity. If I'm using a text editor the project has to remain simple. The best analogy I have was when I used Slackware. Ubuntu users would laugh because Slackware didn't have a package manager that resolved dependencies. Slackware users would laugh because Ubuntu had a packaging system so complex that it needed dependency resolution. Simply put, using a text editor imposes discipline that makes programming more fun for me.
I'm sure I would use an IDE if I were a Dilbert-style enterprise Java developer. The enterprise thing took all the fun out of programming so I took my career in a different direction.
> I'm sure I would use an IDE if I were a Dilbert-style enterprise Java developer. The enterprise thing took all the fun out of programming so I took my career in a different direction.
I think this is the crux of my fear here. Like I don't really enjoy the jobs I've had because they tend to be that kind of environment. I'd compare it to being a logger whose sole job is to saw lots of logs quickly. Using a handsaw just seems barmy but you would probably use one when building a jewellery box. I guess Unix type architecture and design encourages jewellery boxes over lots of planks quickly.
That's fine if you're the one architecting the code, but when you move to a legacy other project with 100s of thousands of lines of codes and many, many files that doesn't work out so well because you're usually only deciding on a small part of the code.
First, "plain" text editors have caught up with IDEs in many ways that you're talking about here. With a good LSP plugin, you can hop to definition and autocomplete perfectly fine. For a strong statically typed language, the editor can even tell you why it won't build and how to fix it before you even try. Many things you used to need an IDE for just no longer require it.
Second, even without those tools, people hacking away at a keyboard are often doing a lot more than just writing executable code. You're editing config files, READMEs, comments, documentation templates, test data, API request examples. None of these things are amenable to any of the niceties an IDE can help with.
Third, in a microservices world or even just working on a plain library that calls into lots of other libraries, unless you download the source code for every dependency, hop to definition and autocomplete isn't guaranteed to work anyway. It's often easier to pull up the API documentation in a browser on a second monitor and refer to it while working. Screen real estate is cheap these days and the more mature projects you're better off using as dependencies anyway tend to be pretty well documented.
Fourth, an increase in the use of dynamic languages has brought with it an increase in dynamically-generated code. There's a lot of convenience here in reducing the amount of boilerplate you need to type out and being able to change behavior without even having to rewrite the core code, but it also makes IDEs less useful. It pushes the mental burden of understanding how code gets generated and runtime objects get decorated and changed by understanding the underlying data model of the language and its runtime, but hey, that's what we're paid for.
Fifth, what does it even matter in the grand scheme to have definitions and names more readily available inside the actual window you're typing into? It's a convenience, sure, but if you type subst when it should have been substring, you try to build or run a test or just a static analyzer or whatever and you get an error message and remember "oh yeah, that's Language X and I'm writing Language Y," you lost what? A minute at most to go do a global find and replace? Compared to the time studying a problem domain, designing and vetting a solution, coming up with adequate test cases and a suitable type representation that models the domain, the time spent literally typing out function names is minuscule. I'm not going to say saving seconds there is worthless, but it's not a huge gain.
I'll try and respond to your points but hopefully without omnislashing.
On 1) I think that's why this post in particular triggered the question. I don't even conceptually understand what vim and emacs are. Like there are terminal buffers, there's an editing mode, you can't quit it without knowing some arcane ritual and org-mode is, like, wikipedia for to-do lists or something. These are very powerful pieces of software with programmability and plugins supporting e.g. autocomplete that bring them most of the way to an IDE. Nano on the other hand I have used when I need to edit some configs or files on a server and I am just absolutely bewildered at the idea anyone would do more than light text editing in it.
Which kind of leads in to the second point but not really. I prefer a specialised tool for each of those, where applicable. Like README or documentation I might use VS Code with Markdown preview or MarkdownPad2. For config files/hand crafted requests I might just use Notepad++ but increasingly VS Code fulfils this role too and will let you know if you've made a syntax whoopsie in a lot of file formats.
For the third I've actually found I prefer a single 13" monitor with a single window for programming. I feel like looking at API docs in a browser is just enough of a context switch that it will break my focus versus auto-completing to victory. I can actually remember the last time I looked at an API doc in the browser because it was today and I wanted to make a nerdy joke but didn't have the IDE open and couldn't remember if the method was WaitAsync or Enter. But otherwise I will use API documentation once in a blue moon. Most API documentation I just don't find helpful and since we rely on a lot of open source libraries in my job a lot of it is porbably either bad or non-existent. Perhaps this is a difference between people who learned programming when one did it by consulting the BASIC manual and then figuring out and typing the code versus a more IDE based way of learning? I'd guess the BASIC generaiton learned programming more methodically and more deeply.
On 4 my brain falls into this same trap of incomprehension with dynamic languages, though I'm interpreting this as dynamically typed which might be a misinterpretation. Re-reading I don't think that was the distinction you were making so I won't expand here.
Lastly, I've personally found the overhead to be a lot higher. Since this is a throwaway account I can't link to the PR but I recently did some JavaScript work in a big codebase in a text editor and even writing a fairly simple 50 line method felt like swimming through treacle. Not knowing what I had defined, what I could do with what was defined, where I'd used something that was just defaulting to global since it was undefined, where I'd made an obvious syntactic error etc. I'd say (for me on that codebase) the slowdown to my personal productivity was between 3-10x. Granted that was a codebase without tests, a linter set up, etc. and with low personal familiarity with JavaScript and working efficiently in raw text-editors but it's not an experience I ever want to repeat. Even with tests the time to run the tests, parse the test output, translate the error message and then apply the corresponding fix (and write the test in the first place) versus just fix what the red squiggly told you just seems intentionally less productive.
An additional 'finally' as a mea-culpa. I once tried to learn Pony since the language seemed interesting but every time I tried I just bounced off it because I felt so lost and unproductive having to use the API docs and tests/compiler workflow. People who are more used to that workflow probably have an easier time picking up new languages and codebases so while in my experience I'm in the top 20% of people in my language I have a poor generalist ability and low efficiency outside my specialization.
It's not about the editor: it's about the combination of other tools. Simple text editors invite you to use specific tools for specific tasks that an IDE aggregates and configures for you.
An IDE is usually good enough, but for some environments, having total control of your tooling can give you big productivity boosts. And not every software depends upon lines and lines of code. Sometimes, you will write useful software that's only a couple hundred lines, but required you hundreds of hours thinking about the problem :)
I can only speak for myself. For background, I was a very long time vim user, only lately switching to mostly VSCode with vim mode.
That said, I largely agree with most of what you are saying. I spent most of my time trying to get vim to be more like an IDE, and others do something similar to varying degrees (fuzzy open file, file trees, etc are among the most popular plugins for vim).
The reason I used vim all these years, and the reason I insist on using vim mode, is actually kind of related to something you said. Programming isn't text editing. Rather, doing anything on your computer is text editing! Me typing text into this comment box is text editing.
It's true that programming is a lot more about reading code and thinking than about writing code. That said, you're still writing code! And documentation, and many other things.
And vim, purely viewed as an alternative way of working with any text, is simply just superior. In the sense that the amount of time that passes between me thinking "I want to change this text here" to me being able to do it, is almost zero. I can instantly jump to a specific part of the code and make "surgical" edits to exactly what I want to change. This is common with all text editing, but especially programming - how often have you wanted to change the inside of certain parentheses combination nested inside a bigger paren (e.g. for an if statement or a function call?). Instead of spending any mental effort or time on executing this, this just flows automatically.
It's kind of like learning to use the shortcuts for copy and paste. Does this change something fundamentally about programming? No. Does it improve a little on taking an action you take many times a day? Yes. It "adds up" in terms of less things to think about.
>>I can see that there's not much difference between an ide and editor for new languages but why do people prefer text editing and prioritize typing speed where IDEs exist? Does an editor create a sort of flow or deeper state since lack of tooling requires deeper mental context?
Simple. Programs should themselves be programmed(Generated). Anything that has a structure should be generated, never written. This is the idea behind compilers/assemblers. And if you extend that idea, that's true for some thing like Python too.
Python or any higher level language should not be written, you should tell your editor what you want and it should generate it for you. And I don't just mean it at a syntactical level. Modern programming is really assembling recipes. And you should be able to extend your editor to spout recipes when you command it.
This ideally should be handled by the programming language itself like Lisp Macros. But most languages don't have macros, so ideally the editor must now act like one. Like take a command and expand code in place at compile/code time.
The reason why people use vim/emacs is its easy to extend these editors. Emacs even more so. Emacs is basically a programming environment which uses cursor movements and text as the output of a elisp program, the text buffer itself is attached to a live REPL(IELM). The result is a very rich library to make the cursor and text do all kinds of stuff. You can now tailor emacs to your precise development workflow. There are videos on YouTube on Clojure programmers making Clojure code from Elisp code. Its quite literally feels like magic at that point in time. And needless to there are other great features like 'Keyboard Macros'.
This can be done in vim too, and these days you can use something like fennel and extend vim in Lisp.
Once you start going this lane, you will discover, you've been typing simply too much, and working too hard to navigate around code which you shouldn't have.
> Simple. Programs should themselves be programmed(Generated). Anything that has a structure should be generated, never written. This is the idea behind compilers/assemblers. And if you extend that idea, that's true for some thing like Python too.
If the code -- I assume that's what you mean by program -- is generated, the code is not the true source of the program. The true code should be the code that describe or instruct (I prefer describe) how the program is generated. If you do think your code is being generated, yet you are still reading and editing that generated stuff, that's just inefficient or wrong, right?
Treating the code as being generated results in a attitude of not caring about the quality of the code and yet not seeking better alternatives.
No, the compiler or preprocessor should process a higher level instruction that you write using the editor. The editor can run the preprocessor or compiler or a chain of them with single click and load or view any intermediate code with convenience of course, but none of the generated intermediate form should be written or saved in a repository.
Haha you're pretty much describing me. I think autocomplete overlaps with spellcheck in a text editor. You won't improve your spelling by relying heavily on a spell checker but it won't really affect your vocabulary either and enables everyone to write syntactically correct text.
Programming is more about telling the story or writing the speech than the spelling of the text. Treating code as manipulating plain text just freaks my brain out as the wrong abstraction level. But as I try and remind myself 'different people like different things and that's ok'.
Ah, I don't know... I don't depend on an IDE, they just make things much quicker and easier for me.
And let's say I do depend on one.. it's not like I'm going to be dropped at a computer where I'm not allowed to use an IDE... but it would just take a day to adjust.
I fully agree to an extent. Some APIs (e.g. Android) are huge and a pain to type in Java without some sort of completion. Maybe I'm just lazy or used to C, but Java makes having an IDE almost essential.
I'm not sure I agree on the inherent value of being able to work without an IDE. If that's what you value more power to you, but that's mostly personal preference.
Its not personal preference, because using an IDE should improve your productivity. It's like saying that digging a hole with your hands vs using a shovel is personal preference.
for me personally I noticed that using an IDE started to replace my memory in a way and I didn't like it. I noticed that when I program in languages with an IDE environment (Java in my case) I only really slowly picked up what functions were available in a libraries and I started to really dislike this reliance on constantly looking up things.
When I just program without autocomplete or for that matter constantly googling I actually paid way more attention to 'where things are'.
In python I pretty much know what every string method is. In some languages I used IDEs for I was still scrolling through the completions because I somehow never picked anything up.
To be fair my memory has always been terrible. I loathed times tables at school. I still don't really know them. I just feel like if I need to know I'll use a calculator and if there isn't one available I'll have other problems like clean water and food! Having a general sense of 'size of' numbers was enough and I'm pretty good at maths.
I get that it impedes memorization but how does that scale to using new libraries which may lack documentation? I'm jealous of your memorization of those string methods, every time I switch to JavaScript I feel lost because I don't recall substr Vs subString Vs substring etc!
I know vi very well - but for programming, these days I use JetBrains, which for me is like having an assistant to do all the rote work that doesn’t actually contribute to the task I’m concentrating on.
Manually adding imports is not virtuous. Renaming a function is not virtuous. Searching across files in a project is not virtuous. They are just chores. That’s what we have computers for.
There are plenty of reasons people choose their editors and I fully respect those choices. But after using IDEs like JetBrains and VSCode for the last few years, vi feels like editing a video file using a hex editor.
>but how does that scale to using new libraries which may lack documentation?
it doesn't really that well which I guess is a drawback. I'm not dogmatic about it so what I usually do with a new larger codebase is I just open it in vscode, read around somewhat, look at the symbols and use that for a while and then when I'm kind of familiar with it I go back to emacs.
>I'm jealous of your memorization
it's was actually very difficult in the beginning and one of the reasons I started doing is because I noticed just how bad my memory and attention had gotten without tools. Even with other things, as a kid I could read for five hours straight and a few years ago I noticed I couldn't read for 30 minutes without distraction.
>Hopefully this post demonstrates that nano is a quite capable editor in its own right.
This post showed how to add a slightly enhanced minibar, remove the help and add syntax highlighting.
It would be more important for me how to quickly navigate text.
Certainly people should use the tools they like and are comfortable with. That said, I would suggest that there's a limit to this "whatever you like is fine" logic.
If you were building a birdhouse and decided you liked hammering in nails with the broad side of a wrench, yeah, ok, I guess that's your business and ultimately you can hammer those nails how you want. But if you saw a professional carpenter hammering in nails with a wrench, you'd have to seriously question whether you hired the right carpenter.
I actually don’t use nano though only because it’s not always there. I learned a long time to pick a narrow subset of ubiquitous tools to know really well, compose those and leave it at that. If I’m dumped in single user mode somewhere with no network, or on a system I don’t have the ability to install packages on, a usable vi implementation is always available.
Going back a couple of decades a colleague was stuck on a Solaris box because he needed pico installed and Miss root was off sick. He learned vi that day.
Incidentally I used to embarrassingly suck at vi until I completely hosed a couple of systems.
I'm all for choice but... The author is, of course, free to do whatever they like, and I'm free to say that using nano is almost certainly not an optimal workflow.
The beautiful irony of this post - some of the most common commands in nano (C-a, C-e, C-f, C-b, C-n, C-p, M-g, C-k, and more!) are taken from Emacs. If the author uses nano and bash (readline) to do work they are 80% of the way to using Emacs, the editor they supposedly don't like. And all the other commands are easily rebound to work like nano. The author could be working in an environment that's nearly identical to their current one, but that also has support for:
* A toolbar, scrollbars, pulldown menus, etc.
* Displaying multiple files side-by-side
* LSP
* Automatic refactoring/type-checking/code formatting/etc.
* Advanced movement (jump to definition)
* Mouse-over to see documentation
* Macros/multiple cursors/batch renaming
* Automatically detect missing dependencies/namespace errors/etc.
* Calling external programs & handling their output
* and more...
If you write code like this I can only assume you either work like I did in high school when I used nano (alone, on small projects, with only specific languages, spending 95% of my time debugging) or that you work at 1/10th the speed of a typical programmer.
1. When I google for "nano ctags", I get one hit: someone's 2011-dated blog about their custom "nanotag.sh" which searches through the tags file and then runs the editor to bring up the right line of the right file, which is kind of like walking a quarter mile to get water from a well instead of having running water.
Maybe Ariadne uses nothing but cscope for naviating through code bases? Cscope is a bit crippling; you use it as a kind of dashboard for searches to which you have to return to start another search. If you find occurrences of an identifier, you have to return to cscope to navigate through that list.
2. I don't see any documented support for running a compile job out of Nano such that it gathers the errors and lets you move around in them for fixing.
3. No mention of "lisp" in the manual. How is the Lisp auto-indent and such?
Ariadne talks about getting the editor to "look" like Vim, but I don't see the point. What does that mean? Vim looks more or less like ... a section of your file. That's what you see. Plus some syntax coloring; is that the point? Looks are only skin-deep; the semantics is invisible from just looking at the editor screen.
She presents a falsely incomplete set alternatives ("false trichotomy"): it's either Vim, Emacs or Nano. It has to be Nano because Vim is modal and Emacs Lisp is yucky (complete with a meme about Emacs being an OS with a lousy editor) (so why would the author care that there appears to be no Lisp editing support in Nano, right?)
But, say, about good old Joe? Joe has ctags support and stepping through compiler errors and such. It's substantially more suitable for programming than Nano.
By my estimation, Joe could be the editor the author actually wants.
I've always liked nano, as it seemed closest in functionality to the text editors I used to work with in DOS (which set the UI standard that I measure interacting with console applications from)
I wasn't aware people have added so much extra functionality to it. Nowadays I turn to vim but I will give nano a closer look
> it provides all of the features from vim I would want anyway, but in a modeless format
> vim-like functionality with modeless editing
> nano is a quite capable editor in its own right
but the only features that are mentioned are syntax highlighting and hiding the help text.
Looking at the man pages for nano, it _is_ a lot more capable than I had previously though (though not as capable as vim or emacs), but the author doesn't really go into that.
Yep, same here. I graduate from Pico on a Vax system to nano on Linux for console editing, with the exception of Ted w/FOCUS since it was a somewhat integrated development environment.
Of course the limitations mean I still had to use things like sed & awk frequently for things that weren't possible or were much slower in nano. That's for relatively small uses though. I use an IDE for most coding.
`sudo vi` runs vi as root, which means 1) it won't have your users configurations, and 2) it's probably way the hell over-privileged for what you are trying to do.
`sudoedit` (and equivalently `sudo -e`) makes a copy of the file that you can edit and then copies it back as root iff it's changed.
I admire the author's straight-up owning her choice here, in spite of the elitism that's long fueled the whole "lol you use nano!?" douchebaggery.
Perhaps worth a chuckle: I once interviewed on-site somewhere, panelist-style format with "the team" hitting me with questions all around. One of them asked about my preferred editor. I mentioned some GUI editor I was using back then (don't remember now, it's changed over the years). He laughed and said something like, "what, you!? YOU use a GUI editor, not vim!? C'mon man! You're better than that!" So I fired right back at him, jokingly: "Dude, it's an editor. Not a religion. I ain't down the the jihad, bro!"
Fact is, you can be productive in just about any editor as long as you know how to use it right.
If vim/emacs is your jam, fantastic, you have fun with that. You can brag about "productivity" all you want, but there are - demonstrably - other people out there who don't do it your way and they're equally productive, and in some cases better. Productivity isn't measured in keystrokes per second. What matters is what gets DONE.
The elitist attitude that anyone not using emacs/vim is "fail" or "noob" is just plain stupid. All that does is demonstrate that you value your own ego over the success of your team, and that you might derive pleasure from putting other people down, a significant mental health problem. It also forces people to raise their guard around you, and erodes their trust in you, especially if that attitude is reinforced in other ways. I'm not saying you can't joke around with people, and it would be short-sighted and foolish to draw any final or major conclusions on ONE thing like this alone, but if someone sincerely pulls this elitist BS on you, you'd be a fool not to raise your guard, to some degree, around that person from then on.
If we're gonna learn a stack of key combo shortcuts, why not go with a editor that was designed with that in mind (i.e. key combos organized into a hierarchy rather than a huge flat mess)?
> why not go with a editor that was designed with that in mind (i.e. key combos organized into a hierarchy rather than a huge flat mess)?
Nano has a tree-like structure. There are a a few root commands for common things but a menu like "replace" has these options shown: https://imgur.com/5IKRyeC
In this screen you can see "M" which means the ALT key. These names (^, M) are not ideal but they have their roots in the originally common teletype names (control, meta). It's not the best but it's easy once you remember those two things since you need to remember nothing else.
An important note about these menus: they remember your previous insert. If you click the up arrow key you can go back in time to previous searches just like your terminal. It's how I could say that 4 searches ago I looked for `affinity_test`.
Also, nano supports all of the standard navigation you will be used to. Things like:
- Page Up/down: Go up/down an entire page of text.
- Arrows: Navigate text one character/line at a time.
- Scroll Wheel: Move cursor up/down for each input.
- ctl + left/right arrow: Move one "word".
- Home / End keys: beginning and end of line.
So, the things you already know from all other programs directly apply. The things that aren't the same that you will use are at the bottom of the screen or behind a "CNTRL+G" menu that is at the bottom of the screen. All for giving up ~3 vertical lines of text. I just checked and at my default font size I can fit 57 lines on my monitor so I'm giving up 5% of my screen so anyone, regardless of skill level, can sit down at my computer and know how to operate the text editor.
It's worth pointing out that many distros ship with a positively prehistoric version of nano (i.e. v2.9), whereas the latest version is actually lightyears better.
I agree with the author completely.
As for the "yes but vim keystrokes" apologists, honestly I have yet to find something truly important I can do with significantly less keystrokes in vim. (especially if you factor in programmability and macros).
Do you not use motions? I use stuff like `dfXa` where X is the character I want to delete to, for example. I could do 23x, d6w, or d/foo<CR>, depending on the information I have, either way this is light-years faster than what I can do without motions. Macros and programmability are great, but they are more for boilerplate stuff than just one-off mangling text fast. You can also hit the arrow keys in sed mode to reuse old commands, a lot more painless than recording and storing a macro in my imagination.
My claim is not that motions and the like are not useful constructs. My claim is that most functionality of this sort, whose use-case is not contrived or trivial, has equivalently low-keystroke solutions in nano; these often tend to be more intuitive as well, and sometimes require even less keystrokes/keyboardtime than vim (especially considering the whole enter/exit edit mode extra keystroke, which tends to be conveniently absent in keystroke wars).
E.g. dfXa -> Mark, Search, X + Enter, Delete
d/foo -> Mark, Search, foo + Enter, Delete
d6w -> Mark, EndOfWord x 6, Delete (or store 'EndOfWord Delete' as a temp macro, and use a predefined repetition command)
To me, '23x' (and to some extent even d6w) is an example of a contrived use-case; while you can come up with ways to minimize keystrokes for such a scenario in nano too, in reality if you have text or code where you need to find the 23rd instance of a character EXACTLY, there's something REALLY wrong with your code/text, in which case '23x' is the least of your problems. In all non-trivial/non-contrived cases, if you need to look up something 23 times, you're probably going to want to walk through those instances as well, and the act of 'counting first then executing the incantation' is likely to cost you far more time spent on the keyboard than what is saved by minimizing keystrokes. And if you really, really need something as arcane as that, and use it often, then you can write a relevant macro easily. No need to bother regular users with that bloat.
Somebody else here already mentioned the ^U^U^U^U^U^K vs y5p comparison: this is a prime example of the above philosophy, and I agree. Keystrokes are saved at the cost of actual time spent on the keyboard. At the end of the day, I'd much rather spend 5 seconds on 10 keystrokes, than 10 seconds on 5 keystrokes. And in practice, most people would use a selection instead anyway, resulting in more keystrokes in vim compared to nano to begin with.
nano was my cli editor of choice because I was overwhelmed by vim. For years I felt subpar and thought that I should learn using vim. I'm using vim for some years now but I don't really make much use of it's features, maybe an occasional cut and paste, which probably can easily be done with nano too.
My dirty software engineering secret is that I don't know how to use vim. Like at all. I've been a developer for over 10 years at this point.
The only thing I remember is that some combo of hitting the escape key and typing :wq gets me out of it. When I get a new machine I have to immediately change the default editor for git so I don't get totally stuck if I need to edit a commit message.
I also use a GUI text editor for git...
I really appreciate that nano has it's shortcuts written on the screen for me to use. It's my CLI text editor of choice for that reason.
https://vim-adventures.com/ is a fun way to flesh out your vim understanding. I've only been through the free bit and balked at the price tag, but very much enjoyed what I played and if I weren't already well versed in vim it would probably be well worth it to continue.
I was shoved in the pool with vim, I don't think it took me more than a couple days to get proficient with it and by the end of the week I didn't want to use anything else. Of course I had a fairly large coding project that I was working on. Of course I'm still learning little bits here and there :)
An easy (and fun) way to get better at vim and learn some of its features is to play vimgolf [1]. After you submit you can see solutions which are slightly better than yours, and run them through to see what each command does.
Nano (or pico) is great for very small, quick edits. I often use it when setting up a VPS for the first time before configuring my editor’s remote SSH exten B sion (or in the past, installing rmate). I wouldn’t personally use it for more than just a quick change, but to each their own!
The thing that is missing from this article and the comments is that vi(m) is available on every unix machine made in the last 30 years. Knowing it well gives an admin a dependable tool that is ubiquitous. And once you know vim, why would you choose anything else?
i spent a good long time writing code in emacs but our current project uses an IDE, and I found I could be pretty productive in it and learned to leverage its advantages. But I could not live without a solid text editor, and still use emacs for texty stuff, like config and log files and such (even though in theory i could do that in the IDE as well)
But as a result, a lot of the cool stuff I had set up in emacs never gets used anymore. not even sure how to run many of the .el's anymore i have in my .emacs tbh. I could probably get by just fine with nano but run full emacs just out of habit.
Nano is a great little editor, however one thing I have not figured out yet is to achieve a true cross platform .nanorc file when dealing with paths, windows vs posix, things like include directives and backup dir.
I always recommend nano to juniors if they need to edit config files on their local environment. Being able to use a CLI editor is an essential skill but there is no need to make it complicated.
there are far worse choices. for quick stuff, i either emacs -q or nano more or less interchangably, and in my larval stage i lived in nano (and pine!) for many years happily enough.
These days, i find that my movement key memory will betray me in nano at the worst time(s), so i tend to stick with emacs -q -nw for light-and-fast stuff, but when that's annoying to obtain, i'll happily fall back and think more carefully about my keystrokes.
Then connect with emacsclient. You can also name the daemon which lets you have specific configurations for specific tasks. At that point, launching emacs for quick stuff is very fast.
Outside of corner cases, most of the things that become the focus of tech religious wars make fairly marginal difference compared to other factors, like proper design, testing, documentation, etc. (Corner cases do exist, however; no one wants to write a compiler in brainfuck). I definitely tend toward a view of do the work, boring stuff included, in whatever text editor, IDE, and language floats your boat.
I can't even properly explain why I like Vim. I guess it's the same way, by habit. When in a non-modal editor I'm just very clumsy. Trying to type commands but inserting text instead by mistake and so on.
more power to ya! that's what's wonderful about general-purpose computing - there are many choices and whatever works for you to get the job done is all that matters.
Do you write code in BBEdit? VS Code feels way more capable, at least at first glance, but I know BBEdit fans have a lot of love for it.
I ask because I'm growing a little tired of VS Code. It works nicely, but it never feels like a native editor. BBEdit, and Panic's Nova, feel like I'm actually using a Mac. I'm trying to decide if either of those are better than (or at least as good as) VS Code.
Yes, I write my own code in BBEdit. When there's no collaboration needed, it's more than adequate, and the Mac integration (AppleScript API) is great.
VS Code is good for git blame integrations, finding references to functions in a deeply nested project, and using extensions. It's an IDE, not just a text editor.
So I suppose it depends on your use case: if you're the only developer, a text editor is enough. If you're working in a larger team, an IDE can be helpful.
Yeah, that's the point. Since they are both tools, I'd rather see more tool war posts regarding languages. At least people will quickly deviate to language theory or quirks in languages so that we can learn a lot.
Alas, nano (and pico before it) have a certain stigma among more "experienced" Unix users that more or less boils down to gatekeeping and snobbery. Which is a shame.
That said... it is worth considering that learning tools like editors is an investment in one's self and pushing through preference to genuinely try to use what others find value in can, if nothing else, help you better understand what you value and adjust your tooling to fit (much like the author adjusted Nano to be more like vim).
That's a pretty nuanced distinction though and I am glad that the author feels comfortable owning their preference and not feeling pressured by peers to conform to more "acceptable" choices while still having tried and learned from them.