Flow
Parts of an honest edit counter
1A named unit
Line breaks added and removed, or lines touched between saves. Not both mixed.
2A small counting function
Takes one change, returns two numbers, knows nothing about the editor.
3A table of plain edits
One letter, backspace, Enter, word swap, whole-line delete, then a paste.
4Counts in the value
Labels stay a short fixed list, like language.
5A running total
A counter that reaches the backend, so span sums have something to match.
Type one letter and my editor telemetry says you added a line. Hit backspace and it says you removed one.
That's the line counter in a small editor extension I keep for tracking edits. Each time the document changes, it records a trace span with two numbers on it: lines added and lines removed. One commit rewrote that part and called it an improvement. It made the numbers wrong in a way that still looks right.
What it used to count
The old version counted line breaks. Lines added was the number of new line breaks you inserted. Lines removed was how many line breaks you deleted. A letter counted as zero. Enter counted as one. Add those up over a day and you get the real change in the file's length.
What it counts now
The new version adds one extra line to any edit that inserts text, and one extra to any edit that deletes text. My guess is someone wanted to count lines touched, since typing inside a line does touch it. But the editor sends a change for about every keystroke, so the extra one lands on every key you press.
added = text.count("\n") + (1 if text else 0)
Done by hand from that rule:
- One letter: one line added.
- Backspace: one line removed.
- Enter: two lines added.
- Deleting a whole line: two removed.
None of those numbers look odd on a chart. That's the problem. Worse, the total now depends on how text got there. A word typed one letter at a time counts as ten lines. The same word pasted counts as one. So anyone who types by hand looks far busier than someone who pastes or accepts a big suggestion.
The check that went missing
The same commit deleted both counters in the extension, including the one counting editor changes. That counter was the only total you could hold up against the span numbers to spot a drift. The export path for counters is still there, but in the code I read nothing feeds it now. There were no tests either. A short table of plain edits, like one letter, one backspace, one Enter and one word swap, would have failed every row, as long as it checked lines added and removed separately.
A better counter keeps two plain counts per change, breaks added and breaks removed, with no bonus. If you want lines touched, compare the file between saves instead. And keep the counts out of the labels, which is what the old deleted counter did, or the backend makes a new series for every pair of numbers.
The commit also added spans for saves, focus changes and terminal changes, and turned the ping span into a generic command span. Those are fine as simple event records. The edit, save and focus spans each send the full file path, though, and that should be a choice someone made on purpose.