Ability to add/define notes section

[essenciary]

Besides just adding todos, I prefer to have the relevant info also in the context of the todo. As such, the todo can be seen as having a title/subject and a content/note.

It would be great if the content/note could be marked and not parsed and hidden from the list. It could be as simple as:

My todo subject +project @context 

---
Note goes here ...
---

Examples:

---

This should be rendered as title/subject: "Schedule Formula GT event" -- with the rest as the (hidden) note. Also, the note should not be parsed as now it's showing a +34 project which is Spain's phone country code.

---

This is a total mess - there are 2 links but only one is shown and when scrolling the todos list, the URLs here cause the UI to break.

---

If this could be an accepted feature, I'm happy to work on a PR.

[CPUGPU]

That would break compatibility with the todo.txt standard.

[ransome1]

Hi @essenciary . Thanks for reaching out. I would propose we close the FR and instead create a discussion, as there are no precise requirements yet.

@CPUGPU does have a point here, it would break compatibility.

But we also have to face the fact, there have been plenty of inquiries about a note function. If we agree on that this would not be activated by default, of course we can talk about it. We would need a discussion about the way this feature would work.

But first things first; @essenciary have you seen, that I am currently rewriting sleek completely (https://github.com/ransome1/sleek/discussions/501)? The code base in master branch is therefor abandoned. I am using the 2.x branch (https://github.com/ransome1/sleek/tree/2.x) to recreate sleek's current functionality but this time in a more sophisticated way. A clear separation of Electron's main process and renderer process, React for the components, MUI for the templates, tests for everything and so on (https://github.com/ransome1/sleek/blob/2.x/CONTRIBUTING.md).

The current implementation does not have the textarea feature. So that would need to be implemented first, before you could start on this. If you know your way around React, Typescript and Electron (or willing to figure this stuff out), you are more than invited to join us ❤️

[essenciary]

Thanks @CPUGPU @ransome1

Maybe I wasn't clear enough - it actually would not be a breaking change. This feature would be a superset of the todo.txt standard, and for all the other clients it would just render as Sleek does now. So this would be just a parser feature where a block of text would be parsed and rendered differently (better!).

TS experience yes, React and Electron very little but I could find my way starting with simple things.

I was not aware of the rewrite, thanks for the heads up :) So what is your recommendation regarding PRs? Wait until the rewrite is more stable?

[ransome1]

You can try out the latest developer preview from today: https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev5

It's pretty stable already and gives you a good overview on where the rewriting is at.

In theory you could already checkout the 2.x branch and scope out how you would implement it. But as I said, the textarea is not yet on my immediate backlog, so that would be something you might want to implement first.

There is a little bit of complexity to it, as we have an auto-suggest feature attached to the text field. Which of course would need to be attached to a textarea. In order to implement your feature, you would look at the TodoDialog and the AutoSuggest components.

Feel free to ask me anything.

[ransome1]

@essenciary Oh yeah and please don't be suprised; Only the main process is currently written in proper Typescript. The renderer React components are not yet.

[dlaidig]

I also think that the ability to add some multi-line notes to a task in sleek would be incredibly useful, as long as it doesn't break compatibility with existing apps.

Maybe I wasn't clear enough - it actually would not be a breaking change. This feature would be a superset of the todo.txt standard, and for all the other clients it would just render as Sleek does now. So this would be just a parser feature where a block of text would be parsed and rendered differently (better!).

How is this not a breaking change? To quote the specification:

The first and most important rule of todo.txt: A single line in your todo.txt text file represents a single task.

So in order to stay compatible with other apps, you'll have to make sure each task is stored in a single line. I see two options for that:

1. Escape newlines, e.g. with \n.
2. Use the key:value syntax for the note content. Custom keys are explicitly allowed in the specification but the contents of the value are quite restrictive: "Both key and value must consist of non-whitespace characters, which are not colons. Only one colon separates the key and value.". This means that newlines, whitespace, and colons would need to be escaped.

I clearly prefer option 1. It is not strictly following the standard todo.txt format, but in any other todo.txt apps the whole content will still show up. It will be a very long line but at least everything is readable and editable.

[rzw]

ENTER and SHIFT+ENTER in the editor are translated/converted to DLE (data link escape) in the file. This creates a new line in the editor pop up window while still being conform to the norm. This is more flexible as DLE is a control character (ALT+016 in Win) not used in texts

[github-actions[bot]]

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.

[dlaidig]

To keep this issue alive: I've recently played around with multiline editing in sleek 2.0. Encoding the newlines with DLE seems to not cause issues with SimpleTask and the todo.txt CLI, which is great. I also got excited about the possibility to put additional content in the task. However, in the task list, sleek renders the full item without line breaks (like shown in the screenshots for the first post), which really prevents this to work for me.

What I would find really useful and easier than the original proposal with the --- fences:

• Only the first line is the actual todo.txt entry, everything afterwards are additional notes.
• When there are notes, an icon/button is shown at the end of the item. Clicking this icon either expands the full contents (while preserving line breaks!) or opens a dialog with the full text.
• Todo.txt syntax is ignored in the note part.

What is the use case for the current behavior (displaying the full multiline content with stripped line breaks)? If there is a good reason for the current way, maybe the best solution is to add some settings (something like "show full content for multiline tasks", "only interpret todo.txt syntax in the first line").

[swantzter]

I've been trying to work on some ideas for how this could be done in this discussion thread https://github.com/ransome1/sleek/discussions/551 - But I disagree that todo.txt syntax should be ignroed after the first line, this would break support with other clients and limit possibilities to render things more neatly

[dlaidig]

I've been trying to work on some ideas for how this could be done in this discussion thread #551 - But I disagree that todo.txt syntax should be ignored after the first line, this would break support with other clients and limit possibilities to render things more neatly

True, it's a valid point that ignoring todo.txt syntax will break compatibility with other apps. I guess which behavior is more useful depends on the workflow. From what you write in #551, it seems like you aim to write complex todo.txt entries and spread the contexts/projects/recurrence/etc to multiple lines. In contrast, I would be really looking forward to having the ability to paste random notes/e-mails/messages below a task. For this, it would be really annoying if I had to check if the pasted text accidentally contains todo.txt syntax.

Unless we want to introduce a setting for it, it might really be good idea to include special marker (like ---, or just an empty line?) to separate multi-line todo.txt content and a plain-text note section.

[swantzter]

Perhaps the recently added markdown support in 2.0.9-rc could be used, stuff in ``` code blocks would already be escaped in markdown-land

[elijaheyes]

I can see that a lot of development and testing has already been done for this topic and for multi-line task support.

I'm going to share my idea anyway in case people find it useful.

Here is my idea:

add a new tag called "note:" that has these rules:

• note text is enclosed in quotes
• multiple note tags are allowed per task
• dropdown arrow on the right side of the tasks allows user to view/hide notes
• define a character to signify a newline (it seems DLE is already in use)
• tags inside note are ignored, these should be attached to the main task

Example:

todotxt file text: (A) 2024-02-21 task1 note:"lengthy description" note:"URL" note:"code block text"

Then the task would have a "v" arrow to view/hide the notes to render something like:

(A) 2024-02-21 task1 lengthy description URL code block text

Each note would be rendered as its own item instead of blending the text together as one giant task.

End of Example

I understand this idea is a little different than having support for multi-line tasks. It seems DLE has already been defined as the newline character. (What's the reason for choosing DLE? I'm not a big fan of having non-printing characters in the text file.)

Will the last rule, attempting to ignore tags inside notes, break compatibilty with the todotxt format?

[elijaheyes]

Please disregard the last comment I made.

The todotxt format states the key and value can't contain whitespace characters or colons. The proposed "note:" tag would deviate from this rule.

[ba66e77]

Could the approach taken by the notes add-on to todo.txt help bridge the gap?

[jcarstairs-scottlogic]

Could the approach taken by the notes add-on to todo.txt help bridge the gap?

To save the next person a bit of time: the approach there is to add a note key, which references a text file containing the note inside a dedicated directory. For example:

todo.txt
---------

Do shopping note:shopping-list.txt

notes/shopping-list.txt
-------------------------

- Brown bread
- Milk
- Butter