[HN Gopher] Notes on switching to Helix from Vim
___________________________________________________________________
Notes on switching to Helix from Vim
Author : chmaynard
Score : 248 points
Date : 2025-10-10 14:37 UTC (8 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| constantcrying wrote:
| I think it is worth pointing out that there are "zero
| configuration" vim distributions, which come with the same
| ease/limits.
|
| Not to take away from Helix, which I think is a cool project. But
| I think it's greatest strength is that it can (and should) be
| more than a vim rewrite in Rust. It can actually get rid of the
| legacy parts of vim and redo the things which did not work and
| integrate modern features from the beginning.
| MyOutfitIsVague wrote:
| Helix very much is not a Vim rewrite in Rust. It's closer to a
| Kakoune clone than a Vim one.
| ikety wrote:
| Zero config distros still require maintenance, and the chosen
| tools change over time. Helix is just Helix
|
| Helix is actively inspiring Neovim to become a more
| comprehensive baseline. Which is freaking awesome. One day the
| ootb experience will be so good with neovim that few will care
| for these "zero config" distros.
| MyOutfitIsVague wrote:
| I love Helix. There are some things Julia didn't list that I also
| miss from nvim, particularly using it as a 3-way diff tool, and
| missing code folding, but I don't see leaving Helix any time
| soon.
| gizzlon wrote:
| yeah, I started using Meld for diffing
| aiiizzz wrote:
| Waiting on proper git, diff, and debugger support.
| phplovesong wrote:
| Skimmed only. Most titles was like "i use X for that" then
| scrolled down for the next one.
|
| And thats the thing. Neovim (vim) is about the unix way, use
| existing tools and use them from vim.
|
| Last time i checked this was not an option in helix, and some
| very trivil things was impossible, like populating the quickfix
| (is it a thing n helix?) from a makefile command.
|
| Bottom line is helix is basically a stipped down version on
| vscode, and wont really succeed without a plugin system (and
| when/if it lands, its basically just a vscode alternative)
| celrod wrote:
| I use kakoune, and don't understand why helix seems to be
| taking off while kakoune (which predated and inspired helix)
| remains niche.
|
| Kakoune fully embraces the unix philosophy, even going so far
| as relying on OS (or terminal-multiplexer, e.g. kitty or tmux)
| for window management (via client/sever, so each kakoune
| instance can still share state like open buffers).
|
| A comparison going into the differences (and embracing of the
| unix philosophy by kakoune) by someone who uses both kakoune
| and helix: https://phaazon.net/blog/more-hindsight-vim-helix-
| kakoune
|
| Sensible defaults and easy setup are a big deal. No one wants
| to fiddle with setting up their lsp and tree-sitter. There's
| probably more to their differences in popularity than just
| this, though.
| ikety wrote:
| I think the easy setup is exactly the reason Helix has taken
| off compared to Kakoune. It probably has the most simple
| onboarding experience I've had with any text editor. Things
| just make sense, and tools that should be built in are.
|
| I think the philosophy of delaying the plugin system as long
| as possible is one of the reasons helix has achieved that.
|
| With Helix I just have to learn selection first, and few
| different binds compared to vim. With Kakoune, I have to
| onboard into a more complex ecosystem, in addition to that. A
| lot of people already have vim/neovim config fatigue so
| that's not very compelling.
| pheggs wrote:
| I genuinely don't like the concept of the keyboard
| interaction in helix and kakoune, selecting things to modify
| them. I don't know what it is, but it somehow just feels much
| less satisfactory to me personally compared to the vim way.
| lawn wrote:
| The problem with that editing model for me is that it makes
| text objects much more cumbersome.
|
| In Vim you can for example do "dap" to delete around a
| paragraph, but you cannot easily invert it ("pad") because
| 'p' is too common and is already bound.
|
| You can also easily do the "select first" in Vim by first
| pressing 'v' to start a visual selection, so I just don't
| see the point.
| ikety wrote:
| The biggest benefit is multiple cursors. The helix and
| kakoune multiple cursor implementation are probably the
| best in any editor. It just goes hand in hand with
| selection first.
| chongli wrote:
| I spent about a month trying to get used to Kakoune. It
| never clicked with me and I went back to vim.
|
| My biggest beef with Kakoune's editing philosophy is that
| it seems to emphasize "editing in the large" as its
| preferred mode of interaction. This is totally backwards to
| me. Editing in the large (making multiple identical edits
| throughout a buffer) is a rarity. Most edits in day to day
| use are single edits. So the fact that Kakoune likes to
| leave a bunch of extra cursors in your wake (like a trail
| of breadcrumbs) as you jump around a file to make single
| edits is extremely infuriating to me, like it's trying too
| hard to be helpful.
|
| The irony of Kakoune using a clippy-style contextual help
| window is not lost on me!
| xcrjm wrote:
| This is unfortunately exactly why I never used (neo)vim or
| kakoune (or tbh, sublime text whose lsp integration I have
| never successfully gotten working). Going from school (Java +
| NetBeans/C# + Visual Studio) to work (C#/JS + Visual Studio
| -> C#/TS Visual Studio Code) I had expectations for certain
| language features being available by default. Helix is the
| first editor of its ilk to get configuration out of my way so
| I can effectively write code the way I'm used to.
| zahlman wrote:
| Aside from the other replies, marketing matters. This is the
| first I've heard of this thing which apparently dates to
| 2011.
| aiiizzz wrote:
| Kakoune's problem is the bad UI (eg LSPs hover), and that
| scripting it is simply too complicated.
| bityard wrote:
| I don't have direct experience with either Helix or Kakoune
| but after only a few minutes tinkering around, I can see one
| big reason: In Helix, most of the basic commands seem to be
| the same as vi. Whereas I understand Kakoune inverts the
| action/movement paradigm of vi. Maybe that's a more sensible
| design, I don't know. I didn't check to see whether or not
| the key bindings were similar but at that point, it's rather
| moot.
|
| I've been using vim for 25 years, my muscle memory isn't
| going to tolerate switching to a whole new text-editing
| "language" at this point. But I could perhaps learn to live
| with a new dialect.
| dtj1123 wrote:
| Helix inverts the verb-selection paradigm in the same way
| as Kakoune.
| MangoToupe wrote:
| `ed` is really much more in the spirit of unix. `vi` culture
| popped up since then, and the idea of driving other tools from
| an editor is more of an emacs/lisp lineage.
| zozbot234 wrote:
| `ed` is in the spirit of teletypes. It's the editor of choice
| when all you have is a dumb text-based prompt with no control
| of full-screen display. The whole point of `vi` originally
| was to be a `vi`sual mode for `ex`, which is a more full-
| featured variety of `ed`.
| eminence32 wrote:
| I really enjoy Helix, but I can't install it everywhere, and so I
| end up going back and forth between Helix and Vim depending on
| what machine I'm working on. This puts a lot of pressure on my
| muscle memory -- I often type a vim keybinding while in Helix or
| a Helix keybinding while in vim.
| nikolay wrote:
| Helix wants to be Emacs. Ever since they decided to use a built-
| in Lisp dialect called "Steel" for scripting and become the next
| Emacs, not the next Neovim, I stopped following it. I love Lisp,
| I wrote so much code in Lisp in the '80s and early '90s, but that
| was another millennium! It's 2025 now, and just because it's easy
| to write Lisp interpreters doesn't mean we should use them. In
| fact, maybe Forth is even easier than Lisp... well, not really.
| Karrot_Kream wrote:
| I'm not sure why you think Lisp makes this "emacs" unless
| you're worried it'll fall flat because most Lisp-interested
| folks would find emacs more full featured? I'm not sure if a
| Scheme is particularly different than neovim's Lua. I'll be
| honest though I'm not sure how deeply Steel is integrated into
| Helix.
| warmwaffles wrote:
| It's not integrated at all right now. It's still sitting in a
| feature branch unfortunately.
| Karrot_Kream wrote:
| Ah I thought the big branch finally got merged.
| lawn wrote:
| Don't worry, Fennel compiles to Lua so you can keep configuring
| Neovim with a Lisp dialect too!
| dcre wrote:
| It's very hard to argue the plugin system has made Helix
| anything in particular, considering it is not merged yet.
| Approximately nobody's experience of Helix up to this point has
| been influenced by this choice.
| GalaxyNova wrote:
| I'm not sure why you think Lisp is somehow "outdated". It is a
| perfectly modern programming language and new Lisp code gets
| written at startups today in 2025.
| cycomanic wrote:
| <Controversial opinion> Computer scientist and mathematicians
| love lisp/scheme, everyone else hates it. The problem is that
| the syntax, concepts etc are so different that you really have
| to learn the language to make even small changes. Just reading
| prefix notation takes quite a bit of adjustment. When I was
| using emacs doom every time I changed my config felt like
| stabbing in the dark (hence I moved away). In contrast I could
| make lua changes (without any prior lua knowledge) without any
| problems.
|
| I don't want to learn a new language just to configure my
| editor.
|
| So by choosing scheme they essentially say this is an editor
| for computer scientists only. </controversial opinion>
| Karrot_Kream wrote:
| Lisps make great configuration languages because of how
| dynamic they are. It's like Javascript on steroids. Redefine
| core symbols. Modify a syntax form and reevaluate all of your
| code so that it does one thing in one environment and
| something else in a different one. When building large
| software in a team this can be a big drag; learning some
| weird syntax form that a coworker merged in that you didn't
| review can be a headache and when everyone makes their own
| design patterns, the codebase becomes a mess.
|
| But when you're just configuring software this heavily
| dynamic nature becomes a strength. I just need to build the
| abstractions in my config that I need, nobody else. It's easy
| to poke around in and spend a few minutes writing and
| iterating on code to get the config I want.
|
| I agree that the prefix notation and the soup of parentheses
| give it a higher learning curve than something like Lua which
| is easily understandable if you have experience in pretty
| much any modern programming language. But it's not the
| mathematical/computational purity that makes Lisps appealing,
| it's their highly dynamic nature.
| ramon156 wrote:
| A year ago I would've loved to see the other way around. Helix is
| cool but definitely not fit-for-all
| kesor wrote:
| "Using vim/nvim for 20 years". "cba to configure LSPs its too
| hard". What?
| naikrovek wrote:
| I think a lot of people on this site have genuine reading
| comprehension problems. I mean that as an observation, not an
| attack.
|
| > "Using vim/nvim for 20 years". "cba to configure LSPs its too
| hard". What?
|
| Nowhere did she say that she tried _and failed_ to set these
| up. Your comment indicates that you read it as her saying that
| it 's too hard to do. Where did that come from?
|
| She said it "felt like too much work" which is A) unrelated to
| difficulty and is B) something that you can say after you've
| done the thing, just as legitimately as you can say it before
| you do the thing.
|
| Being able to recognize that something that works just fine but
| isn't _right_ , and not being satisfied with that is a skill
| whose importance is difficult to convey. It is related to the
| sense people get after a while that gives them an allergy to
| unnecessary complexity. Complexity is fine _if it is required_.
| The zero-step LSP set up procedure for Helix proves that the
| multi-step LSP set up procedure for vim can be improved.
| kesor wrote:
| When someone is competent, as must be after using a tool for
| 20 years (not days). Expecting that someone to complain about
| a difficulty for something trivial is surprising. There are
| other ways to highlight that it is easier or simpler in Helix
| to have working LSP, for example, saying it is "as easy as in
| vscode". But it is definitely bewildering why would the OP
| choose to start by bragging of the vast experience, and then
| focus on a complaint that most people expect from someone who
| has very little experience.
| vaylian wrote:
| > LSPs its too hard". What?
|
| Back when I explored helix as a long-time vim user, I had some
| LSPs set up with neovim. But I was very much in doubt how to
| take advantage of these LSPs and what kind of configuration
| options make sense. The "hard" part is understanding what LSPs
| can do for you and what kind of key bindings I need to set up,
| so that I can use the relevant features.
|
| Helix gives you a sane user interface to LSPs that is
| _discoverable_
| jbrooks84 wrote:
| Vim is life, no need to change
| deadbabe wrote:
| It's true. Once you master Vim, your journey to find the
| perfect editor will have come to an end. For the rest of your
| career, you can rest assured you will be using some form of
| vim.
|
| But some people don't actually _want_ to find the perfect
| editor, they would rather stay on the journey forever, trying
| to master a new tool every few years. Sounds miserable, never
| knowing true mastery and enlightenment.
| ikety wrote:
| I use both helix and vim every day. After a while your brain
| just adjusts. It's like playing on playstation and nintendo
| for a long time. Eventually as soon as your hands touch the
| controller it switches to the appropriate mode.
| kgc wrote:
| What are your differing use cases for each editor?
| ikety wrote:
| My work setup is simply too complex and uses too many
| plugins to work in Helix as of now.
|
| For all personal work and just quick text editing I use
| Helix. If I could use Helix for everything I would
| BeFlatXIII wrote:
| Where does evil-mode land?
| tejohnso wrote:
| I just heard of Helix and decided to take it for a spin. I'm
| not sure why I'd use it instead of Vim.
|
| For all the Vim similarity, inverting the do-this-to-that seems
| like an arbitrary annoyance that I don't understand. Why go
| from "change this word" (cw) to "I want to change this word, so
| I'm going to select it first, then change it" (wc). I mean,
| it's not a big deal, especially if you're not already using
| Vim, but why THAT of all things? The difference is [explained]
| but the reasoning behind it is not.
|
| Also the docs mention zero configuration but the first thing I
| had to do was find out why the LSP wasn't showing any
| information and then create a config file to fix it because the
| default behaviour doesn't show anything from the LSP, which
| makes it seem like it's not even there.
|
| And there's no :help command.
|
| Maybe it's a great editor, but I guess they're not targeting
| existing Vim users for conversion.
|
| [explained]: https://docs.helix-editor.com/from-
| vim.html#migrating-from-v...
| andrewflnr wrote:
| Having separate commands for creating/modifying selections
| and for editing their contents is more orthogonal. In
| kakoune, you can select a word, multiple words, multiple
| search results, a brace-delimited block, or an arbitrary
| sequence of characters (it's pretty common that I want to
| include a bit of whitespace, or instance), and the same 'c'
| command works on all of them. The same 'd', 'i', and 'a'
| commands also work on all of them. In straight-line editing
| it's no more keystrokes than vim, and hardly more than any
| other editor, but for complex operations it lets you tailor
| and preview them as you go. The thing that confuses me is why
| it would even be a debate that this is better.
| eviks wrote:
| Because immediate visual feedback is more natural than having
| to imagine an operation in your head, it's the same logic for
| multiple cursors - where it's even harder to understand what
| "change this word" will actually change.
|
| > why THAT of all things?
|
| Because that's a fundamental improvement
|
| There were a few blogs with more detailed explanations, not
| sure about Helix, but kakoune had it covered
| https://kakoune.org/why-kakoune/why-kakoune.html
|
| > Kakoune tries hard to fix one of the big problems with the
| vi model: its lack of interactivity. Because of the verb
| followed by object grammar, vi changes are made in the dark,
| we don't see their effect until the whole editing sentence is
| finished
| llimllib wrote:
| the lack of a `gq` equivalent to reflow a paragraph, which
| julia mentioned, was the nail in the coffin for me when I
| tried it.
|
| It's a nice project though, I just use that feature
| constantly
| jvican wrote:
| I've fallen in love with Helix and now use it for everything.
| Moved from neovim and VS Code to Helix for the majority of my
| coding.
|
| For me, after trying the Lazy neovim plugin distro and being a
| long-time vim user, Helix fills a unique need:
|
| - It's beautiful (lots of attention to detail) - It's fast
| (meaning: at no point did I think Helix is slower than it should)
| - It's hugely ergonomic (each default keystroke resonates with me
| and the modal selection is a boon for my brain and productivity)
| - It requires almost no configuration out-of-the-box
|
| I can't be bothered to use neovim and configure it, and vim
| doesn't cut it. I need something in the middle between nvim and
| VS Code, and that's Helix for me. This might have been different
| had I been a vimscript wizard, which I'm not.
|
| I don't need Helix to be more modular or UNIXy, I simply need it
| to keep on the direction they've taken. There's a thriving
| ecosystem of tools around it, and I can use it with Claude Code
| (by simply refreshing the buffer when there's a new edit). What
| else can I ask for?
|
| Helix is a great editor, one of the very best I've ever used. As
| a result, I started chipping in monthly money to keep the project
| going.
|
| In terms of future improvements, the only one I'm missing the
| most is the ability to render images or math formulas from the
| editor, which I hope can at some point be done through a plugin
| using Kitty's terminal protocol or sixel. This is especially
| handy when working on Markdown files for notes or blog posts.
|
| Long live Helix.
| weinzierl wrote:
| All of this plus that with their approach of shipping an editor
| that is useable out of the box I feel a lot safer from supply
| chain attacks.
|
| No matter if VSCode or (neo)vim, needing tens of plugins from
| almost that many different parties always made me feel quite
| uneasy.
| christophilus wrote:
| Their cargo.lock file is 3500 lines or so:
| https://github.com/helix-editor/helix/blob/master/Cargo.lock
|
| So, I kind of agree with you, but that's still a lot of
| dependencies baked into the editor. It's probably not as bad
| as Neovim+plugins, but it's still a supply chain issue.
| raggi wrote:
| it's 317 unique crates, some of which are internal
| 305 with helix- removed 258 with gix removed (git
| stuff in multiple packages from a single upstream group)
| 240 with windows api wrappers removed. 170 if you
| remove all subprojects (split on -/_ taking first field,
| then uniq).
|
| what's left? fast math and various hashes
| backtrace utils various build utils some
| allocators, zero copy facilities, mmap and structures
| like lrus time and date handling character maps
| / internationalization concurrency libraries
| (futures, runtime, etc) cross platform path &
| directory helpers support for general unix platforms,
| for redox, for linux, for windows logging
| infrastructure some compression libraries
| markdown various testing helpers rope string
| representation shell lexer and utils terminal
| interaction models toml wasm & wasi
|
| compared to neovim, which is hard to determine because c &
| cmake toolchains are a bit of a shitshow to figure out, but
| lets take a look at maybe debian, that says 34 package
| dependencies downstream. The list is clearly missing a
| bunch of the toolchain, has limited portability and so on,
| but certainly shorter at 34 - for a single platform. Note
| also that neovim bundles several dependencies (e.g.
| markdown and so on - so they're "hidden" (almost surprising
| debian hasn't done their usual trick of insisting this
| isn't hidden))
|
| so where's the rest? well the rest is in the project: tokei
| says helix contains 132kloc. tokei says neovim contains
| 984kloc.
|
| so round a little and you get: helix has an order of
| magnitude more dependencies, but also an order of magnitude
| less code than neovim.
|
| while I'm sympathetic to concerns around dependency bloat,
| particularly with an eye to the js ecosystem and supply
| chain security, it's important to look through the right
| lens - when the functionality is fairly closely equivalent
| (there are differences, helix has a lot more modern
| features, vim has a lot more traditional text manipulation
| and unixy integration features), and there's an order of
| magnitude tradeoff in both directions - this is likely
| demonstration of fairly effective code sharing in helix.
|
| there are important supply chain safety techniques required
| when using a wide number of disparately owned dependencies.
| there are also important supply chain safety techniques
| required when managing a wide number of disparately owned
| sub-directories of a larger project. there could just as
| well be a needle in neovims vimscript haystack as there is
| in helix dependency stack, i can tell you now though, as
| i'm familiar with almost all of helix dependencies i've put
| eyes over their code at least once, there's almost
| certainly been more eyes on helix deps recently than on
| neovims vimscript - though eye's passing over don't always
| catch things either of course.
| eviks wrote:
| But once helix adds plugins it will be exactly the same
| because those tens of VSCode plugins provide functionality
| not present in helix, so will be similarly implemented
| externally
| weinzierl wrote:
| I hope they will properly sandbox plugins like any modern
| software should.
| lawn wrote:
| > This might have been different had I been a vimscript wizard,
| which I'm not.
|
| You mean Lua wizard (for Neovim).
| eptcyka wrote:
| At least lua is a real language, i.e. a language used by more
| than just vim.
| jack_pp wrote:
| If you need something between nvim and vscode what's the issue
| with using vscode with vim plugin?
| ar_lan wrote:
| > _I think what motivated me to try Helix is that I've been
| trying to get a working language server setup (so I can do things
| like "go to definition") and getting a setup that feels good in
| Vim or Neovim just felt like too much work. After using Vim
| /Neovim for 20 years..._
|
| I think this is catching me off guard. Especially in the past 5
| years there are Neovim distributions that make this extremely
| easy to configure.
|
| I am not disagreeing that many (most?) developers don't want to
| spend time debugging their editor - they just want it to work
| batteries included (or a simple button click to install). I think
| this is why JetBrains products are so popular (I still don't
| understand VS Code - it's the worst of all worlds between
| vim/emacs and Jetbrains).
|
| But if you've been a (neo)vim user for 20 years, it sounds very
| odd that you haven't successfully gotten LSP to work in a way
| that feels comfortable. I don't want to assume things about the
| author because I do not know them, but it feels unfair to say for
| vim and doesn't strike me as honest.
| r14c wrote:
| That is surprising. I didn't have much trouble getting LSP
| working either in og or neovim. My editor config is fairly
| barebones by preference, so its not like I spend a lot of time
| editing my configs either. I will say, Lua is a lot more
| ergonimic than vimscript for a lot of things, but I appreciate
| that I can still use the old ways at times. Like ALE isn't
| leaving my config unless I'm forced to remove it for some
| reason.
|
| I hope they're happy using helix tho
| skydhash wrote:
| I use a plugin[0] for LSP in vim and it's pretty easy to
| setup there too. Installing and configuring the lsp software
| itself take more time as I'm constantly moving between OS.
|
| Also, Emacs and Vim is very much about making the tool your
| own. I don't mind shaving the yak every now and then, because
| once an inconvenience is solved, it stay solved.
|
| [0]: https://github.com/prabirshrestha/vim-lsp
| lawn wrote:
| I've never used a distribution and LSPs are in my opinion easy
| to setup in Neovim and especially now with vim.lsp[0].
|
| [0]: https://neovim.io/doc/user/lsp.html
| mariusor wrote:
| I'm not sure your implication of LSPs existing, specifically
| for _vim, or in general, for 20 years is actually true in order
| that your questioning of Julia 's skills to actually make
| sense.
|
| As a similar example, I could never be bothered to install and
| configure any LSPs even though I've been using _vim for more
| than a decade. The friction of doing that was always just a
| little bit higher than installing a full blown IDE when the
| work actually requires high level LSP functionality.
| notdefio wrote:
| ar_lan specifically mentioned Neovim distributions. Examples
| would be LazyVim and AstroNvim. These are packages you can
| install that provide Neovim in a pre-configured and
| opinionated way. They generally come with language servers,
| linting, and various other features out of the box, and have
| their own paradigms for configuration.
|
| They can be easier to get started with than just installing
| Neovim from scratch. But they add their own complexities.
| First, you have to know that they exist, and pick one. Then
| you have to know how to configure them, they may have their
| own nuances about how things are done. Under the hood they're
| using all the same packages, so you'll need to learn how to
| configure those as well if you don't want the defaults.
|
| I would say the distributions to make it extremely easy to
| get started with a functional IDE experience with LSP
| features. But they're not without their own learning curve.
| ar_lan wrote:
| I'm trying to be careful to distinguish that this particular
| part seems odd to me, _specifically because of Julia 's other
| posts in which it seems their skill/knowledge is not much of
| a question._
|
| If someone is new to vim, I 100% agree that it's _easier to
| get started_ with VSCode /Jetbrains/etc.
|
| But if someone has been using vim for a long time as their
| default editor, especially Neovim, and when LSP support came
| to Neovim about 4 years ago [0], it comes across as someone
| who isn't a power user if they didn't end up installing it.
| Which is fine, but the community has also started to build
| reasonable "batteries-included" distributions of Neovim
| (LunarVim is a great example) if someone didn't want to
| figure it out themselves but still wanted to use it.
|
| It's one thing if someone just doesn't love the experience
| Neovim brings to them. That's reasonable, because it's
| subjective. But it is _odd_ to use a tool for so long and not
| further investigate what it offers to fit your needs. Before
| LSP, there were libraries (CoC for example). And if it was
| never satisfactory, why not look at alternative editors which
| had their own flavors of indexing /code navigation?
|
| --
|
| [0]: (https://github.com/neovim/neovim/commit/a5ac2f45ff84a68
| 8a094...)
| rpearl wrote:
| I've noticed a number of moderately sized companies
| "standardizing" on vscode tooling. You can use other editors,
| but they'll have extra special support for vscode: default
| project format settings or special tooling for debug
| integration specifically in the form of vscode config, that
| sort of thing. Recommended plugin sets.
|
| I also took pause at the claim that LSP was the issue. Neovim +
| treesitter + LSP feels... fairly solved at this point? It was
| definitely a bit rough 5 years ago, but it's pretty smoothed
| out now. Not sure where that opinion is coming from (and it
| feels at odds with everything else I've read from jvns, to be
| honest!)
| bee_rider wrote:
| When I worked with programming students we used VScode
| despite me, the professor, and most of the other grad
| students not liking it. It's just so easy to download, has
| the "run" button, and, well, at least it isn't Eclipse I
| guess.
|
| Vim is better of course it's just hopeless to get people to
| use it.
| ar_lan wrote:
| I think with Cursor choosing it as well, this will only
| continue to prevail. Professionally I've had to standardize
| on VSCode due to Cursor (there are a few plugins for Neovim
| but the experience is undoubtedly better in the first-class
| tool).
|
| By the way - I actually generally think this is a good thing
| that companies standardize on something. I might not like the
| choice they standardize on, but the barrier to entry for new
| engineers is already high, so having an easy-to-use and
| familiar development setup that "just works" from the start
| is pretty reasonable for large companies.
| fingerlocks wrote:
| Totally weird. LSP has been a neovim builtin for how long now?
| Two years?
| ar_lan wrote:
| 4 years. https://github.com/neovim/neovim/commit/a5ac2f45ff84
| a688a094...
| treve wrote:
| Also been doing vim and now neovim for 20+ years. LSP just
| broke and several keybinds alongside it and just not looking
| forward to figuring out what happened (but will anyway). It's a
| huge mental block for me whenever I need to get into
| configuration. So to me this feels very relatable.
| commandersaki wrote:
| That bit about search using the ripgrep plugin not providing
| context has always been available using telescope and a handful
| of clone plugins.
| sodapopcan wrote:
| Indeed, Vim has had ways to do this for years, before nvim. I
| suppose their point is that it comes out of the box? It is
| worded in a way that makes it seem like they think like there
| are no options.
|
| There are other things too, like pressing `*` then using `:%s`
| is no different than the behaviour they describe. I use a
| plugin that shows you all the updates live as you type making
| it essentially the same as multiple cursors (for this example).
| The only difference is that you're typing on the command prompt
| as opposed to the current line.
| lawn wrote:
| I think showing live preview for replacements is also a
| built-in Neovim feature now, but I can't remember if it's
| enabled by default or not.
| cycomanic wrote:
| That is not the same as helix multiple selections. I suggest
| trying our helix to really understand.
|
| I really liked helix, but the problem is that pretty much
| everything I use is setup using Vim bindings (shell, browser,
| ideavim,...) so switching to helix concept of editing was
| different enough to require effort, but close enough that it
| screwed up all my other muscle memory.
| sodapopcan wrote:
| Fair enough, I definitely made some assumptions there, but
| it sure sounds the same based on the description. I guess
| `%` selects more than just the token?
|
| But ya, I'm way too invested in Vim to bother with Helix. I
| have years of scripts and plugins I've written. I can't
| even be bothered to switch to nvim (I tried once and was
| not fun).
| weinzierl wrote:
| _" using a terminal-based text editor
|
| For many years I'd mostly been using a GUI version of vim/neovim,
| so switching to actually using an editor in the terminal was a
| bit of an adjustment."_
|
| For a long time my pain with this was that I often want to open
| an ephemeral editor while not losing context and sight of my
| terminal.
|
| With a GUI editor you always get a fresh window, but in the
| terminal this is difficult.
|
| Luckily zellij edit
|
| solves this issue nicely for me.
| Voklen wrote:
| I use Helix and Zellij and it has been amazing, requiring very
| minimal configuration and maintenance.
| eMPee584 wrote:
| from my `/etc/tmux.d/keyboard-shortcuts-comfort.conf`:
| bind-key j command-prompt -p "vim:" "new-window -c
| '#{pane_current_path}' 'stty -ixon -ixoff && vim %1'; select-
| pane -T '%1'"
|
| This binds `j` to prompt for files to open (* or just hitting
| enter works) and launches vim in a new window in tmux (turning
| off flow control and setting filename as title). Probably one
| of my most-used shortcuts.
| Macha wrote:
| I've tried helix a few times but I've also found it clashes
| violently with my vim muscle memory, largely because I still use
| vim in lots of not-vim environments like IdeaVim etc.
|
| Clearly I've been able to have seperate modes in my mind for
| "traditional" keybindings, as I don't find myself having
| difficulty switching from a text field in my browser or chat apps
| and then going to vim and back, so I wonder if it's just a case
| of the helix muscle memory needing to be so ingrained, or if it's
| just in an uncanny-valley to the vim experience.
| xwowsersx wrote:
| I feel the same way. I've put a lot of time into getting fast
| and efficient with Vim, so the benefits of another editor would
| have to be substantial to justify switching. As nice as Helix
| looks, I'm not sure it offers enough to make that leap.
| gtsop wrote:
| I got tired of the constantly moving space of IDEs and their
| plugins.
|
| After 10 years of writting software, i know exactly what i want
| out of my IDE, so i took up a clean (completely clean) neovim and
| started building every single functionality by myself exactly as
| i like it. I call it, jokingly, unlazyvim.
|
| I had been using vim for many years, but finally, after so many
| years my editor feels like a fine glove. Don't look up my code,
| don't ask what I built. Go build your own.
| klaussilveira wrote:
| Helix still has no way to emulate Sublime's Ctrl + Click (placing
| multiple carets), nor Sublime's Ctrl + D (duplicating selections
| and creating a multiple caret for each)?
| eviks wrote:
| It has both? Granted, Ctrl+D requires manual construction from
| a sequence of commands, but click to place extra carets works
| as is
| klaussilveira wrote:
| > requires manual construction from a sequence of commands
|
| Right, I saw some people share some snippets here before. But
| none of them act like Sublime does. I can't double-click a
| token and Ctrl + D to select next instances of it in my file.
| Shorel wrote:
| It's very funny to me that some comments before someone wrote
| that helix has the best multiple cursor implementation.
|
| I was curious about what could it be.
|
| Then you mention it doesn't have two essential behaviours that
| I am used to, and I wonder if these people just know vim and
| cli editors and that's why they have such opinion. Because I am
| also a SublimeTexter.
| mechanicum wrote:
| Cmd + click places multiple carets on macOS. Apparently - I
| never touch the mouse when I'm editing in Helix. I don't know
| which modifier it is on other platforms.
|
| I'm not sure if replicating Sublime's Ctrl + D is possible or
| not, but there are other ways to achieve every use case for it
| I can immediately think of. e.g. I think I'd typically be doing
| `<space>h` to select every instance of the symbol under the
| cursor, or using `s`elect to reduce a selection to a match,
| possibly yanked and pasted.
| runaway wrote:
| There might be a better way but this bind works well for me
| in normal and select modes. C-n =
| ["search_selection", "extend_search_next"]
| impoppy wrote:
| I switched to Helix a year ago and I'm very happy about it. I
| used to spend way too much of my free time configuring my editor
| and now that I can't do that I use my free time to actually write
| some code!
| eviks wrote:
| > crashes: every week or so there's a segfault and the editor
| crashes. ... This doesn't bother me that much though, I can just
| reopen it.
|
| Strange approach to data loss, since it doesn't have persistent
| undo, you can't just reopen it to the same editing state?
|
| > After using Vim/Neovim for 20 years, I've tried both "build my
| own custom configuration from scratch" and "use someone else's
| pre-buld configuration system" and even though I love Vim I was
| excited about having things just work without having to work on
| my configuration at all.
|
| I don't really get it given how primitive the resulting Helix
| config is (I mean, even the most frequent commands are based off
| the mistaken unergonomic w/b defaults), presumably you would've
| been able to replicate it comletely in the first X years of using
| vim, and then there is no hell anymore?
|
| > little help popup telling me places I can go. I really
| appreciate this because I don't often use the "go to definition"
| or "go to reference" feature and I often forget the keyboard
| shortcut.
|
| Exactly! Pity this basic contextual help isn't more widespread,
| every single app that uses a lot of keybind sequences could
| benefit from it, especially if it becomes a bit smarter and only
| shows a popup if you don't finish the sequence right away
| tasn wrote:
| > Exactly! Pity this basic contextual help isn't more
| widespread, every single app that uses a lot of keybind
| sequences could benefit from it, especially if it becomes a bit
| smarter and only shows a popup if you don't finish the sequence
| right away
|
| I've been using Vim/Neovim for 20 years, but still can't get
| enough of which-key[1] which I only installed ~6 months ago.
|
| 1: https://github.com/folke/which-key.nvim
| eikenberry wrote:
| mini.clue is another good option for this feature in neovim.
|
| https://github.com/nvim-mini/mini.clue
| zahlman wrote:
| > every single app that uses a lot of keybind sequences could
| benefit from it, especially if it becomes a bit smarter and
| only shows a popup if you don't finish the sequence right away
|
| Counterpoint: the sequence should only have an opportunity to
| be "unfinished" if there's actually a choice to make. Showing
| too many choices at once can be overwhelming and in the Vim
| environment there are usually a ton of choices. Consider for
| example if I input `n10` in editing mode; that could be
| followed by all kinds of repeatable actions _and_ it could be
| followed by another digit of the count.
| eviks wrote:
| > if there's actually a choice to make.
|
| I don't get it, there is always a choice to make, which is
| which action to continue with?
|
| > Showing too many choices at once can be overwhelming
|
| It can't be more overwhelming than having to remember all of
| those choices and using external docs/configs to look them
| up! Besides, it's not like there are no improvements possible
| and you have to show everything at once. For example, all
| your "all kinds of repetable actions" can be limited by the
| most frequently used 10 actions and an "others" submenu you
| could invoke separately if you were looking for something
| else. And your "another digit" is just a single line "0-9
| continue the count", so what's the issue there?
| zahlman wrote:
| > I don't get it, there is always a choice to make, which
| is which action to continue with?
|
| The point is that if the input for a command is XY, there
| had better also be an XZ. Otherwise XY should just be X.
| eviks wrote:
| How is this relevant to the tooltip conversation? If you
| have XY (without XZ) instead of just X, well, maybe you
| could simplify, or maybe it still makes sense for you for
| some reason, whatever, in any case you'd appreciate
| immediate contextual help if you press X and then forget
| that Y is the finisher.
| FridgeSeal wrote:
| You're going to hate that my shortcut for Normal mode is
| j-k, and I don't have any other j-* commands.
| NetMageSCW wrote:
| I think you completely missed the context for the configuration
| issues in vim:
|
| I've been trying to get a working language server setup (so I
| can do things like "go to definition") and getting a setup that
| feels good in Vim or Neovim just felt like too much work.
| rand0m4r wrote:
| It might have been a bit harder in the past, but with recent
| versions of neovim (>=0.11) it's less than 20 lines of
| configuration. I have quite a few keybindings to jump back
| and forth through errors and the default keybidings already
| include things like renaming, go to definition or listing
| references.
|
| I'd be more than happy to help you configuring it to your
| needs.
| neutronicus wrote:
| FWIW, in my (emacs, C++) experience, writing the editor
| config is a relatively minor part of the yak-shaving
| required to have jump-to-definition on an actual work
| codebase.
|
| I had to get my project to emit compile_commands.json, get
| clangd, figure out which things about our build process
| clangd was not understanding from compile_commands.json and
| add them in .clangd. All to achieve a level of
| functionality significantly jankier than just opening the
| damn .sln file in Visual Studio.
|
| Once I did all that it was, as you say, very little actual
| stuff written in my .spacemacs. And probably could have
| been less if I had felt like figuring out how to get my
| windows emacs to find clangd on the path instead of giving
| up and just specifying full paths to everything.
|
| I only persevered because emacs (unlike Visual Studio)
| gives you all the necessary access to its internals to
| build LLM Tools around its LSP functionality.
| galangalalgol wrote:
| Whatever vim is in rhel 8 supports ale. Ale with rust has
| been great. Go to definition is flawless, all my conpile
| and clippy errors are underlined as I type and binding a
| key to ALECodeAction will apply the auto fix if it has
| one. Usually that is to import whatever I just used,
| which vscode would do automatically, but still its nice
| and having vscode use clippy as well as check bogs it
| down. And ale runs cargo-fmt on save. So yeah, nothing
| I'd wish different from it.
|
| Edit: upon further thought, I don't like having to move
| my hand to the arrow keys to select from the auto
| complete list, even if there is only one thing and then
| hit enter, rather than hitting tab to pick whatever is
| left.
| lemonwaterlime wrote:
| Not sure where you are having issues, but I set up a general
| LSP configuration in my vimrc in vim and just add new
| languages. Everything has worked for me for years.
| " https://github.com/prabirshrestha/vim-lsp "
| https://github.com/prabirshrestha/asyncomplete.vim "
| https://github.com/prabirshrestha/asyncomplete-lsp.vim
| " " The LSP and ALE (above) are set to work together.
| Some of their features overlap. " ALE will handle
| linting, fixing, and errors/warnings " LSP will handle
| symbol navigation and autocomplete. " General LSP
| Settings function! s:on_lsp_buffer_enabled() abort
| " Disable ALE LSP for compat " ALE - handles linting
| and formatting " LSP - handles code semantics, code
| navigation let g:ale_disable_lsp = 1
| setlocal omnifunc=lsp#complete setlocal
| signcolumn=yes if exists('+tagfunc') | setlocal
| tagfunc=lsp#tagfunc | endif " >> KEYBINDINGS
| nmap <buffer> gd <plug>(lsp-definition) nmap <buffer>
| gD <plug>(lsp-declaration) " Think
| implementations/instances of a class nmap <buffer> gi
| <plug>(lsp-implementation) nmap <buffer> gt
| <plug>(lsp-type-definition) " Where is this
| symbol used? nmap <buffer> gu <plug>(lsp-call-
| hierarchy-incoming) " What uses this symbol?
| nmap <buffer> gU <plug>(lsp-call-hierarchy-outgoing)
| " What are all symbols in file (with categories)?
| nmap <buffer> gs <plug>(lsp-document-symbol-search)
| " What are all symbols in codebase? nmap <buffer> gS
| <plug>(lsp-workspace-symbol-search) " All
| references to symbol in codebase nmap <buffer> gr
| <plug>(lsp-references) "nmap <buffer>
| <leader>rn <plug>(lsp-rename) " Jump to
| next/prev error/warning nmap <buffer> [g <plug>(lsp-
| previous-diagnostic) nmap <buffer> ]g <plug>(lsp-
| next-diagnostic) nmap <buffer> K <plug>(lsp-
| hover) "" Scroll in popup menu with keyboard
| "nnoremap <buffer> <expr><c-f> lsp#scroll(+4)
| "nnoremap <buffer> <expr><c-d> lsp#scroll(-4)
| " >> AUTOCOMPLETE WITH LSP {asyncomplete plugin} let
| g:asyncomplete_auto_popup = 0 " >>> Tab
| completion function! s:check_back_space() abort
| let col = col('.') - 1 return !col ||
| getline('.')[col - 1] =~ '\s' endfunction
| inoremap <silent><expr> <TAB> \ pumvisible() ?
| "\<C-n>" : \ <SID>check_back_space() ? "\<TAB>" :
| \ asyncomplete#force_refresh() inoremap
| <expr><S-TAB> pumvisible() ? "\<C-p>" : "\<C-h>"
| " >> Preview Window " >>>> Enable Preview Window
| " allow modifying the completeopt variable, or it will
| " be overridden all the time let
| g:asyncomplete_auto_completeopt = 0 set
| completeopt=menuone,noinsert,noselect,preview "
| >>>> Auto close preview window when done autocmd!
| CompleteDone * if pumvisible() == 0 | pclose | endif
| endfunction augroup lsp_install autocmd!
| " call s:on_lsp_buffer_enabled only for languages that has
| the server registered. autocmd User
| lsp_buffer_enabled call s:on_lsp_buffer_enabled()
| augroup END
|
| --
|
| Then for a new language, I just define one of these:
| " >>> Rust LSP Setup " Configure vim-lsp to use Rust
| " https://github.com/prabirshrestha/vim-lsp if
| executable('rust-analyzer') augroup lsp_rust-analyzer
| autocmd! autocmd User lsp_setup call
| lsp#register_server({ \ 'name': 'rust-
| analyzer', \ 'cmd':
| {server_info->['rust-analyzer']}, \
| 'allowlist': ['rust'], \ })
| autocmd FileType rust setlocal omnifunc=lsp#complete
| endif
|
| --
|
| These days, I just use ctags and grep for most languages,
| though. Simple and fast.
| jfvinueza wrote:
| I've been using Helix daily for about three years, and it has
| crashed about five times. It is very, very rare for it to
| SEGFAULT.
| eviks wrote:
| > every week or so there's a segfault and the editor crashes.
| simjnd wrote:
| > presumably you would've been able to replicate it completely
| in the first X years of using vim, and then there is no hell
| anymore?
|
| I agree with this, but being able to ssh into a server and just
| grab Helix instead of copying over my Vim config and whatever
| else it depends on is really nice. Makes your dev env feel a
| lot more portable (although also more barebones than a crazy
| Vim config)
| mi_lk wrote:
| It's not like Helix is as ubiquitous as Vim on a random
| remote server. If that's not the case surely the effort to
| install Helix is bigger than copying Vim config?
| joemi wrote:
| >> little help popup telling me places I can go. I really
| appreciate this because I don't often use the "go to
| definition" or "go to reference" feature and I often forget the
| keyboard shortcut.
|
| > Exactly! Pity this basic contextual help isn't more
| widespread, every single app that uses a lot of keybind
| sequences could benefit from it, especially if it becomes a bit
| smarter and only shows a popup if you don't finish the sequence
| right away
|
| I agree 100%. This would be helpful in so many places. That was
| my favorite part of the article -- one little paragraph and
| screenshot, but it made me desperately crave that feature
| almost everywhere. I agree that it'd need to be smart about it
| -- after a timeout, as you mentioned, is a great idea. That way
| it can stay out of your way if you know what you're doing, and
| only pop up when you hesitate.
| bionsystem wrote:
| Neovim with lazy.nvim has that by default (delay included).
| thefaux wrote:
| I cannot express how liberating it feels to opt out of "advanced"
| editor tools like lsp. I program in neovim with no plugins, no
| syntax highlighting and no autocomplete of any kind. There is a
| discipline that this imposes that I believe leads to better
| quality programs. It's not for everyone I suppose, but I really
| recommend trying it.
| yacthing wrote:
| Most people optimize for productivity and not raw quality of
| code. I can't imagine that your productivity is higher for
| removing autocomplete.
|
| I'm not saying you need every plugin ever, but autocomplete?
|
| Maybe you haven't tried "advanced" editors in a while, and it
| was a lot worse last time you tried?
| efxhoy wrote:
| I had a few periods of doing the same in sublime text, I did
| use syntax highlighting though. It's a really great feeling and
| very liberating, especially in a greenfield project.
|
| Can't really justify it at work though, projects are too big to
| and gnarly keep in my head.
| chongli wrote:
| Why neovim for this? Why not nvi? Even less distractions that
| way!
| b00ty4breakfast wrote:
| I can see no plugins, I can even see no autocomplete but no
| syntax highlighting is just making things difficult for the
| sake of it
| GalaxyNova wrote:
| The true Plan9 aesthetic
| ratrocket wrote:
| To each their own. I quit using syntax highlighting about 10
| years ago and won't ever go back (been programming for 25
| years, vim/neovim user for 24 years). I just like it better,
| it works for me. It definitely does not make things
| "difficult for the sake of it" (for _me_ ). There are dozens
| of us! :)
|
| (As to the rest: I use a pretty minimal set of plugins and I
| use the built in nvim C-o/C-p or C-x C-o/p "dumb"
| autocomplete. At least I think it's built in...)
| skydhash wrote:
| You kinda get used to it. I often `cat` and `less` code in
| the terminal and my $EDITOR is `mg`. I know about bat, but
| it's never in base.
|
| And I'm using more my mental idea of the code and direct
| line:column navigation. My context is often less than 10
| lines of code.
| dtj1123 wrote:
| I recently found out that Mitchell Hashimoto has a setup like
| this, which blew apart my belief that you need modern tooling
| to be productive. Do you not find that you fatigue more quickly
| as a result of having to actively recall everything though? I
| can't understand how doing things like this would actually
| result in better code.
| skydhash wrote:
| Not GP, but I can add my two cents.
|
| The trick is to avoid idle browsing of the code. Be
| intentional about what you need to do.
|
| I use tools like grep/ripgrep to get a more focused of the
| code. Then with the line number, I can jump directly to where
| I need to be. Same with tools like linters and compilers.
|
| In the same file, I often use search instead of
| line/character movement. You search for a symbols and you
| just cycle through their location.
|
| I don't think it leads to a better code. But badly organized
| code will make this harder, so you tend to think about
| organization.
| scuff3d wrote:
| I'm not sure that's true. I've heard him talk in several
| interviews about using AI tools, including in his editor.
| Definitely not a minimalist setup.
| scuff3d wrote:
| I do this when working on personal projects. I don't go this
| far though. I still like having syntax highlighting, and I have
| an LSP on to try in editor feedback on syntax errors, but I
| don't use auto completete or in editor documentation.
| tooltalk wrote:
| too invested in LazyVim.. just learned to use "edgy" with
| multiple windows: neo-tests, fs browser, diagnostic-trouble,
| Outline, etc.. and they are just too nice.
| almog wrote:
| The one time I tried Helix, I could find no way to switch from
| noun-verb syntax to vim's noun-verb syntax, is it possible now?
| dcre wrote:
| No. Noun-verb is central to the design. Everything is built
| around it.
|
| The best writing about this is "Why Kakoune" (Kakoune inspired
| Helix): https://kakoune.org/why-kakoune/why-kakoune.html
| cycomanic wrote:
| Not really, there is a config and some patches (helix-Vim IIRC)
| that gets you close, but it is still different. It also feels
| like you're throwing out helix main selling point.
| fithisux wrote:
| I never managed to understand Vim/Emacs/Vile/Neovim.
|
| Helix seemed all the same until I started watching a series of
| tutorials on Youtube.
|
| I get better everyday.
|
| I'm on Windows 10 x64 BTW
| quirino wrote:
| The best thing to have happened to nvim in recent history is
| mini.nvim. It's a collection of plugins by echasnovski which
| satisfies many of your needs in a very consistent, very well
| documented way.
|
| With nvim 0.12 (nightly) I've switched to vim.pack (built in
| plugin manager) and the only plugins I had to install are
| mini.nvim and lspconfig.
| ratrocket wrote:
| To save anyone else the search:
|
| mini.nvim site: https://nvim-mini.org/mini.nvim/
|
| repo: https://github.com/nvim-mini/mini.nvim
| eikenberry wrote:
| I switched from Neovim to Helix as my primary editor for around a
| year before switching back to Neovim. The way I'd describe the
| difference is that Helix is a text/code editor and Neovim is a
| toolkit to build a text/code editor. Helix is very simple and
| hits the 'just works' pretty well, but it's development is slow
| and w/o extensions it isn't flexible enough to handle every
| situation. Neovim can be a PITA to setup and maintain, but it's
| flexibility and power are very compelling. It also is semi-
| mainstream and gets a lot more support... eg. it has the only
| official, non-vscode, copilot plugin. I still use Helix as my
| backup editor (when I'm fixing issue with Neovim) and I look
| forward to it maturing a bit more and for the extension system to
| land and see where it goes after that.
| danslo wrote:
| I tried to switch from neovim to helix for a couple weeks, but
| noted down the following things that were essential to me and not
| implemented yet:
|
| - Code actions on save, for example adding Go imports:
| https://github.com/helix-editor/helix/pull/6486
|
| - Fuzzy search with a filepicker like telescope+rg, seems to have
| been added earlier this year: https://github.com/helix-
| editor/helix/pull/11285
|
| - Automatically updating buffers when the files on disk change
| (claude, templ, sqlc, etc): https://github.com/helix-
| editor/helix/issues/1125
|
| - File tree in browser, which has been rejected in favor of a
| plugin system which has not materialized yet:
| https://github.com/helix-editor/helix/pull/5768
|
| There were a number of other things too, that I could have lived
| with. I guess I'll try again in a year or two.
| jzelinskie wrote:
| I rebuild from HEAD using homebrew quite regularly and have
| maybe had a single crash in years using Helix, so I'm shocked
| to see Julia report she's had crashes. But because I run HEAD,
| I can tell you what's actually merged which might not be
| released yet:
|
| > Code actions on save
|
| There are command on save hooks which solve the problem for Go,
| but I could see this being not as applicable for other
| languages.
|
| > Fuzzy search
|
| Man, I'm pretty sure this shipped before telescope was
| particular stable or popular. Although, I don't recall if Helix
| originally used the ripgrep backend at first. They reworked it
| earlier this year and it was a massive improvement.
|
| > Automatically updating buffers
|
| +1 to this. I constantly suspend (ctrl+z) my editor and
| sometimes forget about it and could really use this prompt.
|
| > File tree in browser
|
| Space+e or Space+E opens a hierarchical file explorer on HEAD,
| but this is definitely relatively new
| zimpenfish wrote:
| > I tried to switch from neovim to helix for a couple weeks
|
| I bounced off after a couple of hours because 35 years of
| muscle memory for vim commands meant I was making constant
| infuriating mistakes[0]. Which is a shame because I'd really
| like to use helix and avoid the neovim config faff.
|
| [0] I did try one of the "vim keybindings for helix" but they
| were only partially correct and that annoyed me even more.
| dtj1123 wrote:
| Although the file explorer you link there was abandoned, a vim-
| telescope style explorer was merged earlier this year.
|
| However, when you already have a fuzzy-search based file picker
| built in, an explorer doesn't bring much extra utility.
| scuff3d wrote:
| Totally disagree. I find having both extremely useful. Once I
| start to get to know a code base jumping through files with
| telescope is super useful. But when I'm getting spun up on a
| project and don't know what files I'm looking for, a file
| tree is super nice.
| ngrilly wrote:
| I have the same issue with Helix not watching and reloading
| modified files automatically, as I sometimes run external
| programs modifying those files (templ and sqlc are good
| examples). Curious about how experienced Helix users are
| addressing this.
| colordrops wrote:
| The first example of grep-ing source code is not great. It's
| trivial to install something like Telescope to have functionality
| similar to the Helix screenshot.
| NetMageSCW wrote:
| But how much do you have to find, vet (how much do you trust
| Telescope to not steal your credit cards one day), and install
| for all the features of helix?
| kesor wrote:
| And you can vet that Helix will not be stealing your personal
| information now and in the future? What an asinine comment.
| There is no security, the computer is spying on you, you
| can't really vet anything.
| zoidb wrote:
| The bloat of the neovim distributions are real and what I would
| suggest for anyone who is a long time vim user is to check out
| kickstart. https://github.com/nvim-lua/kickstart.nvim ,
| specifically the modular fork
| https://github.com/dam9000/kickstart-modular.nvim which will give
| you a great (minimal) starting point
| dtj1123 wrote:
| If you're interested in learning Helix, consider doing so from
| the legendary nic-revs redo of the Helix docs:
|
| https://helix-editor.vercel.app/
|
| Significantly more pleasant to look at than the OG docs and he
| includes some nice tips and tricks, e.g. recipes for efficient
| editing and keybinds that help mitigate the lack of a built-in
| terminal.
| shoobiedoo wrote:
| Thank you for this. I was always baffled by the unreadability
| of the official docs. For me, at least
| jvican wrote:
| `hx --tutor` is a life saver though. Did that to quickly
| catch up on hx keybindings and Claude chips in when I need
| more efficient things to do certain text editing operations.
| ngrilly wrote:
| I've been trying Helix and really like it. But as someone coming
| from VS Code, I've been relying a lot on VS Code automatically
| saving and restoring sessions on restart (things like opened
| files, unsaved files, cursor position, etc.). It's helpful when I
| occasionally restart my computer. How do you that in Helix (or
| for that matter in Neovim)?
| nrvn wrote:
| As they say, YMMV.
|
| My personal journey:
|
| 2010-2014 - sublime text
|
| 2014-2017 - vim and later neovim (bunch of plugins to resemble
| IDE-like experience)
|
| 2017-2024 - jetbrains (intellij idea with language plugins
| mostly)
|
| 2024-now - neovim (with lazyvim)
|
| I tried helix in 2023 but it did not stick. Do not remember
| details but remember the final impressions of having to train
| muscle memory to "awkward" vim-like key bindings and dealing with
| various annoyances and bugs. End of trial and error I left it as
| a terminal $EDITOR for quick and adhoc tasks while doing all the
| heavylifting in intellij. Ditched it finally when vim muscle
| memory and hx muscle memory made my brain short circuit several
| times in a row.
|
| Now I am back to neovim and it is surprisingly as productive
| (when equipped with proper plugins) as the beefy jetbrains IDEs.
|
| That said, helix looks promising. Maybe it's the next big thing,
| who knows)
| dividedcomet wrote:
| I tried both nvim and helix from vscode, and no luck. I feel like
| I don't need a lot (syntax highlighting, lsp, goto definitions,
| file hot reloads, and crucially, a file tree). I can kinda get
| nvim there, but it falls apart when I can't just enter and exit
| the file tree+file viewer with a simple 'vi or q!'. Maybe I don't
| understand quite how to get the config just right, but so far a
| friendly terminal first code editor seems out of my grasp.
| sirfz wrote:
| Funny I just updated my neovim lsp configuration yesterday to get
| rid of mason and have more control over my tools and found
| neovim's new vim.lsp.config API really easy to use.
|
| fzf-lua (and several other picker plugins) provide really
| powerful features and ux out of the box.
|
| I understand that configuration can seem overwhelming but
| investing a few hours will be really rewarding. I love (neo)vim
| imjonse wrote:
| "Helix doesn't have tabs, instead it has a nice buffer switcher
| (<space>b) I can use to switch to the buffer I want"
|
| It has tabs if you add (the completely undiscoverably named)
| bufferline="multiple" to the [editor] section in config.
| dcre wrote:
| I use :reflow (mapped to =) decently well for wrapping comments,
| but it doesn't do well at splitting a long single line into
| multiple lines. My workaround is to add a second empty comment
| underneath and include it in the selection before hitting =.
|
| Likely fix here, coming soon according to the last comment:
| https://github.com/helix-editor/helix/pull/11738
| klauserc wrote:
| Was using vim for a decade, discovered Helix, installed it on all
| my systems and haven't looked back (at least not voluntarily; I'm
| always bewildered by the old-school CAD-like command-then-subject
| paradigm when I get thrown into vi on a random machine)
| sectoristerkx88 wrote:
| the percentage of shell scripts that are written in vi as opposed
| to vim is disproportionate, which is the litmus test for nano and
| v-studio types
| conaclos wrote:
| I tried Helix two years ago, unfortunately the default keymap was
| a bit frustrating to me. I don't mind changing my habits, however
| I had difficulty I made sense of the keymap design.
|
| For example, typing `w` select the word. However, typing `2w`
| select the second word and not two words. To select two words you
| have to enter in visual mode (`v2w`). To remove two words you
| thus need to type `v2wd` or `wdwd`. In Vim you can type `d2w`. I
| miss this composability. In Kakoune (one of the main inspiration
| of Helix), you can type `2Wd` (`2wd` has the same behavior as
| Helix).
|
| I was also hoping that the use of Ctrl/Alt modifiers be
| completely removed. Why not fully embrace modal editing?
___________________________________________________________________
(page generated 2025-10-10 23:00 UTC)