code folding

[v217]

Arbitrary text folding like in vim zf.

[lenormf]

Has the integration of soft wrapping made things easier, to support folding?

[net]

Code folding would be very useful.

[lenormf]

My question still stands.

[mawww]

Could be easier yeah, the main problem with folding is similar to what we have with wrapping: we dont know how things are outside of the displayed window, so any movement primitive that would rely on how lines are displayed (necessary with folding if we dont want to open folds everytime the cursor moves on top of them) will behave strangely for non displayed selections.

In general, it seems tricky to have folding and multiple selections work together. Also, I have been trying to move away from display dependent movements, to make interactive use and script use of the editing language as close as possible.

[Iiridayn]

I personally don't use code folding, though I've sincerely tried it (a team member loves it). I feel it makes it too easy to hide code smells which should be cleaned up anyway. Ie - file/method/if-then-else/loop body too long? Split it out (into a file or another method/function - especially long loop bodies). Interdependent code sections too far apart? Move them closer. Even so, I've found decent movement commands (usually *) work pretty well for single file navigation in vim w/o folds for even the worst files I've seen.

So, while I can see why folding would be difficult to do well, I don't mind the lack.

[jeanm]

I also don't use code folding, although I know plenty of people who do. However, one good reason I see for supporting folding in general it is that it would enable the development of plugins similar to VimOutliner and org-mode. KakOutliner would rock.

[laelath]

One way you could get around the problem of inconsistent behavior between interactive and script use could be to automatically expand a fold if a selection enters it.

[andreyorst]

Why can't folded code be edited with multiple cursors in the same way how code is being edited off screen? When I edit 800 LOC file with 200+ carets I don't see whole file, but only part of it. I (and Kakoune) just know where text will be replaced, no need to show it on screen.

[mawww]

@andreyorst The expected difficulty was that it was not clear what say j in normal mode would do on undisplayed text that could be potentially folded.

I believe this difficulty has been solved by deciding that:

• normal mode keys should never take display information into account (with the exception of mouse clicks, which are fundamentally visual)
• Any highligthing that hides buffer text should disable itself when the hidden text is partially selected (i.e. neither fully selected, nor not selected at all).

With that said, I believe we can implement folding by extending the replace-ranges highlighter, currently it assumes (but does not enforce IIRC) that we replace a range with text the same length, we need to extend it so that it can replace arbitrary text, and then its just a matter having an external script setting a range-specs option to <range to fold>|<text to display>.

[andreyorst]

It would be super cool if subset of Emacs Org-mode could be implemented with folding, and #2536 feature

[andreyorst]

Also, I would like to use folding in tagbar.kak to fold sections, in case user don't wan't to see Macros section for example. But I suppose it would be difficult, since after re-displaying the buffer, content' of *tagbar* is being fully replaced by new content, and folds will be opened up after that. This also could be the case when :format command is used on the file, I suppose that it should format folded text but don't open folds.

[aidam38]

What is the timeline on this? When will we roughly have folding? It is the last thing that is keeping me from making Kakoune my 'life-time' editor, it is really crucial for LaTeX.

[andreyorst]

Another good usecase for folding could be hiding all lines that doesn't contain a cursor. So for example you have 40 cursors in whole buffer, but you don't see them all. Instead of jumping between each with ( we could hide all lines that doesn't have a cursor, to see all cursors in one screen.

This could be done without folding if a temporary buffer was opened and lines with cursors vere copied there, and then pasted back when editing finished, but it is less convenient compared to working in single buffer.

[JJK96]

I've experimented a bit with the replace_ranges highlighter and have extended it to be able to replace multiple lines.

currently it assumes (but does not enforce IIRC) that we replace a range with text the same length

I have not really solved this problem yet, if you try to replace multiple ranges the content shifts in some way. ~I think this could be solved with the update_ranges function, but I cannot get it to work.~

https://github.com/JJK96/kakoune/commit/578fdd9e98d690094639a17cd846654e8081d0e4

Full branch (highlight)

EDIT: I see that update_ranges only notices changes to the actual buffer, not to the display_buffer.

[cipharius]

How about approaching code folds and buffer narrowing in general using concept such as virtual buffers/buffer views?

The proposal is to allow taking live slices of a buffer and join them in a new virtual buffer, which would be a projection of the original buffer. Think multi-selections that we already have, but linked to a new buffer like context. Changes in the virtual buffer affect the source buffer and changes in source buffer affect the virtual buffer.

This would bypass the issue of disconnection between underlying data and the presented view. Such virtual buffers wouldn't need special command handling, since the data visible in such buffer is exactly what it contains, except it is composed from regions of it's source buffer.

I think it is noteworthy to point out that Emacs also has similar concept known as buffer narrowing.

EDIT: After browsing kakoune's code base for a bit, it seems that Window is already such "view on a buffer" concept. Perhaps extending window's capabilities is the way?

[andreyorst]

one downside is that searching over such virtual buffer will not unfold folds because there are no text in folds. Buffer narrowing is extremely useful thing, but I see it orthogonal to code folding. This probably will also break diagnostic tools like LSP, or will be hard to pass those to narrowed buffer.

чт, 7 мая 2020 г., 01:00 Valts Liepiņš notifications@github.com:

How about approaching code folds and buffer narrowing in general using concept such as virtual buffers/buffer views?

The proposal is to allow taking live slices of a buffer and join them in a new virtual buffer, which would be a projection of the original buffer. Think multi-selections that we already have, but linked to a new buffer like context. Changes in the virtual buffer affect the source buffer and changes in source buffer affect the virtual buffer.

This would bypass the issue of disconnection between underlying data and the presented view. Such virtual buffers wouldn't need special command handling, since the data visible in such buffer is exactly what it contains, except it is composed from regions of it's source buffer.

I think it is noteworthy to point out that Emacs also has similar concept known as buffer narrowing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mawww/kakoune/issues/453#issuecomment-624913581, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEUROT6N7ESZ5DPQSYVV7LLRQHMWTANCNFSM4BTG6IEA .

[Delapouite]

@cipharius You've described a virtual buffer made of slices from an existing buffer which is quite nice. This same concept could also be applied the other way around: build a virtual buffer which is the concatenation of more than one buffers.

Example: if I'm working on a web frontend component, which is made of 3 files foo.js, foo.html and foo.css. But then I found that I made the same typo in each of those files. So what I could do, is to temporarily merge them into a virtual buffer foo, do my typo fix with something like %sbar<ret>cqux<esc> and then save and close this virtual buffer. It means that I have successfully been able to do a "search-replace" in a set of specific files without learning any new Kakoune editing concept except the "virtual buffer" one.

In the end virtual buffers are cool for narrowing and widening.

[danr]

One can get a makeshift virtual buffer for replacing across several files using https://github.com/occivink/kakoune-find . Nevertheless built-in virtual buffers would be really interesting.

[mawww]

954373d3cfa9d168f7949f12cb7b2e730d18de99 Added support for multi-line replace ranges, which should provide a backend for code folding.

As said in the commit message, it likely has rough edges remaining, but those can be fixed as we find them.

[Screwtapello]

Rough edges in the current replace-ranges implementation include #3644 and #3689.

[joemaro]

i really am looking forward to be able to do folding in kakoune

[Kabouik]

Same here!

[flexagoon]

Same, I really want folding

[joemaro]

Any news or plans on this? Or plugins that make this possible?

[jtrv]

https://github.com/mawww/kakoune/issues/453#issuecomment-485249534

...hiding all lines that doesn't contain a cursor. So for example you have 40 cursors in whole buffer, but you don't see them all. Instead of jumping between each with ( we could hide all lines that doesn't have a cursor, to see all cursors in one screen.

https://github.com/caksoylar/kakoune-focus serves this case just in case anyone comes across this.

still hoping for code-folding 🤞🏽

[nandoflorestan]

I just wanted to mention, in passing, that in 2024 people still want code folding, including me.