Language-specific support framework #44
Description
I'm working on this topic. It's a complicated one, and I feel it's better to implement basic things for v0.1, and explore further possibilities later (inputs from our users will be important).
Before v0.1
- Customize filter and sorter expressions for language.
- See if the elisp sorter is faster than the readtags one. If it is, we'd encourage people to use post-sorter.
Edit: Sorting in Elisp is slower, and that's largely because of GC. I think it's better to wait for the need of multiple queries (see below) to emerge, than implement post-sorter.
Further possibilities
Customize required fields
For now, we just hard code required/optional fields that are useful to show. For the current UI it works good, but after we have user-controlled filtering, users & language support implementations would ask for extra fields to filter on. I don't have a clear idea on this.
Another usage is: readtags can only filter on language-common fields. Language-specific fields may not be shown to the user, but we need to filter on them. Then it also becomes necessary to add a post-filter that uses elisp function.
Case-insensitive languages
For now, how to filter based on the symbol name is handled by Citre, and the case sensitivity is controlled by an user option. For case-insensitive languages like Fortran, we must override this option.
Another problem is for auto-completion in such languages, the user would expect the result to keep the style of their input. For example, the user inputs fun, a tag named FUNCTION is used to complete it, then it's expected to become function.
A more complicated language is Nim. It's not case-insensitive, but style-insensitive! some_function and someFunction are the same. To support it, we must tell Citre: I'll decide how to filter on the symbol name, and I want to transform the tag name into the style of user input.
Multiple queries
e.g. use filter that depends on the result of former queries, for handling class inheritance. See universal-ctags/ctags#2475 (comment).
This may require post-sorter (sorting in Elisp), since we need to put the result of multiple runs in one list.