31–40 of 74 posts
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.
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…
> 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.
the whole point of vi is no key chording so no carpel tunnel. hard pass, thanks.
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).
> 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.
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 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…
> 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 ba…
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.
> 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 ba…
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.