main: normalise capitalisation of field descriptions

[dkearns]

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?

[masatake]

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.

[masatake]

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?

[dkearns]

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.

[masatake]

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.

[dkearns]

OK, I'll finish this.

[dkearns]

@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.

[dkearns]

Should these last two be removed? They don't appear to be used yet so are a bit confusing in the kinds output.

[masatake]

I'm very sorry to be late. Ideally V and B are used internally. I should remove them in the future. However, the knowledges about both OCaml language and OCaml parser are needed to remove.

[SiegeLord]

Yes, for Rust struct 'fields' is probably the right nomenclature. 'members' typically has OOP connotations. Otherwise, the Rust changes look fine to me.

[masatake]

@dkearns, can I merge the changes?