The quickest and easiest ever todolist in tiddlywiki ? Requires 5.2.0

Folks,

Inspired by section Editor, and other discussions of late I just created the attached tiddler quicklist.json (916 Bytes) a single tiddler solution.

Drop it on tiddlywiki.com then create a new tiddler, adding the tag quicklist, and enter a few lines.

Once you save the tiddler each line will have a checkbox in front of it. Use the fold button that appears to hide the text and just see the todo items.

I think this a useful solution already and in its own right.

Although this is only a proof of concept but you will notice leading spaces and blank lines have no effect (standard behaviour) and I have allowed some line prefixes to be ignored so you can use them to organise your items with headings and other notes. However it will not handle multiline widgets or wikitext.

Multiline paragraphs are fine, it just makes use of the new line.

If you play with this a little you will see it has surprising advantages such as allowing inserting and removing items. You can always edit a task but if its already checked it will loose the check (but then it is different).

This is making use of the fact that fieldnames can be tiddler names and tiddler names can be text.

Possible improvements

  • Stop the “prose” fieldnames appearing in the new field dropdown.
  • Add a way to add multiline widgets etc… in a block that is ignored for even richer content along with the todo items.
  • Auto fold the tiddler when adding the tag
  • Click to create a full todo tiddler

https://talk.tiddlywiki.org/t/section-editor-plugin-first-stable-release

It is another reason for the solution raised in this following discussion

2 Likes

One of the best things about tiddlywiki is how quickly you can iterate and improve something. Here is my new version that allows you to create todo tiddlers from your list.

quicklist.json (1.5 KB)

And prefill in $:/templates/new-todo

3 Likes

@TW_Tones
I downloaded it from you the other day - before you added the folding button. Saw the link you are referring here and just used the field hide-body.

It is a very useful tool, I have already used it several times. Small and simple.
Easy to drag to your wiki and get on with the work you are doing - and not growing the wiki doing it. That is what I like.
Great fun to see where you are taking it.

2 Likes

Hi @TW_Tones - Thank you for sharing! Please also see

https://kookma.github.io/TW-Shiraz/#demo%2Fquick-table-taskify

Shiraz quick table allows you to create static todolist like GitHub and interactive todolist

Static todo

Quick table allows you to create sophisticated contents!

See:

https://kookma.github.io/TW-Shiraz/#Tutorial%20Quick%20Tables

Tones,
I think teh new features from TW 5.1.23+ and recent TW 5.2.0 make it easy to parse and display contents in many ways!

2 Likes

Yes,

But for me it is also a maturing of my own skills on this, helped by the frenetic activity with similar solutions in the community.

Yes it does look like quicktable is more sophisticated. My quicklist is intended to be very minimalistic and appeal to new users or an “old” user on a new site or in anew tiddler. I think it may be enhanced somewhat in a few ways but not many. It just needs that use case, and because of its simplicity it can co exists with other solutions.

It has raised the question of system fields because these todo items become fields and pollute the new fieldname drop down. I may prefix them with “todo-” so a filter can hide them.

Thanks @Birthe

Apart from supporting content that is not automatically made into a list item I thought it may be convent to add it from a bookmarklet in whatever tiddlywiki I am visiting. This has led me to consider;

  • Single tiddler prepared todo lists to undertake a reoccurring set of steps, common ones which could be a bookmarklet.
  • Other quick versions like quicktext, quickform, quickreport or even quicktable (or another name).
    • All would use absolutely minimal pseudo markup. eg; Quick list uses any line not proceeded by wikitext markup. Quick form may create a form from a list of fieldnames.
1 Like

Exciting!
The bookmarklet idea for todo would be handy. We are always getting ideas when visiting tiddlywikies.

Now you are talking, a total suit of Quicklets (I will certainly not call them. Quick***) :wink:

Some time ago i GG, you uploaded a quickview - or a name like that. Creating a edit list field. That one gave me so many ideas - it ended up with a edit short list field and a edit long list field. (The last creating tag textarea type fields.) That combined ended up being a kind of database. If one of the fields are called image, it will be shown above the other fields… It worked well, but then the ideas took the better of me - ending up with buttons, help popups and all sorts of decorations (In Danish - for sharing with my not tiddlywiki using friends.) He he, you guessed it, they do NOT know it is a tiddlywiki.

I am telling you this because examples as the Quicklets can be a start for new users of tiddlywiki also.

Now I always want to ask, do your family and friends like tiddlywiki?
I suspect that mine do not - due to all the time I use playing with TW.

Tiddlywiki :: The tinkerers paradise

Takes a 5 pound (2.25 kg) hammer to the phrase, “Just because you can, doesn’t mean you should!”

:blush:
:nerd_face:

1 Like

That’s certainly a quick list! We sometimes talk about “tag” pollution. I would worry that now we will have field pollution. If every item on a todo list becomes a field you could easily end up with hundreds of fields!

Instead of “checked” and “unchecked”, you might consider alternatives like “qchecked” and “qunchecked”. That way you can periodically detect and delete checkbox fields.

You made me remember Alberto Molinas solution. No tiddler for each task and no fields.
From the start to the final solution

Quite some tag pollution though.

1 Like

I don’t think I’ve heard of <<storyTiddler>> before.

I like tw5-checklist, which is light on fields and tags, though the code itself isn’t exactly light.

1 Like

Mark,

Yes part of the Quick here was making it not just its use. I already have thoughts on resolving the “potential” field pollution problem but it certainly raises again something I mentioned before the 5.2.0 release, the concept of a system field namespace.

However one mitigating fact with the current quicklist may be its purpose, a quick list on any wiki to collect thoughts, actions etc…, once completed it can be moved, deleted or exported and the new fields go with it.

Thanks for the suggestion.

Yes, well actually I am tempted in a later release to move from a simple check box because there may be value in having different content in this field. If you have created a tiddler from one of your todo lines it may change to “externalised” (for want of a better word).

I am tempted to apply a prefix or suffix to each field and filter them out of the drop down, then the pollution is much reduced. Being able to filter out fields from the drop down would be a good core hackable.

As @Birthe intimated it is possible to run down rabbit hole with anything in tiddlywiki. Although this example is generating some innovative ideas I also see value in applying a whole lot of constraints. New ideas may form a subsequent solution rather than change this one.

It is now possible to more easily extract and delete lines from text, but there are no mature solutions for this. I think if the item is externalised (with the + button) and tagged with the current tiddler I could delete the line, and field and list here via the current tiddler tag. Think of the quickllist as a scrap of paper, you dispose of rather than keep indefinitely.

<<storyTiddler>> is effectively an alternative to currentTiddler, it is set in the view template process (where I found it) as it iterates the items in story list. In a way, by never changing its value in my own code (unlike currentTiddler in lists etc…) it becomes a reliable alternative for the tiddler title you are looking at. I write all my code for currentTiddler where possible. Other related tricks are possible with the <<transclusion>> variable.

You don’t actually change the value of TW’s “currentTiddler” when you create a list. You’re creating a new variable, called currentTiddler, scoped to the list.

Throw this at tw.com:

<<currentTiddler>>

<$list filter="[tag[HelloThere]]">

:<<currentTiddler>>
</$list>

<<currentTiddler>>

So, inside the list rendering, you can think of currentTiddler as “private” to the list widget.

That is correct!

As they get more complex like using multiple transclusions or macros that use macros it is good to have each macro respond to currentTiddler, rather than demand a tiddlername be provided.

To follow your example;

<<currentTiddler>>

<$list filter="[tag[HelloThere]]" variable=additional-tag>

:<<currentTiddler>> <<additional-tag>>
</$list>

<<currentTiddler>>

In which case <<currentTiddler>> remains the original tiddler.

The final code pattern used here is when you don’t need the value of the filter.

<<currentTiddler>>

<$list filter="[all[current]tag[HelloThere]]" variable=nul>

:<<currentTiddler>>
</$list>

<<currentTiddler>>

Hi Mark, I have a fix for tw-checklist. Coupled with autolist mod and a toolbar icon + keyboard shortcut, it is quite fast. No field or tag pollution. Ping me if of interest. It is not packaged.

1 Like

@fastfreddy [tw5] Re: editor-auto-list - how to add [ ] to * and # - this was very useful.

What is autolist mod?

Thanks!

Hi Mark!
This is a small mod to Saq’s autolist plugin that makes it effective for the check list input format. This is the mod: https://talk.tiddlywiki.org/t/tw5-re-editor-auto-list-how-to-add-to-and/1102

In my workflow (beyond the Autolist mod mentioned above), I have fixed a minor functionality issue in tw5-checklist itself, and I added an option in the configuration tiddler to hide/show the input form. Together with a toolbar button/keyboard shortcut, the checklists behave like numbered or bulleted lists during input.

I appreciate everyone cross referencing other checklists, but this thread has being hijacked.

I would liked to have discussed the original idea rather than all its alternatives.

In future feel free to mention other solutions but please start your own thread and link to that as well in the same reply (edit later if necessary).

My own thoughts on the original quicklist here is as follows;

  • Create the fields with a prefix such as $:/local/ item content
  • Exclude “system fields” or [prefix[$:/local/]] fields from the new field dropdown
  • make a “quicklist” tiddler just one of multiple types of tiddlers that have a different viewTemplate handling. In this case it simply turns each line / list item into a line with a checkbox.
  • I plan to use the object-type field to select from different viewTemplates and hide the existing $:/core/ui/ViewTemplate/body
  • this generic solution would allow us to create a whole range of different tiddlers that respond differently to the content of the text field.