I use tags and attributes quite extensively for both items and tasks but there is no natural way to union them (e.g., item where x > 10 select x union task where x > 10 select x or alike; rather not speaking about the table object here) if I need to query x from, say, everywhere and, e.g., sum it or whatever I want to do with the values…
I think that more natural way of threating the tasks would be that task will be just item with some special extra reserved attribute attached (or some other way to denote the fact and test it, because any “special” or “reserved” is TBH ill by design; see below).
Task is in fact only a item in a list with some additional property, the [ ]s boolean (or other) value, or (better) item in a list is a metadatum of the task, simply because task’s data is, in fact, it’s boolean (or other) value.
Similarly, could we then allow for the [ ] status in paragraphs too? Yeah! Some Markdown interpreters allows for in a paragraph, as you can see here , funny enough) and I simply would like to see it too in SilverBullet. The exact way to access the states of all the s in this paragraph I have no idea how to deal with and it’s a big question to play with.
This sounds like two, maybe three separate problems. Idk too much about lua/space-lua, but I think doing unions of queries should be fairly easy to do, possible even without changes to silverbullet itself.
I think that’s basically it already … more or less. Anything you can query is just an Object with some special tag, e.g. page, item, task, etc. Merging two tags into one isn’t really a solution here I think. It only solves your specific problem. Also how would one properly and easily filter tasks from other items then.
Allowing checkmarks everywhere is an interesting one imo. CommonMark doesn’t have tasks, GFM only has them at the start of list items, so just like silverbullet right now. Technically it would be easily possible (touching lezer markdown parser ), but it poses some questions for me:
Why? Whats the use case specifically? I like generalization, but it’s ranked after never change a running system and common sense on my list at least
How would you query them? Would you even query them? Because how would you associate a checkbox and text?
Allowing checkmarks everywhere is an interesting one imo. CommonMark doesn’t have tasks, GFM only has them at the start of list items, so just like silverbullet right now. Technically it would be easily possible (touching lezer markdown parser ), but it poses some questions for me:
Why? Whats the use case specifically?
It’d be absolutely great feature nobody has done properly (it won’t be as easy, as you may think, I guess),
Why to limit “taskness” to just list items? (And the semantics of the list item is wrong, read below.)
It will serve great for reminders (in connection with [attr: ibutes], of course).
Just type freely a list of things you want to do without the need to break paragraph and building a list. Sometimes you want denote a task here, then there. This feature will lead to relaxing yourself from the need to enumerate some tasks list, you could mark that something needs later attention anywhere and also, whether it already done or in which state it is etc. I love the idea.
… Whatever else (Users will generally use the feature in unpredictable ways, I guess.)
I like generalization, but it’s ranked after never change a running system and common sense on my list at least
This sort of generalization will have several benefits:
it will retain the current task lists although it will certainly break backward compatibility of accessing the states (or some exception will have to be done for the first one state box in a paragraph - e.g. it will get duplicated to the task table for backward compatibility)… So,
list
item
tasks
will still work, but will allow alternatively also
task with checkbox trailing
and tasks with checkbox inside it
and nothing would change (if the backward compatibility will be achieved) but it will provide more syntactical flexibility for single boxed tasks.
I would love that personally!
any paragraph… well, OK, I consider list items content to be, in fact, paragraphs like this:
Item paragraph 1.
Item paragraph 2.
code in item
Item paragraph 3.
I think it’s much clearer semantically to think of them as of paragraphs.
And any paragraph could be made into a task, or a serie of tasks .
You will simply just query for
paragraph
where
state and
parent = 'item'
What do you think? And, by the way, that way, we can say that code blocks are, in fact, also always embedded into paragraphs and therefor could be assigned tags, attributes and tasks. (Maybe we should talk about blocks instead of paragraphs.)
Well, the big question is
How would you query them? Would you even query them? Because how would you associate a checkbox and text?
I have no clear idea yet. But we can have array of states for each paragraph (or heading or whatever…; note: I substitute the task to state from now on for clarity)
```query
paragraph
where
state = 'x' -- any task checked
```
(Quite similarly to how tags = 'foo' works now for the tags array in queries.)
For example for the following paragraph:
This is a sample paragraph.
We would have this array attached to the paragraph:
state:
- ' '
- 'x'
- ' '
or using nil/null (denoted by ~ in YAML, AFAIK) values instead of ' ':
state:
- ~
- 'x'
- ~
I consider here that people use also [free text] in tasks now (we can find better term for the [...] stuff than “checkbox” - what about “statebox”?), not only as the boolean checkbox! User has also the freedom to choose whatever she wants and that way we can allow for it.
How to index? This is the hardest one. I thing each [box] can be a marker to the position in the paragraph (or heading or whatever else it would be allowed to work in - headings are not indexed now). But this forum software clearly knows to handle them, so we can take inspiration from them.
), but it poses some questions for me: