Feature: Bujo backarrow

[RonnyPfannschmidt]

this adds a bullet journal back arrow to complements the already existing arrow for documenting the normal migration

the bullet journal method has 2 types of migration

• > migration which documents the move of a task not completed in the current day/log to a new day/log
• < migration, which documents the move of a task to a future collection for further refinement

as it affects both text syntax and integrated actions i saw no way of implementing this in a plugin

its possible to go on with just documenting everything as "normal migration" but that takes away information useful for reflection

TODO:

• check wiki format version bump
• mini intro for bujo
• squash

[RonnyPfannschmidt]

the feature now roughly works

[pfalcon]

What is bujo backarrow? Why do we need bujo backarrow? How did we manage to survive without bujo backarrow for so long?

See https://github.com/zim-desktop-wiki/zim-desktop-wiki/blob/master/CONTRIBUTING.md#adding-new-features for inspiration.

[RonnyPfannschmidt]

the bullet journal back arrow complements the already existing arrow for documenting the normal migration

the bullet journa method has 2 types of migration

• > migration which documents the move of a task not completed in the current day/log to a new day/log
• < migration, which documents the move of a task to a future collection for further refinement

as it affects both text syntax and integrated actions i saw no way of implementing this in a plugin

its possible to go on with just documenting everything as "normal migration" but that takes away information useful for reflection

[pfalcon]

Counter-argument to that is that even existing Zim "extensions" pose interoperability issues with other (more popular, up to being a de-facto standard) markup formats (e.g. #26 (comment)).

[RonnyPfannschmidt]

if interoperable means that everyone can do next to nothing, that seems to be a flaw
there always is a friction between common feature sets and distinctive features.

As the de-facto standards are not extensible, this is a problem.

even for restructured text only a crude hack comes to mind to add this feature in a pristine way.

[pfalcon]

I fully agree that "if Zim already went beyond simple on/off checkboxes, then it as well can be extended further" is a good argument, I just point out it's not the only argument ("stop any adhoc additions" is also a pretty good one).

The biggest point though is that proposed changes should be well described (and even justified). As of now, the description here is still:

this intends to add bujo style back arrows to checkboxes

Hopefully, that will be fixed eventually.

[jaap-karssenberg]

Patch looks good to me and I intend to merge it. Could you also add some content to the manual (data/manual in the source folder) explaining this checkbox type? Maybe even a short intro to bullet journaling in the "usage" section. Also would like to see a test case that uses this checkbox type to make sure it does not break later.

With respect to the above discussion. Since I already added "[>]" I see no good argument to block "[<]". Yes, this poses an issue when we go to MarkDown, but merging now in our wiki format still leaves open the choice what we support for MarkDown and how we do that. So not a blocking issue right now.

Regards,

Jaap

[RonnyPfannschmidt]

should there be a bump of the wiki format version number (so old zim does not stumble?

[jaap-karssenberg]

Only if you also patch the parser to parse without this bullet support when the version of the page is lower. And patch the dumper to somehow escape the sequence on write. Since there is no escaping format in zim right now this is difficult. Risk is low in my opinion - not much use for a " [<] " sequence in regular use I suspect - so I'm OK without version bump.

…

-- Jaap

On Fri, Dec 4, 2020 at 10:05 AM Ronny Pfannschmidt ***@***.***> wrote: should there be a bump of the wiki format version number (so old zim does not stumble? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHWI4FMTZINNAWBSFQLSTCQ5XANCNFSM4UB7KN2Q> .

[RonnyPfannschmidt]

@jaap-karssenberg do you by chance know a example of the escaping mechanism - i'd like to attempt the version bump if i can figure a sensible iteration sometime this month, else i'll defer to the non-bump version (which is also fine, just irks me if i haven't at least tried the bump)

[jaap-karssenberg]

Afraid adding an escape requires refactoring of the parser. Have that on my long term plan but moving slow. Op ma 11 jan. 2021 00:24 schreef Ronny Pfannschmidt < notifications@github.com>:

…

@jaap-karssenberg <https://github.com/jaap-karssenberg> do you by chance know a example of the escaping mechanism - i'd like to attempt the version bump if i can figure a sensible iteration sometime this month, else i'll defer to the non-bump version (which is also fine, just irks me if i haven't at least tried the bump) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHSV6CDMKCED2RSMA7DSZIZMBANCNFSM4UB7KN2Q> .

[RonnyPfannschmidt]

I see, in that case a escape is not a sustainable way to do it right now,

If you agree that the risk is acceptable, I'd like to implement it without version bump then

[jaap-karssenberg]

Yes, as stated: risk is low in my opinion - not much use for a " [<] " sequence in regular use I suspect - so I'm OK without version bump.

…

On Wed, Jan 13, 2021 at 6:26 PM Ronny Pfannschmidt ***@***.***> wrote: I see, in that case a escape is not a sustainable way to do it right now, If you agree that the risk is acceptable, I'd like to implement it without version bump then — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHSSSJMFG722WO4XOXDSZXJTDANCNFSM4UB7KN2Q> .

[RonnyPfannschmidt]

@jaap-karssenberg gentle ping on this one,
i forgot to mention that i ended the experiment,
i'd appreciate if this was part of one of the next releases

[jaap-karssenberg]

Yes it is on my list, but progress is very slow on integrating as the whole lockdown put a big strain on my available time

…

On Wed, Apr 7, 2021 at 9:39 AM Ronny Pfannschmidt ***@***.***> wrote: @jaap-karssenberg <https://github.com/jaap-karssenberg> gentle ping on this one, i forgot to mention that i ended the experiment, i'd appreciate if this was part of one of the next releases — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHS6UNATFMWUZEQKDZDTHQD3VANCNFSM4UB7KN2Q> .

[RonnyPfannschmidt]

@introt thanks for iterating on the details, i wasn't aware how many detail locations i missed, i wonder of this can be condensed/dry-ed out as a follow-up

[introt]

No problem! Took me a while to find them all, in the end I just grepped for the MIGRATED_BOX and worked the missing pieces out from there...

I've cherry-picked the changes into your branch and closed #1473. You should be able to include those commits in this PR by merging RonnyPfannschmidt#1 (comment)

[jaap-karssenberg]

@RonnyPfannschmidt do you want to check and merge the fixes by @introt - or shall I have a go at merging both pulls ?

[RonnyPfannschmidt]

Thanks for the ping, I missed the pr on my fork, will give it a try in about 10

[RonnyPfannschmidt]

@jaap-karssenberg th merge went well, i'll now take a look at running the tests again

[jaap-karssenberg]

Thanks ! Now fully merged this tree into develop. In case of further updates, please commit a fresh pull request on a new branch.