more numbers of improved language support

[emsi]

more numbers of improved language support

[masatake]

@b4n, thank you. Your words are much more than I wanted to write.

Being phony is o.k as far as we can keep ctags alive.

[k-takata]

You can find the list in news of the document:
https://github.com/universal-ctags/ctags/tree/master/docs/news

[emsi]

I can find it with ctags --list-languages but that's not the point.
The claim in the readme without a link to the source is just phony.

[masatake]

I'm negative about listing the languages because the parsers for them have great variation in quality.

We wrote There is great variation in quality between products. on our README.md to show that we appreciate the parsers' authors and contributors.

Such a list can increase the number of systems where ctags is installed. However, it is not our goal. Of course, I have to thank you for your interest.

[masatake]

Such a list may increase the number of "issues" supporting new languages.

[emsi]

Such a list may increase the number of "issues" supporting new languages.

So you suggest that those parsers are essentially worthless and god forbid anyone tries them?
That strengthens the case that the readme statement is just a phony claim.

[masatake]

So you suggest that those parsers are essentially worthless

Some of them are far from satisfied, at least for me.
I have been wanting to improve them.

god forbid anyone tries them?

Maybe I didn't understand what you wrote well, or my original sentences were broken.

Anyone can try them, whether god forbid or not.
Some of them may be satisfied with it.
Some of them may not.

That strengthens the case that the readme statement is just a phony claim.

Yes. Listing the language can be more phony.

I do also not want to answer the following question precisely; how many languages does ctags support?

[emsi]

If you don't want to provide the list of supported languages you cannot claim that you support more than some other solution. By your own judgement most of them are not perfect or far from satisfied. If that's the case I'd argue that the claim without supporting evidence be then simply removed from the documentation or changed to something vague like: "multiple improved language support".

[masatake]

If you don't want to provide the list of supported languages you cannot claim that you support more than some other solution.

Other solution? Are you talking about Exurbrant Ctags?
Other than Exurbrant Ctags, I don't want to write about comparison.

By your own judgement most of them are not perfect or far from satisfied. If that's the case I'd argue that the claim without supporting evidence be then simply removed from the documentation or changed to something vague like: "multiple improved language support".

You are accurate. However, I will not change the area of the document.
The accuracy doesn't contribute the objective of the project.

[b4n]

@emsi I don't really see your point (apart than the sentence is probably not correct English): would you want a "source" if it was worded "many new and improved parsers over Exuberant-CTags"? The "source" of this claim is the code and the resulting binary, basically make a diff between the two and decide for yourself.
There is no canonical single source of truth on the matter anybody could link to -- apart maybe for sheer number of parsers one could build a list. Or then again, it's all those files around the README.

And I understand @masatake's point as that it's entirely unrealistic and impractical to list all differences: not only it'd be a fairly hard and cumbersome job to actually find all the differences, but it'd also probably have to be updated constantly to stay accurate, and then it's a nightmare.

Regarding parser quality, it's always been like that in the *ctags world: some parsers are outstanding, some are only useful for a very specific usage, many have quirks. It all boils down to contributor time, knowledge and skills, and language characteristics. For example, the C and C++ parsers have been greatly improved (IMO), but it probably won't ever be perfect because C (and even more so C++) are literally impossible to parse properly without complete setup knowledge (including, but not limited to, includes, system details, and even the compiler in some cases -- basically blame the preprocessor and compiler extensions), so do still yield good results for most situations is an incredibly tricky task. An easier language is Python (which is pretty well covered), but it suffers from the other big issues *ctags will have with many language: dynamic features (which basically require actually running the code -- yes, some can be statically inferred, but not everything).
So parser quality will likely never be "perfect", and so is just as good as to whether it serves your purpose. An some parsers were just written to extract a TOC, or just the functions written in a fairly common manner (e.g. all line-based parsers for non-line-based languages).

Anyway, in practice, this should just be read as a means of suggesting passer-by that we believe uctags is more capable than ectags, so if they care they could give uctags a spin. And in reality, I'm pretty sure uctags doesn't have anything to prove anymore, and is possibly even seen as "the current ctags" by many/most -- I'm not dissing ectags to which we owe a whole lot and I sporadically contributed to, but it hasn't seen updates since 2014, which is pretty much the reason why uctags exists in the first place.

[emsi]

Closing as "completed" is just pathetic. Don't you have the courage to close as 'won't fix'?

[masatake]

Closing as "completed" is just pathetic. Don't you have the courage to close as 'won't fix'?

Wow, I didn't know the other choice in the GitHub Web UI.

[masatake]

I have tried recording the interface level changes since 6.0.0 as man pages.

As explained by @b4n, "supporting language" doesn't make sense in ctags.
However, what kind of "kinds" ctags trying to extract may have some sense for people developing client tools.

When we add a new parser, we must add a man page for it. I must review what parsers we have added since 6.0.0.