which is nonsensical from a timestamp perspective (Completed! actually happened at t=200).
The current approach does have a benefit: assuming the timestamps are non-decreasing, it is somewhat possible to derive the "duration" of a line (assuming each line is printed at the very start of a chunk of processing). In the example above, Commencing build... can be inferred to take Δt = 1; if Completed! has t=200, then Commencing build...'s inferred Δt = 200, when 199 of that was actually spent starting with package enumeration. But to do this effectively requires making that assumption.
I also tweaked the style of setLineMetadata, and implemented an optimisation for clear.
What timestamp should a rewritten line have?
I argue we should replace old line metadata with new metadata. This will make timestamps look more sensible in
ESC [1A ESC [K-heavy output.For example, when faced with updating the existing screen (pseudo-rendered):
with a sequence like
ESC [1A ESC [K ESC _bk;t=200 BEL Completed! LF, we currently getwhich is nonsensical from a timestamp perspective (
Completed!actually happened at t=200).The current approach does have a benefit: assuming the timestamps are non-decreasing, it is somewhat possible to derive the "duration" of a line (assuming each line is printed at the very start of a chunk of processing). In the example above,
Commencing build...can be inferred to take Δt = 1; ifCompleted!has t=200, thenCommencing build...'s inferred Δt = 200, when 199 of that was actually spent starting with package enumeration. But to do this effectively requires making that assumption.I also tweaked the style of
setLineMetadata, and implemented an optimisation forclear.