It's great to see more projects in the space, but for me it's not really about the editor itself any more, it's about the ecosystem and the extensibility. The act of selecting and changing text is just a small part of the problem space.
I use emacs not because I'm a neckbeard, but because I can script it to do whatever the hell I like. I switch to vscode when I want to do something my emacs setup isn't yet good for (like, working with Typescript).
On the flip side, I use sublime text as a notepad replacement because it's that fast. I still use nano as my default editor for commit messages. Sometimes I use vim because that's what I happened to type to open a file.
This isn't a comment on helix editor itself...just that, it's a pretty saturated space and I'm keen to see something as novel as light table play out again, but only more successfully.
It's interesting because I come from the exact opposite direction. I started with IDEs, then Emacs for almost 15 years, and last year I switched to Vim.
Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years.
The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc...
No setup, no configuration, it's lightning fast and it just works.
I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
LSP and Tree-sitter seem to have the right approach, aiming to provide a standard layer that can support a wide variety of languages and ecosystems throughout. Language-agnostic tools can interoperate with this approach too but they only provide very basic features, not really enough to compare well with existing workflows.
I totally agree with you !!!
I think using visual studio code gives you everything out of the box like all these extensions just makes things very easier for you.
But learning tools such as vim and learning how to configure those really helps you get out of the comfort zone
I was a regular vscode user but after using vim my workflow really improved
I have nothing against vscode users but sometimes getting out of comfort zone really helps you
The 10 line Makefile doesn't do Smalltalk like development experience, nor is able to single step GPGPU shaders, do live editing of GUIs, graphical visualization of running tasks and threads, provide graphical architecture diagrams, correlate lines of code with the people that edited it and to which tickets the PR were made to.
It is a chicken and egg problem though. The quality of the ecosystem can be improved with a really strong editor underneath. However bringing the ecosystem to the editor is incredibly hard.
I think vim is a messy pile of hacks, and I would love to see that changed. Neovim is nice with the extend and evolve approach but I'm always looking for something that can really provide a clean base for extensions to build on. (Yes ,yes, I know emacs is an editor-writing IDE)
On the other hand I see nothing about plugins here. I think the approach to extensions is a very important question to answer early on.
> I'm keen to see something as novel as light table play out again
All these years and I was starting to believe I had imagined light table. How else could one explain no editors adopting inline, always-on evaluation?!
I'm an emacser, but I disagree. Most editors are awful. IDE editors are generally poor (name it, I've probably tried it).
Large language ecosystems are only good when you don't need them. If they're just gravy, then life is good. If you need a lot of stuff to be moderately productive, that sucks.
LSP is the shining hope here, but you suddenly get into questions about your build environment, and that's another rabbit hole just to get decent completions.
> Most editors are awful. IDE editors are generally poor (name it, I've probably tried it).
What’s awful about VSCode? Genuinely curious. I use it daily and enjoy it. I love all the extensions I have access to.
> If you need a lot of stuff to be moderately productive, that sucks.
I don’t see why I would ever not have access to my extensions, nor is it very difficult to copy-paste my extensions.json file to a new machine and press “install all”.
While I generally agree some ecosystems may require an IDE (Java). Some may say that the ecosystem is the problem and not the lack of an IDE. And I would not disagree.
> I use emacs not because I'm a neckbeard, but because I can script it to do whatever the hell I like.
This. With some elisp knowledge, you can bend Emacs your way. No need to write full-blown packages. A function here and there can get ya very far. I wrote about this yesterday[1]
I use magit extensively because it's an utter fucking marvel, but sometimes I'm in a shell without emacs open, or I have to run some internal tooling that wraps around git.
My point overall was that I see all of these as a collection of tools. Which one I choose depends a lot on context, and it's served me well to be baseline comfortable with all of them rather than depending too heavily on my emacs setup.
I'll admit to doing that. Command line git is baked into my muscle memory now.
(magit is brilliant, but for some reason it's never stuck with me, unless I want to interactively stage a few specific chunks, and then it's much nicer than using the cli).
Maybe I'm not the common use case, but when you say "because [Sublime] is that fast", what do you mean? Creating a new file in VSCode, for example, couldn't be any faster. Is it the case that you close VSCode often? Is it booting the application that is slow? This isn't criticism by the way, I'm genuinely curious since I hear this a lot.
I'm just as surprised as you are that people do see it, that some people don't see it. I have no idea what the explanation is, but there's something radically different about me versus people who can tolerate VSCode's slowness (I'll use VSCode if I have to, but I'll avoid it if at all possible, just because it's slow).
I still prefer sublime text for opening very large files or jotting quick notes.
VSCode load times are heavily correlated to what files I had open last and what extensions I have installed that trigger because of my previously opened files.
When I freshly install VSCode on a machine, it feels blazingly fast. A couple months later when I've loaded up a few linting extensions? Not so much. Of course, the power of these extensions is why I'm using VSCode in the first place. I've yet to see an IDE that can integrate these types of features and not slow-down in some aspect, and VSCode does seem to try to stay as lightweight as possible.
VScode also often has notification prompts when I open it, either from extensions, or as popups generated from the editor itself. This doesn't add load time perse, but it does add to my mental perception of it's load time.
I can open and close an instance of sublime whenever I need to, without having to keep it running somewhere. I'll only use it for tweaking the odd file here and there when I'm in Windows.
I also literally only use VSCode when I have to work with Typescript.
It's interesting he values company management so much. What's stopping Microsoft from one day abandoning VS Code, like Atom was abandoned? Is Microsoft even making any money from it?
Boehm, Hans-J., Russ Atkinson and Michael Plass (1995) "Ropes: an alternative to strings", Software—Practice & Experience 25: 1315–1330, DOI: 10.1002/spe.4380251203, https://dl.acm.org/doi/10.1002/spe.4380251203 (cited 2021-06-01).
It's basically just two stacks of lines, where a line is an array of characters. One stack has the lines before the cursor, the other has the lines after the cursor (in reverse order).
I use emacs, but ropes are a much better way to go if you're starting from scratch.
I wish there were a name for the generic type Foo<T> such that a rope is exactly a Foo<Char>. In other words, a rope-of-non-character primitives (like bytes or floats).
Generalizing even further, I wish there were a name for the generic type Bar<T,M> which is a b-tree of T-values, plus a monoid [1] M over T, where each non-leaf b-tree node stores the M-sum of its descendents [2]. This lets you quickly compute the M-sum of arbitrary ranges or search for an element by the M-sum of its predecessors. Ropes are essentially Bar<Char,(0,+)> so the monoid gives you the number of characters in a range.
If you let M=(0,max) or M=(0,min) you can get the min/max value in arbitrary ranges in O(log n) time. This is extremely useful for all sorts of things, from algorithmic trading (order books) to VLSI (plotting waveforms from gigantic simulations). If M1 and M2 are monoids, then $M1\cross M2$ is a monoid, so these "range summaries" are very modular -- you can mix and match them.
In the functional programming community there is a data structure called a finger tree [3] which are a specific case of Bar<T,M> implemented as an immutable data structure. Immutable data structures are nifty, they have benefits, but also costs. I don't know what to call Bar<T,M> implementations which are non-immutable (i.e. ephemeral or update-in-place) data structures.
If anybody knows of generally-accepted names for these (or wants to suggest some) please reply. I plan to add this functionality into (a fork of) LMDB.
I was in a discussion about this recently. I would probably use an RRB tree, which would give me virtually free tree-based undo/redo, an a simple way to implement multiple cursors.
A rope is a data structure for big strings. Its a string where instead of storing the characters in an array, the characters are stored in a different data structure to make common operations faster. Ropey stores a string where the characters are kept in a b-tree. This allows log(n) time complexity for inserts or deletes anywhere in the string.
So you can have a string with millions of characters (a loaded document) and you can edit it efficiently.
> Built with Rust. No Electron. No VimScript. No JavaScript.
Great. So, what's the extension language? Rust is utterly inadequate to be a scripting language (if you have to recompile the text editor to reconfigure it, that's a non-starter).
VimScript sucks, but it's better than literally nothing. Emacs Lisp is weird, but powerful. Python is great and everyone knows it. Lua is small, simple, blindingly fast, and literally designed to be embedded in compiled projects.
Why is there no mention of extensions or extensibility?
The landing page is just something I threw together in an hour so it a bit joke-y and doesn't convey everything -- I'd like to implement some form of scripting (either via wasm, gamelisp or lua) down the road, definitely. I was waiting a bit to see if Grain or Assemblyscript would mature a bit more, but I'm also at the stage where I'm still adding core features so there wasn't any time to focus on scripting yet.
I posted this on r/rust to get some feedback, definitely wasn't prepared to expose it to HN yet.
Interesting choice, to think about a wasm based scripting language, when the editor itself is proudly free of all webrelated stuff?
Basically, have you given thought into it, and see a way to integrate it in a efficient way, or come those thoughts from the potential ease of use with that and implementation details later?
In either case, I think scripting is very important to many people, so you probably should add a section about it somewhere, that it is definitely planned, open for suggestions (?) on the scriping language, and coming once the core features are stable.
I have been using vanilla Vim with no plugins for years now, and I do have a config file but no plugins or anything.
I was driven away from Kakoune by the "clever" way it uses shell for scripting, and some basic functionality needs scripts. Pretty cool but not for me.
Given a built-in language server and syntax coming from tree-sitter, that already covers almost everything I need from my $EDITOR. The only other thing I need is the ability to open compiler error log and jump to locations.
I think that the perfect editor would use the perfect extension language...which, sadly, does not exist.
As a Lisp+Emacs user, I'm biased towards elisp, but it's definitely not perfect, having multi-decade-old baggage that holds it back. Lua has a beautiful design that is geared toward embedding, but lacking metaprogramming capabilities and things like optional typing. Python's design is ugly in many ways that the other two aren't, but it's more featureful than either of them and doesn't have elisp's warts. JavaScript has a more elegant design than Python, but a bad rep and a community that is borderline averse to performance.
There is no perfect extension language, and I'm convinced that, for fundamental reasons, there can never be.
But, I'll take an imperfect language (again, I'm biased, but I'm very bullish on a Lispy and Lua-y stuff) over none at all.
I really like the way kakoune (https://github.com/mawww/kakoune) handles it, the editor doesn't have any scripting as such, it has an "API" in the form of pipes and environment variables that can be used by shell scripts or tools written in any language. Unix is the IDE.
I just could never get my head around the key bindings with kak.
Lately I've been wanting to get out of the business of maintaining my own vim setup and just adapt to someone else's work. I'm in a state of never coming up with the time to really sit down and create a repeatable modern vim setup, but always feeling like I could be getting more. I've used vi for over 30 years, FYI.
Recently I've been playing with:
OniVim2: I'm not really sure what enhancements it has, but it does have a standard setup. Unfortunately, I'm running into some problem with my setup losing Python syntax highlighting. The ability to use VSCode extensions seems like a real winner, I've never been able to get into the weight of VSCode for my every day shell-oriented workflows. I don't program much, YMMV.
The Amix "awesome vim" setup. It is, unfortunately, TOO awesome. I set it up and some of my first movement commands were bringing up plugins (Ctrl-N and Ctrl-F). Didn't try it very long, it was a bit too much of a departure.
SpaceVim: I spent a while in this, it was working ok once I adapted a few things to it. It's a contender, probably behind Lunar.
LunarVim+NeoVim 0.5: This is looking promising so far, only used it a bit. But the TreeSitter plus LSP seems like a winning combination! Plus it works in the terminal, which OniVim does not. I do a fair bit of my (limited) programming via ssh from a chromebook (my couch compuer).
Hey, Onivim contributor here. Sorry to hear about that syntax highlighting bug! It’s something we’ve received a lot of feedback on, and I know bryphe is planning on dedicating more resources to syntax highlighting fixes in the next couple of months. If you haven’t already, feel free to open an issue on GitHub (or comment on one that’s similar)! It helps us put our finger on where the editor falls short for people.
Will do. I'm so new to Onivim that I wasn't even sure if it was "a problem" or "my problem", or how to get more info on it. It could be a problem with my setup, I try to keep my workstation fairly clean, but it is a working setup so it's no plain vanilla. Thanks for the reply.
I did a bit more investigation, and found that "-f" outputs huge amounts of debugging information. In that I was able to see that after 2 movement commands it is detecting a file changed event, and the "newFiletype" is "plaintext" where it was previously "python".
It doesn't seem to happen if I rename the file I'm editing to have a ".py" suffix. "foo" suffers this fate, "foo.py" does not. Submitted to Issue tracker, didn't look like it was already in there.
I never really felt faster eliminating mouse from my coding workflow. Point and click to navigate things is pretty powerful. Why some devs try to avoid the mouse?
I’m always a bit disappointed that people making the case for mouse-lite workflows stop at “it makes you faster.” In many cases, this is patently false at a global scale - I’ve been using Emacs for a month and I’m certain that I’ve already spent way more hours customizing and researching than I’ll ever make back from saving a couple deciseconds every time I use a keyboard shortcut instead of a mouse.
For me, using Vim keybindings and Emacs shortcuts is valuable because reaching for a mouse or navigating menus adds mental overhead. I view the moment-to-moment practice of programming as largely being an exercise in working memory. You’re trying to hold an abstraction in your head and implement it in an existing codebase that’s filled with other abstractions and interacting parts. Personally, removing a mouse from my workflow does wonders for ensuring that all my mental resources are dedicated to the task at hand. Going mouse-lite might save a trivial amount of time in the moment, but (for me) it makes programming more seamless and natural - which makes it not only more fun, but more productive.
I agree. It's not so much "saving time" as when you are in a state of flow, you want to remove anything that slows you down from converting what's in your head to code.
I notice that when I am totally in the zone, I start to get frustrated quickly when tools take longer than normal or stop working correctly. You have a map of where you want to go and have the mental acuity to do it, but when tools get in your way, it takes you out of the flow.
To add to this, some shortcuts favorite to some users are used millions of times. Think of all that mental overhead that is saved in the long run.
I am a heavy user of shortcuts and a lot of the times I don't even know what the shortcut is, it's all muscle memory. Intent turns into an action and feedback is both tactile and visual and there is usually an easy way to get back of that also with shortcuts. Using the mouse in some scenarios is like looking through a keyhole. That is not to say that using the mouse is bad all the time, because the mouse beats shortcuts in other scenarios.
To me scrolling using the mouse scroll wheel or using keyboard keys are somewhat similar. Where the mouse workflow is eating the mental overhead is aiming a fly on a small landing 200th the size of the screen thousands of times or more daily.
Yeah, in a work year writing just 400 lines of code per day will net >100k lines of code in year. That's.. A lot of new code. Greenfield, best-case kind of scenario. Keyboard shortcuts aren't going to be the secret sauce to writing a measly 2k lines of code, much less 400. Just thinking about this and discussing it probably wastes more time than a lot of those shortcuts would ever save.
As long as somebody isn't being a huge detractor because they refuse to use the tools everybody else on the team does I don't really care. Not even enough to engage in a discussion about it. Unless there are beers.
For me, tracking the mouse cursor and moving it visually is harder than moving a text cursor, since with a text cursor I can generally look at a piece of text and summon the cursor directly to that location. I have trouble seeing and distinguishing the mouse cursor a lot, and I'm much more likely to overshoot it (or move it frustratingly slowly) than a text cursor.
It just feels better for me to use. I do less squinting. :)
I'm not sure if Emacs qualifies as an editor for saving time. As you say yourself, Emacs people tend to play a lot with customization (and Emacs didn't seem useful with default config to me; what the hack is C-x 2?). At the same time, it doesn't add anything useful to editing itself. It's basically scriptable MS Notepad.
Try a text editor that does something for text editing, not scripting. Vim is an option. I personally used Kakoune with (almost) default config for some 3 years and I'm sure it saved me a lot of time. I never redefined default keys, they were good enough, I only added a few user mode bindings. (Although I felt a lack of some features over that time; Kakoune with no plugins is a bit too minimalistic.)
Recently I spent a few days setting up LSP and some useful plugins, now I'm going to forget about customization for few more months again.
There's a benefit to reduce stress on your hand in my experience too. Constantly switching from keyboard to mouse and back again, or even worse keyboard to trackpad, can really get aggravating after a while for some folks. I sometimes like a happy medium of VS code or other fancy editor with a VIM key mapping plugin.
You've received so many replies already, but mine is different. The older I get, the less I want to deal with the video game-like elements of hand-eye coordination, intense visual attention, and timing. I'm tired of things going wrong because I clicked a few pixels off or clicked on the wrong thing because I was surprised by a UI element appearing in a slightly different place or with an unexpected delay or with slightly unexpected contents because of a software update or just something I didn't predict.
With keyboard commands, I don't have to verify the accuracy of my mouse movements, and I don't have to react to the timing, location, content, and focus changes of UI widgets. I just press the keys in the right order. It requires so much less vigilance, it's a big relief.
Surprise OS update popup with focus on "OK", you press enter at just the wrong moment and you're now rebooting. OK, that wouldn't happen as far as I know, but there have been plenty times where I was typing away, glancing over, and the focus had changed and now I'm typing into nothingness (or something worse like in my not too likely example). With the mouse at least I'm actually looking at the screen.
This. Using both (and touch as well sometimes), the right tool at the right time for the job at hand, is what is the fastest for me. Doesnt matter whether it's editing or browsing or ...
What do you mean with older FF? I've been using mouse gestures for decades (Opera anyone?) and I still use the same ones today on FF. Different extension/plugin of course, but works the way it should?
Agreed! I have a keyboard full of OS-level macros and I've rebound the extra buttons on my mouse to ctrl+c, ctrl+v, and enter. If I'm leaning back and browsing through docs, I want to be able to move text around and execute commands without reaching for the keyboard.
I found a nice solution to this with an MMO mouse. I have a Logitech G600 with 12 keys on the side and I mapped them to my most common operations like opening and closing tabs or moving between workspaces.
Automatic refactoring etc is still a long way off being good in Vim.
But I’ve recently started using a combination of Neovim + treesitter + LSPs, and have found it incredibly powerful. Extremely responsive automatic compilation that feels instantaneous, good inline error messages, very good and fast syntax highlighting through treesitter... At what it does, I’d go as far as saying as it achieves more than any other IDEs I’ve tried. But of course, what it does is more limited.
At the moment I rarely even touch a mouse. I work primarily in Vim, with DWM as a window manager and a Vim extension in the browser. When I have to work in a different environment and use a mouse again, I find the constant context switching very distracting
This is a fair thought. It's why some wonder why people use Vim, emacs, or keyboard shortcuts in general...
However, one of my reasons is that I work out of coffee shops a lot. Not having to bring an extra piece of hardware that takes up space is a big deal for me and not taking my hands off the keys is a big deal.
I was a gamer (Counter-strike), and as precise as I believe my mouse-clicking to be, it is far less precise than the correct sequence of keystrokes to get to some parts...
Readline shortcuts available in most shells, i.e., ctrl-a (beginning of line), ctrl-e (end of line), meta-b (back a word), meta-f (forward a word).
In Vim - I can delete entire code-blocks with a quick sequence and have my cursor ready to type, and I can move chunks of code with their delimiters far more easily than my fairly precise mouse clicking and highlighting then moving my hand back to the keyboard to hit backspace. I can also switch to a "tab" (buffer in Vim) with a few keys without having to cycle through tabs or use a mouse to find the tab I'm looking for with a mouse.
There are many benefits, it's why even though text editors have come so far, people still continue to write Vim plugins for them -- think VS Code, Atom, and all the IDEs that Jetbrains produces...
That's my main issue with terminal emulators. Why can't I click anywhere to put a cursor in there? Why can't I delete a selected text? Some hotkeys work as expected (e.g. Ctrl+Delete), but others don't (e.g. Ctrl+Backspace). Those are simple things from a user standpoint. Terminal could be so much more usable. I'm not even talking about integrating real GUI into terminal, for example pressing Tab should open dropdown list, not emulate it with text.
You can use the mouse to select things in the terminal. In vim/neovim `:set mouse=a` and you can scroll around, select things and move the cursor just like you can in a regular GUI editor.
In DomTerm, you can click to move the cursor. This is simulated by converting the click to a series a arrow-keystrokes. If you set up "shell integration" (https://domterm.org/Shell-prompts.html) it just works with a regular click (for bash, fish, or zsh). Otherwise you can can do Alt-click (to avoid risk of mass confusion if you accidentally click outide an application that can handle arrow-key movement).
Deleting selected text works if you're in line-editing mode. It could be made to work in normal char mode, but it's a bit tricky.
Setting mouse-reporting by the application (emacs, vim, mc, etc) works pretty well, but it means the application has to simulate the selection (which may or may not be integrated with the desktop selection), context (right-click) menus, etc.
What causes RSI is mostly centered around tendon and their sheath tension.
For example, if you use a straight keyboard (don't! Ergonomic all the way!) that is raised toward you as opposed to away from you, keeping your hands on that keyboard for multiple hours in a row without ever reaching for the mouse is pretty much guaranteed to give you RSI. Reaching for the mouse will actually bring relief to your tendons.
Another keyboard habit that will put a great deal of stress on your hands and wrists is leaving the Control key at the bottom left of the keyboard. Typing a control key with this configuration will bring great stress on your pinky and other tendons in your hand.
omg I realized this recently after using Android Studio for a short while. Keyboard+mouse workflow is objectively horrible for the wrists. Unfortunately no other alternatives exist for these IDEs.
Modal editors in particular can be a mixed bag, they do seem a little out of place in the world of IDEs and Visual Studio Code, but I'd be lying if I said I don't use them heavily. The main appeal for something like this is to keep your hands on the keyboard so you can focus on writing.
> Why some devs try to avoid the mouse?
Because a keyboard is a much better peripheral to use when you're SSHing into your server. A mouse also has a much higher latency ceiling to execute most commands because it requires much more spacial awareness and brainpower to perform the task than just invoking the keybind. When you move your mouse to hover over a "send" button on an email client, your body is performing subconscious inverse kinematics to try to figure out how far to push the mouse, and when to stop. You can then only click once your mouse successfully lands in the designated area, at which point an additional 50-500ms of latency will ensue, depending on what UI framework your text editor is based off of.
For me the appeal of Vim-type editors is that I do not need to learn new shortcuts when switching between Mac, Linux and Windows that I have to do at work periodically. This is a reason I use a Vim plugin with VS-Code with few custom keybindings to minimize the usage of Ctrl key.
Even though I'm a big admirer of keyboard-driven interfaces, I don't think mouse should be eliminated. Mouse can be better than keyboard for some tasks.
The problem I see is: a lot of things that non-modal, GUI interfaces use mouse for can be better done with a keyboard.
For example, all sorts of drop-down menus and icons that you click on to launch programs. This kind of interface is inherently synchronous: the computer suggests, you pick. To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has (sometimes those actually make me forget what I was trying to do in the first place). I love the related metaphor ESR came up with in his Unix Coans [1].
> To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has
Yes, especially when the suggestions change all the time, like when you go to click something and the icon is replaced by something completely different.
And a bunch more. I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
I don't know how fast you are with the mouse, but I've watched my co-workers jump into source and they can be so slow. I believe that I can answer questions I have regarding the codebase faster than they can, I don't have to rely on my memory for trivialities.
> I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
If you use Xref UI for "Find References/Implementations/Type", M-, should work in those cases too.
There is a more general question: how to "jump forward" again, without re-invoking the previous navigation command with the exact arguments. IDEA, already mentioned in comments, has key bindings for that.
There are several third-party packages which attempt to solve it as well. I'm using this one:
I don't find them particularly good. All these \C-x that emacs forces on you introduce extensive risks of RSI, especially if your Control key is still at the bottom left of your keyboard.
Better chords would be simple shortcuts for actions you do often (for example, "Go to symbol" in IDEA is \C-b).
I'm not sure there's a surefire way of jumping back with your C-x commands that's built into Emacs, but here are two options:
C-x C-SPC will pop the global mark which, depending on what you've done in the buffer you're visiting, can pop you right back to where you started, functioning as the equivalent of M-,.
C-x b RET (C-x b with no input) should take you back to the most recently used buffer, which will usually be the buffer you started from.
Not built in: It's also fairly trivial to write some defadvice that stores your point (pre-jump) to a register, so you can jump back to the register with one key.
> jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
Using builtin commands, `C-x <left>` will switch to the previous buffer if you've jumped to another file, or `C-u C-SPC` (popping the mark) should work if you're in the same file. Not sure if this is sufficient for you, but it's a simple option to try.
Because we don't want to move the hand around. With keyboard-only solutions your wrist stays pretty much put. That's mechanically more fluid and faster.
Have you tried a MacBook with its trackpad right in front of the keyboard? I like keyboard-only too, but some jobs are faster when you can point at the screen
I use the equivalent of "easy motion" aka "ace-jump" or "avy" under Emacs to move to any character on screen about 4 to 5 keypresses. Two to invoke that "jump to any character on screen" command, one to tell which character I want to jump to, then one or two depending on how many occurrences of that character there are on the screen.
I'll put it simply: my cursor is where I want it before you have even grabbed your mouse. And that is the reason why I avoid the mouse.
Same for "menus" and commands: shortcuts are faster than using the mouse. Once a list of potential candidates shows up, I use the same "select any candidate using the minimal possible amount of keypresses" command.
I have always used a "gaming" mouse, eg. high precision, high refresh rate and super smooth, with a mouse mat with just the right amount of friction. It however broke a few month ago and I got a cheap replacement, since then I have been subconsciously avoiding using the mouse, because the experience with the cheap replacement mouse is so bad. So I think the reason people don't like using the mouse is because they don't have a good mouse and mouse pad, and because they haven't spent years playing first person shooters - making it possible to hit a spot on the screen with pixel-precision using just muscle memory...
No... it's because it's just a LOT faster not to have to move your hand between the keyboard and the mouse.
Unless you are typing one handed then there is inherent inefficiency in using a mouse vs. a keyboard command. Example: ctrl/cmd+c ctrl+v vs right click copy/paste.
Context: I've competed at a high level in CS/Valorant and voltaic platinum... mouse accuracy is not my issue.
Once you achieve relative fluency with using a given text editor or IDE then it is natural to gravitate towards using keyboard shortcuts.
Eventually, if you type decently fast (70wpm+, though that's slow by my standards but I'm not here to boast about the size of my epeen) many will find it frustrating moving between keyboard and mouse constantly.
I don't find it's about speed, but rather about staying in the zone. vim enables very intricate navigation and editing that is much more tedious to pull off with a mouse. Since I have these commands memorized and very strong muscle memory, I just do them by instinct and my focus on what I'm doing never drifts.
I hate the analog-like nature of the mouse - having to move where you want, then slow down until you get to the right spot, then click, then click again because the cursor is a character or two off; and going through menus is a pain. And it's worse when you are hungover or tired. I just want a discrete and quick way to move around, and after using vim for a long time, it's not even a question that it's way faster and easier than a mouse. A mouse is a huge drag once you are strong with key bindings
IMO part of the reason is cultural. Computing became mainstream only after the mouse and GUI were invented, but programmers have been at it since well before that. So now it's somewhat of a badge of honor that you can be as productive without the newer conveniences. This apples to any new tools or processes like IDEs or linting as well. There was a very distinguished engineer at my company who chastised young engineers for using graphical step-through debugging.
In Plan 9's Acme, the mouse is your edit mode, the keyboard is your insert mode. I find I'm about as fast for most tasks in Acme as I was in Vim (after using it for years).
Using the mouse to highlight text in order to copy/paste it has always been a pain for me. Especially if the text is wider than the screen. I'm constantly highlight too much or too little. For me its way easier to use vim commands to grab the text I want. Its just one small example, but I can say for certain that I'm faster at editing text in vim than I ever was in a Jetbrains or VSCode editor.
Many editing operations involving the the mouse can be reduced to a few key strokes in Vim and become second nature. As an example, how many coders reach for the mouse when they cut text in "modern" editors? I don't think they need to be convinced Ctrl+X/Cmd+X is faster than the mouse.
There's no muscle memory in point & click, and it is a lot slower for a lot of things.
For instance, you wouldn't type on an on-screen keyboard with point & click. Once you've been using VIM for a while, pretty well any mouse interaction feels like doing just that.
Point and click to navigate is pretty slow compared to keyboard driven approaches. Realized after switching to vim. Probably because, after certain point, it just the reflex which drives vim.
you wont know until you know. if two people can both use a mouse, but only one can do it all with the keyboard, you have to decide if they are being pretentious or if its actually better. i personally think its better for almost all code related tasks, but the mouse still has uses elsewhere
The FAQ made me chuckle, and then wonder what exactly a post-modern editor would look like? I guess if we deconstruct text editing, there would probably be one window filled with nothing but all the (non-uniquified) letters and characters you used, another with format rules, and another with a verbal description of your program...? Maybe? I'm no Derrida, so I'll defer to the philosophy majors.
I'm happy with VScode, but lately I'm starting to want text-mode UI. More grid, one font, less colors, no icons. Not just for my text editor, but for everything.
I don't want everything to look like a glossy magazine. Norton commander, power menu, borland c.. Just let me focus on some text.
I've had a similar desire recently...my reason is because regardless of the power of my desktop machine, I've grown impatient waiting for applications to load...but I encounter no such issues with apps that employ more text-mode UIs. TUIs - in my mind now - are a godsend; ironic that they're considered a "throw back" to "the older days of computing".
That's exactly why I really dislike a lot of IDEs and editors. I've been using (n)vim for 3+ years now as my main editor.
A big value of (neo)vim is the lack of clutter and how easy it is to bring up and hide windows/buffers when I need them. Editors like VSCode and IntelliJ are just too noisy and gets in the way of the actual coding.
I know they can all be customized and configured to reduce this issue, but even then it still feels more visually cluttered and those windows usually end up coming back somehow.
Readit News
I use emacs not because I'm a neckbeard, but because I can script it to do whatever the hell I like. I switch to vscode when I want to do something my emacs setup isn't yet good for (like, working with Typescript).
On the flip side, I use sublime text as a notepad replacement because it's that fast. I still use nano as my default editor for commit messages. Sometimes I use vim because that's what I happened to type to open a file.
This isn't a comment on helix editor itself...just that, it's a pretty saturated space and I'm keen to see something as novel as light table play out again, but only more successfully.
Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years.
The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc...
No setup, no configuration, it's lightning fast and it just works.
I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
But learning tools such as vim and learning how to configure those really helps you get out of the comfort zone
I was a regular vscode user but after using vim my workflow really improved
I have nothing against vscode users but sometimes getting out of comfort zone really helps you
I think vim is a messy pile of hacks, and I would love to see that changed. Neovim is nice with the extend and evolve approach but I'm always looking for something that can really provide a clean base for extensions to build on. (Yes ,yes, I know emacs is an editor-writing IDE)
On the other hand I see nothing about plugins here. I think the approach to extensions is a very important question to answer early on.
https://gist.github.com/deviantfero/45b9354b433f44450de51c82...
make sure you add `:ensure t` if you don't have it automatically set to true.
* web-mode for general html/css/typescript/javascript editing
* tide + company for autocompletion
* flycheck for eslint support
* prettier for auto format on save if configuration is present
lsp is good for many other languages, but for javascript/typescript it's just not there yet
All these years and I was starting to believe I had imagined light table. How else could one explain no editors adopting inline, always-on evaluation?!
Lately I prefer purpose built IDEs for whatever task is needed. I’m over with editor evangelism. :)
Funny thing is a lot of the features are... just like a file system or Perl script to rip through and replace strings.
Large language ecosystems are only good when you don't need them. If they're just gravy, then life is good. If you need a lot of stuff to be moderately productive, that sucks.
LSP is the shining hope here, but you suddenly get into questions about your build environment, and that's another rabbit hole just to get decent completions.
What’s awful about VSCode? Genuinely curious. I use it daily and enjoy it. I love all the extensions I have access to.
> If you need a lot of stuff to be moderately productive, that sucks.
I don’t see why I would ever not have access to my extensions, nor is it very difficult to copy-paste my extensions.json file to a new machine and press “install all”.
This. With some elisp knowledge, you can bend Emacs your way. No need to write full-blown packages. A function here and there can get ya very far. I wrote about this yesterday[1]
[1] https://xenodium.com/emacs-dwim-do-what-i-mean
You don't work with Git as a DVCS? Or you work with Git and Emacs but don't use Magit!?
My point overall was that I see all of these as a collection of tools. Which one I choose depends a lot on context, and it's served me well to be baseline comfortable with all of them rather than depending too heavily on my emacs setup.
(magit is brilliant, but for some reason it's never stuck with me, unless I want to interactively stage a few specific chunks, and then it's much nicer than using the cli).
1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993
2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889
I'm just as surprised as you are that people do see it, that some people don't see it. I have no idea what the explanation is, but there's something radically different about me versus people who can tolerate VSCode's slowness (I'll use VSCode if I have to, but I'll avoid it if at all possible, just because it's slow).
VSCode load times are heavily correlated to what files I had open last and what extensions I have installed that trigger because of my previously opened files.
When I freshly install VSCode on a machine, it feels blazingly fast. A couple months later when I've loaded up a few linting extensions? Not so much. Of course, the power of these extensions is why I'm using VSCode in the first place. I've yet to see an IDE that can integrate these types of features and not slow-down in some aspect, and VSCode does seem to try to stay as lightweight as possible.
VScode also often has notification prompts when I open it, either from extensions, or as popups generated from the editor itself. This doesn't add load time perse, but it does add to my mental perception of it's load time.
I also literally only use VSCode when I have to work with Typescript.
Deleted Comment
Try SciTE if you want something super lightweight!
hx uses the Ropey crate (Rust library) to implement ropes: https://crates.io/crates/ropey
Boehm, Hans-J., Russ Atkinson and Michael Plass (1995) "Ropes: an alternative to strings", Software—Practice & Experience 25: 1315–1330, DOI: 10.1002/spe.4380251203, https://dl.acm.org/doi/10.1002/spe.4380251203 (cited 2021-06-01).
https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...
https://news.ycombinator.com/item?id=15199642
It's basically just two stacks of lines, where a line is an array of characters. One stack has the lines before the cursor, the other has the lines after the cursor (in reverse order).
I use emacs, but ropes are a much better way to go if you're starting from scratch.
Generalizing even further, I wish there were a name for the generic type Bar<T,M> which is a b-tree of T-values, plus a monoid [1] M over T, where each non-leaf b-tree node stores the M-sum of its descendents [2]. This lets you quickly compute the M-sum of arbitrary ranges or search for an element by the M-sum of its predecessors. Ropes are essentially Bar<Char,(0,+)> so the monoid gives you the number of characters in a range.
If you let M=(0,max) or M=(0,min) you can get the min/max value in arbitrary ranges in O(log n) time. This is extremely useful for all sorts of things, from algorithmic trading (order books) to VLSI (plotting waveforms from gigantic simulations). If M1 and M2 are monoids, then $M1\cross M2$ is a monoid, so these "range summaries" are very modular -- you can mix and match them.
In the functional programming community there is a data structure called a finger tree [3] which are a specific case of Bar<T,M> implemented as an immutable data structure. Immutable data structures are nifty, they have benefits, but also costs. I don't know what to call Bar<T,M> implementations which are non-immutable (i.e. ephemeral or update-in-place) data structures.
If anybody knows of generally-accepted names for these (or wants to suggest some) please reply. I plan to add this functionality into (a fork of) LMDB.
[1] https://en.m.wikipedia.org/wiki/Monoid
[2] actually you want to store the M-sum of the descendents of each child node alongside the pointer to that child node
[3] https://en.m.wikipedia.org/wiki/Finger_tree
So you can have a string with millions of characters (a loaded document) and you can edit it efficiently.
https://iq.opengenus.org/rope-data-structure/
Great. So, what's the extension language? Rust is utterly inadequate to be a scripting language (if you have to recompile the text editor to reconfigure it, that's a non-starter).
VimScript sucks, but it's better than literally nothing. Emacs Lisp is weird, but powerful. Python is great and everyone knows it. Lua is small, simple, blindingly fast, and literally designed to be embedded in compiled projects.
Why is there no mention of extensions or extensibility?
I posted this on r/rust to get some feedback, definitely wasn't prepared to expose it to HN yet.
Basically, have you given thought into it, and see a way to integrate it in a efficient way, or come those thoughts from the potential ease of use with that and implementation details later?
In either case, I think scripting is very important to many people, so you probably should add a section about it somewhere, that it is definitely planned, open for suggestions (?) on the scriping language, and coming once the core features are stable.
Otherwise congratulations!
I have been using vanilla Vim with no plugins for years now, and I do have a config file but no plugins or anything.
I was driven away from Kakoune by the "clever" way it uses shell for scripting, and some basic functionality needs scripts. Pretty cool but not for me.
Given a built-in language server and syntax coming from tree-sitter, that already covers almost everything I need from my $EDITOR. The only other thing I need is the ability to open compiler error log and jump to locations.
Here's a list of dyn langs that fit well with Rust:
https://arewegameyet.rs/ecosystem/scripting/
As a Lisp+Emacs user, I'm biased towards elisp, but it's definitely not perfect, having multi-decade-old baggage that holds it back. Lua has a beautiful design that is geared toward embedding, but lacking metaprogramming capabilities and things like optional typing. Python's design is ugly in many ways that the other two aren't, but it's more featureful than either of them and doesn't have elisp's warts. JavaScript has a more elegant design than Python, but a bad rep and a community that is borderline averse to performance.
There is no perfect extension language, and I'm convinced that, for fundamental reasons, there can never be.
But, I'll take an imperfect language (again, I'm biased, but I'm very bullish on a Lispy and Lua-y stuff) over none at all.
I just could never get my head around the key bindings with kak.
For example, https://github.com/purescript/documentation/blob/master/lang... makes picking up PureScript as a Haskell programmer much easier than having to read all of the documentation and do the diff yourself.
If the old joke "plan9 is more Unix than Unix" is true, then "Kakoune is more vi than vim". There are similarities but it is a different beast.
Recently I've been playing with:
OniVim2: I'm not really sure what enhancements it has, but it does have a standard setup. Unfortunately, I'm running into some problem with my setup losing Python syntax highlighting. The ability to use VSCode extensions seems like a real winner, I've never been able to get into the weight of VSCode for my every day shell-oriented workflows. I don't program much, YMMV.
The Amix "awesome vim" setup. It is, unfortunately, TOO awesome. I set it up and some of my first movement commands were bringing up plugins (Ctrl-N and Ctrl-F). Didn't try it very long, it was a bit too much of a departure.
SpaceVim: I spent a while in this, it was working ok once I adapted a few things to it. It's a contender, probably behind Lunar.
LunarVim+NeoVim 0.5: This is looking promising so far, only used it a bit. But the TreeSitter plus LSP seems like a winning combination! Plus it works in the terminal, which OniVim does not. I do a fair bit of my (limited) programming via ssh from a chromebook (my couch compuer).
It doesn't seem to happen if I rename the file I'm editing to have a ".py" suffix. "foo" suffers this fate, "foo.py" does not. Submitted to Issue tracker, didn't look like it was already in there.
For me, using Vim keybindings and Emacs shortcuts is valuable because reaching for a mouse or navigating menus adds mental overhead. I view the moment-to-moment practice of programming as largely being an exercise in working memory. You’re trying to hold an abstraction in your head and implement it in an existing codebase that’s filled with other abstractions and interacting parts. Personally, removing a mouse from my workflow does wonders for ensuring that all my mental resources are dedicated to the task at hand. Going mouse-lite might save a trivial amount of time in the moment, but (for me) it makes programming more seamless and natural - which makes it not only more fun, but more productive.
I notice that when I am totally in the zone, I start to get frustrated quickly when tools take longer than normal or stop working correctly. You have a map of where you want to go and have the mental acuity to do it, but when tools get in your way, it takes you out of the flow.
I am a heavy user of shortcuts and a lot of the times I don't even know what the shortcut is, it's all muscle memory. Intent turns into an action and feedback is both tactile and visual and there is usually an easy way to get back of that also with shortcuts. Using the mouse in some scenarios is like looking through a keyhole. That is not to say that using the mouse is bad all the time, because the mouse beats shortcuts in other scenarios.
To me scrolling using the mouse scroll wheel or using keyboard keys are somewhat similar. Where the mouse workflow is eating the mental overhead is aiming a fly on a small landing 200th the size of the screen thousands of times or more daily.
As long as somebody isn't being a huge detractor because they refuse to use the tools everybody else on the team does I don't really care. Not even enough to engage in a discussion about it. Unless there are beers.
It just feels better for me to use. I do less squinting. :)
Try a text editor that does something for text editing, not scripting. Vim is an option. I personally used Kakoune with (almost) default config for some 3 years and I'm sure it saved me a lot of time. I never redefined default keys, they were good enough, I only added a few user mode bindings. (Although I felt a lack of some features over that time; Kakoune with no plugins is a bit too minimalistic.)
Recently I spent a few days setting up LSP and some useful plugins, now I'm going to forget about customization for few more months again.
Deleted Comment
With keyboard commands, I don't have to verify the accuracy of my mouse movements, and I don't have to react to the timing, location, content, and focus changes of UI widgets. I just press the keys in the right order. It requires so much less vigilance, it's a big relief.
When I have my hands on the keyboard I prefer to keep them there so I use ctrl - w to close tabs, ctrl-t to open a new tab etc.
When I have my hand on the mouse I prefer to keep it there so I used to love mouse gestures on older Firefox versions at least.
What do you mean with older FF? I've been using mouse gestures for decades (Opera anyone?) and I still use the same ones today on FF. Different extension/plugin of course, but works the way it should?
Use vim shortcuts in all the programs, so you never have to use the mouse or learn new keyboard shortcuts.
For Firefox something like Vimium works well.
But I’ve recently started using a combination of Neovim + treesitter + LSPs, and have found it incredibly powerful. Extremely responsive automatic compilation that feels instantaneous, good inline error messages, very good and fast syntax highlighting through treesitter... At what it does, I’d go as far as saying as it achieves more than any other IDEs I’ve tried. But of course, what it does is more limited.
At the moment I rarely even touch a mouse. I work primarily in Vim, with DWM as a window manager and a Vim extension in the browser. When I have to work in a different environment and use a mouse again, I find the constant context switching very distracting
However, one of my reasons is that I work out of coffee shops a lot. Not having to bring an extra piece of hardware that takes up space is a big deal for me and not taking my hands off the keys is a big deal.
I was a gamer (Counter-strike), and as precise as I believe my mouse-clicking to be, it is far less precise than the correct sequence of keystrokes to get to some parts...
Readline shortcuts available in most shells, i.e., ctrl-a (beginning of line), ctrl-e (end of line), meta-b (back a word), meta-f (forward a word).
In Vim - I can delete entire code-blocks with a quick sequence and have my cursor ready to type, and I can move chunks of code with their delimiters far more easily than my fairly precise mouse clicking and highlighting then moving my hand back to the keyboard to hit backspace. I can also switch to a "tab" (buffer in Vim) with a few keys without having to cycle through tabs or use a mouse to find the tab I'm looking for with a mouse.
There are many benefits, it's why even though text editors have come so far, people still continue to write Vim plugins for them -- think VS Code, Atom, and all the IDEs that Jetbrains produces...
Deleting selected text works if you're in line-editing mode. It could be made to work in normal char mode, but it's a bit tricky.
Setting mouse-reporting by the application (emacs, vim, mc, etc) works pretty well, but it means the application has to simulate the selection (which may or may not be integrated with the desktop selection), context (right-click) menus, etc.
What causes RSI is mostly centered around tendon and their sheath tension.
For example, if you use a straight keyboard (don't! Ergonomic all the way!) that is raised toward you as opposed to away from you, keeping your hands on that keyboard for multiple hours in a row without ever reaching for the mouse is pretty much guaranteed to give you RSI. Reaching for the mouse will actually bring relief to your tendons.
Another keyboard habit that will put a great deal of stress on your hands and wrists is leaving the Control key at the bottom left of the keyboard. Typing a control key with this configuration will bring great stress on your pinky and other tendons in your hand.
Recommendation: map Control on Caps.
> Why some devs try to avoid the mouse?
Because a keyboard is a much better peripheral to use when you're SSHing into your server. A mouse also has a much higher latency ceiling to execute most commands because it requires much more spacial awareness and brainpower to perform the task than just invoking the keybind. When you move your mouse to hover over a "send" button on an email client, your body is performing subconscious inverse kinematics to try to figure out how far to push the mouse, and when to stop. You can then only click once your mouse successfully lands in the designated area, at which point an additional 50-500ms of latency will ensue, depending on what UI framework your text editor is based off of.
The problem I see is: a lot of things that non-modal, GUI interfaces use mouse for can be better done with a keyboard.
For example, all sorts of drop-down menus and icons that you click on to launch programs. This kind of interface is inherently synchronous: the computer suggests, you pick. To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has (sometimes those actually make me forget what I was trying to do in the first place). I love the related metaphor ESR came up with in his Unix Coans [1].
[1]: http://www.catb.org/~esr/writings/unix-koans/gui-programmer....
Yes, especially when the suggestions change all the time, like when you go to click something and the icon is replaced by something completely different.
Here are some of mine:
M-. jump to source
M-, pop back to previous source
C-x f r Find References
C-x f i Find Implementations
C-x f t Find Type
C-x r v Rename Variable
C-x c a Code Actions
And a bunch more. I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
I don't know how fast you are with the mouse, but I've watched my co-workers jump into source and they can be so slow. I believe that I can answer questions I have regarding the codebase faster than they can, I don't have to rely on my memory for trivialities.
If you use Xref UI for "Find References/Implementations/Type", M-, should work in those cases too.
There is a more general question: how to "jump forward" again, without re-invoking the previous navigation command with the exact arguments. IDEA, already mentioned in comments, has key bindings for that.
There are several third-party packages which attempt to solve it as well. I'm using this one:
https://github.com/tcw165/history
You can also add "jump back" to your other navigation commands, even if they don't use the Xref UI.
Better chords would be simple shortcuts for actions you do often (for example, "Go to symbol" in IDEA is \C-b).
C-x C-SPC will pop the global mark which, depending on what you've done in the buffer you're visiting, can pop you right back to where you started, functioning as the equivalent of M-,.
C-x b RET (C-x b with no input) should take you back to the most recently used buffer, which will usually be the buffer you started from.
Not built in: It's also fairly trivial to write some defadvice that stores your point (pre-jump) to a register, so you can jump back to the register with one key.
Using builtin commands, `C-x <left>` will switch to the previous buffer if you've jumped to another file, or `C-u C-SPC` (popping the mark) should work if you're in the same file. Not sure if this is sufficient for you, but it's a simple option to try.
Use IntelliJ, it's trivial to do that with `Cmd+B` (on Mac).
I use the equivalent of "easy motion" aka "ace-jump" or "avy" under Emacs to move to any character on screen about 4 to 5 keypresses. Two to invoke that "jump to any character on screen" command, one to tell which character I want to jump to, then one or two depending on how many occurrences of that character there are on the screen.
I'll put it simply: my cursor is where I want it before you have even grabbed your mouse. And that is the reason why I avoid the mouse.
Same for "menus" and commands: shortcuts are faster than using the mouse. Once a list of potential candidates shows up, I use the same "select any candidate using the minimal possible amount of keypresses" command.
Unless you are typing one handed then there is inherent inefficiency in using a mouse vs. a keyboard command. Example: ctrl/cmd+c ctrl+v vs right click copy/paste.
Context: I've competed at a high level in CS/Valorant and voltaic platinum... mouse accuracy is not my issue.
Once you achieve relative fluency with using a given text editor or IDE then it is natural to gravitate towards using keyboard shortcuts.
Eventually, if you type decently fast (70wpm+, though that's slow by my standards but I'm not here to boast about the size of my epeen) many will find it frustrating moving between keyboard and mouse constantly.
In Plan 9's Acme, the mouse is your edit mode, the keyboard is your insert mode. I find I'm about as fast for most tasks in Acme as I was in Vim (after using it for years).
Not needing to move my hand back and forth means not needing to make a context switch that puts a little extra stress into my workflow.
TL;DR: Moving away from the home row to arrow keys or mouse can cause wrist pains.
[0] https://youtu.be/h-epcklOC_g?t=48
It would be a fork bomb, each process of which would kill a random pid in an effort to "subvert structures of systemic hegemony".
It would just display its own source code, but as it wished it was, and the result would not execute.
I don't want everything to look like a glossy magazine. Norton commander, power menu, borland c.. Just let me focus on some text.
A big value of (neo)vim is the lack of clutter and how easy it is to bring up and hide windows/buffers when I need them. Editors like VSCode and IntelliJ are just too noisy and gets in the way of the actual coding.
I know they can all be customized and configured to reduce this issue, but even then it still feels more visually cluttered and those windows usually end up coming back somehow.