Thanks Saq, that was certainly not the answer I was hoping for, but it’s good to know which way the wind is blowing after so many years (I think the original dailytasks plugin that got me started 13 years ago came from you?).
cmari (considering changing my name to “offspec user”!)
Just to add a bit more clarification to the issue since I have a bit more time now than I did yesterday, this functionality should have been implemented as a widget and not a macro. I quickly dropped the link in reply yesterday so you would know that there was some follow up on your post.
JavaScript macros in TiddlyWiki5 are supposed to be for simple text substitution and do not have any facilities for refreshing in response to other changes in the wiki, the input of the macro determines the output. A macro should never modify tiddlers. The macro in question both needs to refresh itself in response to tiddler changes, and also modifies tiddlers.
Such a macro was never intended to be supported but has worked so far because we were aggressively refreshing entire tiddlers when anything in that tiddler changed. So for example a change to a tiddler “list” field would refresh the entire tiddler in the story. However this is suboptimal both from a performance point of view and in terms of user experience. Some of the annoyances commonly encountered like an edit-text widget in a tiddlers text field not being usable to modify a field in the same tiddler come from this aggressive and unnecessary refresh behaviour.
So the question that presents itself now is whether we maintain backwards compatibility for a behaviour from third party macros that was never intended to be supported and holds back improvements, or break such macros as their implementation will trip us up again in unexpected places and limit future possibilities.
Your actual need for the functionality offered by this macro could probably be solved with a wikitext implementation as well. It might be worth a search to see if someone has shared such a solution.
Regards,
Saq
This is one of the first things that came up with a search, perhaps it may be of interest:
https://rawgit.com/Guitlle/habito/build/build/habito-docs.html
1 Like
Yes, I have seen that, thanks. Unfortunately, I lack the necessary skills/time to identify the pieces that would need to be adapted to allow for viewing (and updating) a running overview of the task status for the last 10 days.
Ciao Saq …
Side comment …
… Just to add a bit more clarification … this functionality should have been implemented as a widget and not a macro.
JavaScript macros in TiddlyWiki5 are supposed to be for simple text substitution and do not have any facilities for refreshing in response to other changes in the wiki, the input of the macro determines the output.
… Such a macro was never intended to be supported but has worked so far because we were aggressively refreshing entire tiddlers when anything in that tiddler changed.
Right! YET.
But it is slightly worrying that Simon Kilner’s(?) TOGGLER macro (actually a re-write of something originally on Classic?) is kinda deprecated now. And NEVER was BEFORE.
The tool WORKED forever already.
And your formal explanation kinda misses the point that IF it was working, why is it NOT working now?
Saq, I never want to argue with you, you are so sweet! 
I just think that the recent leap in TiddlyWiki is kinda a BREAK with it’s previous tolerance of non-kosher JS?
IMO, one of the great achievements of TW has been the combo of VAST functional expansion combined with pretty amazing backwards compatibility.
THIS is an interesting case where it broke down.
Just thoughts
TT
But it is slightly worrying that Simon Kilner’s(?) TOGGLER macro (actually a re-write of something originally on Classic?) is kinda deprecated now. And NEVER was BEFORE.
The tool WORKED forever already.
And your formal explanation kinda misses the point that IF it was working, why is it NOT working now?
It’s the price for fixing the ability to edit a field within the same tiddler, which has been a perennial problem/bug that affects many users.
There’s definitely a tension with breaking these macros, but there’s a couple of points:
- More users encounter the edit-field-of-same-tiddler problem than would be running some old broken macro
- These macros were broken to begin with, and in many/most cases the authors chose to ignore warnings
- It should usually be easy to fix: wrap the macro invocation in a <$tiddler> widget referencing the tiddler in question
With reference to the second point, we’ve always tried to educate developers on the proper way to write macros. Literally every time a developer posts about a JS macro that they’re writing, my first angle is to look to see if it follows the rules, and to provide feedback if not.
In many cases, of course, developers aren’t very interested, and work on the basis of “it works for me so why should I change it”, which of course in the end can be very damaging to the community unless the limitations are very carefully documented.
I do plan to update the release note with a more prominent warning of the impact of this change.
Best wishes
Jeremy
@cmari perhaps this is closer to what you need?
https://groups.google.com/g/tiddlywiki/c/9hZTwQBuwe8/m/YlRPXrn0BQAJ
Note that you can use the “arrow” buttons to move forwards and backwards in time.
I’ve bookmarked these two habit tracking solutions so they show up at TiddlyWikiLinks:
https://links.tiddlywiki.com/topics/daily-tasks/
Ciao Jeremy
A compounding factor is that devs of older stuff are often NOT around to fix for compliance with new.
The issue is the users who relied on what they thought were kosher tools that STOP working that the author won’t fix.
Jeremy: | do plan to update the release note with a more prominent warning of the impact of this change.
Good! IMHO, it might also be worth mentioning that their tool of concern would continue to run fine under previous versions of TW.
For working apps mostly it is NOT needed you upgrade!
((“Upgradeitis” is a serious modern disease. :-))
Best wishes
TT
I did test that, but it seems the tiddler-widget only views the tiddler-attribute for a change and a simple state, that only calculates the classes. …
So if any tiddler-field changes, it doesn’t do a refreshSelf() and may be it shouldn’t. It needs to refreshSelf() if the parameter itself is changed, and not if the tiddler, where the parameter points to is changed. …
But this seems to work:
<$set name=x value={{!!toggled}}>
<<dailytasks>>
</$set>
and
<$set name=x value={{!!toggled}}>
<<togglers>>
</$set>
-mario
Did more tests … It seems to be
<$vars x={{!!toggled}} y={{!!barray}}>
<<macro>>
</$vars>
-m
Hi Josiah
A compounding factor is that devs of older stuff are often NOT around to fix for compliance with new.
The issue is the users who relied on what they thought were kosher tools that STOP working that the author won’t fix.
Indeed.
Jeremy: | do plan to update the release note with a more prominent warning of the impact of this change.
Good! IMHO, it might also be worth mentioning that their tool of concern would continue to run fine under previous versions of TW.
For working apps mostly it is NOT needed you upgrade!
((“Upgradeitis” is a serious modern disease. :-))
From the core perspective we really want people to upgrade actively used wikis to each new version because it’s expensive and complex to offer support for old versions. For example, if we had a user on v5.1.23 who was holding back updating to v5.2.0 then that user wouldn’t be able to benefit from bug fixes in subsequent releases. If they reported a bug that was then fixed by the core team they wouldn’t be able to get the fix without updating.
Best wishes
Jeremy
Hello all,
Thanks!! Thanks to Mario for a way to wrap the macro that works perfectly. Thanks to Jeremy and Saq for all of the explanations - for me those always make it easier to adapt to change. Thanks to Saq for persisting with a search for alternatives in the face of my insistence on wanting what I want. And thanks to Josiah for highlighting the amazing longevity of TW tools.
One further question that would help my understanding of things: is the wrapping enough to restore this macro to acceptability? Or is there really some deeper fundamental problem being described by “broken”, “off-spec”, and “improper” that means I should think of the wrapping as only a temporary bandage?
cmari
Hello all,
Thanks!! Thanks to Mario for a way to wrap the macro that works perfectly.
It was Jeremy’s comment, that made me play with the possibilities. …
One further question that would help my understanding of things: is the wrapping enough to restore this macro to acceptability?
IMO it should do the trick. … It basically adds the refresh mechanism that should “inside” the macro code, onto the outside. … The $vars widget (as every other widget) implements a “watchdog” that “listens” to changes that happen to parameters that are passed to the widget.
In case of the workaround <$vars x={{!!toggled}} y={{!!barray}}> it’s the {{!!field-names}} that are important. The variable names don’t matter, since we don’t really need them. Whenever the fields change, the vars widget will redraw itself and it’s childs. Since the <<dailytasks>> and <<togglers>> macro are part of the widget body they get refreshed, in the exact same way as the <$transclude macro did it in the past.
Or is there really some deeper fundamental problem being described by “broken”, “off-spec”, and “improper” that means I should think of the wrapping as only a temporary bandage?
cmari
I think this workaround is perfectly valid. … It still should be fixed on the js-code level. … BUT upgrading to v5.2.0 isn’t “killing” the old functionality anymore. So we have more time to really fix the problem, where it should be fixed.
-mario
Ciao Jeremy …
Jeremy: | do plan to update the release note with a more prominent warning of the impact of this change.
TT: Good! IMHO, it might also be worth mentioning that their tool of concern would continue to run fine under previous versions of TW. For working apps mostly it is NOT needed you upgrade!
From the core perspective we really want people to upgrade actively used wikis to each new version because it’s expensive and complex to offer support for old versions. For example, if we had a user on v5.1.23 who was holding back updating to v5.2.0 then that user wouldn’t be able to benefit from bug fixes in subsequent releases. If they reported a bug that was then fixed by the core team they wouldn’t be able to get the fix without updating.
Right. I do broadly understand that. BUT in practice it is a bit of a puzzle too. Older, non-complaint plugins, by authors no longer active, could end up ESTRANGED.
(FYI, in THIS thread, I do see PMario work hard for a compatible solution for the OP’s user problematic. Maybe that is enough for these edge cases? I.E: a dedicated dev solves the issue functionally. What he is doing is solving a problem for the “absent landlord”. One “good enough” to work for the moment.)
IMHO, I agree you should not go backwards. It would make no sense and would be ineffectual and serendipitous if and when it worked.
However the latest version is, crudely speaking, an “interruptus”. That may throw some plugins (BUT I have no idea how many; it may just be a manageable handful?). But IS the “break with past” minor or serious?
SO, to be practical. I’d say it is still a bit unclear how much of an ISSUE all this is.
Just thoughts from a non-programmer.
Best wishes
Josiah
Is this macro usable with latest versions of TW. If it’s usable, where should the code suggested by pmario in the posts above be added ?
As far as I can remember it’s needed, when you use the macro. You should be good, if you use the following wrapper code for both macros
<<dailytask>> and <<togglers>>
In the mean time you should use the $let-widget instead of the $vars-widget.
<$let x={{!!toggled}} y={{!!barray}}>
<!-- your macro call comes here -->
</$let>
Info: The backticks for the code here are only needed to be imported in the right way at talk.tiddlywiki.org
So you don’t need them for your code.
Thanks PMario. It works now in the latest TW.