Progressive auto-complete

[Xyem]

(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.

[DominikDoom]

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.
But I totally understand that it can be a problem for wildcards or other unordered tag lists. I tried a solution based on edit distance in the past, but that wasn't working well at least on its own.

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).
If we always assume forward completion, that makes it pretty useless for many common tags or wildcards where the common part is at the end and your want suggestions for the beginning.

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.

[DominikDoom]

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.

[PaperOrb]

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.

[DominikDoom]

@PaperOrb The improvements I was referring to were mainly related to the normal tags.
Since quite a while it filters based on word beginnings by default, so if you type "hair" you will not get "chair" anymore but preferably tags that actually start with hair in one of its parts. If you would also want chair, you'd have to instead use "*hair".
So it is much rarer now for it to misunderstand what tag family you mean.

As for the rest of your suggestions, that would require a custom solution for wildcards.
Both can be done, but it is not trivial since the code only ever assumes the tag to be one whole piece when it comes to insertion and coloring. So I would rather try to implement it myself. I'll move the issue to #190, please do any further discussion there as this issue is really old and largely unrelated to how the new feature would work.