Modeless Vim(github.com) |
Modeless Vim(github.com) |
This is heresy!!!!!!!!!!
Prev discussed: https://news.ycombinator.com/item?id=37171294
Similes and feels aside, I wonder which situations using vim in this way comes up that you wouldn't just use your preferred editor for. I know you can set an editor for things like git, but couldn't you use a GUI editor?
Have you tried remapping CapsLock to Escape so now you have a quick access to the most important key of your editor and can actually enjoy it ? Most vim users do it but they never talk about it and the beginners have no clue and suffer needlessly from this historical accident.
It is more like ... when I am writing I like to stay in insert mode as long as possible - and this is where I would put the 80% of the time in vim.
Once I put on my edit/refactor hat, that is where normal-mode shines :)
And of course, special shout out to visual-selection mode.
So it probably not for many people here. But I like it although I use vim as IDE when doing remote development.
I use vim and nothing about its commands are "cryptic" to me. You want to "go to definition"? You press "gd" as in "(g)o to (d)efinition". What's cryptic about this?
nano syntax highlighting is not as good as vim but it can work - the problem is in a lot of places there is nothing but vi
if you can configure vim you probably can also just install nano so it's unlikely this will get any use
I used micro for a while, which was quite pleasant, but didn't have all the LSP goodness.
There's always emacs -nw
Vim purports to be more efficient than other editors because it's a modal editor, but that's nonsense.
Thanks.
With your cursor in the same place, and pressing the same keys on your keyboard, Vim's response will change based on whether you are in normal mode, insert mode, visual mode, or whatever mode.
That's what they mean by modal. In insert mode, you have a ~104 keys that insert new text. In normal mode, the same ~104 keys execute editing functions.
The magical efficiency is because of its modal nature: Without buying new hardware, by switching modes (at a keystroke) you have a magic input device that issues ~104 different editing commands each with one keystroke, and hundreds more with two-key combinations (shift+, ctrl+, etc.).
I think there is something very clearly different in vim, as first time users must have it explained to them that typing `j` when their cursor is at the start of the code area will do very different things depending on the mode they’re in. It’s a paradigm not present in editors like VSCode. This difference is usefully characterized as “modal”.
In VSCode you have your editor program in the middle that does the editing things. Then when you invoke your search box it over takes the control away from your editor program and you are now in the search program which behaves however differently it behaves.
The first thing you must learn (to use Vim) is that it is modal. And this detail really tends to stand out when first meeting Vim. I think "modal" is a nice word to concisely describe and differentiate Vim.
Modes are even more foundational to Emacs than to Vim. A new user will encounter a dozen modes by simply starting to use Emacs for a few minutes. Every buffer has a major mode, and there can be many minor modes enabled per buffer or globally. The entire editor is built on a tree of modes, all inheriting from the aptly named Fundamental Mode.
At a basic level, each mode affects what every key does. The idea of keys doing different things in different modes is not unique to Vim.
Which just goes to show that Vim's definition of "modal" is somewhat contrived, as Vim's definition of "modal" applies to a very specific implementation of two to four modes (which coincidentally Emacs also offers multiple versions of, both natively and as third party packages to varying degrees of faithfulness).
Here modality mainly means "for the same element" (text area), and this is a very important and noticeable difference you can't eliminate with a search box
Once fluent in vim, I could literally get more done in the same amount of time, but YMMV.
My understanding is that Vim purports to be efficient because it lets users make precise edits (large or small) with minimal input.
The main difference is Vim's editing modes are imperative. You have to glue together small painful commands to do what you want. Modern editors are declarative - you say "I want to move this file" or "I want to rename this variable" or "I'll drag this split here" and they do the rest.
Painful?
Physically or mentally?
Physically I find Vim to be pain-free. I've studied and I practice good typing form, which is important—I would look there before blaming any physical pain on Vim's commands.
Mentally I find Vim's interface to be beautiful. Learning it gives your mind an amazingly coherent structure for thinking about the process of text editing.
Those are imperative actions rephrased to make an artificial distinction (and I rename variables in Vim with gR). How high-level the available actions are and being a modal or non-modal editor are orthogonal.
An Emacs "mode" corresponds more closely to what Vim calls "plugins" (Emacs's "major modes" are like Vim's "filetype plugins", and Emac's "minor modes" are like Vim's other "plugins").
Vim's modes are more foundational in the sense that all Vim plugins are structured and organized in terms of the same set of modes. The core of Vim is the modes (insert, command, etc.), which are then customized. Emacs calls the customizations themselves "modes".
I don't consider Vim's definition of "modal" contrived, and I don't consider Emacs to be "modal" in the same way (though you can of course customize it to be).
I just installed nano-7.2-1 and opened a HTML file with `nano test.html` and it opened without syntax highlight, I can see the point in authors endeavor if syntax highlighting out of the box is what they're looking for.
With this, I've passively memorized far more advanced motions in the last 12 months than I did in the ~8 years before that. And since Helix is a vim style editor, many of these motions also work in vim!
I feel like Helix is the perfect editor for people like me who know just enough vim to be comfortable, but never got very deep into customizing or muscle memory with advanced motions. Helix does some things differently compared to Vim, which I hear puts off some more advanced Vim users.
The built-in LSP & highlighting support with a stack-based "jump to symbol" and keybinds to traverse the stack also perfectly maps to how I want to navigate code, it has made me far more productive than ever before.
I'm not affiliated with the project myself, I'm just super happy I found the perfect editor for me :]
It's the Neovim flavor that Shell Bling Ubuntu [1] installs, though, so I'm biased. I've been considering including an option to install `hx` as well in there.
The customizability/hackability will come later, they're working on extension support plus other stuff, but I think for most of their users, this isn't the number 1 priority.
I guess their target users are those who just want to get up and running on a modal editor without spending too much time in Lua or trying to get plugins setup.
> There’s two prototypes we’re exploring that could potentially exist side by side: a typed list/ML-like implementation for scripting and a Rust based interface for things that require performance. Could potentially run both in wasm but I’m personally a bit unhappy with how big wasm implementations are, easily several orders of magnitude compared to the editor
https://github.com/helix-editor/helix/wiki/FAQ#how-to-write-...
So they're not avoiding making it extensible on purpose, seems they haven't found the right way to do it yet.
Of course GUI apps have had pop-downs from the File-Edit-View-... row [since forever?] so that things like Alt+F will show contextual actions. But at least in the Emacs community people get blown away when someone makes such a basic addition.
C-h k to pull up the help for a key combination
C-h f for a function
C-h v for a variable
C-h m for currently active modes
C-c C-h to pull up every key combination that starts with C-c
I am sure you can set up vim to be very much the same, but that is a significant barrier to getting started. I have tried and had problems getting it as I wanted.
The problem is that the keys are different from vim so the muscle memory does not work across the two.
I would really like to have a more lightweight editor with the same key bindings for quick edits on small files.
I'm also restarted my journey with neovim after helix.
Actually lazyvim convinced me to give another chance, because the community packs and mason makes lsp so convenient!
Astronvim is also a good contender, but I broke it so many times trying to customize.
But come on! Learning vim bindings is one of life’s greatest pleasures. Once you’re hooked you’ll hate any non-mode based editors.
I'm definitely going to compare this against micro.
vi and vim have modes because they were created in an era where computing and terminal capabilities were very limited and even when the terminals could support interactive editing, it wasn't expected. They had very low expectations. They were used to things like 'ed'.
The religious beliefs that programmers have about vim are a case study in why I believe that AI will easily take control of the planet in less than a century.
That sentence is questionable in multiple ways.
Anyway, I will definitely try this thing out. Hopefully I am not too lazy to keep installing it. That's what happened with the last one of these.
that's the whole point. it was designed for limited terminals and high latency, very slow serial links. that means when you learn it and all of its shortcuts and you have a fast and modern terminal, you are able to edit at ludicrous speed.
it's like training at altitude or running with weight belts for editing text.
I never ever got this argument for Vim.
I don't spend most of my time slinging around huge chunks of text or repeating commands like they do in YouTube videos where Vim pros flex their skills (to extend the fitness metaphor).
I spend most of my time thinking about code design, reading documentation, writing plans, discussing stuff with my colleagues—editing, writing code is maybe 30 – 40% of my time, at best. I also code fairly slowly anyway.
Funnily enough I think I'm decent enough with a good touch pad, so I can avoid the whole 'click-drag' dance when I have to use a mouse.
That being said, I do consider myself too stupid to use Vim beyond the simplest commands—I know how to change modes, save, and exit.
I mean, maybe 5% faster. Sure. Maybe. But at what price? _At what price, I ask you??_
vim was released in 1991. Same year linux kernel started and Apple PowerBook came out. Limited terminal capabilities is not the reason vim is modal.
Meanwhile, in GUI land: here’s fifteen screenshots carefully manually highlighted which shows you how to change your language to Turkish.
Regular GUI apps are just too rigid.
- For Fuzzy file search you will need to add Telescope plugin
- For File Explorer, you could use Neo-tree.nvim
though, like any project, there are probably bugs at the edges... not sure what bugs you are experiencing however.
ahh yes, the central brooklyn coffee shop as existential bus stop school of computering. "oh, you're 38 too, well then what are you doing with your existential crises?" "well, when i'm not working on my book, i like to think about code design and discuss stuff with my colleagues while listening to instrumental remixes of 90s punk and indie rock classics. my preferred languages are ocaml, erlang and ruby, but usually i tend towards microsoft visual foxpro for professional efforts."
I'm in my 20s, find coffee shops extremely overpriced, have never set foot in New York City, don't listen to much music at all (and if I do, it's classical and Baroque from the 1700s), and usually write in C# or C++ (both in Visual Studio).
Definitely worth it.
With Vim, I don’t think the commands are quite as intuitive (this might be a skill issue of mine), but I do think I am faster without a mouse because of fewer movements required (having to grab my mouse, move it to where I want, click and then move it back to the keyboard vs. just typing a few letters).
In Vim, I enjoy the process of text editing itself (in addition to any joy derived from the substance of the text edited).
That said there's something absolutely defiling about this. It's like installing a V8 in a Tesla, or replacing the pumpkin in pumpkin pie.
I love that it will make VIM more accessible for more people, but I hate how they do it. Kudos to the author.
Most pumpkin pies are actually made with butternut squash and other similar squashes, not pumpkin.
https://en.wikipedia.org/wiki/Cucurbita_moschata
https://www.thekitchn.com/whats-actually-in-your-canned-pump...
Some pumpkin, blended into a paste, some brown sugar, an egg or two, some heavy cream and some cinnamon and crushed cloves and you have your pie filling.
Here in the Willamette Valley of Oregon, we grow a lot of crops for seeds, of which various squashes are some. It’s amusing to see the first time, but squash grown for seed is typically just shredded in the field, with seeds collected and the flesh tossed out over the field. Results in a lot of “wtf are they doing” among those unfamiliar, because it looks exactly like pumpkins were grown just to immediately destroy them.
https://www.snopes.com/fact-check/canned-pumpkin-isnt-actual...
[I'll just add one more note, not mentioned in the article, which is that typical Jack-o'-lantern pumpkins are quite awful for cooking. Much worse than any canned pumpkin. If you want to cook with fresh pumpkin, research the varietals that are known for good texture and flavor. Don't grab a carving pumpkin from the pile.]
As Wikipedia notes:
>The term [pumpkin] is most commonly applied to round, orange-colored squash varieties, though it does not possess a scientific definition and may be used in reference to many different squashes of varied appearance.
If the article is simply intending to say that it does not usually come from squashes that are orange, oblate and ridged, then that's fair. But I don't think it's mostly butternut squash, and I don't see why manufacturers would try to hide using the most popular variety of squash.
And then you have sweet potato pie...
(Chalk and sugar in the same sentence just made me think of Macdonald's milk shakes.)
Everywhere else, when you type vi, you get vim. Some neophile Linux distros provide neovim instead.
Regardless, vi and vim (and neovim) are the same in basic operations.
It's still functionally correct that "vi is always installed" and no additional action is necessary for basic text editing.
Doesn't most major distributions alias vi to vim nowadays? I think I've also come across vi being aliased to vim-tiny if I remember correctly.
Same with this vim: if you just need an editor that is recognisable and "not weird" then this modeless vim might be useful; though why not just install nano, pico, gedit, notepad++ or even notepad.exe?
“But your fingers aren't touching the strings!”
I taught myself vim by setting the vim cheat sheet to be my terminal background, though I greyed it out slightly so it didn't obscure what I was typing. Once you have that there are only a few phrases you really need to know: "+p, "+y, "+d to access the system clipboard, :split and :vsplit, C-w w to switch windows, and g C-g for word/char count.
https://www.glump.net/_media/howto/desktop/vim-graphical-che...
What exactly do you hate?
The site says:
> > Ctrl+S to save, select text using Shift+←/→/↑/↓, and copy/paste using Ctrl+C/V.
I haven't setup Control-S, but I have very similar bindings: Shift and arrows for selecting, then Alt or Control-Shift for moving the selection around, as shown on https://raw.githubusercontent.com/csdvrx/CuteVim/main/record...
Also, like the author I have a shortcut to change themes (F9) and another to toggle invisible chars (F8), and I try to use the top of the screen as much as possible (I show the offset in hex, the row and column position etc).
I like how vim is modal, but some Windows shortcuts (like Control-C) just make too much sense to given them up on Linux: I have put `stty intr ^X` because using Shift-Control-C to copy from the terminal was way worse.
Having a few chording shortcuts give you the best of both worlds!
BTW, all of the other shortcuts proposed on this site make a lot of sense to me: I do expect Ctrl-F to search, and Ctrl-T to open tabs, I think I will copy a few :)
https://unix.stackexchange.com/questions/12107/how-to-unfree...
Ctrl-C does work in the GUI. That said, one thing I like about Linux is being able to highlight text using the mouse and then pasting it by middle-clicking. I don't have to interact with the keyboard at all to copy and paste text that way.
Not expecting anyone to agree, but this is how I feel when using minimal shells that do not implement vi editing, e.g., set -V or set -o vi. Busybox/toybox is one example. In the aggregate, I actually do more editing on the command line than I do in vi. If the shell is permanently set to emacs-like keys and editing then I am constantly switching back and forth to "vi mode" everytime I edit a text file and return to the shell, i.e., nonstop.
Maybe putting diesel generator in a Tesla so you can use it even though charging is not your cup of tea.
"easy vim", aka evim, or "vim -y". see "man vim"
That said, if modeless editor you are looking for... then vim is not the editor you're looking for. It goes against what vim is, and hamstrings it. Learning vim is a journey, and once comfort sets in, you will understand why, why vim.
Of course, I did have to google how to quit easy vim.
For those who know how to quit vim, but want to experience "how do I quit" again, try running `:term`.
cntrl-o --> to get to normal vim mode
then exit as usual
Not the first, not the last hacky project. Saying that it goes against what it is makes me think of JS V8 being used outside of browser.
Perhaps there are good reasons for not having modeless vim (or server side js for that matter), but the industry overwhelmingly accepts good enough solutions, with good enough results.
Vim go brrrrrr, I guess.
Remap the Escape key to CapsLock else you will never like vim (provided you are a normal person)
It's the most important key and you should punctuate all your inserts with it. So it'd better not be the key that's the furthest away from your fingers. The reason that's the case is an historical accident.
Don't be a victim. Remap.
P.S : Yes, I know about people using Ctrl+[, or Ctrl+C, I know you got used to it but one gets used to anything, it does not mean it's good. A weird combination isn't great and Ctrl + C has some quirks --> https://vi.stackexchange.com/questions/25764/use-control-c-i...
P.P.S : Yes, I know about `jk` it's clever ok but my mapping is system-wide and now I enjoy Escape being at the right spot for bash, zsh, fish, gdb, firenvim vim modes at no configuration cost.
I'd recommend checking out `vim -y` as well. (And once you try _that_, you'll likely have a question, the answer to which is Ctrl-l.)
To others on this thread decrying this as heresy: leave 'em be. Let everyone use whatever editor flows works for them.
Programming is hard enough without having to conform to other people's beliefs of how _you_ ought to use your own editor!
I’ve always wondered how different Unix/Linux would be today if decades ago a Common User Access (standardized menu system like FILE | EDIT | etc) had been defined for TUI apps (like how it was for Windows & Mac OS).
Imagine VI & EMacs having the same key bindings due to standards.
https://sqlite.org/hctree/doc/hctree/doc/hctree/index.html#s...
But in the precambrian era you needed to know about ^ to edit a specific version of a file, because diffs were tracked.
They're both wonderful and amazing and can handle anything, because they had to handle everything when filesystems were like a brand new invention and nobody really knew what was good or bad, so they threw everything in.
Tough to get standards before standards exist.
It doesn't make sense to change Vi/Vim/NeoVim keybindings because they're so convenient, composable and easy to remember.
And everything was better, the users adjusted, nobody ever looked back and we were all better off.
Sadly the memo never reached the Unix world, and those terrible 1970s are now enshrined as holy writ.
Worthy attempt, looks cool, but I'm still stuck with having to learn the basics of moving a cursor around reasonably :(
> Q: Why don't you just learn the vim commands?
> A: I did, but if you don't use vim regularly, you keep forgetting them.
The basics are only useful in vim, and editors that you force into vim mode. Other places one types text into which use the same conventions absent in vim: browser input fields, the url bar, email, office software, random input fields in games (I've seen single file libraries that obey the same conventions of moving across words that you get in office), publishing software, chat clients... Vim is the only outsider, and because I only need it rarely, I forget things and I accidentally use the shortcuts from other software which sometimes break things.
I know enough vim, but I keep using conventions from other software out of habit, and shortcuts do other things. Vim is great editor, but a horrible thing to use by default simply because it was made before text editing ux got standardized.
As the article says, if you don't use it regularly you'll never learn it by heart, and Vi doesn't have any affordances that will remind you of what you learned by recognition instead of recall.
> This configuration is not meant for the aficionado who prefers vim over graphical editors. This is meant for people who normally use GUI editors (like VSCode), but sometimes need an editor that can run in a terminal.
I think it's unrealistic to expect users who only occasionally use vim to edit the odd config file in the terminal to fiddle with a custom vim setup.
If you're really looking for a good editor that behaves like GUI editors I really recommend micro [1]. It has mouse support by default, syntax highlighting for many languages out of the box, most keybinds are the same as in GUI editors and copy/paste works like expected.
But since I was logging into different machines all the time I soon decided it was better to just use vi the way it came out of the box, modes and all. That philosophy has served me well over the years.
So I am definitely going to try this.
I'm not going to make the same mistake of judging this. If you are someone who has always hated vim and never want to touch it, go for it, this might make your day easier on some machine if you can load this repo really quick (although as others have noted you would need to ftp the repo onto a machine over ssh to make this work).
As someone who is a neovim enjoyer, you are allowed to not like (neo)vim, I don't want to hear you bitch about the editor you don't want to use. If you're a vim user who has this bad habit of shaming people for their editor choice, STOP! It gives us all a bad name whenever you judge people just because they don't enjoy the vim life, just like emacs it's closer to a lifestyle than a tool and if people don't want to invest the time they have the right to make that choice.
The world is no longer dominated by vim and it really has become an optional skill for new programmers.
That seems insane to me. A few years ago I decided to "get good" at vim, and I learned a handful of new tricks. A few new ways to select text, macros, new ways to navigate, etc. But before that, I was perfectly capable of navigating documents and editing them with the arrow keys, just using "i" and "<Esc>".
It seems like the only person for whom this would be helpful is someone who has no clue what vim is, and doesn't understand modes at all. That kind of person is likely not going to be able to even find this repo, let alone install the configuration.
Major visual difference would be that whatever the editor font settings dictate, would apply to all the UX not just the text-editor tabs. But that, who would even mind.
The extensions compat would have to be NodeJS-based I guess, but the rest wouldn't have to be written in JS/TS I suppose..
Plenty of us are "happily Stockholmed" by the overall DX of VSCode but were there a Electron-less but otherwise 99+%-compat-and-keeping-up-with-vsc rendition (TUI or native GUI), we'd jump on it nonetheless.
Me, I first wrote programs in AMOS Basic, which was certainly not CUA either (I remember shift-backspace erased a whole line, which could be really frustrating). I've done enough learning of tiresome nowhere-else UIs... back when I played Nethack, I would of course insert a big S anytime I tried to save in another program for a while. Nethack was at least fun enough to make it worth it.
VSCode is fast for stuff I do in editors which is slow elsewhere (thanks in no small part to Mr. Gallant!) and better at doing anything an IDE used to do, than most IDEs. Does vim support full-featured language servers/tree-sitters these days?
It's not about building an ideal piece of software, Vim's model of syntax highlighting is probably not the ideal model for a piece of software, ideally you'd use per-language highlighters that are hosted separately. But those highlighters aren't installed by default, and Vim is. So yeah, use the tool that exists and make it usable. Yes, you could install a Vim alternative, but this is not about making an editor to live in or building a perfect system.
So I think this is great, I don't think it defeats the purpose of Vim at all. I say this as someone who set up Emacs to use Vim keybindings and who thinks the modal editing and composition combined with macros within Vim is basically the biggest selling point of the editor. It doesn't matter what Vim "should" be, this is an easy way to get a ubiquitous text editor to be more usable. Not perfect but a one line installation on almost any Linux box with Internet access, so it solves a real problem with relatively little downside in a quick and easy way -- real hacking at its finest.
It might be useful to compare and contrast this to Vim's easy mode (vim -y), but this project is also 2 years old and I don't know what the state of easy mode was back then, and that kind of comparison might be overkill anyway. I like modal editing, so I'm not as familiar with easy mode so I'm not sure what the comparison would be. I know at some point it started defaulting to a graphical session because quitting out of easy mode in the terminal was giving people trouble. But possibly something to look into, maybe, depending on the system you're using if you need to use Vim but can't customize it.
However I also have some customizations myself to use some kind of modeless commands to quickly select or move around, but I still model things around basic vim syntax and its fantastic move keys which keep me in the home all the time (e.g. Using alt+ghjk from insert, I move around, adding shit I select, without having to switch to move or visual mode)
I gave up and switched to Sublime Text, and haven’t looked back. The advantage of an “in-terminal” editor is really just not having to break flow to edit a text file, and Sublime is so fast and simple that it works great for editing files outside of a project. Even over SSH (with RemoteSubl) or for writing git commit messages. I can share config details if people are interested.
I've half-learned vim and like the idea of it, but frankly I also use so many other "regular" programs that at times I wish I never learned vim.
I'm really hoping this is more-or-less what I think it is.
I'd never heard of OP's, I'm sure we can work together to share ideas.
> Vim itself already has support for something similar in its optional mswin.vim config file. However it still assumes the necessity of Normal Mode and such heritage as SHIFT+INSERT-style combinations. This plugin however, attempts to avoid Normal Mode unless absolutely necessary, say for interacting with the NERDTree buffer, wherein Insert Mode has no purpose.
I think this is great advice for EVERYONE, vim user or not. Someone else made this suggestion on HN some 8 years ago and I haven't looked back since.
CapsLock is essentially useless for modern computing needs, but having a No/Cancel/Quit/Esc button immediately under your left pinky is fantastic. Your brain will get used to it in a day or so, give it a try!
But seriously, I have hitting escape muscle memory engrained, I cannot remap it to any key because I won't ever think to hit capslock even if it's ergonomically "better"
...and to try and avoid this being perpetuated as it always seems to: ctrl-c is NOT the identical to escape. Notably is doesn't trigger InsertLeave which means a handful of plugins won't trigger.
I think your advice can be summed up to: Remap esc to something more convenient. My capslock key is tap for escape and hold for ctrl. I use jk for escaping insert mode because why would I want to be a "victim" who has to stretch their pinky even one key when my fingers are always going to rest on JK? ;)
I guess I'm not a normal person then? Never bothered doing the remapping and I've been an enthusiastic Vim user for a decade.
Most people are not believers and when they find something inconvenient they abandon it. Most people do what most people are doing :-) That's not the case for me. I am a believer, I use Firefox, Signal and vim, not Chrome, WhatsApp or VsCode. And I like it that way. The problem with being a believer is that you tend to downplay issues and that can bite you sometimes. I know because I have been been bothered by Escape being too far away for one whole year and use the weird combo instead. Surely there was a good reason for things being that way but I finally asked it turned out there was not.
Maybe you are the rare person that has very long fingers or whatnot and it's not inconvenient for you but you most likely are a believer :)
Also doing embedded stuff, I find the caps lock key nice for when typing out a few defines or macros.
Additionally, I use Ctrl outside of vim very frequently as I keep my terminal key bindings native, which means all of the command line control patterns use Ctrl (jump to front, jump to back, cut (forwards/backwards), move by word, reverse search, etc etc)
I'm still of the opinion that Ctrl+[ like the OP said would be mentioned is the best because (1) it's native and (2) it uses both hands so it's almost as fast as hitting a single key and requires no hand contortion.
- 14 year exclusive vim user
Remapping takes less than 5 seconds in MacOs and Linux. 2 minutes in Windows. And you only have to set it up once.
Also my left pinkie never misses CapsLock and I don't even have to think about it. Can't say that's the case for Ctrl+[ which I have used extensively for one year. I am really happy I switched.
I have taken to remapping it to a function key, moving caps lock to function+shift. Function+tab is mapped to escape, a combination I can easily press with my pinky alone.
This allows me to map a lot of the keys that would require moving my hand to function+[alphanumeric key], function+i is insert, function+u is page up, function+j is page down, function+r is home, function+f is end, and other such combinations.
I use a keyboard that supports QMK, so all of this customization is on the keyboard, but this could probably be done with software running on the computer, like AutoHotKey on Windows.
Master the default behavior of a tool, and then improve your effectiveness with customization, but not so much customization that you can no longer use the tool effectively in its unmodified state. Sometimes you have to use other people's tools, and it's important to still work effectively when you do.
I used to manage complex "dotfiles" and scripts to configure a new computer, etc. I still technically do, but they are much more simple now. I just don't want to spend my time on configuring the stuff anymore, and appreciate the out-of-the-box experience much more. This by itself became a criterion when choosing new tools, frameworks, etc.
- Easy-mode as sensible-editor
- runtime mswin.vim, set nocompatible, etc as the skel vimrc
These are easier to change than driving new users to Google “how to exit vi”.
But remapping Ctrl-O, like this post, is a breaking change.
[1]: https://github.com/SebastianMuskalla/ModelessVim/blob/main/L...
We now have actually portable executables (multiplatform, multios) that contain their own config file: you can just scp 1 binary and be done with it.
After starting the (neo)vim tutorial, all I could think about was if people who "learned" vim never learned how to edit text in a normal text/code editor.
And I don't mean this in an inflammatory way. I mean:
hjkl = Arrow keys
b = Ctrl + Left
w = Ctrl + Right
df<space> = Ctrl + Delete
$d = Shift + End, Delete
dd = Home, Shift + End, Delete
2 = just press the keyboard command twice??
ddp = Alt + Down
ddkP = Alt + Up
The more I read the tutorial the more I felt like... do you not have arrow keys? I mean this literally. Is your keyboard just esc to f12 and there are no arrows or the numpad and it just ends there?
I do understand some good points of vim, like how explicit it is. There are many code editors/IDEs out there and sometimes how they treat Ctrl+Left/Right has subtle differences, e.g. ending the "word" in "-" or "_" or stopping before or after spaces. But most of this stuff is (or at least should be) configurable. But that's about it.
I mean how do you even use the numbers? Who looks at code and says "no, this should be exactly 8 lines below this one." I just Alt + Down until it's right. I'd spend more time trying to write the command right than I'd spend just pressing the keys multiple times.
With relative line numbers it's really easy actually. Typing dd7jp takes less effort than pressing alt + down multiple times and I have hard time believing you'd be make this argument if you were comfortable with modal editing.
In fact, none of the alternatives you listed seem attractive if you're accustomed to modal editing. How is Home, Shift + End, Delete a good alternative to dd? So much movement to do a simple operation.
I would highly recommend you giving it an honest try and if it doesn't work, you can always go back to editing the traditional way but once it clicks, "the old" way feels super awkward.
dt/ Delete text to the next slash.
di( Delete text inside parentheses.
vi{y Select and copy code inside braces.
]] Jump to the next function.
)) Jump to the next sentence.
Ugh, they really are much less aesthetic than a nice plump orange one. This feels similar to the childhood realization that regardless of the name or the box color there's not really much strawberry juice in anything; it's all apple and pear.
More importantly for me personally, is that VIM is a lot more ergonomic than the “standard” Windows-style text-editing ux you prefer. It played a crucial role in helping me (mostly) recover from severe repetitive stress injuries. Many, many others are in the same boat.
I wish I’d started using it in earnest years sooner. IMO, it’s worth learning even if you never have wrist problems. I write, and especially edit, blog posts faster now with it than I could prior to injury when I could type faster.
For the same reason I can never even think of writing in ahk, awk, bash, scss and other arcane syntaxes without examples and snippets. Because the usage is occasional.
And I definitely hit Esc and lost my input too many times. Of course the apps that don’t ask for Esc confirmation are to blame, but they exist.
Interestingly, I expected them to go easy on pretty much anything
I use jk to get out of Insert mode on my local machine, and ctrl-C on remote machines where I don't have my .vimrc.
just embed your own vimrc with zip following the instructions
for others, see https://cosmo.zip/pub/cosmos/bin/
https://github.com/teslamotors/buildroot/tree/buildroot-2021...
I just instinctively did it to see my motion and it's an awkward feeling for me to move my left pinky over to the capslock key, definitely something I have to be mindful of doing to make happen and probably will take a long time for me to get used to.
Meanwhile, I actually extend my ring finger up and barely touch the escape and move it back down, all of that is very comfortable for me and I can do it without looking 100% of the time and never miss it.
Or looked it up once and probably now forgotten it.
Also regex expressions are not vi expresions and have wider applications so author might use them regularly.
So nothing here suggest that the author can remember vi.
But frankly I don't use Ctrl that much. Ctrl + L/K in Firefox (I use vimium but I prefer the native bar) And I have Ctrl + J/K to switch terminal tabs In vim I only rarely use Ctrl + I/O
Add this config to ~/.config/karabiner/assets/complex_modifications/custom-capslock.json
{
"title": "Change caps_lock to Esc and Control",
"rules": [
{
"description": "Post Esc if Caps is tapped, Control if held.",
"manipulators": [
{
"type": "basic",
"from": {
"key_code": "left_control",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "left_control",
"lazy": true
}
],
"to_if_alone": [
{
"key_code": "escape"
}
]
}
]
}
]
}
$ setxkbmap -option caps:ctrl_modifier
$ xcape -e 'Caps_Lock=Escape'
pgrep xcape >/dev/null || (
setxkbmap -option caps:ctrl_modifier
xcape -e 'Caps_Lock=Escape'
)I consider it indispensable.
Not quite the side of my palm, but the joint where my pinky meets my palm. My hands are relatively large, dunno if that's relevant.
I should put more work into buying a keyboard that it does work on, I think using my finger for Ctrl might be starting to cause RSIs in my middle-aged hands.
I guess I'll also add that for me it's a bigger deal when gaming than when using CUA. That Ctrl button is the one true place to put crouch, dangit.
No you weren't. To use your style, if YOU want to play along and be pedantic, then your edit wasn't about North America, it was about just the U.S. and Canada.
I don't think anyone needs (or even wants) the terminal to freeze on such a common shortcut in 2024.
Personally, I have reclaimed Ctrl S for word delete (usually done by Alt-d)
I find it rather useful to keep important output of programs on the screen when it is impossible (or I forget) to pipe them into a pager.
{
"title": "Hold z or / for control",
"rules": [
{
"description": "Hold z for control",
"manipulators": [
{
"type": "basic",
"from": {
"key_code": "z",
"modifiers": {
"optional": [
"any"
]
}
},
"to_if_alone": [
{
"key_code": "left_control"
}
]
}
]
},
{
"description": "Hold / for control",
"manipulators": [
{
"type": "basic",
"from": {
"key_code": "/",
"modifiers": {
"optional": [
"any"
]
}
},
"to_if_alone": [
{
"key_code": "right_control"
}
]
}
]
}
]
}Try with pumpkin, nutmeg, cinnamon, and cloves… it’s that old timer pumpkin pie taste.
This "tradition" of using Butternut Squash instead goes back to the 1930s at least.
In the southeast coast of US, if you make a “pumpkin pie” with squash, you won’t be invited back next year.
If you learn Vim you’ll have access to Vi and Vi-like interfaces in lots of other software including terminals, database clients and everything that uses readline.
From my experience anything with "vi navigation" basically just means using the home row keys for navigation + modes. So I haven't come across many interfaces yet where the verb order differences between helix/vim come into play.
In mpv I use gg/G to getting to the beginning/end of a file.
Many terminal file managers use vim binds or idioms (such as x for delete, marks, etc).
That was more convenient for me, especially as I remap my caps-lock key to CTRL system-wide.
And, agreed, macOS' use of shortcuts is fantastic and I wish I could replicate it on Linux.
gsettings set org.gnome.desktop.interface gtk-key-theme "Emacs"
xfconf-query -c xsettings -p /Gtk/KeyThemeName -s Emacs
I also want to use Command (Super or Hyper?), which really improves keyboard shortcuts. Command + left/right = jump to beginning or end of line, Option + left/right = jump to beginning/end of word. I know you can do the same with Control + Shift, but some apps don't support it. Plus Cmd+c/x/v for copy/cut/paste works fine in terminals, I don't have to remember to "code switch" my shortcut "language". Cmd+Backspace deletes the whole line, etc etc.
setkbmap us -option ctrlL:swapcaps -option compose:rwin
You can place that command at XFCE's startup settings for applications.
My `stty intr ^X` disagrees
I've made Ctrl-C do copy paste in the terminal, even in vim, with a special function for wayland:
vnoremap <C-C> <CMD>call WLCopy()<CR>
In the UK and EU, coffee cake is cake with coffee.
Likewise tea cakes in the US are cakes made with tea and tea cakes in UK and EU are cakes to have with tea. So…
Not a lie, just a Spider-Man meets Spider-Man moment when you learn you can actually make coffee cakes with coffee (or espresso) and you can make tea cakes with tea (I prefer oolong).