GNU nano is my editor of choice
ariadne.space
ariadne.space
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.
(Add to that communicating with a guy on-site over notepad.exe. Mr. Robot vibes.)
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.
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).
In general, most utilities and functions primarily used interactively are optional in POSIX.
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.
You haven’t lived till you have to edit using only sed.
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.
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.
Even alpine based images have a version of vi (it comes with busybox)
# pkg install nanoI'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.
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.
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 was about a decade ago though, maybe RHEL has removed nano since then.
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.
snob: a person who believes that their tastes in a particular area are superior to those of other people.
Nano is superior in that its easier to use. But it's certainly no where near as powerful as Vim or emacs.
(I mostly use a mix of sublime, intellij, and vscode to edit text)
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.
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.
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.
Vs
What you should do is...
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.
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 tend to use nano because I'm mostly making changes to config files and the like so I mostly want simple.
Just say "nano is Linus Torvald's editor of choice" (which is true and will instantly shut down the debate)
> I really need to switch over to something that is actually maintained and does utf-8 properly. Probably 'nano'.
https://www.tag1consulting.com/blog/interview-linus-torvalds...
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.
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
Personally I look with pity at people who invest in cargo-culting the idiosyncrasies of systems from ancient times which simply don't apply anymore.
But the correct answer is ansible or it’s ilk- not being told that managing things one by one is “fine”.
Or like in nano, relegating oneself to managing files character by character.
I too applaud the author for their bravery in coming out as a proud nano user, not that there is anything wrong with it.
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!
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]
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. :)
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
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.
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.
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>`.
Ctrl+k is cut line, similar to yy
Ctrl+u is paste, similar to p
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.
I use the following mappings for emacs-ish editing in insert mode:
" emacs-style editing & motion
inoremap <C-a> <Home>
inoremap <C-e> <End>
inoremap <C-b> <Left>
inoremap <C-f> <Right>
inoremap <C-n> <Down>
inoremap <M-b> <S-Left>
inoremap <M-f> <S-Right>
inoremap <M-d> <C-o>de
inoremap <C-k> <C-o>D
inoremap <C-p> <Up>
inoremap <C-d> <Delete>
" restore support for digraphs to M-k
inoremap <M-k> <C-k>
inoremap <C-k> <C-o>"Kdd
inoremap <silent> <C-u> <C-o>"Kp<C-o>:let @k=""<cr>
nnoremap <C-k> "Kdd
nnoremap <silent> <C-u> "Kp:let @k=""<cr>
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>
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 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).
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 ...)
Does micro support Vi keybindings?
Currently micro does not have any sort of Vim emulation. However, this is the next major feature that is planned, so stay tuned.
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?
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 :)
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.
For me, anyway.
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'.
When you understand that you can start using an IDE. Same as with a calculator or any other advanced tool, i.e learn the basics first.
After that you should of course use the tools available, like an IDE, if it helps you.
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.
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.
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)
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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 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.
>>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.
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.
Nobody should write fileopen-read-close repeatedly over and over again. The editor should write this kind of code for you.
Yes. Macros.
Only Lisp has it. No body really uses Lisp. And languages like Python don't have it. So we have to use these hacks for the mean while.
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.
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.
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.
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.
Another unexplored possibility is Jed.
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
> 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.
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.
Any choice of tool is always about trade-offs.
thanks me later
`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.
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.
include /usr/share/nano/*.nanorc
set autoindent
set minibar
set morespace
set historylog
set linenumbers
set softwrap
set tabsize 4
set tabstospaces
Now you got a full featured IDE.
The key bindings are at the bottom of the screen.
Example: https://imgur.com/tFVNFc4
^ is CNTRL.
> 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.
* pg up/down
* find (^W)
* go to line (^_)
the first two are standard across applications, and the last two are in the help menu that shows up by default.
Confusingly, this is actually not a ctrl (^) shortcut at all. It is alt-g.
alt g is another binding for the same.
^_ is ctrl and underscore
underscore is shift and minus
So ^_ is ctrl and shift and minus.
On my computer, doing ctrl+shift+- brings up 'Enter line number, ...'.
Am I misunderstanding what you mean?
I was like "WTF?" because I'm a Mac programmer and my plain text editor is BBEdit or an IDE. If I have to edit a file in Terminal I'll use nano.
The session leader thought I was weird, but I quit vi (eventually), used nano and it worked fine. I still don't know how to use vi or Emacs.
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).
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.
You learn vi(m) by steps using a quick manual.
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.
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.
Modded GNU Nano using ycmd code completion and IntelliSense.
https://github.com/orsonteodoro/nano-ycmd
Long live nano
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.
emacs --daemon
Not much written about it.
Editors like Vim have a learning curve because they introduce the concept of modal editing which takes some getting used to.
"nano? Real programmers use emacs." "Hey. Real programmers use vim."
Personally I use TextWrangler (BBEdit) for fun, and VS Code at work. I know how to exit vi though!
"Q. How do you generate a random string? A. Put a Windows user in front of vi editor and ask him to exit."
https://www.reddit.com/r/ProgrammerHumor/comments/72y7lr/q_h...
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.
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.
*when editing in a terminal session.
export VISUAL='dosbox C:\DOS\EDIT.COM'