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.
Just this morning I upgraded to NeoVim 0.5 and set up TreeSitter and LSP with Lunar. I haven't had much time to play with it today, but it's looking good so far. https://github.com/ChristianChiarulli/LunarVim
If you're trying to get people to try your new editor, no matter how awesome the ideas that you're trying, you're going to lose a chunk of your audience if it doesn't support C syntax highlighting, a chunk if it doesn't support Python intellisense, and so on and so forth. You can have the best idea in the world, but people will play with it, and decide that they love it but can't use it for "real work" unless you slog through adding native support for a bunch of languages and runtimes/compiler suites.
That's a huge burden.
Now, if you implement LSP, you get "for free" support for C#, C, Python, Rust, etc etc. People can evaluate your editor on its merits as a text editor, not on whether you had the time and energy to add support for their favourite language.
I guess he means that LSP (at least in theory) enables "simple" editors to offer features which in the past have been the domain of IDEs (code completion etc.), and for editors supporting LSP, the support for a given language will (again in theory) be as good in one editor as in the next one you might want to try out...
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.
Those are called tools. They can be separated. Not everything has to be a multi gigabyte monstrosity swiss army knife. You can think microsoft for gas lighting you into that line of thinking.
The problem with separating out tools is that the resulting tools tend not to work very well with each other and suffer as a result. I'll use gdb as an example: using it standalone means I can use whatever text editor I prefer to read the code, but now I'm forced to manually schlep between the debugger and the editor to do debugging: let me figure out what file I need to look at for this current function, and manually open it in the editor. Okay, now let me copy-paste this function name to break on. Oh, here's a value I want to inspect, let me go manually type this in. And constantly back and forth between the editor and the debugger.
Having the tools all work together in one environment is honestly a far superior experience than having each tool live in its own bubble and requiring you to do all the coordination work yourself, with all of the repetition and scope for mistypes in the process.
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.
Not sure about OniVim1, but just last week I bought the OniVim2 Early Access license, after watching oni 1/2 for a few years. I will say that it seems a bit early, but it does look promising. For example: My main workstation loses syntax highlighting after I do two motion commands ("jj" or "Gk" for example).
Hey, Onivim contributor here. Thanks for the feedback! I will mention that syntax highlighting fixes are something we’re gonna be focusing on in the coming weeks/months so if you haven’t already, feel free to file an issue on GitHub (or comment on one that looks similar)!
Onivim looks great! Does it/will it support remote development like VSCode? I do all my development on a virtual machine. I love everything about VSCode except for the vim plugin.
Its a workflow we are looking into supporting, but its difficult. VSCode has extensions that are licenesed in a different way to the rest, which includes all the remote development ones (WSL/SSH/Docker).
Their license can be found on the marketplace, but broadly they can "only be used with Visual Studio Family products" (or something of similar wording, i.e. Code only, some are VS only). They are also fully closed source as well, the GH repos are just for issues.
So we'd like to support that sort of workflow, but it will mean more work on our end since we can't use that existing work due to the license.
Many people constantly recommending Evil mode don't seem to get why some use Vim.
No, Evil mode is not better than Vim itself. For one it's slower, defining keybindings is much more verbose, everything outside the actual text file has completely different controls, and I lose most of the seamless interoperability with other terminal tools. And it runs within an environment that tries to be literally every text-related tool by itself, making it overly complicated in many aspects.
Emacs provides a convincing Vim layer on top of a hackable LISP runtime. While there's not much point in trying to decide which one is "better," it's not an entirely unfounded point.
> For one it's slower
Could you be more specific? At least for me, there's no noticeable lag when using Evil mode.
I for one could care less about how keybindings are set, as it's just something that I write once in a config file and forget about.
> everything outside the actual text file has completely different controls
It's because Emacs is more of a runtime for elisp applications. As such, it makes sense to have different behaviors for each key depending on context. FWIW evil-collection does a pretty good job of making keybindings feel consistent outside of ordinary text buffers, so you won't have to fall back to Emacs keybindings these days.
> I lose most of the seamless interoperability with other terminal tools
This is plainly false. Shell interoperability in evil works exactly the same as in Vim.
> overly complicated in many aspects
This doesn't mean much without specifics. Implementation complexity isn't inherently a bad thing as long as it provides value.
Besides, Emacs is a just a LISP interpreter at its core. If anything, it's easy for programmers to grasp and hack on.
> Could you be more specific? At least for me, there's no noticeable lag when using Evil mode.
Long-time Vim user here. I tried switching to Doom Emacs for a few months. I really, really wanted to like it. As a nerd, the infinite customizability is like catnip to me. It has a really mature plugin ecosystem and you can have a really comfy computing setup with magit, org mode, dired, mu4e, etc...
But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance. And I don't mean line-by-line. Even going half a page, or a full page at a time, pegs a CPU core and there is noticeable latency. The Doom Emacs documentation straight up admits it [0]. They recommend crazy things like turning off line numbers. Even with newfangled native Elisp compiler, it doesn't come even close to vim on alacritty.
> But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance.
Just to play devils advocate (in reality I'm a die-hard-never-use-anything-else vim user, and have been since 1996-ish), I did once manage to set up vim with so many highlighting and display options that I made my i7 crawl whenever I tried to scroll.
(The main thing that pegged the core to 100% was ':set cul' with ':set number' and various different syntax highlighting for numbers, highlighted numbers, highlighted line, syntax-highlighting within a highlighted-line, etc).
So, yeah, vim can be slow too if you nerdgasm all over the config :-)
As an actual user of both editors, I have a hard time believing that scrolling performance between the two is different in a way that's recognizable. For both, scrolling is instantaneous unless
1. you spam the scroll key
2. you're viewing a exceptionally large buffer
3. syntax highlighting happens to perform badly on the buffer
4. some plugin is blocking the editor
For Vim, the forth situation has vastly improved with async APIs pioneered by Neovim, but it still can happen nonetheless.
As for the advice about turning off line numbers, that's just a micro-optimization. I've seen similar advice with Vim too. set nonumber nocursorline etc etc... I don't follow any of those overzealous optimization advice either on Vim or Emacs, and scrolling performance is just fine most of the time. Though for Vim, "set lazyredraw" did make a big difference in terms of scrolling performance, but that piece of advice isn't the sort that hampers usability so I don't think it really counts as an overzealous micro-optimization.
But back to Emacs, my view is that general editing performance is just fine. When you think about it, if general editing performance were noticeably horrid, that would be a deal breaker for pretty much everyone. It's mostly blocking operations that's causing problems, but that's a slightly different situation from Emacs being sluggish in general. Vim used to have this problem too up until a few years ago, but it ceased to be a major source of pain after plugins adopted async APIs. I just wish Emacs would follow suite.
On a beefy (iMac Pro) macOS workstation Emacs 27.2 is often slow at scrolling, which is also admitted in various places -- it has to do with the more pixels, apparently. Regardless of the fact that this station can also play various games at 5K resolution fairly decently...
There are zero excuses for a widely used editor program to lag that badly in 2021, on very strong hardware nonetheless.
One "hack" I found is to have your font not contain emojis. That was literally the only thing that actually helped.
And Emacs itself isn't at fault that LSP does its thing in a synchronous manner in the same main UI thread and makes Emacs super slow. I know that. But I also know that NeoVIM does the same thing asynchronously and doesn't stutter.
Sadly I'll be done with Emacs soon. I like it quite a lot but I'm not seeing any will to make it adequately fast or, at the very least, make it so its main UI thread can't be blocked.
This sends a message to me that the maintainers are using Emacs in a specific way and don't care about how others are using it. Which means that it's time to part ways.
Doom Emacs isn't Emacs. My handmade init.el was much lighter than Doom Emacs or Spacemacs ever where. Not really fair comparing a full blown setup with plugin with a barebones VIM one.
> everything outside the actual text file has completely different controls
Not sure what you mean by this
> lose most of the seamless interoperability with other terminal tools
It's not like VIM is more or less interoperable than Emacs is with other shell tools. They live in their own space, you don't (often) pipe stuff in or out of it.
Though there's not much to read into my comment, it was an attempt of being witty, but evil mode is the best VIM implementation found in any editor and just for the fact that Elisp >> Vimscript, makes evil mode a better environment than VIM itself.
> They live in their own space, you don't (often) pipe stuff in or out of it.
Well that's not true at least for vim.
: read !FOO
will run the FOO command and read the results back into the current buffer. I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file
As a Vim user who uses Emacs for note taking, I can guarantee Evil mode does far better at emulating Vim than you give credit for. In fact, the example you provided works just as well with Evil. The only built-in editing command which I notice missing from Vim is reliable undo/redo, which is sadly a fundamental Emacs limitation and a deal breaker. Apart from that, it's remarkably well-made.
My understanding is that it's still not as good as Vim's builtin undo though. Vim has a persistent undo tree that consistently works and doesn't confuse users. AFAIK the best attempt at it in Emacs is the undotree package, but it unfortunately has a reputation of being unreliable.
I've made no statement about emacs or evil mode. I was just correcting the user I was responding to about vim having interoperability with the rest of unix
But that goes back to the original point they made, everything outside of the actual text editing and you're in EMACS land with all of it's controls. Even with something as complete as spacemacs, the default landing page when you open it has different key bindings.
> I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file
I used to do that too, I now use the Ack plugin which is almost instantaneous on a codebase that grep used to take 2s-3s long to search. The speed isn't what matters though, it's the fact that Ack only searches source code, not all files so my results is less polluted with irrelevant matches.
and in emacs you can just redirect the command output to a buffer. or honestly, 99% of the time, I don't even bother redirecting and muck with the output directly in the eshell buffer.
No reason to be rude, I have used VIM for 15 years, I know how it works.
Yes you can pipe stuff in and out, you can do in Emacs as well.
My point being that VIM isn't better than Emacs on this aspect, and they're not like other shell tools where COMMON usage is by piping stuff in and out; they're not like cat, more, wc. They live in their own space.
This needs to be brought up more. The "emacs + evil" crowd tends to see vim as a set of ergonomic keybindings, but it's so much more. It's the "seamless interoperability with other terminal tools" alongside the keybindings and text-editing grammar that makes vim so powerful.
not sure about worse.
enabling evil-ex-visual-char-range allows you to do things ex commands in (neo)vim cannot do.
That is, run things like !rev on a visual select. in (neo)vim this reverses the whole line where with (evil-ex-visual-char-range t) enabled in evil does what I'd argue is expected, only reversing the string selected in visual mode.
OTOH, Neovim lets you edit the ex command line; e.g. '!}' might expand to ':.,.+5!', which lets you execute any other ex command simply by deleting the '!'. They both have advantages, and I'm certainly not advocating that forcing ex commands to work on lines is the best idea.
> 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”.
- palpably slow on a recent 16-inch high-specced MBP
- does a lot of extra distracting stuff that can’t be easily turned off (I know I opened a .java file, I don’t need you to open an extra tab that takes focus to tell me I don’t have a Java extension installed. I especially don’t need you to try and launch several Java-related daemons that you know I don’t have and then also put up some notifications about failure to find them)
VSCode is fine, not great. Nice scrollbar. Still rather mouse dependent, not enough keyboard navigation (e.g. for git, AFAICT), and tabbed layouts don't use large monitors well. I like many files visible at once to see context.
Re:extensions: great when they work well. But they tend to move fast, and come and go fast. That makes combinations of them brittle. If they're conveniences, that's no problem. But if they're necessary parts of my workflow, then life can suck.
With regards to keyboard navigation it gets really good if you work for it (no harder than you would with an editor like EMACS or Vim).
I use vim extension which works well for editing the files themselves. Accessing pretty much almost anything else can be done using the command palete and you can manually assing keybinds to it as well.
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 think what the poster you replied to may have been referring to is that the marginal cost once the editor is open is roughly zero. If VS Code is being used, a user can hit Ctrl/Cmd-N and have a new empty text field in no time. Similarly, opening a text file is so quick that I can't perceive any passing of time between clicking on it in the file tree and seeing the file open. Perhaps users with slower computers have a different experience?
The second example I posted, illustrating that VSCode is 14 times slower than BBEdit, was opening a file with VSCode already open (it's not obvious, but VSCode was already open in both recordings, so this difference has nothing to do with its launch time).
There's some truth to your comment though, in that VSCode's optimizations are very on rails, i.e., if you go the slightest bit off the beaten path (like I opened a file from the Finder, instead of from the sidebar, in the BBEdit/VSCode video), then VSCode approach to optimization falls apart (you can find accounts of the tricks VSCode uses to appear fast online, there's a lot of smoke and mirrors based around specific workflows -- I think making a new tab is actually the example they use). It wouldn't surprise me if part of the reason I perceive it as so slow is I expect every feature to be fast, not just to most common ones. And I think this is a perfectly fair metric to measure by. Emacs, Vim, BBEdit, and Sublime Text are all fast at everything they do, therefore I think it's fair to call VSCode a slow editor, even if technically it's average for a couple of features.
Often VS Code literally takes longer to process a single key input than Vim takes to start, load all plugins and open a session with multiple files on my machine.
Granted, it's not a high-end workstation, just a laptop from 2016. But I don't think it's slow; when Vim first released it could have beaten the fastest supercomputer. Now of course that's a matter of perspective, but I hope I'm not the only one who thinks editing a package.json shouldn't make any modern PC sweat.
Can’t speak for everyone, but 1,2 aren’t operations that I do hundreds of times a day even remotely. Otoh, I can see the difference^ in scrolling highlighted text between my 6600 and 8700 boxes in vim (which is my main tool; tried and ditched vscode for many reasons but speed, which is fine at both boxes). Maybe I could see that if I looked for it, but it’s not of any import.
^ not just slower, vim annoyingly skips scroll events if they arrive too fast. My system is configured for 6-7 lines per WM_SCROLL, and I guess that adds to the problem. As a result I have to scroll slower (at 6600 box) for vim to scroll faster.
On editors in general: I’d like to have an editor as a library for which I could create modes/cli/behaviors myself. I believe that the sharpest tool is the one you sharpened yourself and for basic editing there is notepad2 and alikes. Vscode is much closer to that, but it’s too cumbersome to create/update personal extensions, so dumb vim hacks be it.
Vim also supports the same LSP implementations that VSCode uses via Coc.nvim (https://github.com/neoclide/coc.nvim), which provides the same code navigation features that VSCode has, including jump to definition.
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?
It’s a play for dev mindshare where they get to control the platform and have access to devs using their software, they have no intentions of making money from it directly only to maximize its appeal & marketshare. It’s a cross-platform dev environment they can easily deliver extensions to connect to their commercial products.
There’s no point in them continuing to invest in fragmenting the dev community by developing 2 competing platforms now that they own GitHub so I’m not expecting to see any increased investments in Atom.
I didn't know atom was abandoned. That's sad. Do you mind linking to a release that states that officially?
For me, plain vim is a great thing. My computer is hot enough without another electron app, and for that reason I've never tried VSCode (ium) -- I feel there is a vast amount I still have left to learn in vim, and although I've been using it for >10 years, I'm far from an advanced user. It just works, is fast, and matches my brain.
Microsoft also has a very, very long way to win back my headspace. I take it this new editor -- which I will give a quick go to -- doesn't come with telemetry and nonfree core code, for example.
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.
The last 20 years have been OK. Before that not really so.
I remember starting emacs on a VAX-750 with 4 MB main memory and 8 users in the 80s.
Even in the 90s with Suns and competitors in single user usage emacs could bring things to a halt. Especially when starting a certain messaging client (hej LysKOM).
Well, back then emacs was a resource hog like today VSCode using 8GB and swapping as someone wrote here. (I would not touch VSCode with a stick). Times have changed, but emacs rather little. So today it can nearly be considered lightweight and efficient.
opening any file with extra long lines (for example minified js files which somehow end up littering any codebase) in emacs is still bring emacs to its knees, especially if you have line wrapping enabled.
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.
It seems the biggest issue with ropes is search. The rust regex engine (which this editor uses) expects an array. In the worst case scenario you forced to copy the entire document into an array to run search on it. Only to throw that away when you are done. That offsets a lot of performance gains ropes are supposed to provide.
If the regex engine doesn't support indexing into a arbitrary (indexable) data structure, that's a deficiency in the regex engine, not in one particular such data structure. You can tell this isn't a deficiency of ropes, because the exact same thing would happen if you used[0] hash tables or b-trees.
Search might be slower with a more complicated lookup (versus a probably-inlined-and-otherwise-optimized pointer-plus-index addition), but that wasn't the problem described; the problem decribed was that non-array lookups weren't supported at all, and search required copying the data over to a array before the regex engine would deign to touch it.
0: for a example, not a suggestion that they would be a good fit for a text editor
It's not widely known but PCRE (which I assume is still the most widely used regex library) supports partial matching which you can use to interoperate with any piecewise linear string representation (ropes, gap buffers, etc).
> 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.
Wasm started in the web, but has since been ported even to the Linux kernel [0]. It seems perfect for situation where you near machine code levels of performance, but don't want to carry different binaries for different CPU architectures - exactly what you want from a plugin system. It also allows far greater isolation than "real" compiled code.
WASM code by itself can run at near C speeds, but where you are going to find the challenges is crossing the wasm <-> "rest of our app" divide.
You can call functions living in WASM with integer arguments and WASM can call functions you expose to it. You're host app has access to the WASM memory space though, and with those tools you have to craft your API. For a text editor there are going to be quite a few hoops to jump through and memory copying going on just to let a plugin read the document text.
Platforms like JVM, .Net, and nodejs/Electron have a huge advantage when doing extensions because they are can easily load code at runtime, and pass "platform native" data structures directly into extension code. Compilers exist for many languages which can target these platforms.
Wasm may be web related, but it's just a reasonably mature technology with a developing ecosystem [1].
You can implement Wasm without anything web related. You can even implement ECMAScript without implementing anything web related (like the document model).
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'm sure you're not saying that your specific needs are representative of everyone who might be interested in using this editor. It's much easier to put customization tools in the hands of developers than to anticipate every legitimate need they may have in an editor.
The thing is that editor scripting interfaces (vimscript in particular) kinda suck. I'd much rather have the essentials as built-in features in the editor. For example, surround.vim is kinda nice feature but it doesn't play nice with undo and repeat.
Most text editor scripting add-ons fall into two categories: 1) core editing features (like surround.vim) or 2) bringing IDE-like features to the editor.
Things that fall under category 1 generally work better when they're implemented in the editor core. Things that fall under category 2 could mostly be implemented outside the editor, e.g. using tmux key bindings to open a new window to run the compiler in and then send the output back to the editor. I don't really want the editor to have a terminal emulator and windowing system to launch the editor in.
There are plenty of proper IDEs out there, there are plenty of scriptable editors out there which have (mostly half-baked) scripted IDE-like features out there, as well as bare bones editors with no scripting. I'm not gonna argue one is better than the other, but there's no reason every editor should have a scripting interface in it.
I have used programming tools in every category and they all have their merits. I had a fully pimped up Vim setup with lots of plugins but I eventually abandoned them as they were more trouble than they were worth and now I have a very bare bones setup with minimal customization.
So yeah, I don't think scripting is an essential feature in a text editor, and I'd much rather see the effort spent core editor features polished than a scripting interface.
As for "my specific needs", I need a good text editor first. I've used about a half dozen different programming languages in the past year, and no editor out there would handle all the "integrated" features to all of them gracefully without a lot of customization.
Currently I use TextAdept which is kind of the inversion of "scripting" the editor - the core is basically a SciTE wrapper and the editor is Lua. It boasts a tiny source code footprint. There aren't many features or integrations, but I am aiming not to need those.
(Becoming IDE-dependent is definitely a thing, but when it goes in that direction, I look for a full-fat IDE experience for that specific language and then use either my text editor or IDE situationally. It's just not worth it to try to configure your way into Nirvana when the language you're using is probably going to change again.)
I also tried Kakoune, coming from pretty vanilla vim as well.
I liked its concepts, but I could not make kak auto line wrap C block comments correctly. Kakoune apparently relies on external tools like `par` to do, at lease for me, pretty essential stuff, which vim does of of the box.
I will take a look at helix, but I hope it comes with basic text wrapping features included.
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.
What happens when I start such an editor? It starts the basic editor and then it spins up 15 other language environments / interpreters to run the extensions?
Yeah, why not? If implemented correctly, this should ensure that the user interface is always snappy because all the slow parts (language servers, build systems, search, embedded applications) would be in backends. Modern multi-core systems are especially well-suited to such an architecture.
The biggest issue would be fragmentation of the extension ecosystem. The ecosystem would be split along implementation languages, which is an altogether disadvantegeous dimension.
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.
> At the same time, it doesn't add anything useful to editing itself. It's basically scriptable MS Notepad.
I don't know, fill-paragraph (M-q), the sexp commands, transpose commands, upcase-downcase-capitalize commands, indent-rigidly are all built-in, bound by default and I use them a lot. And let's not forget Macros.
Vim provides a different, more efficient modal language for talking to the editor (which Kakoune further improves). Emacs on the other hand doesn't, it just gives you some ad-hoc shortcuts. Emacs's language is no different from the one of Notepad or VS Code. It's the language of insert mode + scripted shortcuts.
Shortcuts can improve your experience, yes, but not in such a fundamental way as a new model of editing.
UPD.
For example, the Emacs way of dealing with tables in markdown/latex is to have a custom plugin which will have a separate shortcut for each action one might want. As a consequence, you need to remember the keys for each of them.
Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Give me M-q any day over gqap (or, if you're inside a multiline comment, 3gqq; or, if you're inside a multiline comment starting on the same line as code, just giving up).
Edit: though I have to admit that I'm missing 'dt.', 'd/something', etc.
> 'd/something' is doable with C-s something RET C-w
Doesn't this need to be C-s something C-r RET C-w? Because C-s positions the cursor at the end of the search match.
What do you mean by ad-hoc? They seem to me be chosen and bound by default, because they are useful in practice.
> Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Could you point me to some example?
And I am not sure if what you say about Emacs is necessarily true, you could have a minor mode that modifies the default keys to work with text tables. Org-mode's table implementation is a good example for that.
I mean that in Emacs you have one ready to use action for everything you might want to do. One shortcut covers exactly one use case; if you want more use cases covered, install plugins or write scripts. M-q is an example, it formats the current paragraph. What if I want to format something other that a paragraph? In Emacs, you will need a new shortcut and a new keybinding for that.
In Vim-like editors you have some small atomic terms that you can combine to build the actions. You can have a small number of atomic terms, which can be combined in a multitude of ways and therefore cover a multitude of use cases. In Vim the gqap is not a single take it or leave it action, it's a sentence with verb gq and noun ap. If you want the verb to act on something different, you replace the ap part with something else.
Think of keybindings as a language you speak to your editor. In Vim the language has a number of words that you can combine to build sentences. In Emacs you have only a given number of ready to use sentences, and you have to memorize each one. This is a big distinction if we're talking about a text editor for efficiency, because it defines the ratio “time spent customizing” / “time saved editing”.
> Could you point me to some example?
You can cut and paste columns in Markdown tables using Kakoune's multiple selections. Like this:
- <a-i>p -- select the paragraph
- <a-s><a-;>; -- this creates a cursor at the beginning of each line
- <a-f>| -- move cursor to the next pipe symbol (selecting everything as it moves)
- <a-.> -- repeat the last move command (do this to select the column you want)
- d -- delete the selected (by each of the selection)
- <a-f>| (or <a-b>|) -- again to move cursors where you want to paste things
- p -- paste the deleted column
In this example, I haven't used a single command that I don't normally use while editing, say, Rust or Haskell. And you can manipulate Org, Latex tables with similar commands. In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Kakoune.org has more videos where they show what it can do (without plugins).
> M-q is an example, it formats the current paragraph. What if I want to format something other that a paragraph? In Emacs, you will need a new shortcut and a new keybinding for that.
You'd usually have a DWIM command, e.g. that it formats the region, but default to the paragraph if nothing else is selected. I have the feeling you are making this out to be a bigger difference than it actually is.
What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software. Emacs can steal anything that any other program does, and have it combined with it's existing strengths, like the ball of mud that it is. And even without emulation modes, there is inherently nothing in Emacs that is stopping it from using the same kind of sentence mentality you are talking about (and that I am familiar with, I have used both, but prefer Emacs).
> In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Plugin is the wrong word, you mean package, but not necessarily. Emacs has syntactic commands, that can operate on a major-mode specific definition of expressions, sentences, top-level definitions (defuns).
To do what you did in your example, I'd just use macros, recording this sequence:
C-a M-SPC C-s | (repeat C-s to select the column you want) C-w (again move cursors where you want to paste things) M-w
and then repeat that for all the following lines. Multiple cursors are just visualized macros, after all.
M-spc just inserted a space for me. Do I need some package for it to work? What does your sequence of commands mean in English?
I have no doubt that what I've shows can be done in Emacs. How natural is it to express? How much scripting and packaging does it require? How much extra memorizing does it require?
> What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software
Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default. Of course, you can script anything in it, but it's a meaningless argument; Linux kernel allows you to implement any program you want, but it doesn't make Linux a good text editor.
And in particular, I was talking about interfaces that are efficient, take little time to setup and save you a lot of time when you use them. My claim is that Emacs is not one of them. (Which doesn't make Emacs bad in the ultimate sense. It can be good for other things.)
> Multiple cursors are just visualized macros, after all.
Yes and no. Any text editing operation can expressed in ex commands, but it doesn't make ex a good editor, and definitely doesn't make it an efficient one.
Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
> What does your sequence of commands mean in English?
This time I tested it to make sure that I say the right bindings:
1. Go to the beginning of the line (C-a)
2. Find the n'th column (n * C-s |)
3. Activate the mark (C-SPC)
4. Go to the next column (C-s |)
5. Kill the region (C-w)
6. Go to the column you want (m * C-s/C-r |)
7. Insert the region (C-y)
> How natural is it to express?
To me it is instinctive.
> How much scripting and packaging does it require?
None, these are all basic commands.
> How much extra memorizing does it require?
All you need to know is how to record a macro.
> Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default.
But then you are comparing different apples to oranges? But even if we are comparing vim/kak the interface to Emacs' default interface, I still don't think the difference is that big. The main difference is that vim/kak are parts of the terminal workflow, while Emacs is a shell onto itself.
> Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
You have instant feedback while recording a macro too? You can even make it interactive, and insert a query into your macros to make it easier for you to distinguish between false-positives and the actual places you want to apply macros.
I see the point. The Emacs way can also be seen as object-verb, it's just that object is given via selection. I don't have any objections to what you said, maybe I was wrong about Vim/Emacs difference.
But. Kakoune is still something bigger for me. It does take text editing to a new level and it does make it more efficient. It is similar to Emacs in the sense that both follow the sequence “select and apply an action”. But Kakoune has richer selection primitives and has actions that work on multiple selections at the same time; this can be done with macros, but it's by far less convenient.
In your example, you can record a macro and apply it to all the lines of a table. Will you have to do it for each line one by one? Can you say, “run the macro on each line of this paragraph”?
> You have instant feedback while recording a macro too?
Sure, but not on all the places where you're going to apply it at the same time. And your macro may not work correctly on some of the lines, you will not see it while recording it. With multiple selections you see it immediately and can undo the last action and try again.
Multiple selections stay there after you apply actions on them. After you apply something, you can see the result and slowly think of the thing to do next with them. With a macro, you will have to type in the whole sequence when you record the macro.
Macros can achieve the same things, but they require more mental effort and are harder to get used to. And when you're focused on your code, the mental effort it takes to used your editor matters.
In the same way, multiple selections are an improvement over Vim's tradition of shooting regexes at your text; for the same reasons: interactiveness and instant feedback.
Emacs and Vim are both equally efficient at text editing, I don't think you gave Emacs a fair shot. OTOH, VSCocde is frustrating to use if you are proficient at vim/emacs.
> Emacs people tend to play a lot with customization
I used to do that when I was young. Lots of elisp. Then I threw away a lot of customizations I didn't use anymore, added packages for the languages I'm using now and I think I ended up with a straightforward configuration.
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.
Vim and neovim do not have support for multiple cursors. The vis editor, is a vim-like editor that does support multiple cursors (and also structural regular expressions, if that's your thing).
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.
Most of the time you are using a browser, I can almost guarantee you’re not typing text. Likewise, but to a lesser extent, I bet most of your editor time is spent reading and doing minor tweaks instead of pure insert mode.
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
Just by following the instructions I had a pretty good setup already, but I made a couple of further changes, like setting up autoformatting on save, which was a bit trickier. `vim.lsp.buf.formatting` was useful there, but I had to do a bit of research to figure out how to use it (it wasn't immediately available on the READMEs).
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.
Thanks for this, you finally got me to look at the mouse options in vim, which I've always preferred off, as it's extremely annoying when using multiple windows and a click to focus window manager (like explorer, for the most part) when it places me somewhere else.
Now that I know how to enable it for specific modes, I'll definitely be using it for visual mode, and maybe insert mode (we'll see how much that annoys me). Now I'm off to see if I can get the mouse wheel to work at all times but click to place cursor off except when I want it, which would be ideal.
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.
This was 10 years ago, but I remember reading up and something with the forces enacted on your tendons moving the mouse around were exponentially worse than typing on a keyboard.
I use a touchpad when possible knowing that, but I've never double checked myself. Anecdotally, I've only developed RSI in my mouse hand from gaming (same story for my friends who game as well).
One point to add to all of the great points here is consider getting a smaller keyboard (or an ergodox) especially if you're on the smaller side (for the same reason as the last point, stretching less tends to be nicer on the tendons).
I'm not saying RSI in your wrists, that's mostly on straight keyboard (dacman all the way folks), but I personally had pretty bad RSI in my shoulder from the keyboard-mouse switching.
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.
Android Studio is based on the Jetbrains IDE, IntelliJ, and you don't need the mouse to do anything with them. If you don't know how, I recommend you watch some guides on https://blog.jetbrains.com/idea/category/tips-tricks/ or find some presentations on Youtube (after I watched one many years ago, I've been feeling like I have superpowers and can do anything with a couple of shortcuts).
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:
Jumping "forward" is sort of built into Emacs with C-x C-SPC, pop-global-mark.
The objective and this command are fairly but not completely aligned, so it may require multiple presses of C-x C-SPC. To be clear, you only need to press C-SPC after the first invocation to repeat the command.
"sort of" and "not completely aligned" are just right: IMO, the mark navigation feature is just clunky/broken compared to the alternatives.
You don't want to iterate between the marks in the current buffer in a loop, or somehow keep track of whether each of the last three navigations changed the buffer or not (which would affect which one of the mark rings you'll have to use to go back or forward).
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 have, and it's much better than a mouse, especially since I've got used to working the trackpad with my thumb.
But I still prefer keyboard shortcuts, they juste feel more natural while the hands are already in "typing mode". I feel like there's a question of "waiting around". Even though I've always found the mac trackpad to be very precise, even for quick movements, you still have to aim for an icon, move the cursor to it, click, etc.
Now in the particular case of a macbook, where the windows will probably be maximized or not move around a lot, you may get some kind of muscle memory. But you still have to look around for the icon, etc. Whereas a shortcut is always the same, you press the keys and you're done, it doesn't matter where your cursor and / or window happen to be. I also prefer hidden icon toolbars, this allows me to gain some vertical space.
But, as another commenter said, some actions are easier with the mouse and wouldn't throw mine away. In my case, that's web browsing.
I’ve tried the vi-like plug-ins for browsers that let you press a key then choose a link/button on the page by letter(s). I haven’t quite got ‘into’ them, however.
File management is also something that I find a lot easier with a pointing device. Also drawing diagrams, unsurprisingly!
"pointing at the screen" can be done a lot better, a number of different ways. My personal favorite is the Trackpoint, IBM's nifty little nipple that lets you use a joystick from the home row. You can actually type while using your mouse, and it's a a very jarring experience. Barring that, a touchscreen is also a great interface for quickly interacting with specific UI elements. I like Apple's trackpads, but the rest of their input peripherals are pretty terrible for ergonomics.
I've been a huge fan of the Trackpoint for many years, but unfortunately it's always been plagued by annoying drift issues, where the cursor keeps moving in one direction and you have to fight with it to make it stop. This has been an issue on older IBM ThinkPads as well as modern Lenovo models. It's a disgrace the technology hasn't improved much (at all?) in the last 20 years that this is still a recurring problem.
The trick is: as soon as you notice it drifting, take your finger off it and let it come to a stop. If you keep pushing opposite the drift it'll never stop.
Also, if you haven't in a while, replace your cap. I replace mine every year or so and it makes it perform much better. You don't have to push as hard, which also reduces the drift problem.
Yeah, I do this as well, but it's still annoying as it takes it a few seconds to stop. And then usually happens again soon after, so I often just force push it in the direction I want.
I don't replace the cap often, but I do take it out and clean it, blow out the dust, etc. I'll give a fresh cap a try soon, thanks. It's just ridiculous this highly disruptive behavior is still a thing after all these years...
There was also just shy of a dozen different Trackpoint designs, I don't doubt that one or two were seriously faulty, and I certainly have my preferences (the lower profile ones definitely don't track as well). In any case, the positioning and design of it is pretty ideal for people looking to reduce context switching at any cost.
I've not used a MacBook, but I've used laptops with trackpads. Either way, I'm a vim user, so I really don't have a reason to use the mouse for editing.
I don't get why you are being downvoted. A good trackpad under a keyboard (like on the Macbooks) is probably the (or at least, my) best input method. I would pay high price for a desktop keyboard with a qualitative touchpad right under the keyboard.
Indeed. If the challenge is to move to an arbitrary location visible on screen, then it’s logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts. Keyboard shortcuts can be more efficient in some specific cases of course (e.g. moving to the beginning of the next word, or something like that). But I see no point in memorizing the more obscure shortcuts when the trackpad works so efficiently and requires no thought or memorization.
The difference is that with a pointer device you need to control the input very carefully and precisely, which wastes time and brain cycles. A misclick could result in either maximizing or closing a window. Consecutive clicks can be interpreted differently depending on the configured period. Dragging and dropping is awkward, etc.
On any trackpad other than Apple's this becomes even more difficult. Gestures are nice but also require nuance and IME don't become part of muscle memory as quickly as keyboard use does.
Keyboard-driven workflows have no such issues. A keyboard shortcut is an immediate command to the computer to perform an action, and if that's something you do often, it will save you time and effort right away. You'll memorize it soon and forget about it since it will become part of muscle memory.
> If the challenge is to move to an arbitrary location visible on screen, then it’s logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts.
But moving "to a location on screen" is never a challenge worth using keyboard shortcuts for. If moving a cursor is your only UI option then a trackpad will be more efficient than doing the same with a keyboard of course. What you should do is use hotkeys to perform the action you would with a pointer so that you don't have to move it to begin with.
I’m not really sure what you’re getting at. I find my MacBook trackpad to be a fast and precise method of placing the cursor at an arbitrary location within a text buffer. Outside of certain special cases it is faster for this purpose than fiddling around with keyboard shortcuts. There should not be any significant mental overhead associated with using a pointer device if you are sufficiently practiced at it.
If trackpads don’t work well for you then don’t use them. I believe you, and have no interest in proving that your favored working methods are suboptimal. However, having tried the ‘keyboard first’ approach, I know that it is less efficient for me.
I do tire of the ritual haranguing of anyone who notes that they find the use of pointer devices an aid to their working efficiency.
I'm disagreeing with your assertion that "it's logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts".
I thought you were talking about moving the cursor to a general area of the screen, not within the context of a text buffer, but there I still think using the keyboard for motion is more efficient once you build up the muscle memory for it. There are plugins like vim-easymotion[1] that make this faster, but I've found plain motion bindings to be efficient enough for me.
In any case, my intention wasn't to dismiss your personal preference, so apologies if it came out like that. At the end of the day we all have a specific workflow we prefer for whatever reason, and that's fine. I just objected to the general statement that a trackpad is more efficient.
As a developer, eventually, the raw task of "writing code" is really not where I feel losing time. Tbh, most of my time developing software is reading code and thinking about what needs to be written and "doing nothing" waiting for build/test to complete.
Fast switching between tools using touchpad gestures is more important to me than being able to type faster (but I acknowledge you can do both). As a sidenote, I absolutely love macOS fullscreen mode combined with 4 fingers swap. It's such a productivity marvel that I don't understand why Windows never copied it.
It's not so much about saving time for me as it is about avoiding the context switch. If I'm typing on the keyboard moving my hand away to the mouse or down in the case of a trackpad and then carefully positioning the cursor on the screen and clicking, is disruptive to my workflow when I just want to think about what I'm typing. For daily use I use a Trackpoint to at least avoid the hand movement, but moving the cursor around still takes me out of whatever I was doing to focus on the UI (in addition to the annoyingly persistent Trackpoint drift issue).
But I agree that Apple's touchpad gestures are awesome and from the few times I've tried it it worked much more reliably than on any other device. Still, I haven't found a more comfortable setup than a ThinkPad keyboard + Trackpoint. The insanely short key travel on Macbooks is unbearable to me.
>but there I still think using the keyboard for motion is more efficient once you build up the muscle memory for it.
I think a lot of people underestimate how fast a good trackpad can be with practice. I can move the pointer to an arbitrary location on screen in less time than it typically takes me to make a key chord. However long and hard I might train on Vim (and I did use it for ~10 years!) there's a hard limit on how much time that could save me when the trackpad is already so damn fast.
True, but it's much more precise than an analog pointing device sensitive to subtle movements, click timings, etc. Keyboard input can be trained and ingrained in muscle memory. Mouse movements always require focus to at least ensure you're clicking on the right UI element.
In my experience, a good work environment let's you go a really long way without even thinking of the mouse (or trackpad). So discussing which pointer device is most comfortable is sort of foreign to me. For context, I use shells and vim in tmux. If I don't need a web browser, I'll often not even start an X server (so no mouse at all).
Obviously it's possible to just use the keyboard if that's how you want to work.
The point is that using a good quality trackpad positioned below a keyboard doesn't actually require you to move your wrist much, if at all. With this set up, there is not really any cost associated with switching between the trackpad and the keyboard. Thus, there is really no benefit to using the keyboard for tasks which can also be accomplished efficiently using the trackpad (as you are not paying any significant penalty for switching between the two input methods). For example, I was able to move my mouse cursor to the 'update' button to submit this form faster than I would have been able to use the relevant keyboard shortcut.
I'd say that pointing is inherently slow because it involves checking where the cursor is, where the target is, moving it in that direction, then stopping at the right time. With a typical keyboard-based browser interface clicking the update button would have been a 2 key combination. Two discreet steps without any timing or measurement nuances.
I guess which is better for me doesn't have to be so for someone else. Mouse interfaces do have a certain simplicity to them.
You say that you hardly ever use the mouse. If you’re out of practice then you’d probably be slow at it.
On a good trackpad you don’t actually need much visual feedback because the response is very predictable. You can make a short movement and click more quickly than you can press a couple of keys.
Saka Key looks to be both slower and more complex than navigating using a trackpad (especially once you take scrolling into account).
With a pointer you treat the screen as a continuous space. With Saka Key's link clicking method (for the lack of a better term) you're selecting out of a discreet set of keys. I'm not sure what the implications are, but I feel like the difference is qualitative.
I would buy such a keyboard too. Or a touchscreen. I can raise my hand, touch the screen to place the cursor close to where I want and probably be faster than with a touchpad, surely much faster than with a mouse. Unfortunately I would have to clean my screen as often as my glasses.
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.
I'm not familiar with Dota, but I'd guess that like other games whatever interface elements a player has to click are always in the same place and they're probably already having their hand on the mouse so know exactly where the cursor is.
Now compare this with an usual "desktop session", where you may have multiple windows which aren't always in the exact same place, the cursor moves around, maybe even hidden because you've been typing, etc. Now you have to spend some extra time to 1. locate the cursor, 2. locate the button to click, 3. move the mouse over. It will probably not be slow but it clearly takes you out of the flow compared to keeping your hands where they were and knowing that whatever your shortcut you have to press will do what you expect.
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.
I'm intrigued (because I like to see experiments in the modal editing space), but I'd really appreciate a "why" section.
The editor space is crowded, and I like understanding which pain points new ones address. I mean, "neovim, but in Rust" is a perfectly valid decision, but is it the only reason? It looks like this might be an ongoing experiment for the author? (See also the github remark on alternate renderers)
I used to use multiple cursors in sublime, but I do find vims find/replace syntax to be better. Paired with a macro that fills out most of the find/replace command for word under cursor, I find it fast and flexible.
The best part is, when you need to do that across multiple files that you can find with a :grep or :Rg command, its trivial. Populate the quickfix/location with grep (or ripgrep or silver searcher etc) and fire off a cdo with a :s/foo/bar/g and watch it run.
Onivim 2 is getting there. Version 0.5.5 was released two months ago, 0.6 would be worth taking a look at https://v2.onivim.io/#timeline
It's a main contender for me to replace VSCode, whereas this one doesn't look that enticing. I want a terminal in my editor, not an editor in my terminal, had enough of that.
What I would really like to see is a modal editor that doesn't use vim-like keybindings. Ideally something where the user decides what key executes what function, and maybe some optional vim-like defaults.
Vim's macros are great. You can record a list of actions (with q), and they will be written in a clipboard as a string of key names. Unfortunately, this depends on w meaning "move to start of next word", i meaning "enter insert mode" ^[ (the escape character) meaning go to normal mode, etc. You can remap a key on the keyboard to represent a different key in a specific context ("nmap j k" gives the j key the k key's behavior in normal mode), but you can never change a key's underlying meaning (j will always mean go down a line, even when the j key behaves as k).
Vim's keybindings are so deeply hardcoded into what vim is that's it's just not feasible to change them. I would really like a modal editor that doesn't have that problem: a modal editor that doesn't even try to be vim.
There is multiple cursors[1]. Checkout the video by emacsrocks[2]. You can combine that with regex tools if you need to do this over complex patterns[3]. There is also iedit which may fit your mental model better[4].
The highlights and fancy replacement preview are added by a plugin called anzu[0], but otherwise this is a standard emacs feature. I couldn't tell you what the default binding is but the function is query-replace-regexp.
(I don't understand why people are trying to bring multiple cursors into this)
I use replace-replace-regexp a lot. What was shown in the video was qualitatively different. Multiple sites were shown changing at the same time. That's not what q-r-r does, even with "bang" version mentioned above. You could actually see the old text replaceable by the being-entered new text.
The buffer was not being edited when the replacement was shown to be happening. The plugin anzu uses overlays[1] to show the text being replaced and the replacements.
If you select a region with transient mode on, then `query-replace` (`M-%` by default) will only affect the region. So select the region you want the change to effect (just like in the demo video), hit `M-%`, then type the old and new text, then you can type `!` when prompted for what to do and all instances of old become new only within the region.
This seems something I can love, will give it a shot.
I switched from Emacs to VSCode but occasionally misses the
editor-in-the-terminal-without-project-setup. I use vim when I'm forced by, say git, but I can barely copy-n-pate and undo, and I have no desire to learn the decades old tool. It's too anti-fancy to spend my precious spare time.
As a backup, I'd love to hear how to learn vim as a something modern and fancy. I'm happy to be convinced.
In my opinion the only way to learn vim is to fully commit to it: Use it as your only editor and every time you hit a wall, spend the time to learn and unblock yourself. Productivity will take a serious hit for weeks, likely months.
I did this 10 years ago and never looked back. Although in the last years I have evolved to an 80/20 JetBrains/vim split. Using the excellent IdeaVIM plugin to bring all my vim skills and configs to a full IDE.
What do you think about using vim emulation in VSCode?
For me it seems impossible to be productive without the ecosystem of extensions VSCode provides.
I am intrigued by the power of modal editing, but going all-in vim seems a step back with regard do "modern" development workflows.
In vim it appears you have to configure every piece of it from scratch, while in VSCode if you pick a new language it's usually enough to install an extension and you're good to go.
I suppose vim emulation also works if the emulation plugin is good.
The point is to make the switch and stick to it even though you will be slower for a while. And spend the time to look for better approaches when you feel like you are repeating yourself. (Just like you get that DRY itch to refactor when repeating the same code snippet a few times)
I don't know why people put up with this stuff. With something like this it is just a nonsensical joke to make a clickbait title that immediately gets walked back.
I never thought people would adamantly defend links like this - "sure they made up something that makes no sense, but they back peddle once you click the link"
Not only that, this isn't even a text editor, it is a front end for neovim.
It's a personal project, I'm allowed to have some fun with the tagline. For what it's worth, I did not post this on HN, and the original title I used on r/rust was "A kakoune/neovim inspired text editor written in Rust".
Its funny and pokes fun at the larger conversation but I hear you.
Though I think its fair since neo vim is referred to and means new vim. The author here likely believes helix to be more modern than neo vim hence, post modern.
Whatever, I'm sure you understood that. I enjoyed the humor and think its fair
I am excited to try Helix. I was a vim user many years ago, but not a superuser. Neovim caught my eye for a while, but I felt like I should stay with vim or vi even to be able to jump on any system and work with modal editing tools. I loved emacs, but found myself playing with it more than using it as a text editor or simple IDE. This looks great for me, and fits in with my learning Rust too. Unfortunately the release build for Windows throws a panic, and so does a new build on my machine. I put in an issue on Github, because I wasn't competent enough in Rust or Helix to know what the issue was other than an array length violation or mismatch.
thread 'main' panicked at 'index out of bounds: the len is 3451 but the index is 3451', helix-tui\src\buffer.rs:185:14 stack
The issue was addressed very quickly, and I was able to try Helix out. I love it! However, some modes are not working (LSP?), and it crashes when I am using it. I can pull up file view, but I am not sure how to jump up a directory. I think I will put it on the backburner and either look at the code myself, or wait until the bugs are worked out for Windows 10. I really like it though. Changing colors would be cool too.
Really exciting, I wish you would display what keys you are pressing in the demo video though, as it was hard to track down how to find bindings such as the file-picker (I come from sublime where it is bound to ctrl+p)
This was my observation before actually reading the post... a reaction to the title. If you visit the actual site you will see that the author points out that the use of "post-modern" is intended to be a joke (which I quite like, lol): From an art perspective "postmodern" would be something that challenged the concept of modernism. That would be work based on idealism and reason vs that based on scepticism and suspicion of reason. Since that doesn't really apply to this editor perhaps this editor is simply a modern editor?
just a nit-pick but I would push back on the notion that the only thing that came to challenge modernity was neo-Idealism, neo-Rationality. I have never seen any one really define post-modernism that way, and in fact such things are just as challenged by postmodernity! Postmodernity is first and foremost a loose collection of tendencies post-WWII. I also agree its cute that its a little joke.
maybe something that makes/or would make it a true PoMo editor is an effort in juxtaposing modern vscode-IDE stuff onto an older terminal aesthetic
Geany is really fast, and according to typometer (From Pavel Faltin), it processes keyboard input faster than any terminal I've tested (linux). So A terminal editor doesn't do anything for me...
There's a lot of this I like, but I'm kind of scratching my head about the central design feature being "multiple selections by default". I never even gave Kakoune a shot, because in general multiple-selections just didn't seem like a significant design advantage to me. If I'm doing a lot of multiple selection editing, I tend to think of it as a strong signal that my code/system has a design mistake.
When refactoring, the typing tends to be the least of the work, and multiselect style changes tend to be less helpful once you are doing all the other things you should be doing during a proper refactor.
This looks promising, and I like what they've done with the multiple selections. I like the idea of TreeSitter+LSP, but at least for Python it doesn't look to do anything more than basic editing. It says it has indent information for go, rust, typescript, and javascript. Very interested to see where this goes.
I don't get the point of using a modal editor these days. Just get a keyboard with QMK ( for example, there is also a software approach) and you can edit completely on the home row (everywhere!) without the need for a modal editor.
How keyboard macro can possibly replace an editor that operates on text objects?
Let's say you have 'foo bar' string, and you want to change quotes to "
In Kakoune this operation could look like this:
<a-a>' # select string including quotes
<a-S> # select first and last character of previous selection
r" # replace selections with "
Trivial, 5 keystrokes and it works for any type of quotes (I can do for example <a-a>`). Notice that "replace quotes around the string" is not built-in operation in Kakoune.
Now how would you achieve that in non-modal editor that also doesn't have this operation built-in?
I have a QMK 34 key keyboard, with lots of layers, combos, tap-olds and things, but it doesn't provide nearly as much as a modal editor does.
Select inside a block? Comment out a region? Jump to line X? Jump Y lines up? Go-to definition? Autocomplete? Insert snippet? Even a simple thing as delete the next two words or jump to next "f"?
Link your keymap.c? I've seen people add binds for various "Vim like" actions, but they always seemed a bit ad-hoc. I would love to see a map that's been battle tested.
Compared to Neovim 0.5, this doesn't seem to bring much on the table. Surely, some things work out of the box, have nicer UI elements and there are a few new features. But with a huge cost of no big ecosystem.
I agree that if you have a setup that works for you, it might not make sense to migrate. I wrote this specifically to move from neovim though, because:
- I had to maintain a large config just to get basic features like code commenting shortcuts
- My config would often break, this week all my LSPs died after a neovim update
- Vim wasn't designed to support multiple cursors
Secondly, I've tried adding a snippet mode in lua:
- Neovim would lose any marks on lines that got modified. This got better with nvim_buf_set_text (instead of _set_lines), but it'll still lose marks inside the content area.
- Vim is based around macros, so any sort of scripting requires you to inject an incantation of keys. Try programmatically setting a selection? No such luck.
Rather than dealing with the bugs I decided to work on my own thing because I can iterate on it faster than dealing with C / C's vimscript interface.
One day there will come an editor which has alternating line color theme by default - I hope.
Never mind that. I hope they won't forget to add 'read from stdin'.
I take slight issue with the joke around "postmodern". Modernism and postmodernism are actual things. Modern means a new way to do something without much influence from the older ways. Postmodern means looking at multiple ways something has been done over time then extracting and combining a sets of the good ways from any time and tradition into a new, workable whole.
Saying something is postmodern because it came out after something modern cheapens the word.
What I really want from another Vim replacement is why it's better than neovim, not jokes about usurping Vim at the expense of the English language. I think that's presumptuous at best and I don't find it very funny to claim to be better because it's newer.
>Saying something is postmodern because it came out after something modern cheapens the word.
Well,
(a) it's meant as a joke.
(b) it's not such a great word for us to care about "cheapening" it. It's not like "postmodern" is a word loaded with valor, like "freedom" or "justice" or some such for example.
(c) Actually neither modernism nor postmodernism mean what you wrote as they are canonically defined. Modernism is a specific early to mid 20th century movement in arts, design, literature and so on, and postmodernism is another one (mid to late 20th century, the term started from architectural critique and moved to philosophy and aesthetic discourse to general use), with a quite specific context and history.
Do you have sources to back up those definitions? The Oxford dictionary on my iPhone don’t really agree with your assessment and Wikipedia considers postmodern a specific period in time (mid to late 19 hundreds)
"Postmodernism is generally defined by an attitude of skepticism, irony, or rejection toward what it describes as the grand narratives and ideologies associated with modernism, often criticizing Enlightenment rationality and focusing on the role of ideology in maintaining political or economic power. Postmodern thinkers frequently describe knowledge claims and value systems as contingent or socially-conditioned, framing them as products of political, historical, or cultural discourses and hierarchies. Common targets of postmodern criticism include universalist ideas of objective reality, morality, truth, human nature, reason, science, language, and social progress. Accordingly, postmodern thought is broadly characterized by tendencies to self-consciousness, self-referentiality, epistemological and moral relativism, pluralism, and irreverence."
and later
"Postmodernism is an intellectual stance or mode of discourse[1][2] defined by an attitude of skepticism toward what it describes as the grand narratives and ideologies of modernism, as well as opposition to epistemic certainty and the stability of meaning.[3] It questions or criticizes viewpoints associated with Enlightenment rationality dating back to the 17th century,[4] and is characterized by irony, eclecticism, and its rejection of the "universal validity" of binary oppositions, stable identity, hierarchy, and categorization."
It's fairly funny to say that as a joke in isolation. It's not funny IMO to put the word in the hype line of the project and then to later define that as a joke in the FAQ.
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.