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

Nested folds #44

Closed
wants to merge 7 commits into from
Closed

Conversation

Monkeypac
Copy link

Hi, as I told you earlier, I needed the nested folds for my usage.

Review welcome if you find something not good.
I added the nested folds as an option but I changed a few other things so don't hesitate on the review :)

Copy link
Collaborator

@mrkkrp mrkkrp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this contribution!

I tried the new feature and it looks like it works, but fold deletion behaves a bit unexpectedly: it deletes all enclosing folds instead of just the one I place cursor at.

I'm not sure what is the correct behavior here, as I mentioned before, nested folds look confusing to me :-)

vimish-fold.el Outdated
@@ -131,6 +131,15 @@ overhead is undesirable."
:type 'boolean
:package-version '(vimish-fold . "0.2.3"))

(defcustom vimish-fold-allow-nested nil
"Whether to allow nested folds
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first line should end with a full stop. In emacs-lisp-mode Emacs should show warnings for these things I think...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I missed it. Done.

I don't have warning though, do you have something special for this in your configuration ?
(I don't have flycheck enabled right now though)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think it's Flycheck.

vimish-fold.el Outdated
and will not be created."
:tag "Allow nested folds."
:type 'boolean
:package-version '(vimish-fold . "0.2.3"))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's have 0.2.4 here, because I'll release a new version with this feature.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

vimish-fold.el Outdated
@@ -415,6 +451,23 @@ This feature needs `avy' package."
folds-before-point)))
(message "No more folds before point"))))

(defun vimish-fold-previous-existing-fold ()
"Jump to previous vimish region in current buffer."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How this is different from vimish-fold-previous-fold? It'd help if you mention the differences in the docs string too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one.

The difference is that if you have the following:

# {{{ Fold 1
# }}}

# {{{ Fold 2
# {{{ Fold 2.1
# }}}
# }}}

When you are on Fold 2.1, the old function will make you go back to Fold 1 because Fold 2 is in the region of Fold 2.1. The new function makes you go back to Fold 2.

I thought that a new function was better since it does not alter the behavior but works fine without nested folds. It is however just a little bit slower since we process a little bit the list of folds (vimish-fold--folds-beginning-in).

Done, tell me if you prefer another solution for this :)

vimish-fold.el Outdated
@@ -224,6 +233,21 @@ This includes fringe bitmaps and faces."
'(vimish-fold--folded
vimish-fold--unfolded)))

(defun vimish-fold--vimish-overlay-at (pos)
(let ((overlays (overlays-at pos)) res-ov tmp-ov (min-space (max-char)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Emacs says:

All variables and subroutines might as well have a documentation string

I understand that this is nitpicking, but since we're already following the whims of Emacs Lisp official style guide, there is no reason to stop following them now :-)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

I'm not used enough to elisp dev I guess ^^"

vimish-fold.el Outdated
@@ -311,6 +338,15 @@ If OVERLAY does not represent a fold, it's ignored."
#'vimish-fold--vimish-overlay-p
(overlays-in beg end)))

(defun vimish-fold--folds-beginning-in (beg end)
(let ((list (vimish-fold--folds-in beg end)) tmp-ov)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same stuff about missing docstring.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

vimish-fold.el Outdated
(let ((list (vimish-fold--folds-in beg end)) tmp-ov)
(while (list)
(setq tmp-ov (car list))
(unless (and (>= pos (overlay-start tmp-ov))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get the following warning here:

reference to free variable pos

You should first declare the variable using let and then use it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woops it should have been beg and end, how did this even work ? ><

vimish-fold.el Outdated
@@ -261,7 +286,8 @@ This includes fringe bitmaps and faces."
(defun vimish-fold-unfold ()
"Delete all `vimish-fold--folded' overlays at point."
(interactive)
(mapc #'vimish-fold--unfold (overlays-at (point))))
(save-excursion
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to make sure: does save-excursion make any difference is this case?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like no ... I wonder why I did it. Removed.

@Monkeypac
Copy link
Author

Oh and I forgot to check the fold deletion, I'll do it.

@mrkkrp
Copy link
Collaborator

mrkkrp commented Dec 4, 2017

This looks mostly good. However, when you have nested folds, say B inside A, and you expand both A and B, there is no visual clue left that B exists. To fold it back one has to find it blindly or from memory. This is not acceptable. We should do something about it. Maybe the color of fringe should change somehow for levels of nesting greater than one.

@Monkeypac
Copy link
Author

Oh I don't use fringes so I didn't see that :D
I'll check that

@mrkkrp
Copy link
Collaborator

mrkkrp commented Dec 13, 2017

Any update on this? In principle, I can merge it in the current state if you find it usable.

@Monkeypac
Copy link
Author

Don't merge it yet, I have a few changes to make but I didn't have many time last week, sorry for that ^^"

@Monkeypac
Copy link
Author

Little update here, forget this, I don't have much time recently so I'll make it work on my fork when I have time and restart a pull request then.

Sorry for taking your time there, still working on it but when I have time ...

Monkeypac and others added 7 commits February 14, 2018 22:15
This patch only handles the fold / unfold functions.
If a fold is nested inside another one, set a different fringe color.
This patch does not handle the reclosing of the folds when terminating
the search. This would need some more development to change the way
vimish refolds / unfolds its folds.
@Monkeypac
Copy link
Author

Monkeypac commented Feb 18, 2018

Okay so finally forced myself to take the time for this, waiting for your review but I hope it's going to be ok :D

@Monkeypac
Copy link
Author

@mrkkrp , up ?

@mrkkrp
Copy link
Collaborator

mrkkrp commented Feb 22, 2018

Yes I remember about this. This weekend.

@Monkeypac
Copy link
Author

Thanks :D

Copy link
Collaborator

@mrkkrp mrkkrp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the whole thing too hairy. I'm unsure if I'll be able to maintain it because instead of relatively simple and elegant solution we get a monstrosity. I must admit that I just did not think about nested folds when I wrote the original code.

Not sure I should merge even if you address the comments, sorry. Maybe you could fork?

@@ -518,6 +662,7 @@ This minor mode sets hooks so when you `find-file' it calls

For globalized version of this mode see `vimish-gold-global-mode'."
:global nil
:keymap (make-sparse-keymap)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this is necessary?

@@ -205,7 +218,10 @@ If PREFIX is not NIL, setup fringe for every line."
(propertize "…" 'display
(list vimish-fold-indication-mode
'empty-line
'vimish-fold-fringe)))))
(if (vimish-fold--nested-vimish-overlay-p
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not work for me. Nested folds use the same fringe as non-nested folds: vimish-fold-fringe.

(defun vimish-fold (beg end)
"Fold active region staring at BEG, ending at END."
(defun vimish-fold (beg end &optional nested)
"Fold active region starting at BEG, ending at END.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a user, why should I care about manually telling vimish-fold whether my new fold happens to be nested in some other fold or not? As I understand it, the fact whether the new fold is nested or not is determined entirely by position of the new fold and existing folds in the buffer.

@mrkkrp
Copy link
Collaborator

mrkkrp commented Feb 24, 2018

Or alternatively, this needs a total re-thinking of the design and a good test suite because of the added complexity. Unfortunately the package was intended as a very lightweight thing originally and if I merge there will be too many moving parts in it, if you understand what I mean.

Test suite would be really good at this point, but I don't have any spare time at all these days :-(

Opened #48, maybe I'll get to this some day...

@Monkeypac
Copy link
Author

Yeah, I feared this but I understand.

This might be a little bit off-topic but:
For the time being, could you explain me how I could use my fork locally with use package ?
For the moment, I load the original package and then force load my local vimish-fold.el.

If I find time, I'll try to participate in #48.

@mrkkrp
Copy link
Collaborator

mrkkrp commented Feb 24, 2018

I don't use use-package, maybe you could ask on its issue tracker? Also, I think there is a project that allows to pull packages from git directly, but I forgot its name.

@Monkeypac
Copy link
Author

Okay thx :D

@mrkkrp mrkkrp closed this Jun 22, 2018
@Monkeypac Monkeypac mentioned this pull request Feb 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants