Closed markafitzgerald1 closed 10 months ago
P.S. Awesome tool, by the way - thanks for creating and maintaining it! ❤️
I did not know such behavior of wc -l
.
If it is a specification of a well-known command, I would consider adopting it.
So I experimented a little.
wc -l
= 0
a
wc -l
= 0
What? Really?
a
wc -l
= 1
a
wc -l
= 2
a
␣␣␣␣
wc -l
= 2
It seems to be more complicated than I thought. (Especially "1letter".) What should we think about it? Can you explain it with simple rules?
Incidentally, the current implementation is the same as the VSCode counting method.
Thanks for the response and great question about how wc
defines lines, @uctakeoff. I believe POSIX (Linux and other Unixes) specifies how Unix tools like wc
define lines of text - specifically Line and Incomplete Line.
In the screenshot you share, I guess that if you're in a file that ends in an Incomplete Line the incomplete line does have a line number, but does not count into the overall line count in POSIX and POSIX tools like wc
. Thus VS Code shows its line number, even though it is potentially an Incomplete Line.
I understood that a line that does not end in a newline is not considered a "line".
The feature was added in ver. 3.3.0.
However, the default behaviour is the same as before, so please set includeIncompleteLine
to false
in the configuration.
Oh, I mistakenly set the default setting to false. Oh well.
It would be helpful to be able to treat a trailing newline ('\n') character as the end of the line immediately preceding it, instead of treating it as a separate blank line at the end of the file as VS Code Counter currently does. Having VS Code Counter do this would match the POSIX interpretation of tools like
wc -l
. Could this possibly be added as an option, or as a change of core tool behaviour?As a bonus, adding this functionality would also allow output from VS Code Counter to align with that of the fairly popular cloc command line lines of code counting tool.