Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tokei could be better with .y files #767

Closed
ghost opened this issue May 17, 2021 · 2 comments
Closed

tokei could be better with .y files #767

ghost opened this issue May 17, 2021 · 2 comments

Comments

@ghost
Copy link

ghost commented May 17, 2021

Hello! The version of tokei I installed via cargo (12.1.1) is incorrectly identifying .y files (for the yacc / bison parser generators) as Happy source code. It looks like the correct way to approach a fix for this is to specify the comment types in the languages.json file.

I'm willing to make these changes, but I'm not sure where to find information about the Happy language. It's hard to search for given the name. Is it this Haskell parser generator? A brief, nonexhaustive glance at the documentation doesn't yield any information about comments in that language.

Conversely, we do know the kind of comments that Bison and Yacc use, so adding information there should be easy enough.

Do I understand this correctly? If so, I can get a PR up soon. I just want to be sure I understand correctly before filing a useless PR. :)

@brightly-salty
Copy link
Contributor

As far as I know, Happy (which is a parser generator written in Haskell, yes) would use the same comment syntax as Haskell. -- for single line and {-/-} for multi-line comments.

@XAMPPRocky
Copy link
Owner

XAMPPRocky commented Jun 17, 2021

Thank you for your issue! I'm going to close this as a duplicate of #67. In short, yes I would like to support this, but I want to provide the way to change at runtime, as I don't want tokei to flip what extension is counted as what between versions unless it's a bug, and while it might be unintuitive that the extension is not mapped onto a language you'd expect, I don't consider that a bug.

If you'd like to make a PR implementing #67 it is more than welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants