You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For easier management of time entries, it would be better to employ special syntax, that would refer to time entry not with ID or its description, but by the order they are presented in the listing.
The listing would have numbered lines:
Description Duration Start Stop
1. Some entry 0:04:09 9:07:32 AM 01/21/2019 running
2. Some entry 0:00:11 8:54:57 AM 8:55:08 AM 01/21/2019
3. Some entry 0:02:00 8:54:08 AM 8:56:08 AM 01/21/2019
Then it would be possible to reference the issues like: toggl continue $2, toggl rm $3.
Potential problems:
If there is a change in the state from another source (Toggl's web client, other tool using it API calls) the referenced lines may differ and hence you can modify (or worse - delete) lines that you have not intended.
One solution to this problem, could be to store the state of the last command locally and when a call with this syntax, the ID of the referenced line would have to be retrieved from the previously stored state. This could go hand in hand with #86. But even then it could resolve in problems.
Let me know what you think and if you would be interested in such a feature!
The text was updated successfully, but these errors were encountered:
For easier management of time entries, it would be better to employ special syntax, that would refer to time entry not with ID or its description, but by the order they are presented in the listing.
The listing would have numbered lines:
Then it would be possible to reference the issues like:
toggl continue $2
,toggl rm $3
.Potential problems:
If there is a change in the state from another source (Toggl's web client, other tool using it API calls) the referenced lines may differ and hence you can modify (or worse - delete) lines that you have not intended.
One solution to this problem, could be to store the state of the last command locally and when a call with this syntax, the ID of the referenced line would have to be retrieved from the previously stored state. This could go hand in hand with #86. But even then it could resolve in problems.
Let me know what you think and if you would be interested in such a feature!
The text was updated successfully, but these errors were encountered: