Helix: a post-modern modal text editor
helix-editor.com
helix-editor.com
I use emacs not because I'm a neckbeard, but because I can script it to do whatever the hell I like. I switch to vscode when I want to do something my emacs setup isn't yet good for (like, working with Typescript).
On the flip side, I use sublime text as a notepad replacement because it's that fast. I still use nano as my default editor for commit messages. Sometimes I use vim because that's what I happened to type to open a file.
This isn't a comment on helix editor itself...just that, it's a pretty saturated space and I'm keen to see something as novel as light table play out again, but only more successfully.
Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years.
The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc...
No setup, no configuration, it's lightning fast and it just works.
I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
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.
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
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.
Anything else is a klundge.
If I have to thank anyone, it is Xerox PARC, TI, Genera, Apple and Borland, long before Microsoft mattered at all.
Yours was a very ungrounded commentary.
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.
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.
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.
> defining keybindings is much more verbose
This is why some use Vim? I don't see how this:
(define-key evil-normal-state-map (kbd "w") 'some-function)
nnoremap w :<C-u>call some-function()<CR>
> 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.
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.
https://gist.github.com/deviantfero/45b9354b433f44450de51c82...
make sure you add `:ensure t` if you don't have it automatically set to true.
* web-mode for general html/css/typescript/javascript editing
* tide + company for autocompletion
* flycheck for eslint support
* prettier for auto format on save if configuration is present
lsp is good for many other languages, but for javascript/typescript it's just not there yet
All these years and I was starting to believe I had imagined light table. How else could one explain no editors adopting inline, always-on evaluation?!
Lately I prefer purpose built IDEs for whatever task is needed. I’m over with editor evangelism. :)
Funny thing is a lot of the features are... just like a file system or Perl script to rip through and replace strings.
Large language ecosystems are only good when you don't need them. If they're just gravy, then life is good. If you need a lot of stuff to be moderately productive, that sucks.
LSP is the shining hope here, but you suddenly get into questions about your build environment, and that's another rabbit hole just to get decent completions.
What’s awful about VSCode? Genuinely curious. I use it daily and enjoy it. I love all the extensions I have access to.
> If you need a lot of stuff to be moderately productive, that sucks.
I don’t see why I would ever not have access to my extensions, nor is it very difficult to copy-paste my extensions.json file to a new machine and press “install all”.
- 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)
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.
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]
You don't work with Git as a DVCS? Or you work with Git and Emacs but don't use Magit!?
My point overall was that I see all of these as a collection of tools. Which one I choose depends a lot on context, and it's served me well to be baseline comfortable with all of them rather than depending too heavily on my emacs setup.
(magit is brilliant, but for some reason it's never stuck with me, unless I want to interactively stage a few specific chunks, and then it's much nicer than using the cli).
1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993
2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889
I'm just as surprised as you are that people do see it, that some people don't see it. I have no idea what the explanation is, but there's something radically different about me versus people who can tolerate VSCode's slowness (I'll use VSCode if I have to, but I'll avoid it if at all possible, just because it's slow).
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.
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.
^ 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.
this is what emacs is and what makes everything else feel so poor by contrast.
I think 4coder[1] might be close to what you want. It's been popularized by being used in the HandMade Hero streams.
In IntelliJ command B will take me where something is defied, be it system library or in code base. Not perfect but close.
I’ve not had luck getting vim to do this.
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.
VSCode load times are heavily correlated to what files I had open last and what extensions I have installed that trigger because of my previously opened files.
When I freshly install VSCode on a machine, it feels blazingly fast. A couple months later when I've loaded up a few linting extensions? Not so much. Of course, the power of these extensions is why I'm using VSCode in the first place. I've yet to see an IDE that can integrate these types of features and not slow-down in some aspect, and VSCode does seem to try to stay as lightweight as possible.
VScode also often has notification prompts when I open it, either from extensions, or as popups generated from the editor itself. This doesn't add load time perse, but it does add to my mental perception of it's load time.
I also literally only use VSCode when I have to work with Typescript.
Try SciTE if you want something super lightweight!
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.
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.
hx uses the Ropey crate (Rust library) to implement ropes: https://crates.io/crates/ropey
Boehm, Hans-J., Russ Atkinson and Michael Plass (1995) "Ropes: an alternative to strings", Software—Practice & Experience 25: 1315–1330, DOI: 10.1002/spe.4380251203, https://dl.acm.org/doi/10.1002/spe.4380251203 (cited 2021-06-01).
https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...
https://news.ycombinator.com/item?id=15199642
It's basically just two stacks of lines, where a line is an array of characters. One stack has the lines before the cursor, the other has the lines after the cursor (in reverse order).
I use emacs, but ropes are a much better way to go if you're starting from scratch.
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.
Generalizing even further, I wish there were a name for the generic type Bar<T,M> which is a b-tree of T-values, plus a monoid [1] M over T, where each non-leaf b-tree node stores the M-sum of its descendents [2]. This lets you quickly compute the M-sum of arbitrary ranges or search for an element by the M-sum of its predecessors. Ropes are essentially Bar<Char,(0,+)> so the monoid gives you the number of characters in a range.
If you let M=(0,max) or M=(0,min) you can get the min/max value in arbitrary ranges in O(log n) time. This is extremely useful for all sorts of things, from algorithmic trading (order books) to VLSI (plotting waveforms from gigantic simulations). If M1 and M2 are monoids, then $M1\cross M2$ is a monoid, so these "range summaries" are very modular -- you can mix and match them.
In the functional programming community there is a data structure called a finger tree [3] which are a specific case of Bar<T,M> implemented as an immutable data structure. Immutable data structures are nifty, they have benefits, but also costs. I don't know what to call Bar<T,M> implementations which are non-immutable (i.e. ephemeral or update-in-place) data structures.
If anybody knows of generally-accepted names for these (or wants to suggest some) please reply. I plan to add this functionality into (a fork of) LMDB.
[1] https://en.m.wikipedia.org/wiki/Monoid
[2] actually you want to store the M-sum of the descendents of each child node alongside the pointer to that child node
So you can have a string with millions of characters (a loaded document) and you can edit it efficiently.
https://github.com/xi-editor/xi-editor/issues/1192#issuecomm...
There's a way to search through rope chunks by using the low level regex-automata: https://github.com/rust-lang/regex/issues/425#issuecomment-7...
Alacritty currently does that to search over it's cells, I'd like to look into it.
It sounds like that offsets lot of performance gains the rust regex engine is supposed to provide, actually.
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
Great. So, what's the extension language? Rust is utterly inadequate to be a scripting language (if you have to recompile the text editor to reconfigure it, that's a non-starter).
VimScript sucks, but it's better than literally nothing. Emacs Lisp is weird, but powerful. Python is great and everyone knows it. Lua is small, simple, blindingly fast, and literally designed to be embedded in compiled projects.
Why is there no mention of extensions or extensibility?
I posted this on r/rust to get some feedback, definitely wasn't prepared to expose it to HN yet.
Basically, have you given thought into it, and see a way to integrate it in a efficient way, or come those thoughts from the potential ease of use with that and implementation details later?
In either case, I think scripting is very important to many people, so you probably should add a section about it somewhere, that it is definitely planned, open for suggestions (?) on the scriping language, and coming once the core features are stable.
Otherwise congratulations!
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.
The theoretic benefits of wasm I know, but I thought it would need more time, to be useful in that area?
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.
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.
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.
Here's a list of dyn langs that fit well with Rust:
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.
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 just could never get my head around the key bindings with kak.
For example, https://github.com/purescript/documentation/blob/master/lang... makes picking up PureScript as a Haskell programmer much easier than having to read all of the documentation and do the diff yourself.
If the old joke "plan9 is more Unix than Unix" is true, then "Kakoune is more vi than vim". There are similarities but it is a different beast.
Recently I've been playing with:
OniVim2: I'm not really sure what enhancements it has, but it does have a standard setup. Unfortunately, I'm running into some problem with my setup losing Python syntax highlighting. The ability to use VSCode extensions seems like a real winner, I've never been able to get into the weight of VSCode for my every day shell-oriented workflows. I don't program much, YMMV.
The Amix "awesome vim" setup. It is, unfortunately, TOO awesome. I set it up and some of my first movement commands were bringing up plugins (Ctrl-N and Ctrl-F). Didn't try it very long, it was a bit too much of a departure.
SpaceVim: I spent a while in this, it was working ok once I adapted a few things to it. It's a contender, probably behind Lunar.
LunarVim+NeoVim 0.5: This is looking promising so far, only used it a bit. But the TreeSitter plus LSP seems like a winning combination! Plus it works in the terminal, which OniVim does not. I do a fair bit of my (limited) programming via ssh from a chromebook (my couch compuer).
It doesn't seem to happen if I rename the file I'm editing to have a ".py" suffix. "foo" suffers this fate, "foo.py" does not. Submitted to Issue tracker, didn't look like it was already in there.
For me, using Vim keybindings and Emacs shortcuts is valuable because reaching for a mouse or navigating menus adds mental overhead. I view the moment-to-moment practice of programming as largely being an exercise in working memory. You’re trying to hold an abstraction in your head and implement it in an existing codebase that’s filled with other abstractions and interacting parts. Personally, removing a mouse from my workflow does wonders for ensuring that all my mental resources are dedicated to the task at hand. Going mouse-lite might save a trivial amount of time in the moment, but (for me) it makes programming more seamless and natural - which makes it not only more fun, but more productive.
I notice that when I am totally in the zone, I start to get frustrated quickly when tools take longer than normal or stop working correctly. You have a map of where you want to go and have the mental acuity to do it, but when tools get in your way, it takes you out of the flow.
I am a heavy user of shortcuts and a lot of the times I don't even know what the shortcut is, it's all muscle memory. Intent turns into an action and feedback is both tactile and visual and there is usually an easy way to get back of that also with shortcuts. Using the mouse in some scenarios is like looking through a keyhole. That is not to say that using the mouse is bad all the time, because the mouse beats shortcuts in other scenarios.
To me scrolling using the mouse scroll wheel or using keyboard keys are somewhat similar. Where the mouse workflow is eating the mental overhead is aiming a fly on a small landing 200th the size of the screen thousands of times or more daily.
As long as somebody isn't being a huge detractor because they refuse to use the tools everybody else on the team does I don't really care. Not even enough to engage in a discussion about it. Unless there are beers.
It just feels better for me to use. I do less squinting. :)
Try a text editor that does something for text editing, not scripting. Vim is an option. I personally used Kakoune with (almost) default config for some 3 years and I'm sure it saved me a lot of time. I never redefined default keys, they were good enough, I only added a few user mode bindings. (Although I felt a lack of some features over that time; Kakoune with no plugins is a bit too minimalistic.)
Recently I spent a few days setting up LSP and some useful plugins, now I'm going to forget about customization for few more months again.
With keyboard commands, I don't have to verify the accuracy of my mouse movements, and I don't have to react to the timing, location, content, and focus changes of UI widgets. I just press the keys in the right order. It requires so much less vigilance, it's a big relief.
When I have my hands on the keyboard I prefer to keep them there so I use ctrl - w to close tabs, ctrl-t to open a new tab etc.
When I have my hand on the mouse I prefer to keep it there so I used to love mouse gestures on older Firefox versions at least.
What do you mean with older FF? I've been using mouse gestures for decades (Opera anyone?) and I still use the same ones today on FF. Different extension/plugin of course, but works the way it should?
Use vim shortcuts in all the programs, so you never have to use the mouse or learn new keyboard shortcuts.
For Firefox something like Vimium works well.
But I’ve recently started using a combination of Neovim + treesitter + LSPs, and have found it incredibly powerful. Extremely responsive automatic compilation that feels instantaneous, good inline error messages, very good and fast syntax highlighting through treesitter... At what it does, I’d go as far as saying as it achieves more than any other IDEs I’ve tried. But of course, what it does is more limited.
At the moment I rarely even touch a mouse. I work primarily in Vim, with DWM as a window manager and a Vim extension in the browser. When I have to work in a different environment and use a mouse again, I find the constant context switching very distracting
- https://github.com/nvim-treesitter/nvim-treesitter#quickstar...
- https://github.com/neovim/nvim-lspconfig#install
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).
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...
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.
Deleting selected text works if you're in line-editing mode. It could be made to work in normal char mode, but it's a bit tricky.
Setting mouse-reporting by the application (emacs, vim, mc, etc) works pretty well, but it means the application has to simulate the selection (which may or may not be integrated with the desktop selection), context (right-click) menus, etc.
What causes RSI is mostly centered around tendon and their sheath tension.
For example, if you use a straight keyboard (don't! Ergonomic all the way!) that is raised toward you as opposed to away from you, keeping your hands on that keyboard for multiple hours in a row without ever reaching for the mouse is pretty much guaranteed to give you RSI. Reaching for the mouse will actually bring relief to your tendons.
Another keyboard habit that will put a great deal of stress on your hands and wrists is leaving the Control key at the bottom left of the keyboard. Typing a control key with this configuration will bring great stress on your pinky and other tendons in your hand.
Recommendation: map Control on Caps.
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).
NHS seems to back this as well: https://www.nhs.uk/live-well/healthy-body/tips-to-prevent-rs...
I built a trackball into my split keyboard and now I move it with my right hand and perform al clicks on my left hand side of the keyboard.
It was for me.
Most of my RSI was due to mouse usage. Moving to a thumb trackball did wonders.
> Why some devs try to avoid the mouse?
Because a keyboard is a much better peripheral to use when you're SSHing into your server. A mouse also has a much higher latency ceiling to execute most commands because it requires much more spacial awareness and brainpower to perform the task than just invoking the keybind. When you move your mouse to hover over a "send" button on an email client, your body is performing subconscious inverse kinematics to try to figure out how far to push the mouse, and when to stop. You can then only click once your mouse successfully lands in the designated area, at which point an additional 50-500ms of latency will ensue, depending on what UI framework your text editor is based off of.
The problem I see is: a lot of things that non-modal, GUI interfaces use mouse for can be better done with a keyboard.
For example, all sorts of drop-down menus and icons that you click on to launch programs. This kind of interface is inherently synchronous: the computer suggests, you pick. To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has (sometimes those actually make me forget what I was trying to do in the first place). I love the related metaphor ESR came up with in his Unix Coans [1].
[1]: http://www.catb.org/~esr/writings/unix-koans/gui-programmer....
Yes, especially when the suggestions change all the time, like when you go to click something and the icon is replaced by something completely different.
Here are some of mine:
M-. jump to source
M-, pop back to previous source
C-x f r Find References
C-x f i Find Implementations
C-x f t Find Type
C-x r v Rename Variable
C-x c a Code Actions
And a bunch more. I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
I don't know how fast you are with the mouse, but I've watched my co-workers jump into source and they can be so slow. I believe that I can answer questions I have regarding the codebase faster than they can, I don't have to rely on my memory for trivialities.
If you use Xref UI for "Find References/Implementations/Type", M-, should work in those cases too.
There is a more general question: how to "jump forward" again, without re-invoking the previous navigation command with the exact arguments. IDEA, already mentioned in comments, has key bindings for that.
There are several third-party packages which attempt to solve it as well. I'm using this one:
https://github.com/tcw165/history
You can also add "jump back" to your other navigation commands, even if they don't use the Xref UI.
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.
Better chords would be simple shortcuts for actions you do often (for example, "Go to symbol" in IDEA is \C-b).
C-x C-SPC will pop the global mark which, depending on what you've done in the buffer you're visiting, can pop you right back to where you started, functioning as the equivalent of M-,.
C-x b RET (C-x b with no input) should take you back to the most recently used buffer, which will usually be the buffer you started from.
Not built in: It's also fairly trivial to write some defadvice that stores your point (pre-jump) to a register, so you can jump back to the register with one key.
Using builtin commands, `C-x <left>` will switch to the previous buffer if you've jumped to another file, or `C-u C-SPC` (popping the mark) should work if you're in the same file. Not sure if this is sufficient for you, but it's a simple option to try.
Use IntelliJ, it's trivial to do that with `Cmd+B` (on Mac).
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 use the equivalent of "easy motion" aka "ace-jump" or "avy" under Emacs to move to any character on screen about 4 to 5 keypresses. Two to invoke that "jump to any character on screen" command, one to tell which character I want to jump to, then one or two depending on how many occurrences of that character there are on the screen.
I'll put it simply: my cursor is where I want it before you have even grabbed your mouse. And that is the reason why I avoid the mouse.
Same for "menus" and commands: shortcuts are faster than using the mouse. Once a list of potential candidates shows up, I use the same "select any candidate using the minimal possible amount of keypresses" command.
Unless you are typing one handed then there is inherent inefficiency in using a mouse vs. a keyboard command. Example: ctrl/cmd+c ctrl+v vs right click copy/paste.
Context: I've competed at a high level in CS/Valorant and voltaic platinum... mouse accuracy is not my issue.
Once you achieve relative fluency with using a given text editor or IDE then it is natural to gravitate towards using keyboard shortcuts.
Eventually, if you type decently fast (70wpm+, though that's slow by my standards but I'm not here to boast about the size of my epeen) many will find it frustrating moving between keyboard and mouse constantly.
In Plan 9's Acme, the mouse is your edit mode, the keyboard is your insert mode. I find I'm about as fast for most tasks in Acme as I was in Vim (after using it for years).
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.
What you say reminds me of synchronous-asynchronous analogy I just made in another branch of this thread.
Not needing to move my hand back and forth means not needing to make a context switch that puts a little extra stress into my workflow.
TL;DR: Moving away from the home row to arrow keys or mouse can cause wrist pains.
It would be a fork bomb, each process of which would kill a random pid in an effort to "subvert structures of systemic hegemony".
It would just display its own source code, but as it wished it was, and the result would not execute.
I don't want everything to look like a glossy magazine. Norton commander, power menu, borland c.. Just let me focus on some text.
A big value of (neo)vim is the lack of clutter and how easy it is to bring up and hide windows/buffers when I need them. Editors like VSCode and IntelliJ are just too noisy and gets in the way of the actual coding.
I know they can all be customized and configured to reduce this issue, but even then it still feels more visually cluttered and those windows usually end up coming back somehow.
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)
> thread 'main' panicked at 'index out of bounds: the len is 2856 but the index is 2856', helix-tui\src\buffer.rs:185:14
However, I'm afraid that there is no niche to be filled by yet another text editor.
(Also, even though I'm an Emacs and Acme user, the assumption that VimScript is bad for the battery is... weird. Mind to elaborate?)
Now there's a rare breed
For example, in vim I typically visually select a block and then run :s/foo/bar or hit > to indent etc
Is the flow on helix that different? Does it save a keystroke?
You can do the same things in vim, but there's no visual feedback: you have to undo and change your query. (Or do cgn, then . . . )
Here's a good example from vis: https://asciinema.org/a/41361
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.
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.
[1] https://github.com/magnars/multiple-cursors.el
[2] http://emacsrocks.com/e13.html
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)
[1]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Ov...
I wonder how these two compare?
[1] https://github.com/martanne/vis [2] http://doc.cat-v.org/bell_labs/structural_regexps/
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.
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.
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.
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)
> Post-modern?!
> It's a joke. If neovim is the modern vim, then helix is post-modern.
That's the absolute first question answered on the linked page.
FAQ
Post-modern?!
It's a joke. If neovim is the modern vim, then helix is post-modern.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.
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- completion - documentation help/hover - formatting - diagnostics - go to (definition, reference, etc)
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
I don't want to acknowledge that.
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 "
Now how would you achieve that in non-modal editor that also doesn't have this operation built-in?
I consider key remapping orthogonal though, as TeddyDD has stated, there's more to modal editors than just convenient shortcuts.
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"?
I think the issue is that you don't grok vim.
- 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
- 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.
$ target/release/hx .
Error: unable to create new appliction
Caused by:
Is a directory (os error 21)$ brew tap helix-editor/helix
$ brew install helix
This makes a lot of sense and I wish it were easier to do elsewhere. Probably wouldn't leave the vs code ecosystem for this alone, though.
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.
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.
https://plato.stanford.edu/entries/postmodernism/
https://www.wordnik.com/words/postmodern
https://www.thecollector.com/modernism-vs-postmodernism/
https://www.webpages.uidaho.edu/engl_258/Lecture%20Notes/mod...
Considering specifically that you mentioned Wikipedia: https://en.wikipedia.org/wiki/Postmodernism
"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."
Sorry, trying to make sure I understand. Am I to read this as saying you do find it somewhat funny but not very funny?
By the way, you seem to be taking more than just "slight" issue with such a silly thing. Very pre-post-modern of you.