Repository navigation
Missing empty lines #49
Description
XML does not follow POSIX standard and an empty last line is not required. We could, however, consider whether having a sniffer fixer to ast least unify it (have an last empty line or not) would be helpful; since most files have the empty line it is likely better to make a FileHasEmptyLastLine* family.
Activity
jordikroon commentedon Aug 6, 2026
Yes, this makes sense. Both as sniffer and as fixer.
hakre commentedon Sep 5, 2026
Your example diff shows the symmetry betwenn A and B nicely (the diagnostic might be puzzeling, one of the artificial common UI issues on Microsoft Github - and it's not getting better in the Copilot era), so the sniffer/fixer would need to check if it needs unification after all, and in case the symmetry was broken betwenn A/B to restore the balance for that edit/change.
Which is semantically tricky: do we say unification in terms of content-tracking, or is it just an author that knows how to reformat an object quickly and only needs to know the rules of the game? If the later, a clever author configures this because every if not the next tool has it - git since ~25 years - and unifying the configuration of the docbook-cs utility with the standard utilities is certainly very helpful, but I noticed a small caveat, an interesting one though, that could easily get lost once past this point:
As you outlined we can't treat the XML text as-if it's with the POSIX stream editor; XML adheres to a content-type model (MIME) - but what intended the author? Is it just a preference in the editor configuration they last used to save the file? By accident or purposefully intended? Absolutely irrelevant in terms of application/xml as a tracked contents' type, right?
Which made me thinking that we may have different semantics/needs depending on whether the docbook-cs tool is used during authoring (editing text files) or in a content-pipeline (clean/smudge filter, CI build environment, etc.).
What do you two think about adding a parameter named 'worktree' (bool) to the configuration to better distinguish between the two during an invocation?
There is no need to rush this in, it's just the tool could then do both with the same sniff/fix: keep the balance of text diffs during content tracking or apply an editors preference during authoring. The "empty last line" example unveils this very interesting aspect of diff for me, especially as the standard unifcation for authoring and editorial work is already available (editor configuration, content tracker configuration, standard utilities etc.) which may allows us to unveil we've reached a point to make sniffs and fixers content-type aware and bring the model of the content repository onto the next level. Discussing the worktree parameter may help to figure that out, too.