priority of task in done.txt is removed after `complete`

[vt128]

Do you want to request a feature or report a bug? bug

What is the current behavior?

before in todo.txt:

(B) +todolib @dev add test

after do in done.txt:

x 2020-11-21 +todolib @dev add test

the priority of task is not kept.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

todo add "blah blah"
todo p 1 b
todo do 1

What is the expected behavior?

in done.txt

x 2020-11-21 (B) +todolib @dev add test

Which versions todo.sh are you using?

Run todo.sh -V

TODO.TXT Command Line Interface v2.12.0

Which Operating System are you using?

macOS 10.15.7 (19H2)

Which version of bash are you using?

Run bash --version

❯ zsh --version
zsh 5.7.1 (x86_64-apple-darwin19.0)

[inkarkat]

No, this is not a bug, but a deliberate decision to remove the priority once a task is done. Priorities are done to establish an ordering of when tasks should be done; once a task is done, a task drops out of that.

The spec has this to say:

Many Todo.txt clients discard priority on task completion. To preserve it, use the key:value format described below (e.g. pri:A)

[inkarkat]

❯ zsh --version zsh 5.7.1 (x86_64-apple-darwin19.0)

Even if you use zsh as your shell, todo.sh will be executed by Bash, due to its shebang line (#!/usr/bin/env bash). That's why the template is asking about the Bash version. (None of this matters for this kind of feature bug report, though.)

[vt128]

Sorry for my ignorance!

It's:

❯ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc.

Btw, I noticed that @bug and @BUG are treated as different context, whereas +todo and +TODO are treated as different project. There's no normalization for context and project. Is this also a deliberate decision?

[inkarkat]

I noticed that @bug and @BUG are treated as different context, whereas +todo and +TODO are treated as different project. There's no normalization for context and project. Is this also a deliberate decision?

The list action is case-insensitive for convenience, but for grouping into projects and contexts, case matters. I guess this is influenced by the underlying Unix philosophy, but I wasn't there when this decision was made.

[vt128]

Ok, thanks!