GothenburgBitFactory
Make showing the task id in reverse order possible
Description
With the current behaviour, tasks ID go from 1 (oldest task) to X (being the number of pending tasks if the GC is enabled). This change adds a new boolean configuration option reverse_id to make the ID go from X (oldest task) to 1 (newest task). It should only affect the place where we load the tasks and where we add them, no behavioural change elsewhere.
Additional information...
- [X] Have you run the test suite?
Many changes need to be tested. Please run the test suite
and include the output of
cd test && ./problems.
I also added a test case for this change, and slightly updated the documentation for running bash tests (it wasn't fully clear to me that the script had to be sourced)
taskwarrior/Build/test $ ./problems
Failed:
Unexpected successes:
Skipped:
Expected failures:
lexer.t 4
For the context, I have around ~100 tasks laying around. The tasks I work on usually have ids ranging from 90 to 115, because the rest is just in my backlog for a time where I'll have enough availability to get to them.
This means that for every annotation/modify/etc I do, I need to type one or more 3-digits tasks, while my 1-digits tasks are never acted on. That has been annoying me for a couple of months and since I don't care much for the ID staying constant, this behaviour works much better for me.
Sounds good regarding the coding change, I will have a look tomorrow when I get back to my computer.
I just want to be sure about something regarding the code change. Mapping the (increasing) id to their reversed counterparts could easily be done with something like
int TDB2::reverse_id(const int id) const
{
return _id - id;
}
Was that what you had in mind? Going with this change would mean that every place that prints a Task's id would have to be modified to check for the reverse_id option though. If that is what you/we want, wouldn't it make more sense to replace those places with a new Task::print_id function?
Also: If we need to check the configuration every time we print an id, could this cause performance issues? (I'm not really all that familiar with the code, so kind of a naive question here)
The reason I suggested separating the two is that, with this change, "id" is going to be ambiguous -- and in the majority of tests and use cases, they will be identical, so it will be very easy to introduce bugs where the wrong id is used. You're right that the translation is easy, but it should be explicit -- at least in variable/function names. Probably the best way to handle this (and my Rust background is showing here!) would be to use separate types for the two. Maybe the storage ID could be a new type wrapping an int, and the display type could remain just a plain int? Then the compiler will enforce the appropriate conversions.
As for checking configuration -- if it is a problem we could easily cache that configuration in a private property of the TDB2 class.
Hi @Nelyah, I looked at the code, and while the changes look relatively self-contained I am afraid adding the option to reverse the IDs would bring non-negligible amount of work in terms of maintenance overhead.
In particular, one of the core principles of TW is that the IDs stay immutable within the duration of one modification window. In otherwords, the user can run the following set of commands:
task <report something>
task <add a task>
task <modify a task>
task <delete a task>
task <add another task>
and re-use the same IDs from the report generated in the first command in the sequence of the modification commands. The proposed behaviour of reversing IDs would mean that every addition shifts the list of IDs, which would be a major workflow assumption change.
We'd also have to make sure this is sufficiently well-covered in connection with other task functionalities that might implicitly rely on the current ID numbering system, which might enlarge the size of the test-suite.
Perhaps as an alternative to merging to mainline, maintaining this patch on top of the stable release could work for you? I can definitely see why this is useful, especially if the task lists are large, but I'm not sure I can justify the cost/benefit ratio.
Hi @tbabej, and I first and foremost apologise for not giving any news.
What you suggest sound good, I can definitely live with a patch for my own use case! I'll close this MR now.
one of the core principles of TW is that the IDs stay immutable within the duration of one modification window
Oh! I had always assumed that the IDs not being modified unless I generated a new report (task next) was a bug. Turns out, "It's not a bug, it's a feature!" Good to know, thanks for that!
Hope you're having a rad day!