[HN Gopher] Vim Roadmap 2025
___________________________________________________________________
Vim Roadmap 2025
Author : testelastic
Score : 22 points
Date : 2025-01-29 22:04 UTC (56 minutes ago)
(HTM) web link (zed.dev)
(TXT) w3m dump (zed.dev)
| testelastic wrote:
| Cool features from zed's Vim mode
| Daunk wrote:
| "Vim mode" in editors like Zed is great and all, but to me, Vim
| is much more than just a set of shortcuts. What I love about Vim
| is how seamlessly it integrates with the terminal and shell. I
| can pipe, redirect, and manipulate text with Bash, use any CLI
| tool, and move fluidly between my editor and my system. The
| terminal is insanely fast, works on any computer and OS,
| scriptable, and gives me access to everything I need.
|
| Zed looks great, and I'm glad it has a Vim mode... but without
| that deep integration, it's missing what makes Vim truly powerful
| imo.
| v3ss0n wrote:
| Terminal is not insanely fast. UI wise it is not efficient.
| Rendering is slower than vscode too even with GPU powered terms
| nicce wrote:
| I believe that the use case you describe is a bit different
| than where you would use Zed primarily. If I have a code base
| with 100k lines of code, and I am developing that, I don't hop
| from terminal to editor and back by using the same terminal
| instance. I have different terminal window for that. Closing
| the editor window would lose too much context.
| hellcow wrote:
| tmux solves for this.
| crvdgc wrote:
| My colleague taught me to never close the editor, but just
| suspend it to background. You can achieve a lot with Ctrl-Z,
| fg, and :e!.
| VeejayRampay wrote:
| used to think this mattered a lot but funnily one of the main
| vim-universe inspired editors, helix, has convinced me otherwise
|
| their choice to subtly diverge from the vim way of things is
| actually super nice, somehow way more mnemonic and easy to
| remember and use everyday
| n42 wrote:
| I really want a Helix/Kakoune mode in Zed, but last I checked
| the development of such a thing was dead in the water,
| unfortunately
| zamalek wrote:
| Zed has recently merged support for helix-like bindings, but
| it's still pretty far off (e.g. there's no way to default to
| "helix-normal" mode, meaning your first hotkey will be pure
| vim). I found it basically unusable for daily-driving, and
| Helix has me way too hooked on their style of modal editing for
| me to tolerate anything else.
|
| Edit: here's my Helix keymaps, they're in Nix but that's pretty
| straightforward to port to JSON:
| https://codeberg.org/jcdickinson/nix/src/branch/main/home/co...
| bombela wrote:
| I have been eyeing helix for quite a while. Been using (neo)vim
| for 22y. Why not Helix for the next 22!
|
| I find the helix model of select then act so much more aligned
| to my mental model. Rather than verb then noun in vim.
|
| Vim register handling on deletion is pure crap. (delete a line
| lands into a different register than delete a word, pasting
| over a selection overrides the default register etc.).
|
| There is one plugin in vim that I cannot live without though,
| and that is easymotion (there are other similar plugins). It
| highlights objects with a letter (like the start of words for
| example), pressing the letter jumps to the object. I find this
| so much more natural and easier than jumping to line numbers. I
| might have to implement this into helix ;)
| selectnull wrote:
| When Zed got released, I was looking forward to trying it out
| because I saw the potential.
|
| Very soon I found out that: Vim mode must be perfect and few of
| my <leader> key combos have made me (Neo)vim addict. And also, I
| prefer terminal editor.
| 2c2c2c wrote:
| humble request to make marks for the number key registers global
| marks
|
| they're global marks in vim. no one uses them there because those
| registers are reused for clipboard history
|
| the vscode extension doesn't implement registers this way so
| they're safe to use. i imagine zed's implementation is similar
___________________________________________________________________
(page generated 2025-01-29 23:01 UTC)