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

Language-specific support framework #44

Open
2 tasks done
AmaiKinono opened this issue Jan 16, 2021 · 1 comment
Open
2 tasks done

Language-specific support framework #44

AmaiKinono opened this issue Jan 16, 2021 · 1 comment
Milestone

Comments

@AmaiKinono
Copy link
Member

AmaiKinono commented Jan 16, 2021

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.

@AmaiKinono AmaiKinono added this to the Future plan milestone Jan 22, 2021
@semenInRussia
Copy link

Can I already try it, for example, with python?

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