I don't see the problem. It's a great result: (paraphrasing) "people arguing about whether code folding is useful or not is pointless. we're going to do it eventually but not right now." What's wrong with that?

In therapy, I love the thought experiment of "What could he have said instead?" and WHY did he choose THIS exact phrasing, out of the millions of approaches he could have chosen?

Say that he is concerned about the time required for the project and only wants to safeguard the project. The post could convey the exact same message like this:

--- Alternative fictional answer by maintainer--- Confirming that code folding is a planned feature. It's a high-impact addition, but the implementation is non-trivial and requires careful design. The primary blocker is technical: our current buffer and positioning logic (see src/core/text_object.rs). A correct implementation requires a significant refactor of how we map logical buffer lines to visual screen positions.

Because core dev time is focused on xxx, a community-led effort is the most realistic path forward for this feature. I can provide review and guidance, but won't have the bandwidth to drive the implementation myself in the near term. If anybody want to contribute, Analyze the groundwork in PR #6417.

I'm keeping this issue open for high-level implementation strategies. Please take detailed design proposals to a new thread in Discussions to keep this focused. Off-topic comments will be removed. --- end of fictional answer ---

Basically, it all comes down to the vibe each response gives off. The real post is a classic "Do Not Enter" sign. The maintainer acts like the only one with the keys, essentially saying, "This is too hard for you, so don't even bother." It shuts the door on anyone who might want to help, which means the project is stuck waiting for that one person to have free time.

My rewritten version is more like leaving the door open for other smart people. The attitude is, "Look, this is a tricky problem and I'm swamped. If you're up for a real challenge, here’s the map to get started." It respects other developers' skills and invites them to be part of the solution.

I think the key to a great open-source project is that you have to actively build a team you can trust. You do that by giving people a real chance to contribute, learn the hard stuff, and eventually share the load. That's the only way a project grows beyond a one-person show and actually sticks around for the long haul.

It's fine that they dont want to do it or dont want to do it yet.

Still, I wasn't especially impressed with "code folding is hard, we might do it one day but don't hold your breath" from an editor that purports to be a replacement for vim or neovim.

Development is a bit slow because there are only a few maintainers, but also because they have a strong vision and are very aggressive about prioritization and rejecting features that don’t fit. This is why Helix is so good and so focused a tool.

I've never used Helix and I likely never will, so I've got no horse in this race. But code folding, seriously? I'd be totally against it. It's yet another editor feature that ties your source code to tooling. It allows you to write too large and too many functions, while keeping the code readable to yourself. Source code should be readable (mostly) independently of tooling. It should be readable when printed to paper. (This is also why type inference in languages that aren't inherently functional languages is incredibly stupid; I understand that the compiler can infer the type under "auto", but now, when reviewing the code, I too must. Who the fuck wants that, seriously.)

And I'm unsure what your problem is with the discussion in the ticket. I've now read the first comment (the feature request), and the last comment (the one you highlighted). Both sound totally reasonable to me.

Could not agree more with everything you said. I hate code folding because it leads to giant functions and blocks that are way too big, but because of the folding people don't have to look at it and scroll (which if they did, they would be much less inclined to write and ship such shit in the first place). Same with type inference. It's almost no effort to write out the type, and it's eminently readable. With type inference, it's not at all obvious. I usually get "well you can just hover over it with the IDE and it will tell you the type." I don't want to have to hover over stuff just to see the type! Not only is that a major downgrade from the previous state where it was just "String some_str" or whatever, but having to pause and grab the mouse and move it over to the variable is majorly disruptive to reading and requires me to use a mouse (which I don't normally use). Also, I use neovim, not whatever IDE you use and think everyone else must use.

I likewise thought the final response linked to was great. It was straightforward and to the point.

The way to prevent giant classes and methods is with linting rules, not by crippling your text editor.

type inference makes code waaaaaay less verbose which aids readability.

> It should be readable when printed to paper.

Why should anyone waste time targeting a dead use case?

Right. But if we replace 'paper' with 'webpage' the parent post is still relevant.

Web page can run (and some code-focused pages do) code folding code, so the question is still relevant with minor modification.

The whole premise of losing productivity and spending time in the most common case to support underpowered rare use cases is deeply flawed.

It's similar to the argument for using bad defaults in config/keybinds 99% of the time just because in 1% of the time you would use another computer without your customizations.

What's so bad about this? I skimmed through it and it seems like it was handled quite well. Curious what you're learning from it about the project health.