I don't have anything against all these "default configurations" for vim (even though I'm struggling to imagine, why the kind of person who doesn't want to configure vim himself would choose vim in the first place), but this line just made me chuckle.
Before I tell you how, I want to tell you the 2 reasons why I don't like splitting with Ctrl-W: 1) because I think Ctrl-W should the same thing as on readline or emacs 2) because even if existing uses of Ctrl-W were removed from the picture, splitting with Ctrl-W use 3 keys. Why use 3 keys when you can use 2?
I like short sequences, and chording, and there are many 2 keys sequences that are free to use if you know where to look for: I prefer to use what can only be done with MOK sequences, because these sequences are more likely to have a degree of redundancy.
For example, Ctrl-I duplicates Tab: if you use a MOK you can have Tab do something (indent) while Ctrl-I does something else (jump in the edit history). Ctrl-I is "free to use" without limiting function, because keyboards generally have a Tab key. These are "sensible defaults", because most people do that in other editors.
My splits are mapped to MOK sequences (Ctrl-; Ctrl-' Ctrl-\ Ctrl-/ Ctrl-`) but I've thought it may not be a good idea because 1) it's more unusual and 2) I rarely use split in vim so I don't think I can make an educated choice besides having Ctrl-T start a new tab (like it does on a browser), so I've left them out: I've just left the "echo" part.
If splitting is important to you, and you want to try out these MOKs, search for "echomsg.*was hit" and bind your windows split around line 256. I would like to know what you think of these. I may trust your judgement more than mine, if only because I don't use splits much in vim.
If you think these MOKs does the job for you, and if you think splits are important, let me know and I'll add the split mappings to the defaults for the next release (EOY, it may include a CuteBash)
I'll be honest, I just took a bit of offence to the "sensible defaults" wording.
I think there probably are some things you can do in vim that the vast majority would agree with. But I think you've gone a wee bit too far into just making it your preferences. I totally get your logic by the way, I'm just not convinced it's strong enough to be considered a "sensible default" ;).
You're not wrong that it's 3 keys instead of 2, but I find it makes sense. Ctrl-w puts you in (w)indow management mode and then you split (v)ertically or (h)orizontally. I don't split often enough that it matters. I do remap ctrl-w+h/j/k/l to just ctrl+h/j/k/l since I do move around in my splits that saving a keypress does matter.
> My splits are mapped to MOK sequences (Ctrl-; Ctrl-' Ctrl-\ Ctrl-/ Ctrl-`)
They make no sense to me. I have no idea what any of those key combos do.
FWIW, I see you said that it was a bit of a joke in another comment. Maybe I'm just grumpy because I'm sick during the holiday season :(.
Also for what it's worth, the general idea is super cool. I love seeing all the cool things cosmo enables
> I'll be honest, I just took a bit of offence to the "sensible defaults" wording.
Then I have to apologize for the bad joke.
I wanted to show cute and inspiring things, that would make people smile during the holidays, not offend people with bad jokes.
> They make no sense to me. I have no idea what any of those key combos do.
It's made to evoke what the result will look like, based on the characters on the keys (like ; is a thing above the other, so it evokes vertical split)
However, I feel Ctrl-T should be the default to create tabs (since that's how anyone does in the browser, while Ctrl-Shift-T reopens) so I'm not sure about how to mix and match all that (+ my lack of use of vim splits) to select defaults that'll give a great experience.
> Maybe I'm just grumpy because I'm sick during the holiday season :(.
Then get better and let's talk about shortcuts later!
Someone who likes window splitting and care about vim shortcuts in vim could help a lot!
As pointed out in other comments, the vimrc isn't really the key part of this project. Of course, calling these "sensible defaults" is maybe a bit antagonistic, even if it wasn't meant that way, and draws too much attention to it.
I will say that the "tab" line is a super useful feature. For anyone not using it, look into it! Hint: you don't have to use it for tabs at all. It's a great place to stick any persistent info that is global to the current Vim instance. And of course you can tweak it to conditionally display whatever you want. Much like this repo does, when I did a lot of pairing at my last job, I stuck the current file name up there because that is where my coworkers were used to looking.
> Of course, calling these "sensible defaults" is maybe a bit antagonistic, even if it wasn't meant that way, and draws too much attention to it.
It's a bit of a joke, it's intended to make you laugh like when I say to go buy an OLED screen instead of commenting out a specific line :)
But TBH it's only half a joke: I think not supporting selection with Shift and Control+Shift+Arrows may drive intermediate users away.
> I will say that the "tab" line is a super useful feature
Absolutely! Like you, I've also noticed the tabline (and the line numbers) helps when I'm showing files to other people.
Even if everything else I consider sensible defaults (rainbows! emacs/readline like chording shortcuts everywhere! selection with the arrows, shift and control!) doesn't popular, I hope the tabline with X,Y coordinates and hex position will.
"antagonistic" wasn't the exact right word... like, the same word but less strong, lol.
> I think not supporting selection with Shift and Control+Shift+Arrows may drive intermediate users away.
I actually don't have anything like this to move words around! I use `]e` and `[e` from tpope's unimpaired [0] for moving lines around (I use tons from that plugin). I may toy around with some word-moving mappings.
I do agree with readline everywhere! I'm on mac and have it configured so readline works in all apps, lol. Again with the tpope plugins, vim-rsi is a great plugin and I very much agree with its premise: I love the stand vim bindings in command mode but when in some kind of "insert" mode, even outside of vim, I want readline!
> PS: If you don't have an OLED screen, don't comment out autocmd ColorScheme * call OLED_Black() around line 1162. Instead, go buy an OLED screen! It's really worth it!!
Interesting truth. Vivid colors, best response time, saves power in dark mode, #000 looks amazing (and off-black looks muddied). Honestly I wish we normalized true black themes for this reason.
To quote from their readme: “Overriding dark themes to replace the uggly muddy darkgreys by a pure #000000 black: this is ideal on OLED screens which can do pitchblack and give you a higher constrast”
Those muddy dark greys are actually there for purposefully lowering the contrast, to prevent fatigue. It takes a while to accommodate to lesser contrast, but once you do it, you will likely never want the pure blacks back, unless you will also make the foreground colors darker to compensate for it.
Regarding OLEDs, I’ve gotten the best 31.5” professional grade OLED display, and sent it back, because of the flickering (due to pixels changing state) in low light/brightness conditions. It got me tired very fast (30 minutes) while working at night.
I think you're talking about two orthogonal topics. If the fatigue comes from the difference between foreground and background, it's independent of how "pure" the black is. You can have #000 black AND keep a low contrast between bg and fg, which looks great on OLED screens AND doesn't hurt your eyes.
This is anyway very subjective. For example, I feel the widely popular Solarized colorscheme MORE tiring because the low contrast requires more effort to tell the letters apart.
I literally have mentioned that you can have black and low contrast by adjusting the foreground colors.
It’s subjective indeed, and it requires an investment, purposefully putting up with it for a while, to be able to harvest the benefits. But everyone I personally know who did that, doesn’t want to go back to rich contrast.
You can also turn way down the brightness & save even more power if #000 & #fff are used to get a low contrast. Seems folks forget about this adjustment as anyone using a low-contrast theme for their site makes me crank up my brightness just to read it. Books being high contrast black & white wasn’t an issue since it’s in ambient light, but if your screen is brighter than ambient, then of course you’ll want a low-contrast theme, but you could have just lowered your brightness.
I’m happy with my OLED phone, laptop, & monitor while not having daily driven a IPS device in 5 years.
Anyway, if you want to lessen eyestrain, you want light mode. Light text on a dark background blooms more and makes it harder to distinguish the characters.
I asked my optometrist about the best setting for viewing comfort, and she said black letters on white background. So I have that, except with a bit of tint, also following a theory that looking at certain colors affects moods.
>> Light text on a dark background blooms more and makes it harder to distinguish the characters.
> I asked my optometrist about the best setting for viewing comfort, and she said black letters on white background
I did some reading before I started using light themes, and the theory agrees with your optometrist, especially for astigmatism.
However, after getting an OLED screen, my experience didn't match the theory anymore: I could make the dark theme more comfortable with basic settings.
So I went back to check the research and I noticed it was not correctly controlling for ambient illumination and for the screen brightness.
I call that the 3 deltas:
- the 1st delta is between ambient brightness and the screen background color,
- the 2nd delta is between the screen background and the foreground color,
- the 3rd delta is between the ambient screen brightness and the screen foreground color.
In a dark room (at night), if you use a dark theme with a pitchblack background (as possible on an OLED screen) with a foreground of white text, it will NOT be comfortable if you leave the full brightness (usually 400 to 600 nits)
However, an OLED screen gives you precise control over the brightness: reduce it and you'll see it's possible to make the characters easier to distinguish on a dark theme than on a light theme.
I have scripts to do color inversion and different correction filters. I even have a shortcut for each, to reduce friction and try different settings for different conditions: I can go from a dark theme to a light theme in about 200ms, so I just go "click click click" on the keyboard until I find what conditions "clicks" with me :)
Unless I'm sitting in a very well light place (that I consider too bright for my preferences), I'm more often with the dark theme.
I'd encourage you to take into consideration the 3 deltas and try by yourself a dark theme while doing brightness control +- color filters, or at least to check the research (ask GPT!) your optometrist recommendation is based on.
Hyperlinks to scripts? I’ve been wanting to do something similar for ages for those few occasions where ambient sunlight really wanted me moving to something that wasn’t a dark. It seemed like quite a bit of work since, like you, more often than not, I’m not in that sort of environment.
I have no nice release but on hyprland, I use the following to increase /sys/class/backlight/intel_backlight/brightness by steps of +- 200 units that I calibrated with my eyeballs and /sys/class/backlight/intel_backlight/max_brightness:
The script is just reading /sys/class/backlight/intel_backlight/brightness and writing back the same value +- 200
The most important is what plays with that: color inversion, red shift, contrast increase, so install gammarelay-rs and wl-gammactl then do key mappings.
The contrast increase is a nice feature to avoid trimming low contrast element (ex: light key text on a grey background), before moving to use exclusively red on black ("submarine" night mode)
# alt= dark red nightmode
# WARNING conflict betweel wl-gammarelay-rs and wl-gammactl: before using one, must killall the other first
# So unconditionally kill the other before running commands
> I’ve been wanting to do something similar for ages for those few occasions where ambient sunlight really wanted me moving to something that wasn’t a dark.
If it's a rare occasion, you must use a dark theme by default, so I would do
- first Ctrl+Printscreen to try to increase the constrast of your back theme: it's rare and counterintuitive, but if you have no reflections on the screen, it can help in the sun
- if it's not enough cancel it by another Ctrl+PrintScreen, then Shift+Printscreen to toggle the inverted mode
- then Fn F5 (which causes XF86MonBrightnessDown on by thinkpad) to reduce the brightness until you like it
If works best if you have OS-wide theme toggle. I use 2 terminals with different themes because unlike on Windows Terminal, on Linux the hot toggles of colors themes for Terminals isn't working so well.
If you have a brightness sensor (often in the keyboard, for color calibration on thinkpads, or in the webcam housing for balance adjustement), you could do much better: record in a sqlite database the timestamps, the brightness value, and your actions (ex: reducing lightness +400)
After a few days of collecting metrics, you should be able to calibrate a default reponse that would change with your habits: imagine pressing a key and reproducing your modal reponse to this kind of ambiant brightness (this theme, that brightness, this color filter...)
Benefits of LCDs over OLEDs: less burn-in, can dim to low brightness without PWM (flicker noticeable with peripheral vision) or color degradation, no funky stuff with gray-to-black transitions, no limitation as to how much of the screen can hit peak brightness, no gray point uniformity or variance issues, etc.
From what I understand, iPhones are the best as far as panel quality goes, but even at those tiny sizes they are still full of shortcomings (see, e.g., https://www.xda-developers.com/apple-iphone-14-pro-max-displ...). Compared to a phone, my laptop’s screen is much larger, color reproduction is much more work-critical, and I stare at it for longer, so thanks but no thanks, I’ll stick with LCD.
This is sick and eliminates the "but I want my muscle memory to work on bare-metal Vim installed by default on every Linux" complaint against stuffing too much config into Vim. Why bother using the barebones install when you can just scp a single binary over that contains everything, to literally any OS? Amazing.
That being said, the config is definitely highly personal — it would be amazing to have a set of scripts to compile one's own personal .vimrc and related config files (really, the entire .vim directory) into a single APE.
> and related config files (really, the entire .vim directory) into a single APE.
I don't like having a billion files everywhere (like plugins/ etc) so I didn't think about that usecase, but that would be a great addition because most people have a .vim tree: even with my dislike for having too many files, I have myself a few in .vim/after/syntax/ (to apply italics to comments)
If you can contribute a script that converts your .vimrc and .vim/ tree into something that can be added to the APE, I'd be very happy to add it!
The binary was compiled with Cosmopolitan Libc [0], and therefore the binary will execute natively on Linux, Mac, Windows, FreeBSD, OpenBSD, NetBSD, and bare metal (BIOS boot).
Have you written anywhere---or would care to expand here---why you have stuck with Vim over NeoVim? I ask because I have done the same. I made a couple of attempts to switch to nvim the last of which was abandon just over a month ago. Just curious! I have a very hard time articulating what I like more about Vim other than simply it just suits me better (which isn't an interesting answer).
Wow that's a very personal question! I'll try to answer the best I can!
I like retrocomputing and hacking, especially for Christmas: I want to write things I can share, that'll mix old stuff and new stuff, and that will make people smile - call it the spirit of Christmas or whatever. My 2022 Christmas project was to write a web server in perl, exposing the whole C:\ drive, just for fun.
perl, vim, bash (etc) are old, so they are stable and available everywhere: other things equal, I think doing the same with neovim might have had less impact.
Also I think it's better and more satisfying to make existing tools work the way you want (ex: I want images in my terminal without moving to another terminal!), instead of moving to other tools when your existing tools can't do something you want. I believe it's the true spirit of hacking.
> i have done the same. I made a couple of attempts to switch to nvim the last of which was abandon just over a month ago.
TBH I never really tried neovim, maybe because I like the start screen of vim? The idea of doing something for orphans may be cheezy, but I really like the message!
Also why did you attempt to switch to neovim? I don't feel any limitation in vim. I'd be curious to know why you tried.
I felt them in tmux (lack of sixel support) or bash (incomplete history file), but instead of doing the sensible thing such as using zsh within kitty like everyone else, I spent some time to have tmux intercept and transcode sixel sequences into "ascii art" (https://github.com/csdvrx/sixel-tmux/) have bash save commands start and stop time in a sqlite database (https://github.com/csdvrx/bash-timestamping-sqlite)
> I have a very hard time articulating what I like more about Vim other than simply it just suits me better (which isn't an interesting answer).
I see what you mean. I didn't like zsh when I tried it last time I tried to move to Linux on the desktop. I liked hyprland - it sealed the whole linux-on-the-desktop deal. It "suits me better", but it's new so I think (or I hope?) it's not just by weird interest in retrocomputing that makes me prefer bash+vim to zsh+neovim :)
> TBH I never really tried neovim, maybe because I like the start screen of vim? The idea of doing something for orphans may be cheezy, but I really like the message!
Ha, I like that! Personally I hide the home screen but I can get behind that and have donated to Vim before.
> Also why did you attempt to switch to neovim? I don't feel any limitation in vim. I'd be curious to know why you tried.
The first time years ago, was the try out the async stuff, then Vim got it so I switched back. The second time was very recently. I'm primarily a web developer and write a lot of Elixir. The Elixir community is rallied around NeoVim so the experience is quite a bit better. The maintainer of elixir.vim doesn't even write Elixir anymore (though he is very attentive to PRs and issues). I've contributed a bit to it, but ultimately I don't spend a lot of time hacking on Vim anymore (though I do have a todo item to update my vim plugins to make use of viml 9). At the same token, there is a bit of sunk cost fallacy going on in that I know VimL very well. I don't like the idea of having my config in two different languages nor do I like the idea of having to port my whole vimc config (which I know quite intimately) over to Lua. And ya, as you said, I feel no limitation in Vim other than the previously mentioned lack-of-Elixir support.
Oh ya, I was also convinced to try it out thanks to this talk [0]. Though, even as a quiet person myself, I found his speaking style very hard to take (but I powered through).
I'm actually aware of your Sixel project but never ended up trying it out. I've actually been following you on github for quite some time but---being primarily a web dev---often when I have to compile C on my mac I think "meh, I'll look into this later" and, of course, rarely come back to it. Not a very good reason, I know.
And ya, I kind of just switched to zsh years ago because it was "the thing to do". I do write enough shell scripts and never use any zsh-specific features, so I've been thinking of moving back to bash just to try it out again.
A vim that'd use cosmopolitan binaries for the plugins would provide a solution without making everyone compile C code!
> The maintainer of elixir.vim doesn't even write Elixir anymore (though he is very attentive to PRs and issues). I've contributed a bit to it, but ultimately I don't spend a lot of time hacking on Vim anymore
If the community has moved to neovim and the maintainer of the vim package isn't writing in this language anymore, it may be hard to get a good "out of the box" experience with prepackaged solutions
But if the result you get still satisfies you, maybe it's not worth chasing what everyone else is doing with neovim? A minimal hacking around your working vim configuration could get you further, or at least fix your pain points enough to make everything else less important.
Also, you can't be certain that what the neovim elixir community find important, their pain points, will be identical to yours: hacking your own solution guarantees you'll be satisfied by it (because if you aren't, you can hack it some more :)
This is giving me the idea to check a NeoVim ActuallyPortableExecutable containing my NeovimRC into my Dotfiles git repo. Would be very handy to be able to SCP it to servers in an SSH pre-command & always have my setup!
For a file to end up in ~/.vim/backup you need to have (had) the right to edit it in the first place. (I assume) files that are edited as root would go into the root home directory, so no problem.
I can maybe see it be a problem for servers but I can't really think of a likely case, you would have to mess up pretty badly.
On the other hand, files edited through a flow like `sudoedit(1)` get copied into /var/tmp with mode 0600 and edited under the user's editor. This is in some ways much better than something like `sudo vim`, since that's a lot of privilege to be granting to a large attack surface. But it does create files like ~/.undodir/%var%tmp%shadow.XXcFqVH3: also with mode 0600, but they stick around even after sudoedit(1) terminates. So I think that it's fair to say that it is a nonzero security risk because it creates persistent copies of potentially sensitive files.
Aside from just a strict Unix permissions model, I think it's also easy to imagine cases where you create a sensitive file, edit it, delete it, and expect it to be really deleted. Or even just use Vim as a scratch buffer with no name! Yet undodir persists data in these cases, too.
To solve the issue with Ctrl-k Ctrl-u leaving out one char in normal mode, have you considered setting virtualedit=onemore? It's often a sensible option when you want to "unify" the behavior of normal and insert modes (I've not tested it in your environment, though).
I hadn't. but I will! I like Ctrl-k Ctrl-u to clear the line, and this leftover character is something I really don't like, so THANK YOU!
If you have more suggestions, I'd be interested to know! (the best way might be for you to try to edit files with it for like 10 minutes, to see what's missing from your usual configuration)
I'd love hear what different people find missing from CuteVim to make it more helpful and pratical (ex: I leared the sudoedit security issues here, so I'll add a undo and backup exclusion for files from /var/tmp)
With the risk of being somewhat off-topic, in this thread I'll be the one bringing up Helix first. As a vim user for 20 years, I tried it out last time it was brought up on HN two months ago. I have been using it ever since and I probably won't go back. Despite my 20 years of vimming I had never really successfully customized it deeply, going with very few plugins and changes. Tried neovim a few times and it is amazing when it works, but the various distros, plugin updates and occasioanal errors made me anxious. If you are a power vim/nvim user who likes tweaking their config and playing with plugins that's great and nvim truly delivers on the Personal Development Environment idea as it is sometimes called.
For me, having more things covered almost out of the box (and by installing a few non-Helix packages like LSP servers) in Helix than I ever properly had without issues in vim setups (LSP, treesitter, fuzzy file open, built in keymap help, etc.) is liberating. The only clear downside for me is some of the shortcuts are different (xd instead of dd) but even those can be configured to be more like vim if you wish to.
For others no built-in-debugger or git integration may be showstoppers, since those will only be done via plugins when the plugin infrastructure is done.
When I heard about Helix a few years ago I was dismissive since it seemed like a pointless rewrite of and editor in Rust for performance or for a more consistent approach to keymappings, both of which seemed good goals but not good enough to switch your editor. The fact that it comes with so many features built in and thus stops the possibility of fragmentation across a lot of dimensions is very reassuring though. I want opinionated tools because I am not that special and neither are my programming tasks that different from other people's. Vim still has a special place in my heart and use it on remote servers.
So, sorry if off-topic, but for those who are in similar position - want bells and whistles not just a plain editor, but gets tired by finding and maintenance of many plugins - it may be worth checking out.
Neovim is a bit of a disappointment on a certain front.
The devs stated decision is not to deliver an actual editor (up to a point), their focus is on creating an editing component and ecosystem. Which is fair on their side, but it shows in the quality of end-user tooling. For example nvim-qt is quite barebones compared to Gvim (which could be argued to have had too many features... maybe).
> Tried neovim a few times and it is amazing when it works, but the various distros, plugin updates and occasioanal errors made me anxious.
I have the exact problem as you. I don't even need a ton of features besides the core Vim/Neovim ones, I'd just want stuff I've come to expect from similar editors/IDEs in the past decade, and Neovim doesn't want to bless any of them:
- file manager
- universal search (commands and files; Ctrl-Shift-P, Ctrl-P)
I think it's best to accept that the target audience for Vim/Neovim is a certain kind of person and despite a relative match on many fronts, we're probably not enough of a match for long term use. Oh well.
Project governance types affect the end result. While smaller projects like Helix have a few (or maybe one?) decision makers, vi/vim/nvim is such a large and decades old community with so much diversity that the proliferation of plugins - which in itself would not be bad if there wasn't so much low quality and abandonware without clear signs that that is the case - cannot be easily transformed into a solution most will agree on. Most 'the ultimate vim/nvim plugin pack' will just have its own small community, rise and fall.
Vim/Neovim need package managers or at least package repos with a great degree of curation.
I really like the Sourceforge/PyPi maturity ("5 - Production/Stable") ratings. Of course they can be misleading, but at least they're a data point.
I also like the idea of package bundles, but more than that, I like the idea of package bundles which are suggested by core devs, to make them a bit more official. Sort of 2nd tier of trust.
> I have the exact problem as you. I don't even need a ton of features besides the core Vim/Neovim ones, I'd just want stuff I've come to expect from similar editors/IDEs in the past decade, and Neovim doesn't want to bless any of them:
> - file manager
> - universal search (commands and files; Ctrl-Shift-P, Ctrl-P)
Can you describe what you'd like to see? How it would work, what it would do?
I'd like to add more interaction between fzy and vim, and better integrate bash and vim.
Well, open up any of Sublime Text, VS Code and quite a few other editors.
You press a key combo (Ctrl-P is the standard combo these days, it seems).
A small input window pops up at the top and the search results drop down, this is way more ergonomic for reading, unfortunately, than the old timey Emacs/Vim command mode input at the bottom and pop up results.
Ctrl-Shift-P would be for searching for commands. So you'd go "find" and the drop down would contain the relevant "find" commands which you could then select and parameterize: https://youtu.be/B-s71n0dHUk?feature=shared&t=380
For search, you go Ctrl-P and the same input window pops up, just that it does a fuzzy search of your project folder by default.
For the file manager, it's that thing on the left in Sublime Text, VS Code. It's a mini file manager that shows the project/folder you've opened. It's very convenient when not editing a lone file, which is probably 99% of the time for DevOps and dev work.
> Rock musicians have a love-hate relationship with dynamic range compression, since it removes a dimension of complexity from their music, but is necessary in order to sound professional. Bloat might work by the same principles,
Speaking of which I am a bloated rock musician. I don't feel seen.
Basically; it's using the "Actually Portable Executable" system to make a single binary that includes everything it needs including enough portability stuff to run on different systems directly.
> Is so, what is this doing?
When I say "everything it needs", that includes files; APE binaries, AIUI, include some code to transparently read files embedded in themselves, so that line says "run this vim binary, but when it starts instead of reading the user's normal .vimrc (if any), read the vimrc that we embedded in this binary under the virtual /zip path"
The actual binary (vim.com in this case) is also a valid zip file, which it can read and write as a private virtual mount point. /zip refers to files inside the binary, inside the zip file.
Redbean web server (by the author of Cosmopolitan, Justine.lol) also uses this method to store its web root.
The whole point of Vim is to configure it however you dang well please!
But yes, calling these defaults "sensible" isn't the best idea. You could certainly make a case for some sensible vim defaults, but these ain't it (even though I like some of them).
That's not true. For many people Emacs' text editor is the least interesting part of it and use evil mode to get Vim-like bindings. While the jokes may lean on the differences in key-bindings, they are hardly the whole story. Vim is a super lightweight editor that is available everywhere and very easy to carry around your own single-file config. You're allowed to configure it however you want. Vim too has its share of annoying key chords... <c-r><c-g> is one I use often enough that I stilllll haven't made a mapping for (and likely never will at this point).
The point of vim is to be vi but with more features.
It's not to configure it however you dang well please.
If this were the point, which it isn't, you could use emacs, which can be configured in vastly more dang ways. Including ways which are a superset of vi, as you yourself admit.
> emacs, which can be configured in vastly more dang ways. Including ways which are a superset of vi, as you yourself admit.
lol
I think this may be turning into a emacs/vim war :)
> The point of vim is to be vi but with more features.
What defines the point of a tool is what its users make with it.
Having vim with emacs short inside a binary I can run anywhere (from BSD to Windows, which I still love to use sometimes) gives me freedom, so for me the point of vim is freedom.
I like emacs shortcuts (at least the readline ones) but not emacs itself, so for me, there's no point in using emacs.
But if you prefer emacs, why don't you try to do the same thing I did, yet with emacs? You can follow my tutorial (check the part about strace to know where to add your files) and the binary from https://cosmo.zip/pub/cosmos/bin/emacs
I may not like emacs, but if you prepare something containing what you consider should be the defaults, I'd be curious enough to give it a try :)
I don't use emacs (except for rendering orglatex) or vim (ever, I do use vi, though!), you're just pattern matching onto "an emacs/vim war" because you want to.
You're not curious; you're trying to wage an editor flamewar and are confused that I'm not. I'd jokingly say "ed" or "windows notepad" except you'd earnestly try to explain to me that vi or emacs or something is better.
Agree to disagree, I guess. However, the first half of the very first sentence on www.vim.org is "Vim is a highly configurable text editor" so take that as you will. I'm fairly certain there won't be any vim police showing up at my door if I make a chord-mapping :D I'm not into the chord-mappings myself, but I support those who are.
> a tabline on top
I don't have anything against all these "default configurations" for vim (even though I'm struggling to imagine, why the kind of person who doesn't want to configure vim himself would choose vim in the first place), but this line just made me chuckle.