Odd code that goes to a LOT of trouble to do something simple
Closed this issue · 17 comments
One thing I don't understand is why your code reacts differently if you press [Tab] on a single item completion list versus clicking on that single item with mouse. [Tab] only works with a single item on the completion list, so it must be as definitive as click-select.
You have this:
def _onCompletionListTabPressed(self):
"""Tab pressed on completion list
Insert completable text, if available
"""
canCompleteText = self._widget.model().canCompleteText
if canCompleteText:
self._qpart.textCursor().insertText(canCompleteText)
self._invokeCompletionIfAvailable()The following code appears to be equivalent, at least I can't think of any counter example:
def _onCompletionListTabPressed(self):
"""Tab pressed on completion list
Insert completable text, if available
"""
canCompleteText = self._widget.model().canCompleteText
if canCompleteText:
self._qpart.textCursor().insertText(canCompleteText)
self._closeCompletion()It's simpler, more efficient, and works exactly like the click-select code above it to accomplish exactly the same task (in def _onCompletionListItemSelected).
Click always closes the completion.
Tab inserts as much as possible, than reinitializes completion for new text
- Create file with contents
longword
longerword
- Wait few seconds
- Type
lon - Press
Tab
Only 1 letter will be inserted. Completion window will be updated.
Current code works fine for single-item and for multiitem completions.
I don't understand the problem.
The problem is that as you have it.
- The entire text of the single completion still in the popup
- The popup window does go away, as it has no further use because its job is totally done.
That's the observable behavior.
My fix forces the popup to go away via the same mechanism as when you click on an item from the popup list, which is far quicker (on my machine anyway) and more efficient.
Ken
On Thu, Mar 6, 2014 at 11:14 AM, Andrei Kopats notifications@github.comwrote:
Click always closes the completion.
Tab inserts as much as possible, than reinitializes completion for new text
- Create file with contents
longerword
- Wait few seconds
- Type lon
- Press Tab
Only 1 letter will be inserted. Completion window will be updated.
Current code works fine for single-item and for multiitem completions.
I don't understand the problem.Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36904309
.
Could you please make a very detailed step-by-step instruction or a screencast how to reproduce a bug?
It's not a bug, your code is going to a lot of unnecessary trouble to
achieve the desired effect. You can see this yourself any time you like,
either in a debugger or with print statements, you can verify that if you
terminate the auto-completion via [Tab] when there is only one item in the
popup, your code will not immediately destroy the popup. Instead, it will
go back into the word matching logic, finally determine that your word is
complete, and then destroy the popup.
The logic of the situation is identical to selecting an item from the popup
w/ a mouse click. In both cases, the user has given a completely
unambiguous command to accept one single word from the popup, and that
therefore the popup can be destroyed. So ifor identical circumstances, why
not follow the same (simpler, more efficient) code path?
Ken
On Thu, Mar 6, 2014 at 12:37 PM, Andrei Kopats notifications@github.comwrote:
Could you please make a very detailed step-by-step instruction or a
screencast how to reproduce a bug?Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36913985
.
Tab should not close completion, if more than one item is visible. Do you want to add an if statement?
Tabs do nothing if there is more than one, right? Unless, I suppose it's
selected via arrow keys. In either case, when the tab key selects anything
at all, meaning the user has made a decision, the popup should be destroyed.
Ken
On Thu, Mar 6, 2014 at 12:52 PM, Andrei Kopats notifications@github.comwrote:
Tab should not close completion, if more than one item is visible. Do you
want to add an if statement?Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36915768
.
Tabs do nothing if there is more than one, right?
Tabs do something.
I found that github markdown hid one of words. Try the updated example at my first comment
That is useful, but I would describe the behavior differently. When there is more than one candidate, those candidates may have one or more as-yet-untyped characters in common.
All of the as-yet-untyped characters in common are insert upon tab, or if there is one candidate, it is inserted.
So in the context of your current master, file "completer.py":
def _onCompletionListTabPressed(self):
"""Tab pressed on completion list
Insert completable text, if available
"""
canCompleteText = self._widget.model().canCompleteText
if canCompleteText:
#krc:
model = self._widget.model()
word_count = len(model.words)
if (word_count > 1):
self._qpart.textCursor().insertText(canCompleteText)
self._invokeCompletionIfAvailable()
elif (word_count == 1):
#krc: There can now be only one word in list
self._qpart.textCursor().insertText(canCompleteText)
self._closeCompletion()Otherwise, on my computer, at least, there is a perceptible pause after [Tab] w/ only one candidate. This I think might be the Achille's heel of all autocomplete, the perceptible pauses, and other timing-dependent behavior.
The reason I'm even doing this project was the frustrating autocomplete on SequelPro, which inserts wrong stuff if you pause, and just generally pauses erratically. MySQL Workbench has different autocomplete issues, equally frustrating. The best SQL autocomplete (in my opinion) is SQLyog. That's what I'm trying to match.
If you load a significant amount of source code into your test application, say 10K lines, performance suffers, again on my computer.
If this control is destined to become part of enki, it will suffer in comparison to all the other autocomplete editors I've ever used. What they have in common is that their word lists are based on syntactic considerations, plus reserved word, obviously.
Word processing is the same issue, word lists are from dictionaries plus user-maintained word lists.
Your control is quite good, the best I've found, and I've tried them all. I hope I haven't given the impression that I think anything significantly negative about your code or your control.
But it's in the nature of these things that you don't really know where you're falling short until somebody uses your control beyond a test framework, in a context that's far beyond anything in your test framework.
You could say that I'm doing that for one of your supported languages, SQL (MySQL), and autocomplete, as you have it, is virtually useless for SQL. SQL files tend to be smaller, there are very few "variables" (as Python might use them), and what folks want is autocomplete based on keywords and database server object names (databases, tables, columns). Just like SQLyog does, check it out, that's the premium ride.
I'm currently actively using two Python IDEs, Wing and iep, both are (in my opinion) not as good as PyScripter (previously my only IDE). What PyScripter has is keyword + syntax-derived word list. Wing also knows the property/method names of many objects, PyQt for example, and that's pretty damned cool.
Ken
Hi
Qutepart is used not only in test framework, but as current editor widget for Enki. I have been coding in Qutepart for more than year, other people also use it.
I never percepted lag, caused by completion. And, I'd like to fix it instead of hiding, if it is possible.
Could you please provide your big file and step-by-step instructions how to reproduce the lag?
There are many problems w/ your autocomplete implementation for my use
case, and this one is relatively minor.
I have tried to show you as clearly as I know how, both conceptually and
via working, tested, shippable code, how to support SQL, as well as more
flexibly support other languages. At your request, I modified my own code
to put it in a form that was directly comparable to your current master.
At each step, you have indicated that what I had provided was entirely
useless, 10% of the job, etc.,, and requested more.
I don't have time to do what you want now, and apparently you don't want
what I've given so far.
Probably it will be best for me to maintain my own fork, it's working
beautifully in my application (a MySQL IDE essentially), This fork easily
exceeds the editor feature set of the best product currently on the market
(SQLyog in my opinion).
Good luck with qutepart.
Ken
On Fri, Mar 7, 2014 at 12:22 AM, Andrei Kopats notifications@github.comwrote:
Hi
Qutepart is used not only in test framework, but as current editor widget
for Enki. I have been coding in Qutepart for more than year, other people
also use it.I never percepted lag, caused by completion. And, I'd like to fix it
instead of hiding, if it is possible.
Could you please provide your big file and step-by-step instructions how
to reproduce the lag?Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36969008
.
Now we have concrete problem. Lag after Tab. I want to reproduce and fix it, not only for case of 1 item in the completion list, but for all cases.
I need your help to reproduce the lag. What is wrong?
Little reminder: I'm not paid for this job. I created Qutepart for free, now I'm trying to solve your lag for free
I tried to be clear, but perhaps I failed.
I have come to believe that working on qutepart, aside from my own fork, is
not fruitful for either of us.
What's the point then?
On Fri, Mar 7, 2014 at 1:20 AM, Andrei Kopats notifications@github.comwrote:
Now we have concrete problem. Lag after Tab. I want to reproduce and
fix it, not only for case of 1 item in the completion list, but for all
cases.
I need your help to reproduce the lag. What is wrong?Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36971060
.
Yes, I see that, and I'm grateful, as I've said many times.
I'm in the same situation myself, and I have solved the lag problem on my
own. You have the code.
Ken
On Fri, Mar 7, 2014 at 1:23 AM, Andrei Kopats notifications@github.comwrote:
Little reminder: I'm not paid for this job. I created Qutepart for free,
now I'm trying to solve your lag for freeReply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36971173
.
I think you solved the case when completion list has 1 item, but the same lag should reproduce, if completion list has more than one item. So, it is a workaround, not a fix
All cases where the code is actually using the popup (repopulating it and
so forth) are slowish. In the case of only one item, there's really no
excuse, that can and should execute instantly.
That's not a workaround, that's isolating an important (at least in SQL)
special case, and making it work several orders of magnitude faster.
You may not see this because you don't start nearly every file with
"sel'[Tab] to get "SELECT". Many SQL keywords can be gotten at three
letters plus [Tab].
These are the practical difficulties of supporting SQL as a programming
language.
Ken
On Fri, Mar 7, 2014 at 1:28 AM, Andrei Kopats notifications@github.comwrote:
I think you solved the case when completion list has 1 item, but the same
lag should reproduce, if completion list has more than one item. So, it is
a workaround, not a fixReply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-36971411
.
@kcrossen, I tried to test completion on huge files, and I discovered that opens slowly, if has too many completion variants. Now completion list will not shown automatically if it contains more than 256 items.
But, I still can't reproduce the lag after Tab, and I can't include your code to the upstream without a test, which proves that it is useful.