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

Autocomplete improvements #75

Open
dicene opened this issue May 7, 2018 · 4 comments
Open

Autocomplete improvements #75

dicene opened this issue May 7, 2018 · 4 comments

Comments

@dicene
Copy link
Contributor

dicene commented May 7, 2018

@gamecreature Was curious about a couple things I wanted to run by you. I'm working on integrating the Autocomplete feature into Mudlet/Mudlet and have been modifying some parts of that system. Fairly certain that all the changes are relatively universally acceptable, but I wanted your input on this.

  • I've modified the way findAutoCompleteItemsForRange() works to have it return a value indicating how good of a match it is. It's currently very simple, one value for a case-insensitive label_.contains match, a better value for a case-insensitive label_.startsWith match.

  • Modified fillAutoCompleteList() to use a QMultiMap instead of a QList, so that it sorts by the value returned from matchLabelScore()(with lower values being higher priority on the list).

  • I've added another property to the TextAutoCompleteItem class so that it can additionally hold the usage of a function(and I'm hoping to add another field explaining the effects of the function). I'm working on modifying fillAutoCompleteList() to use QWidgets instead of QListWidgetItem, so that I can have multiple things displayed in each entry, including an icon and differently formatted text. Here's an example of what I'm aiming for(from the Eclipse IDE):
    image

  • In the future, I'm hoping to build in a way for the completer to pull declarations from the document you're editing so that you can see variables(and their members) from your code added to the autocomplete list. Since this seems like a far more code-intensive task than the other changes, this idea is sort of in the air for now.

Any feedback for how those ideas could be implemented in a way that is generally applicable, and not just for Mudlet would be appreciated. When I finish getting the rest of the first 3 of those ideas fleshed out in code, I'll add a link for the branch I push them into.

@gamecreature
Copy link
Member

Thanks for your reaction! Apologies for my late response..
I was working on an AutoComplete list based on document variables. (The implementation I've made was very basic, and just build as a proof of concept). I will push this is in a temporary branch.

It's ok to add extra info to TextAutoCompleteItem. (Try to match the naming of items with the langserver protocol).

@dicene
Copy link
Contributor Author

dicene commented May 14, 2018

No worries, and it sounds good. I was going to pursue the document variable-based autocomplete at some point, but it seems like a pain in the ass for a language like Lua. Especially since, in the case of Mudlet, the same Lua session is spread over potentially hundreds or thousands of documents.

I've also implemented a signal/socket for detecting and responding properly to backspace, added an item delegate to customize the way the ListWidget gets drawn, and some other things along those lines. Would you prefer I try to keep separate changes in distinct PR's, or do you mind if it's a large single PR for the majority of the changes?

Also, I've been trying to get familiar with LSP over the past week or so, and I'll be adjusting things as best I can to match names and similar things as I go.

For reference, here's what it's looking like so far:
image

I'll try to change it to reflect the current theme in use if I can figure out how.

@vadi2
Copy link
Contributor

vadi2 commented Jul 10, 2018

@gamecreature any thoughts on the PR style?

@gamecreature
Copy link
Member

Yes, I prefer several PR's, because this makes it possible to merge/evaluate them one by one.
If it's to hard, a single PR is also possible, only the risk is that it's not mergable in whole because of certain changes.

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

3 participants