• vort3@lemmy.ml
    link
    fedilink
    arrow-up
    11
    ·
    9 months ago

    I was reading some opinions and blogs about helix and thought it’s really cool, gave it a try, and almost immediately switched back to vim. It was the moment when I tried to use some regex substitution and as it turns out there are no regex matchgroup substitutions in helix. You can’t easily do stuff like replace all occurences of a pattern “firstword secontword: thirdword” with “thirdword - firstword” for example. At first I thought that I’m just new to this editor and don’t know how it’s done, then after searching for a while found that helix doesn’t try to implement things that can be done by external tools, and the way to go is pipe your selections (or entire buffer contents) to sed or awk or whatever and and read from their stdout back into your file (?).

    So, while it feels more unix-way (why have regex substitutions when you can pipe into tools that already do this), I still like that vim has this builtin, it feels more integrated into the tool probably. At this point, if helix doesn’t want to implement things other tools can do, why even have regex search and select? This could be done by piping into grep as well, I think. Anyway, just my silly opinion and my experience with helix is that I can’t use it without regex match groups and substitutions and I’m too lazy to learn how to pipe into sed and do this properly in helix, and it feels natural to me that vim has this builtin with a great amount of advanced options and features.

    Like, for example, in vim you can do regex searching and tell vim which part of the match should be your final selection. It’s incredible how powerful regexes in vim are.

    • dgkf@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      9 months ago

      For anyone who’s curious, this is the state of discussing this feature: https://github.com/helix-editor/helix/discussions/8572

      I’m not an authority on the helix ethos, but I’ve contributed a bit and hung around long enough to have a good read on their stance on most topics. The project is still young and managing the growing pains of getting a lot of traction relatively early. I think the devs value keeping the maintenance footprint small to keep the project sustainable.

      The philosophy of helix’s design is to be a more convenient kakoune, not necessarily a vim. vim is much more widely known, so that analogy springs up more often, but this idea of using piping out to an external command for most operations comes from kakoune.

      For features that would introduce significant maintenance overhead, may jeopardize the performance of a more common workflow or where the design goals are still maturing, the team tends to push such suggestions toward being developed as plugins when that system is added. I get the impression that they see the value of this workflow, but would prefer to see it battle tested as a plugin first.