Add Code Folding

[waterlubber]

As far as I can tell, Helix does not (yet) support code folding.
Syntax or LSP/Treesitter based code folding is probably my most missed feature from nvim,

It would probably be best to add it in a similar manner to nvim's approach, although initial patches might only support syntax-based folding if it's simpler.

There's a chance I might have missed this feature - I couldn't find it in the editor, documentation, or as an issue, so I figured I'd make the feature request. Apologies if I have missed something, though!

[r-odriguez]

Just for the matter of visualization:

I think this is a pretty nice UI (it's from neovim)

[naveedpash]

any progress on this?

[EriKWDev]

I find myself really missing this. In rust when you have a bunch of "pub mod foo { /* ... */ }" it can be very handy to be able to fold them away when not working on them.

[crispinb]

I find emacs-style narrow (aka hoist) more useful than the (more common) fold. Folding complects navigation with focusing, but navigation is already covered by lsp. Narrowing is extremely useful for focusing singly on a chunk of code to be worked on. It's a shame narrowing isn't more widely implemented - perhaps helix has an opportunity here.

[Zoybean]

I've never encountered narrowing before, but from googling it just now, it seems like it might serve a different use case than folding, and maybe they could both be added?

[crispinb]

Sure, they're not incompatible. Emacs has both.

My perspective (no more than that!) is that folding doesn't offer much given its relative UX complexity (multiple operations and keybindings). It does 2-3 things: offers a code overview + helps with navigation, and allows you to focus on one section of code by folding others.

To me, navigation is already taken care of by many existing helix/lsp features. Focus is managed much more simply by narrowing - it's just a single and simple pair of operations (narrow/expand), which fit like a glove with a central existing concept (the selection - to which you can narrow).

That leaves potentially the code overview as folding's one unique use. Seems like a sledgehammer to crack a nut to me, and probably handled better by other (and again simpler) means, but obviously it's pretty subjective. Folding is far more widely implemented than is hoisting, so I guess people must find it useful.

[Zoybean]

Yeah, I admit that from my experience with folding in vim, it does feel clunky even when it's working properly, so I see some value in investigating other possibilities for a code overview feature aside from traditional folding.

[SoraTenshi]

Just for the matter of visualization:

I think this is a pretty nice UI (it's from neovim)

this is only possible once virtual text is implemented.

I believe to implement this (to have it done in a imo nice way) would be to wait once #417 is merged.

[emilyyyylime]

I don't think it makes sense to drop folds in favour of narrowing, but I'd be glad to have narrowing in core. I can imagine it in it's own submenu with equivalents for all tree-sitter movement commands (A-[iopn]), and exiting and entering narrow. If it does get in though, I would like to see it implemented as in https://github.com/Malabarba/fancy-narrow, though at narrowing may be deservant of its own issue.

Do note I have 0 experience with narrowing and I'm saying all of this only after a tiny bit of research into what it even is and why its useful. I think done like in https://github.com/Malabarba/fancy-narrow it would get a very real usecase of helping with focusing on code and let the other commands I've suggested above operate much more smoothly, unlike when just creating a virtual buffer.

[creikey]

Would really love folding so I can navigate big files reading a succinct overview, then have the ability to drill down into parts of code I need to edit/read.

[matklad]

Important subfeature of code folding is "fold function bodies by default" config. Ie, folding some elements by default, based on the "kind" of element, rather than just level.

[Eloitor]

For python it would be useful to be able to fold docstrings

[pashadia]

For python it would be useful to be able to fold docstrings

I would do exactly the opposite: Fold everything BUT the docstrings

[frondeus]

So, #411 is closed now, which I guess was a blocker.

[EzekielEnns]

Lets GOOO!!!

How would this be implemented in codebase?

[SoraTenshi]

How would this be implemented in codebase?

i would assume that we would also create tree-sitter queries for this, and then basically manipulate the text rendering in a way to skip all the lines that are within that context.
Also; rendering the "context core information" such as function name, etc. as virtual text.

[pascalkuthe]

A conceal API was excluded from #5420. I have a prototype for that locally but it needs more work. I am doing some small refactors of the vritual text API anyway atm and improved the conceal implementation there but I probably won't include the conceal API with the PR for that that as it's a bit more complex and I want to avoid doing large PRs

In particular we must be careful that vertical/horitzontal movement moves past the concealed text (vrtical movement already does) while any other movement/search etc. that would place a selection inside the concealed text expands the concealed text. This requires centrelazing the way we set selctions which is something we want to do anyway.

[AndyJado]

💡 an edge case usage description

suppose I have a text file with 800 lines, and the one and only 7th line owes 1 million columns.

should it be folded even before I open the file? will that help ?

[MrGibus]

we must be careful that vertical/horitzontal movement moves past the concealed text (vrtical movement already does) while any other movement/search etc.

I think this is a very important aspect. The vim implementation in vscode had a very annoying flaw in that moving vertically past a fold opened it, as well as several other issues related to it, which probably still plague it to this day.

[prescientmoon]

Are there plans to also support marker based folding? That's a pretty important part of my workflow.

[87113]

Hi there, another use case for folding (vs narrowing) is for markdown.

I like to be able to fold titles or list for example.
Like that I can see the file's structure without all the text around.
It's a bit like an inside TOC.

[stonecharioteer]

It would also be great to fold merge conflict sections like VS Code does so that you can compare them too across splits.
Folding is a very amazing editor feature!

[connortsui20]

Is there any plan to work on this? There seems to be a lot of additional features on top of basic code folding that would be interesting to have, but there is no basic implementation yet.

From #5798 it seems like a conceal API will not be fully implemented soon, but I'm not sure it would be absolutely necessary for basic code folding.

The way VSCode does folding is simply adding dots to the end of the first line, darkening the line, and removing the folded lines from sight:

Maybe this would be a good first step?

[pascalkuthe]

Code folding and conceal need the same lower level API being able to hide part of the document and replace it with some virtual text.

That API doesn't exist yet and is not easy to implement. When it exists implementing code folding (and conceal) will not be that hard. The hardest parts are already done in #5420 but further work is needed and I don't have the time and motivation to finish that right now

[ghost]

Usually I only want a list of functions in the current displayed buffer. I use vsplit-new and then :pipe grep.... A quicker way to achieve this would be useful.

[Eloitor]

This would be useful for saturn notebook support: https://github.com/mrzv/saturn

[camilodlt]

Hello, I've been using Helix for a week and it's amazing. Thanks! . What about folding with the "region" command.

It's done on vscode and some lsps recognize them apparently:

# Unfolded code

# region set seeds
random.seed(1)
# endregion

# Folded : 

# region set seeds ...

Of course, different languages have different markers for comments vs code regions

[prescientmoon]

@camilodlt In vim I use # {{{ and # }}} comments for folding (this is referred to as "marker based folding" I think), so the nicest option would be having configurable markers (so both our comments would fold as intended)

[tgross35]

As far as the logic for how to fold: nvim uses folds.scm, with an @fold capture. There are already some of these in the codebase, e.g. https://github.com/helix-editor/helix/blob/7e389b67c24dfe4466112c988b240c807e7e2414/runtime/queries/latex/folds.scm

See also: discussion on standardization of these files nvim-treesitter/nvim-treesitter#3944

[luccahuguet]

Code folding and conceal need the same lower level API being able to hide part of the document and replace it with some virtual text.

That API doesn't exist yet and is not easy to implement. When it exists implementing code folding (and conceal) will not be that hard. The hardest parts are already done in #5420 but further work is needed and I don't have the time and motivation to finish that right now

Hi @pascalkuthe, is there an issue to track this lower level API that you mention, and if not, can I create one?

[ortense]

I really like this feature and use a lot in other editors but in helix I "indirectly replace" it by using more the symbol picker.

I think that a improvement in this view mixing the idea of folding and symbol picker could create an amazing workflow.

[pashadia]

I really like this feature and use a lot in other editors but in helix I "indirectly replace" it by using more the symbol picker.

While I agree that using a symbol picker is preferable when possible, when working with poorly maintained codebases, you sometimes encounter functions spanning hundreds of lines, and several distinct flows.

[valpackett]

using a symbol picker is preferable when possible

Not everyone agrees: A Missing IDE Feature: Fold Method Bodies by Default

[lukasjuhrich]

Piggybacking on @valpackett's comment: I'd also warn against the blanket judgement "if code folding is necessary, then it must be due to a poor quality codebase or it can be mediated by a symbol picker": There can be various other reasons. For instance because i might be looking at a compose.yml with large environment configuration sections which don't always matter, but take up half a screen of space.
Similar things hold for JSON or XML (popular for msbuild project files). Sometimes, symbol navigation might not even exist or be reasonable to use.

Helix does much more than just allow you to write rust code, thus it should aid the user in a variety of environments. Code folding would help a lot with that.

[emilyyyylime]

Not to mention a batteries-included editor should aim to improve the experience of editing bad code. A lot of actively maintained code out there reeks of technical debt and Helix can't just turn its back and pretend it's someone else's problem. As mentioned in the blog a text-mode function view has many non trivial advantages like being able to search within a selection, multi-cursor rename, wrap in an inline module, or freely move (cut+paste) functions en masse

[hoichi]

As mentioned in the blog a text-mode function view has many non trivial advantages like being able to search within a selection, multi-cursor rename, wrap in an inline module, or freely move (cut+paste) functions en masse

This. FWIW, out of modern terminal/TUI tools, I love flexibility of broot that blurs the line between terminal and TUI. For a clever, terminal-friendly, post-modern editor, I think we could use more of that.

Also, any kind of filtering/narrowing in the same buffer could use the screen estate more effectively than most IDEs. And as for things like multi-cursor rename (provided it can’t be done via LSP, of course), I guess you could integrate some of it in a separate [outline] mode, but maybe it could be done seamlessly and consistently in the same one.

[TheZoq2]

I really like this feature and use a lot in other editors but in helix I "indirectly replace" it by using more the symbol picker.

I feel like people make the same argument against a file picker, and it misses some points. Fuzzy matching is incredible for finding an exact file, or an exact function if you know what to look for. But sometimes you don't know exactly what to look for, sometimes because the code base is bad, but often because it is big and you don't have enough experience in it to know exactly what is in there. Being able to "casually" scroll through the things then is super useful

[pascalkuthe]

The discussion here is not fruitful. We will add folding in the future but it's a non-trivial task that requires changing our core positioning code. Some of the groundwork was laid in #6417 so this is definitely something I will do and is possible but it's a complicated feature to implement. It can likely only be done by me (or somebody very experienced/another maintainer in close collaboration with me). Other things are taking priority, there is only so much bandwidth in a volunteer-based project.

I will leave this issue unlocked for now in case there is some implementation related discussion but I will mark these sort of meta discussions (including comments asking for ETA) as off-topic. You can use a github discussion or matrix (or other platforms) for that sort of discussion but an issue is not the right place for that