Dropboard plugin somewhat broken in 5.2 prerelease

[jc-ose]

I am roughly aware of the various changes done in the prerelease, and know that there are some changes to the way wiki-text macros are parsed. Is this change expected to break some backward compatibility?

I apologize if this question is a poor one, I have not read most of the discussions here, but did do a quick search and didn't find anybody mentioning something like this so far.

I'm asking about this because I use Reid Gould's dropboard plugin in one of my wikis which does not behave the same way in v5.1.23 (and previous versions) and v5.2.0. I think the new parsing functionality may be causing some of the wikitext to be interpreted differently, and that has lead to some problems with the plugin.

I'll be honest, I haven't tried to track down why it is not working at this point, I just know that there are issues. I can spend some time looking at it later if that would help.

[pmario]

Hi @jc-ose ... I think it would be best to raise an issue at: https://github.com/reidgould/tiddlywiki-dropboard ... That's the original github repo.

[Jermolene]

Thanks @jc-ose that's helpful. I've an idea what might be the problem. Can you describe how Dropboard doesn't work? Could it be described as a matter of the screen not updating as expected?

[jc-ose]

@pmario I will do that if there is still an issue after 5.2 is released. Right now I suspect that the new parsing tools are causing something odd to happen.

@Jermolene The issue I noticed is that in the rendered macro content, there are three closing </$set> tags showing up just below it now, which tells me wiki-text used by the plugin is being interpreted differently. So I don't think this is a screen updating issue but I could be wrong. This was tested in an empty prerelease file with only the plugin installed - in a tiddler where only the main macro (or in this case, transclude widget) needed to run the plugin is called. I also found that some widths no longer seem to be right on some of the divs created by the macro, but most of the core functionality of the plugin seems to still work more or less.

Because of all that, I believe there is something wrong with the way the wikitext provided by the dropboard plugin is being parsed in the new version. If that is expected based on the changes to TW, that's fine. But I think the goal has been to make it as backward compatible as possible, which is why I've asked about this here.

Here are some additional notes:
The way the plugin is setup, each board is rendered with the wiki-text: <$transclude tiddler="$:/plugins/reidgould/dpbd/templates/view/Board" mode="inline" />

In that tiddler that is rendered ($:/plugins/reidgould/dpbd/templates/view/Board), there's a lot of wiki-text content, including a lot of set widgets, so the issue is probably coming from there. I should have some time this weekend to take a deeper look into what's going on, but I may be limited in what I can do to determine why it is behaving differently between the the previous stable TW version and the 5.2 prerelease.

If you have something specific in mind you think I should be looking for, that would be helpful.

Anyway I hope this helps in some way.

[AnthonyMuscio]

While you are looking I have seen similar results in my own solutions

• when a variable has no value. That is something contains a null value. This can sometimes result in the wiki text being interpreted differently, and resulting in displaying stray set or list closure. This is especially if that variable contains wikitext such as in actions.
• Also if the order of open and close is broken you will get stray set or list closure.
• Some designers rely on auto closure (assumed at end of the tiddler) of set and vars widgets which may give rise to artefacts like this.

Its a worthwhile project moving drop board into the latest version.

[Jermolene]

Hi @jc-ose

In that tiddler that is rendered ($:/plugins/reidgould/dpbd/templates/view/Board), there's a lot of wiki-text content, including a lot of set widgets, so the issue is probably coming from there. I should have some time this weekend to take a deeper look into what's going on, but I may be limited in what I can do to determine why it is behaving differently between the the previous stable TW version and the 5.2 prerelease.

That's very helpful, thank you. I can now duplicate the problem – I copied the text of that tiddler to a new tiddler on https://tiddlywiki.com/prerelease, and saw the </$set> </$set> </$set> problem you referred to.

[Jermolene]

It turns out that the problem is that the tiddler in question has a typo:

  <$set name="table-ListWidth-Dec" filter="[field:title<tiddler-SearchListFilter-Live>]"
      value=<<list-ListWidth-Dec-SL>>
      emptyValue=<<table-ListWidth-Dec >

The last line should be emptyValue=<<table-ListWidth-Dec>> >.

The trouble is that this typo is parsed differently in v5.1.23 vs. v5.20. Presumably it's one of these changes. @saqimtiaz do you have any thoughts?

[saqimtiaz]

@Jermolene I don't have the opportunity to test or debug at present. However I am very confident this difference in parsing is arising from #5451 and that the widget parser now also used for macros is not as lenient of syntax errors.

[saqimtiaz]

@Jermolene confirmed #5451 as the cause of this change in behaviour.

I would be inclined to think of this as an inadvertent bug fix.

[Jermolene]

Thanks @saqimtiaz that's my thinking too. I'll add a new section to the top of the release notes highlighting this and the support for parameters in macros in filters.

[jc-ose]

That's very interesting, thanks for looking into this! I originally wanted to bring awareness to this because of the change in behavior, but since that change is due to a typo, the issue definitely falls on the original plugin to fix it.

I really appreciate you all helping me understand what was going on. Keep up the good work! I'm looking forward to the release of 5.2.