Now that Balpan v0.3 will support C/C++, So, reading .h supposes that it is written in C/C++ syntax.
But, many of iOS/macOS native apps are written in Objective-C/Swift. AND IT ALSO USES .h file within its repository.
In this context, we should not suppose that parsing .h file always requires treesitter-cpp.
How do we approach this problem?
To handle this problem, We have to choose which parser is appropriate for each runtime.
One of possible approach is statistics. Counting all of files that are written by language balpan support, and the behaviour on .h file could be decided by majority.
For example, most of files are written in C/C++ syntax, we can assume that .h file have to be parsed using treesitter-cpp.
If most of files are written in Swift syntax, we can also assume that .h file have to be parsed using treesitter-swift.
Also, we need to investigate which programming language uses .h extension
🐛 Describe the bug
Now that Balpan v0.3 will support C/C++, So, reading
.hsupposes that it is written in C/C++ syntax.But, many of iOS/macOS native apps are written in Objective-C/Swift. AND IT ALSO USES
.hfile within its repository.In this context, we should not suppose that parsing
.hfile always requires treesitter-cpp.How do we approach this problem?
To handle this problem, We have to choose which parser is appropriate for each runtime.
One of possible approach is statistics. Counting all of files that are written by language
balpansupport, and the behaviour on.hfile could be decided by majority.For example, most of files are written in C/C++ syntax, we can assume that
.hfile have to be parsed using treesitter-cpp.If most of files are written in Swift syntax, we can also assume that
.hfile have to be parsed using treesitter-swift.Also, we need to investigate which programming language uses
.hextensionOther details or context
See https://github.com/ReactiveX/RxSwift/blob/main/RxCocoa/Runtime/include/_RXDelegateProxy.h