Open ronan36880 opened 1 week ago
I don't think it has anything to directly with lstrip
.
Previously by
was stripped to by
which is < 3 characters and does not trigger completion
After the change, it triggers completion for by
, which matches a LOT of tags (I think). Much more than any other 3-letter prefix. And it's just slow because it's a lot.
I don't think it has anything to directly with
lstrip
.Previously
by
was stripped toby
which is < 3 characters and does not trigger completion After the change, it triggers completion forby
, which matches a LOT of tags (I think). Much more than any other 3-letter prefix. And it's just slow because it's a lot.
Oooh, that's interesting. It does match a lot of tags from a quick look through the csv file. What would be the best way to fix it? It does freeze the UI thread every time after the change.
One obviously workaround would be to edit the csv file, but I'd rather avoid that if possible 😅
I think sorting and cutting off the csv is not a bad idea in general (not by hand obviously) - the tags with low use-count won't work anyway. Not sure if that throws out enough of the by
matches though, but it doesn't seem to be a problem for the existing sets which include similar tags.
Don't have a great idea how to fix it in code. Could start auto-complete only at the 4th character, but that makes it less useful. Or special case the by
prefix, or a bit more generally anything with a trailing space perhaps...
Commit 1c5e832100ced03cda5148d20c00f8d35ba6b812, which was created created to address #1294 seems to have caused a performance regression on auto-completion (I have confirmed with a git bisect).
I don't fully understand what is going wrong here, but here's the completion file I am using: fluffyrock-unbound-tag-completion.csv
Replication steps:
fluffyrock-unbound-tag-completion
completion file in the settings.by
and press space.It will then take some time to process things:
https://github.com/user-attachments/assets/19dbd639-ad88-457d-aa08-999d01f5795f
Locally reverting this commit seems to have fixed the issue - I wonder if the
lstrip
function could be much more computationally intensive than expected?