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

Add file extension-based plugin recommendation system #1382

Open
mechatroner opened this issue Oct 2, 2018 · 2 comments
Open

Add file extension-based plugin recommendation system #1382

mechatroner opened this issue Oct 2, 2018 · 2 comments

Comments

@mechatroner
Copy link

VSCode does this and I think this feature is convenient for users and helps to discover new plugins.
E.g. when someone edits .cpp file, Sublime Text can show a list of recommended C++ - related extensions.
When .py file is being edited - python related extensions are shown, etc.
Here is how VSCode suggestion box looks like:
vscode_suggest_box
Plugins in the list can be sorted according to the download count or some other criteria.

@FichteFoll
Copy link
Collaborator

FYI, there is currently no system in place for packages do denote their target programming language (or file extension) and it would be quite the effort to add this retrospectively for 3k packages. It could be automated for a couple of them (Syntax definition, programming language in package name), but that's about it.

Just to give you some perspective.

@mechatroner
Copy link
Author

mechatroner commented Oct 3, 2018

I can try to implement a script that would do automatic assignment when I have more time.
And to be clear, this system would never be "fair" because:

  1. Some packages won't get any language assigned since they are language-agnostic e.g. "Sidebar Enhancements", theme packages, etc. So they would be never recommended (at least not with language-based recommendation system)
  2. Some languages are more niche than others, e.g. Coconut-related packages would have much smaller chance to be recommended than C++ - related since *.coco files are just more rare.

Also thinking about this now, I am starting to understand that using just file extensions may not be good enough, since conflicts are possible e.g. *.pl can be used both for perl and prolog. So maybe a better option would be file extension + some file content-based model. I can think of "Bag of Words": https://en.wikipedia.org/wiki/Bag-of-words_model - It is very simple, easy to implement and reliable.

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