Tiddlywiki5: Proposal: "enhance" tree macro

[sycom]

The tree macro is a very useful tool that helps to understand the code. I have some frustrations with it and I would like to propose some enhancement. Since macros and tools usage is very personal I wished I had some advice about those :

• For now, when a _folder_ is also a _tiddler_, it will show two times in the tree. In a more "tiddler first" way the folder could directly link to the tiddler when needed. Tree will be shorter and clearer.
• For some trees, exploring might be pretty boring since you have to open each folder to go further. Adding an option to _show all_ or _hide all_ as asked in #3792 may fix this.
• Since it's difficult to remember if you have to put the separator or not at the end of the prefix, the macro could be caring of this
• Some sorting capacities with a sort parameter, could also be useful (since a bit limited)

Here is a mock-up for some of the functionnalities

[morosanuae]

Hi, @sycom, the current version of the "tree" macro is my work. It's an enhanced/refactored version of the Jeremy's initial version.
Here is my opinion regarding your proposals, if you're interested:

For now, when a folder is also a tiddler, it will show two times in the tree. In a more "tiddler first" way the folder could directly link to the tiddler when needed. Tree will be shorter and clearer.

I personally don't like this, it is confusing, sorry. Anyway, the problem here is that when you make the folder title (chunk) a link, the default action will be to open the tiddler not expanding the "folder". In the current implementation both the icon and the title (chunk) are inside a button that has a single role: expanding/collapsing that folder.

For some trees, exploring might be pretty boring since you have to open each folder to go further. Adding an option to show all or hide all as asked in #3792 may fix this.

I've answered this, in great detail, in the #3792 issue.

Since it's difficult to remember if you have to put the separator or not at the end of the prefix, the macro could be caring of this.

You can use other separators to define a hierarchy if you want to, so adding a default one automatically is not a viable solution.

Some sorting capacities with a sort parameter, could also be useful (since a bit limited)

I don't see a practical use for this so an example would be useful.

[sycom]

Hello @morosanuae,

Here is my opinion regarding your proposals, if you're interested:

I am interested in any opinion of course, particularly by yours as you worked on this macro. This is the main goal of a proposal issue, isn't it?

I personally don't like this, it is confusing, sorry.

OK. I find more confusing and less "tiddler spirit" to separate tiddler and folder for the same object. But I can understand your point. See below as well.

the problem here is that when you make the folder title (chunk) a link, the default action will be to open the tiddler not expanding the "folder". In the current implementation both the icon and the title (chunk) are inside a button that has a single role: expanding/collapsing that folder.

Yes, but we can imagine that the button is limited to the folder icon. Which is kind of logical if there is a link just beside. I admit there is a confusion risk here but still limited.

I've answered this, in great detail, in the #3792 issue.

Well, I have some limitations with my English and I'm afraid I didn't really get the conclusion of this issue (which remains open doesn't it?). Am I understanding right if I say that :

• there is a performance issue when triggering on $:/ (default _prefix_) or another heavy root of the system ? In this case, may be an alert on using this parameter would be sufficient. And leaving this as a parameter and not putting a button could also limit the risk. I'm pretty sure the wiki will idle but will not crash.
• it would be better to make this though a plugin ? Isn't it a bit heavy for such a functionality?

You can use other separators to define a hierarchy if you want to, so adding a default one automatically is not a viable solution.

I have some limitations with my English and may be this was not clear. My idea is that if - is the separator <<tree my-root "-">> should deliver the same result as <<tree my-root- "-">>.

I don't see a practical use for this so an example would be useful.

May be if you want to have the latest modified tiddler first in your tree instead of the alphabetical order? But I agree that it is a bit odd. And it may be pretty tricky to implement properly...

Great discussion by the way. I think I will make a functional <<other-tree>> demonstrator to test all this. Will come back with experiment results ;-) Stay tuned.

[morosanuae]

@sycom my English is also my main limitation that keeps me from clearly understand others and express myself in precise manner. And sometimes is becomes very frustrating so I know what you're saying.

I understand your needs but It seems to me that your proposals are somewhat specific to your way of thinking and usage, so maybe they will not be appropriate for everyone (including me). And also you'll have to introduce some risky (no so intuitive) usage situations like you're saying.

The only thing that I think is mandatory for the "tree" macro is the "collapsing all" button which I've already proposed/created (see it here: (http://morosanuae.tiddlyspot.com)) some time ago.

So, basically what I'm saying is that I personally wouldn't want a "tree" macro augmented with functionality that I'll never use and degrade performance, so this should stay as generic as possible in the core. More complex/specific functionality should be explored in plugin territory. Gosh, I've started to sound like Jeremy and Mario :)

Anyway, please, don't take it personally, it's just an opinion, a personal one. If you'll make a demo I certainly test it and share my feedback with you.

[Jermolene]

Hi @sycom @morosanuae a couple of thoughts:

• It's fascinating how individual user needs subtly diverge as one gets into the details. Sometimes it's appropriate to use configuration options to cater for different needs, but more often it's better to use the plugin model: common functionality that is extended by optional modules. In this particular case, I'd be happy to see multiple variants of the explorer in the core, just as we do with the TOC macros. Presumably most of the code would be common

• It's a privilege for me both that our community brings together people from many different cultural backgrounds, and that we work in English. I try hard to use English carefully, to make it as easy as possible for people to understand if English isn't their first language. I am open to proposals for making the project more accessible to non-English speakers

[morosanuae]

@Jermolene I think it's very kind of you to care about such things but I don't think there is something that can be done except non-native English speakers to learn English better, especially if they want to contribute to the project. The TiddlyWiki itself is intuitive enough no to pose such problems IMO.

On the other hand I wish a Romanian group/forum or something like this to exist, but I don't think there is such a thing. And despite being one of the best wikis out there I doubt a lot of people from my country know about it.

So in conclusion, in my opinion is not something that you should address. For me it is simply just a life fact! Thanks anyway.

[sycom]

@morosanuae @Jermolene
Just as said, I made a demonstrator of an _other-tree_ macro for testing purpose. My main goals (folder-tiddler merged and this-one giving the same result as this-one-) are successful. For other goals, it's far from perfect. For sorting particularly :-/ I guess what's wrong, but I'm too lazy for now to fix this ;-)
You may try this here: https://sycom.frama.io/TiddlyWiki-Plugins/tree-macro.html I'll be glad to have your feedback. And any other reader's as well of course.

For now, there are a lot of differences with the core tree macro and I will have to look further at the TOC example to have a good idea of what you mean with _plugin model_.

Concerning community and language, I know there has been a lot of discussions. I'm lucky enough to belong to the friendly and at least a bit structured French community. Most of the time though, for most advanced issues, we have to step out and speak with the worldwide community. So we have to work our English. And even if this is often frustrating as @morosanuae said above, it's also very enriching since most people of the TiddlyWiki community seems to share your approach of openness and benevolence. Thanks for that as well.
That said, I'm pretty sure that we could get traction by enhancing our capacity to have clear documentation and to make translations easier. But that tends to be off-topic.

In a more philosophical approach, I guess that the same mechanism that led humanity to so many languages in the world is making us see a wide variety of very personal TiddlyWiki usages.

[AnthonyMuscio]

@morosanuae and @sycom

I know it can be frustrating at the beginning when you really want a different thing to what tiddlywiki provides. What I must say it may may not be long before you can make your own. Alternatives to the tree macro was one of the first things I did. Remember you can always raise such things in Google Groups and will get help if not a solution. It is very easy to copy an existing thing and modify it.

[AnthonyMuscio]

Sycom,

Can I please suggest that this is a good case for you to publish a macro or plugin that provides an alternative tree macro. People can use the existing tree macro as is or adopt your own. I do not think it is necessary to fill the standard distribution with alternatives. People would have made solutions that used the current behaviour and a change may compromise those, or at least the documentation they wrote.

Most likely there are others who would prefer you approach so publishing yours will add value to the community.

Perhaps you can publish and thus close this issue?

Regards
Tony

[sycom]

@AnthonyMuscio,

of course, I could publish it elsewhere as an alternative. By the way I did it almost. I have some work to make it more compliant with the current tree macro and track some bugs.

The issue with side projects publishing is that they don't get audience. So whenever another user would like this version of the tree macro, s•he will not find it. S•He will not even know it does exist. So closing the issue this way means "proposal rejected : do it for yourself and publicize it the best you can".

And if I read correctly this thread, @Jermolene said "_In this particular case, I'd be happy to see multiple variants of the explorer in the core, just as we do with the TOC macros. Presumably most of the code would be common_".

We all want to keep TiddlyWiki as small as possible and avoid adding unnecessary tools. On the other side, it's already full of tools that each doesn't use but others find somewhat useful and it's a good thing. I do understand that long-standing issues with no conclusion is not a good thing. So I will do my homework asap to make a clean PR for helping close this one (not so old by the way - we've got issue from year 2013 here neh ;-) whether the PR is accepted or not.

Regards
Sylvain

[morosanuae]

@sycom

The issue with side projects publishing is that they don't get audience. So whenever another user would like this version of the tree macro, s•he will not find it. S•He will not even know it does exist.

May I ask you why do you need a wider audience? The problem with finding the plugins should be resolved in a better (correct) way: an official plugin repository for user made plugins or something like that, not introducing all the possible tools into the core. I personally think the core it's already full of features that only some people use, and maybe the "tree" macro also falls into this category. I still think that splitting the core into sub-modules will be the best solution but Jeremy thinks differently. We need a "lite" version that has the basic functionality that can be augmented with plugins. And everyone will be happy!

So closing the issue this way means "proposal rejected : do it for yourself and publicize it the best you can".

I've experienced the "proposal rejected" outcome myself in the past, so I guess it's something we should live with. There are so many people with different needs. This is the main problem with community driven projects. I wander if we would need to vote for features in a democratic way, where would we end up?

[sycom]

@morosanuae ,

I have no problem with rejection. Sometimes you have good ideas, sometimes not. I just think that it should be clear.

1. Proposal rejected : maintainers team closes the issue. And I will do what I have to. Or not, doesn't matter.
2. Proposal accepted : maintainers team tells what is the way to fix.

I don't call any democracy. I guess that some projects would benefit some democratic functionalities, but that's definitely not the point here.

I don't call for audience, I have not enough time to maintain properly some of my creation. I don't run for more responsibilities...

The maintainer said something that clearly place us in the second case above, so I don't get why we should imagine another way to go.

Maybe the additions in my PR are too heavy and ineffective for a not so interesting new feature. If so, well may be it can be made better, may be not. If it can not, well, so long for this idea.

What's open source of you can not, suggest, demonstrate, and finally fail or success? I don't get the purpose of what some people do here...

[AnthonyMuscio]

@sycom this example requires a value judgement. Jeremy is providing it, because he sees room for multiple tree options. If you could have this become an option on the existing one, it could be even better, but I suggest with Jeremy's support, go for it.

Always keep in mind we want to be able to cut tiddlywiki back to a minimum, thus we are reluctant to add to the core. However I have argued a few times recently we should have a minimalist edition like empty, and a standard edition which would include alternatives like yours, a configured contents TOC and more.

Also keep in mind there is a lot of tree alternatives out there. I even roll my own as needed because I love recursive code and the various TOC solution are not dissimilar to trees. Why should they not be in the core ahead of yours? Well because @Jermolene is supporting your suggestion!

Regards
Tony

[sycom]

OK, I made a PR (#4279) as a conclusion for this issue that might be closed though not fully solved :

• the PR does not include the _show_ parameter as recommanded by @morosanuae. My tests show that in the worst case the wiki doesn't crash, but idles a lot and even with loud and clear warning it's probably not a good idea to implement it. So #3792 remains open. I think we could imagine a filter that prevent _show all_ if the total tiddlers number exceed a value.
• the PR does not include the _sort_ parameter. The implementation made in my tests was not efficient enough.
• the tree-compact macro and its components are directly added in the $:/core/wiki/macros/tree tiddler. Directly inspired by TOC macro that @jermolene gave as a reference. Maybe they could be added in a $:/modules/wiki/macros/tree/tree-compact tiddler instead. So, switching to a more _modular_ vision of TiddlyWiki as described by @AnthonyMuscio with a minimal core would be easier.

I learned a lot with this discussion and working on the PR, thanks to you all for this. I close this with remaining thought that I drop here for the record :

• After reading the thread around this idea, I do find the _minimal core_ concept very interesting, but
  
  
  
  • I still wonder about how to choose what should integrate or not. e.g. should the *tree macro be part of the minimal core? This functionality is not so important (nor widely used I guess). Did not find any issue discussing from that.
  
  
  • We will have to deal with dependencies if we go further : e.g. if you want the tree-compact macro, you will need the tree macro.
  
  
• We have a lot of debate around the _community_. It's not possible to list all issues, and threads in google groups here. Some around the global governance, some around the good way to make documentation more consistent, some around code management, some around tools and code sharing or accessibility... There is probably something to find to build a more structured debate between _basic users_, _advanced users_, _hackers_ and _devs_. Lacking of this might sometimes drive us to not so constructive or re-inventing the wheel debates. Let's call this build a democratic life (which does not mean build a democracy).