concept for calculation of a task's id

[nnako]

ttodo provides a feature to create an "id string" for any task listed within the current task file. When in NORMAL mode, such a task's id can be created by pressing <localleader>ti or issuing a :call ttodo#ftplugin#AddId( <count> ).

In order to evaluate the "stability" and "universalit" of a task's id, I would be interested in knowing how exactly such a task id is calculated internally. As there are many possibilities to grab aspects of real life in order to set such an id, which ones did you pick and how did you combine them to generate the id string?:

• did you use the position of the task line within the task file?
• did you use the absolute number of tasks within the task file?
• did you use the textual content of the task?
• did you use a MAC address of the network interface of the local computer?
• did you use part of a current global time stamp?
• did you use a representation of "where" the local computer is located on earth?
• did you use the current computer's user name?
• ...

combining a subset of these options (or completely other aspects) could ensure a good and stable task id which is not found anywhere else within that scope.

could you describe the implemented concept?

[tomtom]

The ID is calculated in s:EnsureIdAtLine() (in ftplugin.vim). If you use vim >= 8, the id is based on reltimestr(reltime()). The resulting number is then encoded as a string with base 62 using tlib#number#ConvertBase(). This procedure would fail if 2+ IDs were created in the same microsecond.

Before vim8, I used the task structure converted to a string and encoded with a homebrewn Adler 32 function.

One should keep in mind that the main goal of the ID is to reconstruct dependencies from the archive file (done.txt) for a given todo.txt file. As such it has to be unique only for a given todo.txt file (and its user). While it should be possible to define dependencies in todo.txt based on the ID, I have never actually used it this way. In todo.txt, I use indented tasks for that.

The ID should be unique at the time of creation. Once a task got an ID assigned to, the ID is not supposed to be changed. The ID is not meant to be unique across machines, users, todo files etc.

[tomtom]

And the ID should be as short as possible and consist only of alhpanumeric characters.

[nnako]

Hi @tomtom . Thanks for clarification. I use the todotxt format in an environment, where there are multiple people working simultaneously on different and even the same todo files, shared via a common file-based synchronization method like NextCloud. Potentially 1000 people working in collaboration within a shared project. This environment makes it rather possible to accidentally hit the same microsecond when creating a new task on one of the multiple task files. So, I personally like the former concept better, where you created an id in dependence of the task's textual content rather than a timestamp alone.

And the ID should be as short as possible and consist only of alhpanumeric characters.

That is a good requirement for short, human-readable text lines. And it is rather pleasing to the eye ;-) .

The ID should be unique at the time of creation. Once a task got an ID assigned to, the ID is not supposed to be changed.

That should be common practice for any task management system. Even if tasks are completed and transferred to the done file, their ID shouldn't be reusable within the same project.

The ID is not meant to be unique across machines, users, todo files etc.

In my environment, the ID sould rather be exactly that. unique as far as possible.

How come, you changed the concept for id calculation for vim >= 8? Were you forced by some technical issues? Or does the new id calculation concept promise a smaller probability for collisions? Would it be possible to maybe offer both concepts (selectable via a configuration parameter)? Or maybe combine them for even lesser collision probability?

[tomtom]

The change wasn't forced. It was a matter of taste. You can now choose how IDs are generated and append a (possibly user-specific) suffix.