Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

code folding #453

Open
v217 opened this issue Nov 1, 2015 · 13 comments

Comments

Projects
None yet
9 participants
@v217
Copy link

commented Nov 1, 2015

Arbitrary text folding like in vim zf.

@Delapouite Delapouite referenced this issue Jan 20, 2017

Closed

Advertise Kakoune #249

6 of 8 tasks complete
@lenormf

This comment has been minimized.

Copy link
Contributor

commented May 16, 2017

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

@net

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2017

Code folding would be very useful.

@lenormf

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2017

My question still stands.

@mawww

This comment has been minimized.

Copy link
Owner

commented Sep 19, 2017

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

This comment has been minimized.

Copy link

commented Feb 5, 2018

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

This comment has been minimized.

Copy link

commented Feb 23, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 16, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 17, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

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

@andreyorst

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2019

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

This comment has been minimized.

Copy link

commented Mar 4, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 21, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.