edbee-lib
edbee-lib copied to clipboard
Autocomplete improvements
@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-insensitivelabel_.containsmatch, a better value for a case-insensitivelabel_.startsWithmatch. -
Modified
fillAutoCompleteList()to use aQMultiMapinstead of aQList, so that it sorts by the value returned frommatchLabelScore()(with lower values being higher priority on the list). -
I've added another property to the
TextAutoCompleteItemclass 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 modifyingfillAutoCompleteList()to useQWidgetsinstead ofQListWidgetItem, 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):
-
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.
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).
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:

I'll try to change it to reflect the current theme in use if I can figure out how.
@gamecreature any thoughts on the PR style?
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.