todo.sh add -f FILE "..."

[kwryankrattiger]

Feature

What is the current behavior?

Currently can add files and such, but there isn't an easy way to add things to a specific file. The current workflow, that I can tell, is to add a todo and then move it to another file which.

Which versions todo.sh are you using? v2.12.0

Which Operating System are you using? Ubuntu 20.04 LTS

Which version of bash are you using? zsh 5.8

[inkarkat]

The "theory" behind todo.txt advocates a single file that contains all open tasks. The todo.txt-cli application is not completely strict about this, and tries to accommodate other workflows (like having local todo files) — to a degree. I'm against making it too easy to choose a different file, because then users might inadvertently pick up a bad workflow (and blame the app if it doesn't work well for them). In other words, the application should not prevent you from going against the built-in assumptions, but it should require some effort, so that you critically question your intentions.

todo.sh add -f FILE can already be done as TODO_FILE=/path/to/file todo.sh add if you replace

export TODO_FILE="$TODO_DIR/todo.txt"

in the default configuration with a conditional initialization:

: ${TODO_FILE:="$TODO_DIR/todo.txt"}; export TODO_FILE

You can make this more convenient to call via a shell alias or wrapper script. You did not describe your motivation for using a separate file, so it's hard for me to give any further hints. I hope that this will cover your use case — if not, please speak up. One nice thing about this solution is that it will work with any action (also custom ones), not just for todo.sh add.

If your use case requires more changes than just the different file name, as an alternative to the above you could also define a complete second config file, and then define aliases for todo.sh -d /path/to/config_file, instead of overriding just the TODO_FILE variable.

[rjk9w5]

I have two use cases for this.

1. The first is to directly add tasks that are done to the done pile. This is probably to most inline with the todo.txt CLI workflow, it creates a record that a task was done and I can go back and check that later.

todo.sh add -f done.txt "Give context to my todo.txt CLI request @opensource +todo"

2. I find it very convenient to have a notes.txt next to my todo.txt. I label notes under contexts and projects to keep organized.

todo.sh add -f notes.txt "CLI add to file: https://github.com/todotxt/todo.txt-cli/issues/370 @opensource +todo"

This is more functionality available in the CLI vs changing anything about todo.txt, so I don't know why it would be an issue. The CLI already supports multiple adjacent files to the todo.txt, so this is more of an extension to that existing feature rather than something entirely new.

It is fine if you don't think this would be useful to others, I am happy to just implement my own actions for these. But I thought I would share the idea because I am probably not the only person who would find it useful.

[inkarkat]

Thanks for sharing your use cases, @rjk9w5!

add tasks that are done to the done pile

Retroactively adding a task and immediately marking it as done indeed is a common use case. I would not implement it by redirecting the add action's target to done.txt though. In fact, I've implemented a custom adddo action that simply delegates to the built-in add and do actions. This has two benefits:

• it hides the implementation detail that done tasks are stored in a different file, and instead interfaces with the user though the well-known add and do actions
• by actually running these actions, any customizations will run as well (for example, I use custom syntax that specifies a recurring action, and that hooks into the do action; I can use adddo to create and schedule the next instance of the task, too)

---

a notes.txt next to my todo.txt

I would solve this via a second configuration file, and alias notes='todo.sh -d notes.cfg' to invoke it. todo.sh add -f notes.txt is tedious to type, so I think you would want a wrapper, anyway, and with that, how the actual file redirection is implemented doesn't matter any longer.

Also, a separate configuration allows for things like defining a different DONE_FILE, too, so you can cross off notes via notes do 42 without mixing them with done tasks in a single done.txt. The suggested -f enhancement would have to be applied to the do action as well (and likely many other built-in actions, too), whereas the separate configuration automatically covers everything, without any change to the application's code.

---

The CLI already supports multiple adjacent files to the todo.txt

That's not true. The application works with a fixed set of files (active tasks, done tasks, and reports). The move action is supposed to be used for transfers across those three (well, the report file is not about tasks, so it barely counts), but the implementation allows arbitrary destination files within the todo directory.

I hope you'll agree that custom actions and/or a second configuration offer more flexibility than the proposed -f FILE, and these don't require any extension to the core application at all.