Possibility of adding support for length estimate?

[FakeNameSE]

Hi, I think an identifier for the length of a task (marked in the text file by a special character like #) would be a pretty nifty feature to have. The technique works with plain searching (in the cli at least) and enables workflows like knocking out the smallest high priority task if the user only has a couple of minutes or dedicating a day to the tough stuff. I understand that this can be more or less accomplished with the preexisting features, but I have a feeling that combined with the fancy GUI (color code the difficulty maybe), this would be rather practical.

[sanpii]

It’s a good idea 😃

I won’t use # (or other special character) to prevent a second parsing of tasks. I prefer using keywords (d for duration or e for estimated time ?).

For displaying, I don’t think color code is a good idea. There is already two color codes (for priority and for the circle), I don’t think a time period is usually mapped with colors and it’s uncorrelated to difficulty.

I imagine a small progress bar at the bottom (or top) of the task with a logarithmic scale (8*log(t)):

• 1m : 15%
• 1h: 30%
• 1d: 45%
• 1w: 60%
• 1m: 75%
• 1y: 90%

Or a clock (mixed with the circle) on the same principle.

[FakeNameSE]

Thank you! I agree that it makes a lot more sense to use keywords instead of a special character, although I have not used keywords enough to know how it would work with filtering and sorting. Maybe something like et (estimated time) for the keyword is a good option (d resembles due a little too much for me). Concerning display, a clock appeals to me more than the progress bar (the progress bar makes me think that the completion of the task is already underway while the clock is reminiscent to me at least of a cook book with time estimates).

[geek-merlin]

I'd really love this! Just a note: Adding a keyword of "t" does not work via UI (in the sense it is not added).

"et" for estimated time is my favorite too. I'd use "st" for spent-time then (which for me fits nice with gitlab's /spent syntax).