on the list command, it seems that the projects are sorted by update date (why not, it's not a bad idea)
But what I'm not sure to understand is the index, the index doesn't seem to be an ID linked to the project but rather a temporary display index. So the ID for a project will change from one execution to another. It means that in the future is there is a resume command, we won't be able to rely on the index. Since the name is not unique it can't be 100% reliable too, meaning the only unique key will be the location path, which is not handy. so I believe a unique and permanent index should be linked to a project instead. So it will become a identifier (absolute) rather than an index number (relative to the sorting).
on the
list
command, it seems that the projects are sorted by update date (why not, it's not a bad idea)But what I'm not sure to understand is the index, the index doesn't seem to be an ID linked to the project but rather a temporary display index. So the ID for a project will change from one execution to another. It means that in the future is there is a
resume
command, we won't be able to rely on the index. Since the name is not unique it can't be 100% reliable too, meaning the only unique key will be the location path, which is not handy. so I believe a unique and permanent index should be linked to a project instead. So it will become a identifier (absolute) rather than an index number (relative to the sorting).