helix
helix copied to clipboard
helix-editor
Add Code Folding
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!
Just for the matter of visualization:
I think this is a pretty nice UI (it's from neovim)
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.
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.
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?
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.
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.
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.
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.
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.
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.
For python it would be useful to be able to fold docstrings
I would do exactly the opposite: Fold everything BUT the docstrings
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.
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.
💡 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 ?
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.
Are there plans to also support marker based folding? That's a pretty important part of my workflow.
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.
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!
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?
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
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.
A basic version of folding would be amazing, even if it is behind a flag that is disabled by default until it's fully complete. Is there a rough time frame on when work will start on this?
Edit: Why did I get downvote bombed? Is it because I asked about a rough timeline?
Reaching here when trying to find how to fold in Helix. Fold is one of the Vim function I use all the time. In my use case, I have a text file (currently already 25k lines of text). I break it into section and sub-sections and require Fold for me to navigate.
This would be useful for saturn notebook support: https://github.com/mrzv/saturn
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
