That’s right. The only problem we have, is that TW5 does not really have an indicator of a read-only mode.
May be there should be a tv-read-only definition somewhere.
I think that would be a good idea. But regardless of that, I would simply like a way to turn it off. I can manage it for myself when I’m toggling my own read-only mode.
I made something based on my other ViewTemplate checklist that is more functionally similar to the markup usage in TW5-Checklist, but they’re draggable. It doesn’t use the $checkbox widget so no field/tag/external tiddler needs to be created, they’re $button-widgets that look like checkboxes that rewrite the text field directly.
It’s also fairly expandable/customizable in terms of applying a template to an individual line with some sort of markup prefix so you can add functionality besides checkboxes.
6 Likes
I’ve dragged the six listed tids, as well as ReadMe: VT-markup as example of a working checklist, to an empty.html to test, and it’s not working. I’ve checked that the content and tags are definitely there, saved and loaded from scratch. Still no dice.
Any idea what the missing magic sauce is?
Check the order of the cascade filter $:/config/ViewTemplateBodyFilters/VT-markup
ah perfect. VT-markup before the built-ins instead of after and it’s working a charm!
I’d be curious what the performance difference is between this and the tgrosinger/TW5-checklist solution is. Both are very close to what I’ve concluded I want (human-readable wikitext), with the draggable items and more minimal UI of VT-markup winning me over. Plus for my clumsy/naive awareness of what’s happening under the hood, it seems more extensible too (something I simultaneously appreciate, and probably wont use!)
@arunnbabu81 Thanks for answering that for me
I too wonder about the performant-ness of my solution… The drag and drop basically duplicates the entire tiddler into a data tiddler before writing it back over the original so depending on the length of the content it could be a lot. It also has issues with how it splits up every single newline and will screw up widgets spanning multiple lines
I have extended the extensibility even more, it now covers some of the other topics that have come up in recent discussions, @JuanPalomo you may be interested in checking it out. I have split up the code a bit so it should be easier to customize for your own needs, and now you can add/remove additional checklist stages that you can write template tiddlers for. You can also now indent for subtasks.
https://hoopy-wiki.tiddlyhost.com/#ReadMe%3A%20VT-markup%20drag%26drop%20checklist%2Fcycles
1 Like
Thanks so much, hoopyfrood.
I’ll take a look and try it out to see if I can adapt it to what I want.
Best regards.
1 Like
Right. Difficult.
But it is a good solution? Because D&D is voluntary. It adds value but does not assert control?
Let me give you an example where I could use it for arbitrary order.
This is a shopping list in one Tiddler made with 21 Grossinger Checklists.
I order within them manually in WikiText. Add to them via Grossinger.
Could your way add dragability within each of the 21?
Due to a zero padding issue the drag and drop can handle up to 99 lines whether they be checklist items or lines of plain text, though it would be an easy fix to change the zero padding to allow for up to 999 lines. It is also of note that a list with 99 lines (not all checklist/drag and drop items) does lag like half a second on Firefox though it seems snappier on Chrome, see this example to assess the lag yourself:
https://hoopy-wiki.tiddlyhost.com/#99%20line%20shopping%20list
(seeing the 99 line long list made me add columns as a feature, simply type the number of columns into a field called “VT-markup-columns” and that tiddler will render with columns)
1 Like
It’s working well for D&D! Very good.
I did stumble on one issue. The checklist parsing seems to interfere with WikiText that starts at the left margin … Example …
Best, TT
1 Like
That’s because of the way wikitext checkboxes are parsed, replaced by widgets and then rendered line by line.
I was working on another wikitext checkboxes implementation, and I ran into the very same problem 
I might have found a solution, I’m still working on it. What I want to do is transform original tiddler text with a pipeline of functions, so that I can get the whole result in a single variable. Then I can <$transclude> the variable, and TW core will take care of the rendering of inline/block mode wikitext as usual.
[EDIT] The code is available below [/EDIT]
Fred
1 Like
How did Grossinger do his parsing?
Just a thought, TT
Grossinger’s plugin uses a javascript “wikitext-rule” module to define new wikitext, in the same way as normal core wikitext is defined. This can only be done with javascript, so a pure wikitext checklist needs another, hack-ier, solution.
Fred
1 Like
Here’s an example of pure wikitext checklists based on a viewtemplate and functions.
It’s very basic feature-wise, no D’n’D, no sorting, no sub-lists, but checkbox state can be toggled in view mode.
Syntax:
[ ] empty checkbox
[x] checked checkbox
[X] checked checkbox, with a capitalized X
[ ].userClass a checkbox with user-defined CSS class
So this:
is rendered like this:
Limits:
- Checkboxes must be at the beginning of the line.
- Empty checkboxes without a space between brackets won’t work (sorry @twMat)
Things that could/should change:
- Promote procedures and functions to a
$:/tags/Global-tagged tiddler - Make default classes configurable
- Include the viewtemplate in ViewTemplateBody cascade
- Checkboxes should be rendered and functional in edit-mode preview (might happen when previous item is done)
- Replace currently generated
<li><$button>...</li>by a custom widget
Things I won’t do myself:
- Add advanced functionalities (sorting, D’n’D, new item input, …) as I won’t need them
Please feel free to reuse the code as you wish.
The code might interfere with other solutions like @hoopyfrood’s or Grossinger’s.
As usual, don’t try it on important data, and be sure to have a backup before proceeding.
wikitext-checklists.json (5.3 KB)
Import this file in an empty wiki, then open “Result of wikitext-checklist transformation” tiddler.
Example wikitext is in “Wikitext-checklist test text”, and the code is in the template: “wikitext-checklist-viewtemplate”.
Fred
2 Likes
Very clever getting the whole thing into a single variable to transclude! I haven’t really worked with \functions or the :map filter operator before so I learned a lot looking at your code. I managed to hack some of it into my code and that solved the inline/block mode issue, the update is here
Although another issue has arisen: " quotation marks break it, only 'single quotes' can be used… it’s because I got a little weird with this bit of code:
\function parse.pass()
[[<$let linetext="""]][<linetext>][[""">]]
[<parseprefix>]
[[</$let>]]
+[join[]]
\end
Is there a better way of getting a parameter of a \function to be a variable in a \procedure that can be put into a different \function? Just trying to call it with <<double brackets>> wasnt’t working…
I’m glad it has been useful for you, I was hoping so when I posted this code!
This is the very reason why in my code, the “label” is included inside the custom widget body and not as a parameter. As far as I can tell, there’s no 100% reliable method to directly insert a variable content into a wikitext string without a risk of conflict with a special character.
In your code, you could try to uri-encode linetext before inserting it in the let widget, and let it be decoded at render-time (absolutely untested code!):
\function my.decode(string) [<string>decodeuri[]]
\function my.encode(string)[<string>encodeuri[]]
\function parse.pass()
[[<$let linetext=<<my.decode "]][my.encode<linetext>][[">>>]]
[<parseprefix>]
[[</$let>]]
+[join[]]
\end
You’d have to make at least my.decode function globally available though.
Fred
1 Like
that untested code worked perfectly! thanks!
1 Like