-
Notifications
You must be signed in to change notification settings - Fork 306
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
Progressive auto-complete #43
Comments
The issue is that this script currently doesn't do any sorting, it just filters by your typed string. This is not a big problem for tags, since those are ordered by count in the CSV. So generally more used tags will be higher in the list, which is similar enough to what the booru sites themselves do. The progressive completion is an interesting idea, however it might be more tricky with general tags. For example, if you type "hair" it will both filter "long_hair" and other hair lengths, but also "hair_bun" or even "chair" somewhere further down the list. We know the common part is what was typed, but we don't know in which direction the user wants to complete (or even both at once if the word is in the middle of the tag). So it would definitely have to be some kind of hybrid solution. Currently my only idea in that regard is putting perfect matches at the top. But that wouldn't help in your foo example. Edit distance and its related algorithms would work better in that case, but be worse generally since for example typing just "f" would prefer other single letter tags over words that start with f. And even if we first filter and then sort based on edit distance so we only choose from words containing an f, it often preferred very niche tags over common ones just because they're one letter shorter, so it was slower for common tags. TL;DR: Guessing the most likely word is hard since it can be completed in both directions, so they are just shown in the order of the file. So I'm kind of stuck regarding this problem, other than implementing one of those and leaving it off by default. But I'm open to suggestions if you have an idea. |
With the current completion system and code, I don't see this happening, but since the completion behavior has also improved a bit since then I also think it's not needed anymore. |
@DominikDoom What improvements are you referring to that help with this? Solution wise, the wildcard system from dynamic prompts uses this type of structure for nested folders: /character/body/hair.txt. Currently, typing "ch" and then pressing tab would autocomplete /character/body/hair.txt in it's entirety assuming it's the at the top of the autocomplete results Instead though, could tab completition be made to only complete one level of wildcard path at a time? So typing "ch" and then tabbing would autocomplete the first result of "/character/" assuming it's at the top alphabetically. Then "b" and tab would append "body" so you end up with "/character/body/" and so on and so forth. If nothing else, do you have advice for which file to edit for color coding different levels of nested wildcard folders for easier skimming? I don't know much coding, but I could probably make that adjustment for myself using chatGPT and share it on here if I'm successful. |
@PaperOrb The improvements I was referring to were mainly related to the normal tags. As for the rest of your suggestions, that would require a custom solution for wildcards. |
(Copying from adieyal/sd-dynamic-prompts#20 (comment))
When writing a prompt, I can use the tab key to autocomplete wildcards. This is very useful, except it will auto-complete whichever one is the top one, rather than filling in only what is "common" to the current possibilities. This means I have to type out a considerable amount before I can auto-complete usefully.
For example, if the three files are "foofoo", "foobar" and "foobaz". I would expect the following:
f<TAB>
becomes "foo"foob<TAB>
becomes "fooba"Currently,
f<TAB>
would just autocomplete whichever happens to be first in the list of possibilities.Additionally, this happens when auto-completing tags, not just wildcards, I just hadn't used tag autocomplete enough to notice it.
The text was updated successfully, but these errors were encountered: