RFC: timedot changes
8 views
Skip to first unread message
Simon Michael
May 2, 2023, 11:42:44 PMMay 2
to hledger
G'day all. Any fellow timedot users out there ?
I'm fixing/improving timedot's description/comment/tag parsing. But before that..
which do you think is better:
1. generating little transactions for each line, as we do now:
2023-01-01
a ....
b ....
c ....
->
2023-01-01
(a) 1
2023-01-01
(b) 1
2023-01-01
(c) 1
Or 2. generating one big transaction per date line ?
2023-01-01
(a) 1
(b) 1
(c) 1
I don't remember why it's implemented as 1. Right now, 2 looks a little tidier ?
It would be a breaking change (print and register reports would change;
balance reports would not).
The above affects how timedot format can support descriptions and comments (and tags).
Variant 2 would simplify that design space a bit: date lines can end with a transaction
description and comment, time lines can end with a posting comment.
I'm fixing/improving timedot's description/comment/tag parsing. But before that..
which do you think is better:
1. generating little transactions for each line, as we do now:
2023-01-01
a ....
b ....
c ....
->
2023-01-01
(a) 1
2023-01-01
(b) 1
2023-01-01
(c) 1
Or 2. generating one big transaction per date line ?
2023-01-01
(a) 1
(b) 1
(c) 1
I don't remember why it's implemented as 1. Right now, 2 looks a little tidier ?
It would be a breaking change (print and register reports would change;
balance reports would not).
The above affects how timedot format can support descriptions and comments (and tags).
Variant 2 would simplify that design space a bit: date lines can end with a transaction
description and comment, time lines can end with a posting comment.
Simon Michael (sm)
May 3, 2023, 1:29:24 AMMay 3
to hledger
A change to 2 is looking good to me: https://github.com/simonmichael/hledger/pull/2030
Reply all
Reply to author
Forward
0 new messages