-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
https://github.com/helix-editor/helix/issues/1927
Devs could use the unofficial plugin for Emacs (https://github.com/zerolfx/copilot.el) as a guideline to add support
I want to like Helix, I really, really want to. It's lean, fast, polished, purely console based so it fits my workflows perfectly... but the almost-like-vim-but-not-really key bindings are a deal breaker. I just can't make the switch.
If Helix were completely different in this regard, like Emacs is, I could handle--and I know because I use both vim and Emacs regularly pretty fluently. But Helix is way too close to the vim keybindings to discern it from a memory muscle perspective. I use vim keybindings everywhere else (zsh, all readline-based apps via a setting in ~/.inputrc, VSCode), so getting used to slight differences in just one editor is extremely hard because I can't just drop all other apps.
I recently tried this: https://github.com/LGUG2Z/helix-vim which attempts to provide vim mappings to Helix. It's funny how the description in the page describes my progression almost 100%. And while it makes things slightly better, it's still not accurate enough to make this a non-issue.
> I really like the Kakoune-style motions.
Kakoune has often seemed like a platonic ideal to me. I gave it a try, but had to go back to emacs ecosystem.
This led me to inevitably tryout https://github.com/meow-edit/meow which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.
I vastly prefer Vim's way of action+selection to kakoune's selection+action. Tried kakoune in the past for a few days and this decision was constantly getting in my way.
Here is a short write-up (not mine) about why kakoune model is not that appealing: https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
> They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
I am sincerely curious of what flaws from Vim has Vis inherited, in your opinion.
I have the impression that the design idea of Vis is taking only the modal design of Vi (not Vim), plus the structural regular expressions of Sam, then make it as clean as possible with programmability via Lua plugins.
In fact, the state non-goals [1] seems to clearly distant itself from Vim.
[1]: https://github.com/martanne/vis#non-goals