Show HN: CuteVim – Portable Vim with a cute vimrc
github.com
github.com
> 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.
How do you split if ctrl+w is cut word instead?
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 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
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!
OK, but as a vim user you would switch readline to vim mode and never look back ;)
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.
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.
> 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!
[0] https://github.com/tpope/vim-unimpaired [1] https://github.com/tpope/vim-rsi
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.
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.
Very happy with a Black IPS panel now.
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.
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.
> 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.
binde = , XF86MonBrightnessDown, exec, $HOME/.config/hypr/changebrightness.sh - 200
binde = , XF86MonBrightnessUp, exec, $HOME/.config/hypr/changebrightness.sh + 200
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
bind = ALT,Print, exec, killall wl-gammactl
bind = ALT,Print, exec, killall wl-gammarelay-rs || ( wl-gammarelay-rs & busctl --user -- set-property rs.wl-gammarelay / rs.wl.gammarelay Temperature q 1000 )
# Control= increase contrast for OLED dark
bind = CONTROL,Print, exec, killall wl-gammarelay-rs
bind = CONTROL,Print, exec, killall wl-gammactl || GTK_THEME=Adwaita-amoled-dark-Fix wl-gammactl -c 2.500 -b 0.700 -g 1.000
# Shift= invert
bind = SHIFT,Print, exec, killall wl-gammarelay-rs
bind = SHIFT,Print, exec, killall wl-gammactl || GTK_THEME=Adwaita-amoled-dark-Fix wl-gammactl -c -1.000 -b 2.000 -g 1.000
# Win= brightness menu
bind = WIN,Print, exec, killall wl-gammarelay-rs
bind = WIN,Print, exec, killall wl-gammactl || GTK_THEME=Adwaita-amoled-dark-Fix wl-gammactl
> 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...)
For ICC profiles colormgr can help: https://wiki.archlinux.org/title/ICC_profiles#Wayland
If you just need basic brightness, contrast and gamma, wl-gammactl should do that: https://github.com/mischw/wl-gammactl
BTW Hyprland is not required, it's just the most practical way to have shortcuts key mappings in Wayland
I’m happy with my OLED phone, laptop, & monitor while not having daily driven a IPS device in 5 years.
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.
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.
I have very special preferences (like CHORDING EVERYWHERE! :) )
> it would be amazing to have a set of scripts to compile one's own personal .vimrc
Actually, I thought about people who may have different preferences!
If you want to do the same thing but with your own .vimrc, just check the "How can I make my own CuteVim APE?" section in the README (https://github.com/csdvrx/CuteVim?tab=readme-ov-file#how-can...)
This section documents the use of the refresh.sh script from https://github.com/csdvrx/CuteVim/blob/main/refresh.sh
> 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!
I would call that portable.
I am agreeing with the original comment.
Why would you post that? What is wrong with you?
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 :)
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.
Thanks so much for your answer!
You're welcome!
I'll try to release more APEs for the sixel related projects because I'd like to make things like https://github.com/bytesnake/vim-graphical-preview/ more accessible.
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 :)
(It's wild to me that despite *gestures wildly*, zsh's release tarball is under half the size of bash's, though...)
Is this a security risk? Not complaining, as it can be changed in the vimrc, just want to pose the question.
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.
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.
sudoedit is something I hadn't considered. The backup should have an exclusion list, with at least /var/tmp
> Yet undodir persists data in these cases, too.
Except showing the count of available backups files somewhere in the interface, I don't see an easy way to avoid that
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)
:set complete-=i
:set nrformats-=octal
:noremap Y y$
:noremap vv V
I'd add j to 'formatoptions' for .c and .h files (or even for all types of file).
Thanks a lot for your suggestions! I'll prepare a new revision!
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.
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.
> - 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.
It looks like a good usecase!
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.
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.
./vim.com -u /zip/usr/share/vim/vimrc
But I apparently am distracted by shiny things and couldn't focus on any of the other stuff after seeing rainbow indentation for the first time.
Speaking of which I am a bloated rock musician. I don't feel seen.
Redbean web server (by the author of Cosmopolitan, Justine.lol) also uses this method to store its web root.
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"
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).
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.
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 :)
And why were you condescending of BSD users?
I have no idea what that second sentence means.
Then I would take you to heart because I love Notepad and its minimal set of features. SciTE is nice too
> I have no idea what that second sentence means.
Nothing, I have confused you with someone else.