add custom folding regions #1825

danthe1st · 2024-12-02T23:27:25Z

Relevant issues: https://bugs.eclipse.org/bugs/show_bug.cgi?id=173796 (and there are also similar ones like https://bugs.eclipse.org/bugs/show_bug.cgi?id=258965 for CDT).

There is also a Stack Overflow post asking for how to do that with quite a few upvotes so I'd say it seems like many people are interested in such a feature.

What it does

This PR allows to add custom folding regions using comments.

I added new options to the preferences in Java > Editor > Folding (not that I changed this preference page to use Groups):

If a comment containing the start region and a comment containing the end region are present in the same source file, a folding region is added allowing to collapse that section.

~~This works even for elements of different levels~~

Notes / What I'm not sure about

Custom folding regions are disabled if either of the custom texts/preferences are empty or if one contains the other. Should I add some information about that to the preferences? Would it be better to disable it by default (currently, it defaults to #region/#endregion)?

I haven't written any tests so far. Are there existing tests for folding in JDT-UI? What about performance tests (my implementation requires scanning more parts of the source file which could affect performance)?

Regarding performance, I used String#contains to check whether comments contain certain the region begin/end tokens (e.g. #region/#endregion) which requires creating a String for each comment every time the file is edited. Should I change that to use the char[] returned by getCurrentTokenSource() or similar?

I have bumped the minor version of org.eclipse.jdt.ui due to adding new elements in PreferenceConstants. Is this ok that way?

I guess this should be added to the "New and noteworthy" list (assuming this change gets accepted and merged). If so, should I add it and is this the right place?

How to test

Create a Java source file
Create a comment containing the text #region
Create a comment containing the text #endregion
Test similar things with the source file
After editing the corresponding changes in Java > Editor > Folding, it is necessary to reopen the source file.

Author checklist

I have thoroughly tested my changes
- I will check the performance again due to the changes I made.
The change is following the coding conventions
I have signed the Eclipse Contributor Agreement (ECA)

HannesWell · 2024-12-07T16:13:13Z

@fedejeanne in the dev-call on Thursday you mentioned that you could have a look at this, does this still stand?
Eventueally we need a JDT committer to submit this anyways.

danthe1st · 2024-12-16T08:54:02Z

@jukzi Sorry to ping you but would you mind taking a look at my PR and giving feedback?

jukzi · 2024-12-16T09:10:10Z

At a rough view the PR's is a legit feature request. The code looks simple enough to be reviewed and tested. There are no obvious flaws. Such a contribution should come with a Junit Test, that tests both the added API and the effect of the change. I am sure that similar tests already exists but i don't know where. You may look in the git history of the changed files or the call hierarchy to find related tests.
Since i am personally not interested in this particular change i can not offer much time for review/testing/adding junit. If someone else (@fedejeanne ?) likes to help with that i can offer to merge once necessary steps done.

fedejeanne · 2024-12-16T13:18:42Z

Hi. It's on my list but I am currently focusing on issues regarding the Edge browser, which have top priority until the end of the year.
I haven't forgotten about you @danthe1st though, I am just swamped 😓

fedejeanne

I did a quick review and made some comments regarding coding style.

I also tested a bit and this is what I found:

It doesn't work if I define a region completely inside the public static void main(String... args) method but it does work on other methods like public boolean equals(Object obj)
I can define regions if the comment starts with the custom text e.g. // #region2, if that is intended then the text in the preferences should say so. I would add some extra label explaining how custom regions work, right before the 2 check-boxes
If I fold the // #region2 in this snippet, the System.out.println() is folded too:

@Override
public boolean equals(Object obj) {
	// #region1
	// #region2
	if (this == obj)
		return true;
	if (obj == null || getClass() != obj.getClass())
		return false;
	Cat cat = (Cat) obj;
	// #endregion2
	System.out.println();
	return size == cat.size;
	// #endregion1
}

Moving regions around works without reopening the source file but creating regions doesn't. I would very much like it to work too, it doesn't feel natural to have to close the editor to add regions.

Your questions

Custom folding regions are disabled if either of the custom texts/preferences are empty or if one contains the other. Should I add some information about that to the preferences? Would it be better to disable it by default (currently, it defaults to #region/#endregion)?

Some info about it is supposed to work is good but I'd keep it short, 2-3 lines in a label. If it gets too long you could consider adding some help page like the Readme example does.
I'd disable (gray out) the group "Custom folding regions" in the preferences if the checkbox "Custom folding regions" is not selected.

I haven't written any tests so far. Are there existing tests for folding in JDT-UI? What about performance tests (my implementation requires scanning more parts of the source file which could affect performance)?

To test performance you'll have to do it manually. Alter this generator (credits to Andrey Loskutov) and let it generate several internal classes with custom folding regions: GenerateJava.zip. Then sample with VisualVM and share the results.

I don't know of any functional tests, maybe someone else does?

Regarding performance, I used String#contains to check whether comments contain certain the region begin/end tokens (e.g. #region/#endregion) which requires creating a String for each comment every time the file is edited. Should I change that to use the char[] returned by getCurrentTokenSource() or similar?

You'll have to sample with VisualVM and see if this is a performance bottle-neck.

I have bumped the minor version of org.eclipse.jdt.ui due to adding new elements in PreferenceConstants. Is this ok that way?

It's fine and this commit did the same so you're safe: d0563dc. Such bumps are no longer necessary since they will be done automatically by GH, as was the case for the mentioned commit.

I guess this should be added to the "New and noteworthy" list (assuming this change gets accepted and merged). If so, should I add it and is this the right place?

Correct, but let's cross that bridge when we get there :-) . Usually a committer adds the "noteworthy" tag to your PR / Issue right after it was merged/solved and that's your queue to do the PR for the N&N entry.

fedejeanne · 2024-12-19T08:20:38Z

org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/text/folding/DefaultJavaFoldingStructureProvider.java

 						}
-						case ITerminalSymbols.TokenNameCOMMENT_LINE:
+						//$FALL-THROUGH$


I'd avoid falling through, it hurts readability.

I'd push the if (fCustomFoldingRegionsEnabled) inside checkCustomFolding (make it an if-!-return) and call the method once for each case in this switch.

fedejeanne · 2024-12-19T08:22:27Z

org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/text/folding/DefaultJavaFoldingStructureProvider.java

+	private String fCustomFoldingRegionBegin="#region"; //$NON-NLS-1$
+	private String fCustomFoldingRegionEnd="#endregion"; //$NON-NLS-1$


These are overwritten later anyway.

Suggested change

private String fCustomFoldingRegionBegin="#region"; //$NON-NLS-1$

private String fCustomFoldingRegionEnd="#endregion"; //$NON-NLS-1$

private String fCustomFoldingRegionBegin;

private String fCustomFoldingRegionEnd;

fedejeanne · 2024-12-19T08:24:47Z

org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/text/folding/DefaultJavaFoldingStructureProvider.java

+							for(int token = scanner.getNextToken(); token != ITerminalSymbols.TokenNameEOF; token=scanner.getNextToken()) {
+								if(isCommentToken(token)) {
+									checkCustomFolding(ctx, regions, scanner, scanner.getCurrentTokenStartPosition(), regions.size() - 1);
+								}
+							}


Duplicated code.

Extract to method and call twice.

danthe1st · 2024-12-19T14:30:56Z

It doesn't work if I define a region completely inside the public static void main(String... args) method but it does work on other methods like public boolean equals(Object obj)

Should be fixed, this was because of it being the only (or last) method.

I can define regions if the comment starts with the custom text e.g. // #region2

It should work whenever a comment includes the text #region so it could be // Hello #region World or anything like that. If you would (intuitively) expect something else, I'd be happy to hear that and possibly change my implementation. Currently, it treats all comments the same way but I'm open to change that if other people prefer it differently.

Moving regions around works without reopening the source file but creating regions doesn't. I would very much like it to work too, it doesn't feel natural to have to close the editor to add regions.

Interestingly, that worked for my by just adding a comment like // #region or whatever. What doesn't work is it being automatically updated when changing the preferences related to custom folding regions.
Maybe you wrote the #region commend but not the #endregion comment?

I'd disable (gray out) the group "Custom folding regions" in the preferences if the checkbox "Custom folding regions" is not selected.

The checkbox is about initially folding/collapsing these elements. If the checkbox is disabled, the elements should still be folded but not collapsed by default.

I don't know of any functional tests, maybe someone else does?

I didn't find any existing tests related to folding so I'll try making my own tests for custom folding regions in a new directory org.eclipse.jdt.ui.tests/ui/org/eclipse/jdt/ui/tests/folding (I currently don't have a good way to access the folding regions/annotations added to the editor and I don't want to add API just for tests but I might find a good way to do it at some point ()). If anyone still finds tests after that, it shouldn't be hard to move them (once I wrote the tests).

My current approach for automated tests is subclassing DefaultJavaFoldingStructureProvider and overriding computeFoldingStructure and getProjectionRanges to access the created IRegion[]s.

Anyway, do you have any opinions on the defaults for the #region/#endregion marker texts? Do you think using a different text would be better? I think one alternatively I have seen in other IDEs was // region where it must be at the start of the comment but I felt it being at any position was more flexible.

danthe1st · 2024-12-19T14:41:40Z

I might still rework that label in the future.

BeckerWdf · 2024-12-19T15:43:39Z

The texts: "Text marking start of custom folding region" looks a bit unnecessary too long for my
Why not simply saying "Text marking start of region" and "Text marking end of region"
due to the box around you don't need to repeat that it's a "custom folding region".

I am unsure if it's singular "region" or pluar "regions".

danthe1st · 2024-12-19T17:42:25Z

As discussed in today's devcall, I changed the PR to disallow regions between an element and it's child.

class X{
	// #region
	void a() {
		// #endregion this is not folded with the outer region because it is at a different level
		
		// #region However, this is folded because loops are not considered children elements and I don't think it's a good idea to parse all of that for folding
		for(int i=0; i<10;i++) {
			// #endregion
		}
	}
	// #endregion this will be folded with the outer region
}

Another suggestion during the devcall was to restrict this to comments starting with #region (or whatever is configured) instead of allowing it anywhere (// Hello #region World).
Since the token scanner seems to treat the whole comment as a token (including the prefix like //, /*, /** or ///), I decided to not change this for now. If it is wanted, I can implement something stripping away the prefix of the comment token (skipping up to two slashes/stars and any whitespaces at the beginning) but I am unsure whether this is actually the preferred way of doing this as this might be a maintainance burden if new comment types (or similar) are added to Java.

danthe1st · 2024-12-19T21:57:24Z

Preliminary profiling results:

I ran the generator mentioned by @fedejeanne with 12_000 inner classes (the default) and added a custom region both outside and inside each of these classes.

I loaded the class in Eclipse, started CPU sampling with VisualVM, added some newlines at the top, bottom and in the middle of the file. I also added a single-line comment in the middle of the file.
This is what VisualVM shows:

Similar with CPU profiling:

As it seems, the custom folding logic does have an impact on performance.

Loading all the folding annotation takes a bit of time in general (especially with the profiler active) but it does not block the UI.

CPU profiling with similar operations with custom folding regions disabled (loading the folding regions still takes time with in this case):

It seems like the biggest issue is that custom folding regions require the scanner to process more tokens (it needs to actually go over method bodies etc which is otherwise not done for methods without any children). I could get rid of the scanner.getCurrentTokenSource() call in every comment but I don't think it would change much here.

I don't know whether this is a problem. The generated file has 156 005 lines. If the performance is a problem, we can disable this feature by default.

fedejeanne · 2024-12-20T07:10:42Z

@danthe1st can you provide:

The simplified version of the generated file (generate it with 1 inner class)
Sampling/performance analysis for the same scenarios on master (for comparison)?

Keep in mind that generating 12.000 inner classes is an extreme case so performance will always degrade, the question is how much.

akurtakov · 2024-12-20T07:41:59Z

As a reference for people interested in similar functionality for other editors - Generic editor provides extension point for that https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/bundles/org.eclipse.ui.genericeditor/schema/foldingReconcilers.exsd

danthe1st · 2024-12-20T09:00:20Z

profiling with merge base (not current master but the master I based my PR on):

sampling:

Generated code with one inner class:

package a.generated;

public class TestClass {

    // #region outside
    public static class InnerClass0 {
        // #region inside
        public int x = 42; // no error
        
        public void helloWorld() {
                System.out.println("Hello World!"); // no error
                System.out.println("In class " + 0 + ", x=" + x); // expected error
        }
        // #endregion inside
    } // end of InnerClass0
    // #endregion

}

(I changed the code to not have any compilation errors - some regions may be missing in that case (probably because of the token scanner behaving differently))

Notably, this doesn't test long comments (the current implementation converts all comment tokens to a String on which it performs the contains() check. As mentioned above, I could change this to only check the beginning of the comment (and use the char[] provided by scanner.getSource() or similar) to only check the first characters (filtering out things like //, ///, /*, /**). If wanted, I can also make a comparison with that.

danthe1st · 2024-12-20T11:17:00Z

Other experiment with 6_000 inner classes and each class having a multiline comment with 20 lines each containing the character a 100 times:

// #region outside
    /*
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    */
    public static class InnerClass0 {
        // #region inside
        public int x = 42; // no error
        
        public void helloWorld() {
                System.out.println("Hello World!"); // no error
                System.out.println("In class " + 0 + ", x=" + x); // expected error
        }
        // #endregion inside
    } // end of InnerClass0
    // #endregion

Custom regions disabled, sampling:

Custom regions disabled, profiling (I had to disable automated collapsing of normal/header comments to be able to do this without Eclipse not responding):

Custom regions enabled, sampling:

Custom regions enabled, profiling (automated collapsing of comments enabled as well):

danthe1st · 2024-12-20T12:28:24Z

I realized that I can use the information of what the current token is from the scanner to know where I need to start looking for characters (so I don't need to check for things like //). With this change, it is now required that region markers (#region/#endregion) are at the start of the comment so // Hello #region World is now prevented as discussed in the devcall.
I used this chance to change the implementation to use char[]s and not process the entire comment.

Sampling with that change and custom folding regions enabled:

Profiling:

Note that all VisualVM screenshots I have included so far are about modifying source files after opening them and not about initially loading the source files (this isn't included in any sampling/profiling I've done until now).

danthe1st · 2024-12-20T13:15:27Z

EDIT: This issue is fixed now.

I noticed a bug in my implementation where the following is not detected:

class Z{
	void a() {
		// #region this is not detected because there is an inner class (considered as a child) in the same scope and there are statements/non-comment tokens between the comment with the region marker and the inner class
		int x;
		
		// #endregion this marker can be detected without issues
		class Inner{
			
		}
	}
}

This seems to only occur with local classes (declared within methods). The "old" folding implementation (master) generally ignores multi-line comments written in positions like that (it only folds comments before classes/methods/etc).

I plan to try fixing it but doing so might require over scanning bigger parts of the source file.

BeckerWdf · 2024-12-23T08:58:12Z

I might still rework that label in the future.

I am not a big fan of big explanatory text directly in the preference page. Can't we simply put this into the help document related to that preference page?

BeckerWdf

Thanks for the text shortening.

danthe1st · 2024-12-24T07:55:10Z

I am not a big fan of big explanatory text directly in the preference page. Can't we simply put this into the help document related to that preference page?

I guess I can remove the label and write a PR changing https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.common/bundles/org.eclipse.jdt.doc.user/reference/preferences/java/editor/ref-preferences-folding.htm once this is done.

danthe1st force-pushed the folding branch 2 times, most recently from 0301e82 to 1828731 Compare December 4, 2024 22:01

danthe1st marked this pull request as ready for review December 4, 2024 22:05

danthe1st force-pushed the folding branch 3 times, most recently from 56d6c84 to a8a21b5 Compare December 7, 2024 15:43

add custom folding regions

f8960b9

danthe1st force-pushed the folding branch from a8a21b5 to f8960b9 Compare December 14, 2024 22:01

jukzi added the enhancement New feature or request label Dec 16, 2024

fedejeanne reviewed Dec 19, 2024

View reviewed changes

address review comments

b01ae04

add label for custom folding regions

279abd5

use early return pattern for custom folding region check

74d94eb

danthe1st added 2 commits December 19, 2024 18:30

do not allow custom folding regions at different levels

c5add44

shorten custom folding regions preference text

636b720

jukzi added the noteworthy Noteworthy feature label Dec 20, 2024

use char[] based startsWith instead of contains()

d77d334

add custom folding region checking before current element start

c5ba965

BeckerWdf reviewed Dec 23, 2024

View reviewed changes

danthe1st added 4 commits December 24, 2024 11:42

tests for custom folding regions

d9340bf

more strict custom region tests

2bddaed

remove unused method in tests

b4ed19d

remove unused variable in tests

a731884

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add custom folding regions #1825

add custom folding regions #1825

danthe1st commented Dec 2, 2024 •

edited

Loading

HannesWell commented Dec 7, 2024

danthe1st commented Dec 16, 2024 •

edited

Loading

jukzi commented Dec 16, 2024

fedejeanne commented Dec 16, 2024

fedejeanne left a comment •

edited

Loading

fedejeanne Dec 19, 2024

fedejeanne Dec 19, 2024

fedejeanne Dec 19, 2024

danthe1st commented Dec 19, 2024 •

edited

Loading

danthe1st commented Dec 19, 2024 •

edited

Loading

BeckerWdf commented Dec 19, 2024

danthe1st commented Dec 19, 2024 •

edited

Loading

danthe1st commented Dec 19, 2024 •

edited

Loading

fedejeanne commented Dec 20, 2024

akurtakov commented Dec 20, 2024

danthe1st commented Dec 20, 2024 •

edited

Loading

danthe1st commented Dec 20, 2024

danthe1st commented Dec 20, 2024 •

edited

Loading

danthe1st commented Dec 20, 2024 •

edited

Loading

BeckerWdf commented Dec 23, 2024

BeckerWdf left a comment

danthe1st commented Dec 24, 2024

		private String fCustomFoldingRegionBegin="#region"; //$NON-NLS-1$
		private String fCustomFoldingRegionEnd="#endregion"; //$NON-NLS-1$

add custom folding regions #1825

Are you sure you want to change the base?

add custom folding regions #1825

Conversation

danthe1st commented Dec 2, 2024 • edited Loading

What it does

Notes / What I'm not sure about

How to test

Author checklist

HannesWell commented Dec 7, 2024

danthe1st commented Dec 16, 2024 • edited Loading

jukzi commented Dec 16, 2024

fedejeanne commented Dec 16, 2024

fedejeanne left a comment • edited Loading

Choose a reason for hiding this comment

Your questions

fedejeanne Dec 19, 2024

Choose a reason for hiding this comment

fedejeanne Dec 19, 2024

Choose a reason for hiding this comment

fedejeanne Dec 19, 2024

Choose a reason for hiding this comment

danthe1st commented Dec 19, 2024 • edited Loading

danthe1st commented Dec 19, 2024 • edited Loading

BeckerWdf commented Dec 19, 2024

danthe1st commented Dec 19, 2024 • edited Loading

danthe1st commented Dec 19, 2024 • edited Loading

fedejeanne commented Dec 20, 2024

akurtakov commented Dec 20, 2024

danthe1st commented Dec 20, 2024 • edited Loading

danthe1st commented Dec 20, 2024

danthe1st commented Dec 20, 2024 • edited Loading

danthe1st commented Dec 20, 2024 • edited Loading

BeckerWdf commented Dec 23, 2024

BeckerWdf left a comment

Choose a reason for hiding this comment

danthe1st commented Dec 24, 2024

danthe1st commented Dec 2, 2024 •

edited

Loading

danthe1st commented Dec 16, 2024 •

edited

Loading

fedejeanne left a comment •

edited

Loading

danthe1st commented Dec 19, 2024 •

edited

Loading

danthe1st commented Dec 19, 2024 •

edited

Loading

danthe1st commented Dec 19, 2024 •

edited

Loading

danthe1st commented Dec 19, 2024 •

edited

Loading

danthe1st commented Dec 20, 2024 •

edited

Loading

danthe1st commented Dec 20, 2024 •

edited

Loading

danthe1st commented Dec 20, 2024 •

edited

Loading