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

Support common IDE features #53

Open
8 tasks
testing-in-chrome opened this issue Jul 26, 2018 · 4 comments
Open
8 tasks

Support common IDE features #53

testing-in-chrome opened this issue Jul 26, 2018 · 4 comments

Comments

@testing-in-chrome
Copy link

I think you're doing a great job, and your extension has the potential of being the standard for dlang, even better than code-d/serve-d. It's great that you release often and keep things up-to-date, and it just works without issues (at least for me).

Now it's time to add some IDE features that we desperately need. Please feel free to use this issue as a meta-issue for other IDE features sub-issues.

  • When doing code completion of functions, on accept, insert it as a snippet pre-populated with parameters signatures that user can tab to each and fill with appropriate arguments.
  • Find all references. This should work for user-defined types, local/global variables, fields, parameters, ... etc.
  • Call hierarchy. Invoking this on a function should give a tree of all the callers of that function.
  • Type hierarchy. It should be possible to invoke this on:
    • A function: to get a tree of all functions from base classes that this function is overriding, and all functions from derived classes that override this function.
    • A class or an interface: to get a tree of all derived and base classes (in case of a class) and all classes that implement the interface.
  • Semantic highlighting: User can configure which color/bold/italic for D symbols based on their types (e.g. class, interface, static function, static variable, member function, member variable, local variable, parameter, alias, string, character, module, keyword, template parameter, enum type, enum item, ... etc).
  • Some refactoring features:
    • Find and replace all occurrences of a particular symbol.
    • Suggest when cursor is on a struct or class field to auto implement a getter or setter property.

Please add more if you remember anything else.

To help you get started, all the above features have been implemented successfully for a very popular C++ vscode extension called cquery cquery-server / cquery-extension. Please take a look.

@LaurentTreguier
Copy link
Collaborator

I don't know what you mean by "you release often and keep things up-to-date" since the last official release was in 2016, and the last commit a year ago 😅
As I posted on another issue, I have been concentrating my work on trying to build a language server, just like cquery, since language servers can be re-used in different editors; with minimal editor extensions.

Regarding the features themselves:

  • snippets should be doable
  • finding all references might be better suited to be directly a DCD functionality, which can already find the usage of a symbol within a single module
  • I don't know how a call hierarchy would be implemented, this will need a lot more thinking
  • same for type hierarchy
  • semantic highlighting is being discussed and worked on, and will be a part of the Language Server Protocol at some point, maybe in version 4.0
  • once the "find all references" is implemented, it should be easy enough to ass a find and replace/rename function

However, as I stated earlier, I don't think I'll be working on this extension anymore, but rather the language server. For example, someone here has an issue with VSCode which prevents them from using it, meaning all of the effort put on this single editor extension is basically useless for that person.

@testing-in-chrome
Copy link
Author

I don't know what you mean by "you release often and keep things up-to-date" since the last official release was in 2016, and the last commit a year ago

I was talking about your DLS server. Ok, maybe I should have created this issue there.

  • finding all references might be better suited to be directly a DCD functionality, which can already find the usage of a symbol within a single module

I don't know how DCD works. I believe cquery uses libclang to build a full index db of the project which it then uses for all sorts of things. I suppose you can do something similar? (I know it's a lot of work, sorry! :()

See this

  • I don't know how a call hierarchy would be implemented, this will need a lot more thinking
  • same for type hierarchy

Similarly, please look at call hierarchy, inheritance hierarchy, and member hierarchy in cquery.

However, as I stated earlier, I don't think I'll be working on this extension anymore, but rather the language server. For example, someone here has an issue with VSCode which prevents them from using it, meaning all of the effort put on this single editor extension is basically useless for that person.

We can't deny that vscode is very popular and is getting better and better constantly really quickly. So developing a really good dlang extension on it is not a wasted effort and will be greatly appreciated by many people, especially that all the current available extensions for vscode and otherwise are all below one's expectations.

@LaurentTreguier
Copy link
Collaborator

I was talking about your DLS server. Ok, maybe I should have created this issue there.

Oh, that makes more sense indeed

(I know it's a lot of work, sorry! :()

No need to be sorry :)
DCD uses symbol cache as well, containing information about everything needed for autocompletion, etc. I haven't done any work in DCD myself yet, but I'll probably start getting my hands dirty soon enough.

So developing a really good dlang extension on it is not a wasted effort and will be greatly appreciated by many people

This is why I made an extension for VSCode using DLS, I didn't mean that I was leaving VSCode behind or anything (in fact it's still my go-to editor). The difference is simply that the work on DLS can benefit other editors, as well as VSCode.

@testing-in-chrome
Copy link
Author

I just saw that you implemented some of the stuff here in version 0.11.0. That's awesome! Thank you very much.

I wonder if we should move this thread somewhere else where it can be more visible.

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