Direct markdown/wikitext checkboxes !?

While definitely interesting, I think this is a step away from some the “readability over formatting” principle for markdown. Also, I think these “shortforms” should have as highest priorities: “effortless to remember and to type”. IMO, [] and [x] are so far the clearest suggestions. (Maybe [] and [ ] could be synonyms - the former is of course smoother to type quickly (imagine a 20 items list!) and the latter has smilar width as when checked.)

If that is to be done, then maybe a similar tactic to what we use for tables could be used, i.e various “flags” to signify e.g h(eader) and f(ooter).

…but for a checkbox list it wouldn’t concern “rows” but instead, as you indicate, more be a matter of adding “surrounding functionality” (- “clear all”, “sort”, etc). So it could maybe be invoked with keywords, something like:

[]add,delete,clear,sort
[] bread
[x] eggs
[] milk

<!-- [ ] Bananas --> .

I like that idea. And bananas too.

I think I would too. Having check/uncheck items in view mode, but add/remove items in edit mode, feels like the right demarkation to me (though if I got into using checklists heavily, I may change my mind)

That’s an option in tw5-checklist

fwiw, the checklist system I had my eye on is the one used here Mehregan Edition — a personal knowledge management app …but looking into it now, I see it’s this Kara checklist, which wraps them in a @@.todo block, and can (afaict) only have one checklist per tid. Kara 0.9.7 — In tiddler plain checklist and interstitial journaling plugin …it turns out what I like about kookma is having the hideable footnote with the todo list in it, but now I’m not sure that’s exactly what I would want in all cases

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.

https://hoopy-wiki.tiddlyhost.com/#ReadMe%3A%20VT-markup

6 Likes

3 posts were split to a new topic: Searching for Flexible Checkboxes for Task Management

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?

image

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 …

Screenshot 2025-09-04 11.27.04

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 :confused:
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:
image
is rendered like this:
image

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 :man_shrugging:

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