Add support for customisable TODO keywords

[FlorianF]

, kinda works … it’s just a tad unaligned…

[alex0]

About the issue of custom TODO keywords, if it was for me I’d trash the current implementation for something based on tags and namespaces:

• the user creates tags like:
  • #task/todo, #task/doing, #task/done
  • #bug/open, #bug/closed
  • etc
• namespaced tags like these have a little button next to them that change them by cycling between tags of the same namespace

If order is crucial, then introduce a special property that these tags would have to specify the order:

task/todo.md
next:: #task/doing

Possible UI implementation:

Advantages:

1. You can open #parent/child page to have an overview in Linked References for example of #task/todo.
2. You can open #parent page for the same overview of all #task, #bug etc.
3. You can further specify by adding other levels like #bug/closed/wontfix that still count as #bug/closed
4. The three points above but in queries, for example (and [[project]] [[task/todo]])

[alex0]

Then add the desired margin top like this:

.form-checkbox, .form-radio {
    float: right;
    margin-top: 5px;
}

[FlorianF]

This worked for me:

.form-checkbox, .form-radio {
    position: relative;
    left: 100%;
}

thanks.

[francescob]

I 100% agree. I already do something similar because I have items that are “todo right now” (like a checklist) and items that are “todo far in future when a certain thing happens”, and I already organize those through…guess what! Tags

Tags are super powerful, can replace basically anything.

[qroq]

great you are working on this, just a suggestion: maybe take in account an option to have localized TODO keywords, I mean the workflow may be fine but user just wants those special words to be in the same language as the rest of the app… this ideally would extend for other words like SCHEDULED or NOW etc. -as they don’t look too good when mixed I think-

edit: for instance in spanish it could be something like: PENDIENTE ENCURSO COMPLETADO… words are way longer though

[PaulN07]

I love this concept its great! all I would like to add is keyboard shortcuts are key as long as u can use the ctr+enter to cycle them and have the ability to set a default. Then if u have it so when your cycling u can type a slash and be sent one namespace level deeper. E.g. to give a task “development/bug/open” u can do ctr+enter type the start of “production” then select from keyboard then u can use ctr+enter to cycle between “development/bug”, “development/design” etc etc then type another slash and cycle todo, doing etc etc

Just a possible idea but would mean you can add any tag to any item in any tag namespace ALL without having to remove you hands from the keyboard. Defiantly after a while the common ones you use would become complete muscle memory.

[alex0]

@futurized what are the advantages of using properties for tasks workflow instead of tags as explained here?

Add support for customisable TODO keywords

About the issue of custom TODO keywords, if it was for me I’d trash the current implementation for something based on tags and namespaces: the user creates tags like: #task/todo, #task/doing, #task/done #bug/open, #bug/closed etc namespaced tags like these have a little button next to them that change them by cycling between tags of the same namespace If order is crucial, then introduce a special property that these tags would have to specify the order: task/todo.md next:: #task/doing…

Notice that hashtags can be inline, so we could have compact one-line tasks. Properties instead force bigger blocks. Personally I like my tasks to have only one line.

[FlorianF]

I would love properties to be able to be placed anywhere inside the block (just like tags) and Logseq logic to be able to differentiate and use them as properties in an auto-hiding properties section. So, for example, I would have this task:
- Buy the milk status::Task/TODO:: (- Buy the milk ::Task/TODO:: would mean the same thing and the status property name would be auto-infered due to the workflow definition somewhere in config.edn or in the namespace). The result would be - [ ] Buy the milk. One would not need to place the TODO text right after the bullet but Logseq would still place the Checkbox at the beginning of the block while having the status:: property in the properties section as well.

In the case of status: property one would not see the TODO because it will be transformed in a Checkbox by Logseq UI, but for other properties this would open up so many possibilities. For example:
- In this book, author:: Dale Carnegie:: speaks about... would be rendered as - In this book, Dale Carnegie speaks about.... I am not suggesting the tehnical way to differentiate the property from its value and the surrounding text but the above would leave visible on-screen the value, while “pulling” into the properties section the author:: Dale Carnegie property:: value string.

Some of these are maybe feature-request material but I wanted to express here as well my need to have properties inline as tags can currently be placed.

PS: While writing the body of the block, one would refer to the saved properties as variable to be able to reuse them throughout without re-typing them again:
- Another interestng point I find author:: making is that .. → - Another interestng point I find Dale Carnegie making is that ..

[alex0]

@FlorianF I have proposed a syntax for inline properties here sometime ago:

Syntax for inline properties::

From the discussion here I think we have a cool proposal. We want this syntax: - [[title::The Picture of Dorian Gray]] is a [[type::book]] written by [[author::Oscar Wilde]]. as a more compact way to write this block: - type:: book title:: The Picture of Dorian Gray author:: Oscar Wilde [[The Picture of Dorian Gray]] is a [[book]] written by [[Oscar Wilde]]. Rendered, with links, as: The Picture of Dorian Gray is a book written by Oscar Wilde. So it’s rendered just like: - [[Th…

CC @futurized in case you are interested

[FlorianF]

Cool suggestion. But I would add the property as dynamic variable to the mix and also block editor suggestions based on block text or properties values.

[Deviation]

Wondering if there has been any progress on this recently?

I have been doing something similar to @alex0 suggestion, but of course its all manual (rather than clicking to change state, I have retype the tag.)

One further suggestion is that this be added to a workflow template as a property. By example, if a template is “Prepare Taxes” it might have a workflow:: property of “0:TODO, 1:DOING, 2:DONE” wheres a template for “Paying Bills” might have a workflow:: property of “0:DUE, 2:PAID”

[alex0]

@Deviation

Wondering if there has been any progress on this recently?

In the DB version: yes, but tasks are implemented with the new “properties templates” i.e. you add the hashtag #task and then appear properties where you set to-do, done, priority, schedule ecc and you can create your custom workflows.

[overthere]

Neat, thanks for the info. I didn’t know they were tacking other stuff while working on the DB implementation. Is there a summary somewhere of done and planned work, as an alternative to reading through 2k+ commits?

[Federico_Frosini]

@alex0 in the DB version there is still the possibility to change status via keyboard like now with the / command?

[alex0]

@overthere

Is there a summary somewhere of done and planned work, as an alternative to reading through 2k+ commits?

Contributors on GitHub have access to automatic builds after every commit but everyone can build it locally:

Building and Playing with the Logseq DB Branch

Here there is a summary of the features:

The future of Logseq - Sneak peak at the DB Branch

@Federico_Frosini

@alex0 in the DB version there is still the possibility to change status via keyboard like now with the / command?

Yes, commands like /Done update the status property with the relative value.

[overthere]

Thanks, that looks interesting.

[jeroen_ophetweb]

Please do not do this. This is one of the big reasons why I left Obsidian. It might be a standard but it messes up list and alignment all over the please in Obsidian.
I like the TODO/DONE method as it is inline and can be added in the beginning or at the end of a sentence and it is always moved to the beginning.

More, configurable, states would be great.

[onkeltem]

Hi!

I believe I’ve read the entire thread and haven’t missed anything. Is there any progress with implementation of this cool feature? We’d be really happy to start using customized workflows.

I personally can’t use the current workflows at all. Imagine I have a list of books that I haven’t started to read. The only option now is to mark it either LATER or TODO. I opt to TODO:

Now I start reading all of them and to reflect that Ш click the TODO labels and get this:

As you see, my day in the journal is now augmented with a long list of repeating blocks that I already have on this page. I cannot find how I can disable this behavior.

I would really want a workflow that doesn’t produce any side-effects. Those statuses are for my own use. For books I want “TOREAD” > “READING” > “READ” or “FINISHED” | “CANCELLED”, for dozens of other entities I want their own workflows.

I’m pretty sure this scenario is one of the most requested ones (judging from the thread).

[finticemo]

“These statuses are for my own use”

Then (assuming you don’t otherwise want the NOW query) you should probably remove it from your list of default queries in config.edn. I don’t remember the exact detail but IIRC searching ‘:journal’ should find it, because it’s specifically associated with journal pages.

I think this query could be smarter, eg. excluding blocks that are already shown in the current page. However I think you will find that some people do prefer the ‘dumb’ behaviour (suppose you had a much longer page that had TODOs mixed in, for example) and there is no obvious right answer for what the default config should be here.