ctags
ctags copied to clipboard
universal-ctags
main: normalise capitalisation of field descriptions
This just caught my eye. Capitalised descriptions outnumbered those that weren't so I went with that.
I'm not sure if the commit prefix needs to be more elaborate than "main:" and reference the touched parsers?
main: is enough. One of the purpose adding common prefix is for making the category maintainers' attentions. main: hooks me, @masatake. I strongly believe docs: prefix hooks you:-)
Assignees of github can be used for the same purpose. If one thinks getting an agreement of the category maintainer is requisite, use Assignees. If it is optoinal, use the common prefix.
I took these field descriptions from the man page. They are capitalized. In this aspect we should make all --list-fields output be capitalized.
In other hand, --list-kinds (and --list-kinds-full) output use lower case. (Basically these output comes from Exuberant-ctags.)
--list-pseudo-tags, which I added, uses lower case. --list-extra output is capitalized. This one comes from man page.
We should apply a unified rule to the output. What we should do?
Flip a coin? :)
I don't think it really matters and the command output doesn't have to be the the same as the man page which can include more elaborate descriptions.
Since the command output descriptions are more often than not fragments rather than proper sentences how about we go with lower-case for all command output? It looks a bit nicer to me.
We can probably drop "Include" from the start of the descriptions in --list-extra output and "the" from --list-pseudo-tags as well.
I agree with you that lower-case is better.
We can probably drop "Include" from the start of the descriptions in --list-extra output and "the" from --list-pseudo-tags as well.
Can I ask you to fix these things?
If a --list- option supports --machinable, we can write a test case which verifies the description column of the option output starts lower case. With the test case we can enforuce using lower-case as the start of description to contributors and ourselves.
@SiegeLord Could you please check the changes to Rust's kind descriptions make sense and that I haven't introduced any subtle errors? From the Rust docs I guess "struct fields" is more appropriate than "struct members"?
@Twinside, likewise, could you do the same for the OCaml and Objective-C changes?
Thanks.
Yes, for Rust struct 'fields' is probably the right nomenclature. 'members' typically has OOP connotations. Otherwise, the Rust changes look fine to me.
