RFC 13 - Todo Notes #1358
Replies: 10 comments 13 replies
-
Using the bracket ( Using frontmatter variables to track completion and only rendering the SuggestionInclude the <!-- raw markdown -->
- [[proj.[x]-dig-a-hole-[x]]]
- [[proj.[ ]-build-a-cabin-[]]] TradeoffDendron will need to rename tasks files and all the corresponding reference links as the task's completion status changes. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Perhaps we could get to a good middle ground by using the decoration highlights, but adding integration with Todo Tree. For example, we could automatically add a |
Beta Was this translation helpful? Give feedback.
-
There's a lot of interesting history in the org-mode world with states stored in the name. Typically you'd have The most interesting part that could be immediately useful for this feature is the ease of formatting these "chains" through the pipe symbol separator. Left side is active, right side is inactive. Using this type of qualifier would also make it very easy for org-mode users to migrate to Dendron, set up for better pod import/export support, and very easy to manage in settings. Example: |
Beta Was this translation helpful? Give feedback.
-
As someone who constantly uses markdown editors on my phone for tasks I keep track of with Dendron files, I really hope the "editing notes outside of VS Code" scenario is kept in mind as we design this feature. If it's possible, I'd recommend not relying too much on VS Code's UI, text decorators, keybindings, or even file names to show task-related information or to make them discoverable. External editors often recognize the I'm not sure what to recommend, so I'll share a description of what I currently do. Hopefully a user story can be productive? I use Todo Tree with a few different patterns that are also tags in Dendron. I've configured Todo Tree to look for the names of some top-level tags as patterns (like I'm used to the Taskpaper format of annotating tags, where annotations go in parentheses: This use of tags also works with sub-tags. If I have In my files, I currently enter tasks like this:
This lets me see the different annotations in the files themselves, whether in Dendron, the Todo Tree pane, and also in external editors on my phone. I'm not sure if using Dendron's tags like this is the ideal approach to todo notes, but it is at least understandable in external editors. Perhaps what this user story suggests is that we might want to consider at least two different types of Todo Notes or todo-related behaviors? One might be a special type of note for projects. Its features could rely more on frontmatter, and be less interoperable with external editors. It might use the decorator trick to show percentage done wherever it's referenced, based on something in the frontmatter, and could also serve as a log. The second feature might be more for atomic tasks / sub-tasks, and be designed with interoperability in mind? Maybe there can be a Dendron command (like Basically, I just want to say that I'm thrilled that so many people are thinking about how to use VS Code & Dendron to do something that's difficult with text files! I also really hope that we keep interoperability with non-Dendron tools in mind as the patterns and features develop. |
Beta Was this translation helpful? Give feedback.
-
An ability to hide todos on published pages would be good. One can hide lines with HTML comment tags |
Beta Was this translation helpful? Give feedback.
-
UXAfter using task notes for a week or so now, I feel the need of converting an existing note into a task note. e.g.)
Another sort of command that would be nice is a command that prompts you for setting the frontmatter properties specific to task notes. e.g.)
I've read a few prior discussion on exposing more metadata (e.g. status) to the filename. I feel like this goes against the conventional expectation of markdown task lists. I think this problem stems from the fact that we don't have wysiwyg rendering of the notes in VSCode, and have to resort to text decorations to emulate it. Ideally we would not worry about this if we have full control of how it's rendered. But for now my personal opinion is on the conservative side and preserving the conventional way of markdown task lists. Instead, we add tooling around some operations that we lose from rendering text decorations:
On the enhancement direction of todo notes (special notes in general)The discussion on storing state in the note name a la org-mode is interesting. We definitely have a lot of users coming from org-mode and this would be a great addition. However, I think the purpose of having a note type system, and implementing a special note type that Dendron natively support is to suggest a best practice. I think it is important that we take note of that and limit what the todo note is capable of. (This is not strictly a point discussed with the note type system RFC, but I have brought this up in the discussion for note indexes here: #1076 (comment), which was where @jonathanyeung suggest we develop the idea of note type system.) Perhaps we can fully develop this note type (and accompanying commands) so that it offers a best practice experience of the conventional markdown todo note, and separate the concerns of extended power features like supporting org-mode-like features or external integration capabilities to another special note type? This way, we have the freedom to explore complex operations like org-mode's chaining and taskpaper's notations without worrying about how it meshes with the vanilla todo note. Building a solid foundation around the vanilla todo note type would capture light users and newcomers. Separating a more advanced todo note into a separate note type would make power users happy. Separating the two will simplify the implementation details. Less moving parts on each note type system, less things that could be broken. Just some of my personal sentiments toward the note type and its future direction. Not necessarily opposed to any of the prior suggestions in this thread; I just think they are on a different scope and perhaps need some separation of concern. |
Beta Was this translation helpful? Give feedback.
-
For tracking purposes and awareness, here are the docs for the evolving Task Notes in the Dendron Docs as this continues to be implemented |
Beta Was this translation helpful? Give feedback.
-
First I'd like to quote from a beloved tool nb which takes an interesting approach. Todos are a file, and tasks a markdown Another really nice aspect of nb is that it uses Second, I want to second what @ryan-p-randall said. One of the reasons I chose dendron is to be able to combine it with other VSCode extensions. Being able to manage our data (todos and others) with other tools is a huge win. Personally, my dream would be that many PKM systems interoperate on the same data structure, so switching is zero cost. Anyway... |
Beta Was this translation helpful? Give feedback.
-
What about tracking the
Advantages
|
Beta Was this translation helpful? Give feedback.
-
This is the discussion for RFC 13 - Todo Notes.
Beta Was this translation helpful? Give feedback.
All reactions