[REQUEST] Add-on | filter +projects & @context to be automatically prepended (beginning of line).

[fohrums]

Since todo.txt is formatted as 1-line per task, I find it neater to view each task with +projects & @context automatically prepended (respectively) to the beginning of each task's line.

EXAMPLE

Let's just say I need to jot my ideas down before i can properly categorize them, so (that would look like):

Drop off mail @postoffice
Deposit check @bank
Read up on Chapter 4 +homework
Buy butter, milk, & eggs +bday @store

But if I wasn't worried about how I would like todo.txt to display my tasks, then my suggestion to automatically prepend +projects & @contexts (respectively, with projects stated first) to beginning of line would basically change the above example to make it look like so:

@postoffice Drop off mail
@bank Deposit check
+homework Read up on Chapter 4
+bday @store Buy butter, milk, & eggs

OTHER THOUGHTS

If tasks were added via Android-app, then calling out todo.sh would somehow automatically make the apprehension happen.... unless of course, the Android-App is capable of this add-on as well.

[chrysle]

Maybe an option could be added for that.

[inkarkat]

This can easily be done via a filter command (TODOTXT_FINAL_FILTER); someone should contribute that (similar to add-ons), and only if it becomes popular (unlikely given the lack of supportive comments here), it could be packaged with todo.txt-cli and a commented-out configuration added to the config file template.

[chrysle]

@inkarkat Thanks for the explanation!

BTW, do we have some developer's documentation about environment variables?

[chrysle]

BTW, do we have some developer's documentation about environment variables?

I mean for example TODOTXT_FINAL_FILTER and TODOTXT_VERBOSE.

[chrysle]

@inkarkat Sorry for annoying you ;-). But I think a list of all TODOTXT_* vars with usage would really make sense.

[inkarkat]

@chrysle The "official" ones are all listed and documented in the default todo.cfg (at the end, under BEHAVIOR). The script itself has additional (internal, and therefore undocumented and not guaranteed to be stable) variables that influence the behavior, but these are only required for very advanced use cases and complex add-ons.