[GH-ISSUE #4] [Feature Request] Replace wildcard tokens #1

Closed
opened 2026-10-30 21:16:42 +00:00 by bsakaguchi · 11 comments
Owner

Originally created by @horribleCodes on GitHub (Oct 13, 2022).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/4

Originally assigned to: @DominikDoom on GitHub.

Do you think you can make this script work with the wildcard tokens from this script as well?
The idea is twofold:
First, after typing __ (two underscores), you get a list of all available .txt files. Selecting one completes the token.
Then, the list changes from available token names to the items of that list. Selecting one replaces the token with the item.

So, as an example:

  • Entering __ shows a list of the wildcard files, like artist, adjective, style,...
  • Selecting adjective replaces the __ with __adjective__
  • A list of the content of adjective.txt is shown: angry,beautiful,dark,...
  • Selecting ´beautiful´ replaces the __adjective__ with beautiful
Originally created by @horribleCodes on GitHub (Oct 13, 2022). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/4 Originally assigned to: @DominikDoom on GitHub. Do you think you can make this script work with the wildcard tokens from [this](https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Custom-Scripts#wildcards) script as well? The idea is twofold: First, after typing `__` (two underscores), you get a list of all available .txt files. Selecting one completes the token. Then, the list changes from available token names to the items of that list. Selecting one replaces the token with the item. So, as an example: - Entering `__` shows a list of the wildcard files, like `artist, adjective, style,...` - Selecting `adjective` replaces the `__` with `__adjective__` - A list of the content of adjective.txt is shown: `angry,beautiful,dark,...` - Selecting ´beautiful´ replaces the `__adjective__` with `beautiful`
Author
Owner

@DominikDoom commented on GitHub (Oct 13, 2022):

It should be possible, I'll have a look at it. But I don't know how easy it will be to parse in my current implementation, so it'll probably take a bit of experimenting.

<!-- gh-comment-id:1277339798 --> @DominikDoom commented on GitHub (Oct 13, 2022): It should be possible, I'll have a look at it. But I don't know how easy it will be to parse in my current implementation, so it'll probably take a bit of experimenting.
Author
Owner

@horribleCodes commented on GitHub (Oct 13, 2022):

From what I've seen, your parser should be able to read the data just fine - it'll just have a single column. I guess an array for the filenames and a two-dimensional one for the content should work.
You can use /\b_{2}(.*)\b/gU to match incomplete tokens, and /\b_{2}(\S*[^_])_{2}\b/gU to match complete ones.

<!-- gh-comment-id:1277381540 --> @horribleCodes commented on GitHub (Oct 13, 2022): From what I've seen, your parser should be able to read the data just fine - it'll just have a single column. I guess an array for the filenames and a two-dimensional one for the content should work. You can use `/\b_{2}(.*)\b/gU` to match incomplete tokens, and `/\b_{2}(\S*[^_])_{2}\b/gU` to match complete ones.
Author
Owner

@DominikDoom commented on GitHub (Oct 13, 2022):

Yes, that part is fine. The tricky part is only autocompleting / changing the part of the prompt we are actively editing. For example, if the user has a longer prompt with keywords repeated multiple times, we only want to replace the one that is currently being typed by the user.

For normal tags this works well in the current implementation since after the hints close we are done with that tag. But for your suggested multi-stage wildcard selection, the window needs to stay open or re-open after the file selection, so I'm currently trying to implement a forced re-evaluation of that part for the autocompletion even though nothing changed (so the script still knows in which part of the prompt we want to change things). If I can get that part to work, the rest should be able to reuse the existing insertion code without much issue. If not, I'll have to do it a bit hacky with its own separate method that just replaces the results directly again.

<!-- gh-comment-id:1277410362 --> @DominikDoom commented on GitHub (Oct 13, 2022): Yes, that part is fine. The tricky part is only autocompleting / changing the part of the prompt we are actively editing. For example, if the user has a longer prompt with keywords repeated multiple times, we only want to replace the one that is currently being typed by the user. For normal tags this works well in the current implementation since after the hints close we are done with that tag. But for your suggested multi-stage wildcard selection, the window needs to stay open or re-open after the file selection, so I'm currently trying to implement a forced re-evaluation of that part for the autocompletion even though nothing changed (so the script still knows in which part of the prompt we want to change things). If I can get that part to work, the rest should be able to reuse the existing insertion code without much issue. If not, I'll have to do it a bit hacky with its own separate method that just replaces the results directly again.
Author
Owner

@horribleCodes commented on GitHub (Oct 13, 2022):

Well, I thought it would be better if the prompt did change after the first selection - in case you want to just use the wildcard token, not a specific word.
In that case, you'd know exactly what changed, right?

<!-- gh-comment-id:1277421491 --> @horribleCodes commented on GitHub (Oct 13, 2022): Well, I thought it would be better if the prompt did change after the first selection - in case you want to just use the wildcard token, not a specific word. In that case, you'd know exactly what changed, right?
Author
Owner

@DominikDoom commented on GitHub (Oct 13, 2022):

The multi-stage selection is definitely a good idea, yeah. Currently, it just wouldn't handle the case of a prompt like ... __wildcard__ ..... __wildcard__ since a simple regex comparison would replace both. So I at least want to try to use the what-changed-logic already in place. But if it doesn't work out, I'll probably just save the index to selectively replace.

<!-- gh-comment-id:1277428745 --> @DominikDoom commented on GitHub (Oct 13, 2022): The multi-stage selection is definitely a good idea, yeah. Currently, it just wouldn't handle the case of a prompt like `... __wildcard__ ..... __wildcard__` since a simple regex comparison would replace both. So I at least want to try to use the what-changed-logic already in place. But if it doesn't work out, I'll probably just save the index to selectively replace.
Author
Owner

@horribleCodes commented on GitHub (Oct 13, 2022):

Have you considered using the cursor position?
https://stackoverflow.com/questions/2897155/get-cursor-position-in-characters-within-a-text-input-field/48150864#48150864

You could run back until the first separator, and perform the match from there. That way, the first match should be the relevant one.

<!-- gh-comment-id:1277437102 --> @horribleCodes commented on GitHub (Oct 13, 2022): Have you considered using the cursor position? https://stackoverflow.com/questions/2897155/get-cursor-position-in-characters-within-a-text-input-field/48150864#48150864 You could run back until the first separator, and perform the match from there. That way, the first match should be the relevant one.
Author
Owner

@DominikDoom commented on GitHub (Oct 13, 2022):

I already use cursor position for inserting at the right place. But I currently can't trigger autocomplete on a specific part, only the whole prompt at once which is then deconstructed into sections to find the actual text difference. So I'll probably just add an optional parameter to skip that step if we already know what changed and supply it.

<!-- gh-comment-id:1277446854 --> @DominikDoom commented on GitHub (Oct 13, 2022): I already use cursor position for inserting at the right place. But I currently can't trigger autocomplete on a specific part, only the whole prompt at once which is then deconstructed into sections to find the actual text difference. So I'll probably just add an optional parameter to skip that step if we already know what changed and supply it.
Author
Owner

@evanjs commented on GitHub (Oct 13, 2022):

This is an interesting proposal

I currently use wildcards heavily with some modifications to allow for more "fuzziness" re paths (match file or directory), but those changes might not be necessary (or at least fundamentally different) if I could use wildcards against Danbooru directly.

This would be especially true if we could source tag groups

<!-- gh-comment-id:1277549708 --> @evanjs commented on GitHub (Oct 13, 2022): This is an interesting proposal I currently use wildcards heavily with some modifications to allow for more "fuzziness" re paths (match file _or_ directory), but those changes might not be necessary (or at least fundamentally different) if I could use wildcards against Danbooru directly. This would be especially true if we could source [tag groups](https://danbooru.donmai.us/wiki_pages/tag_groups)
Author
Owner

@DominikDoom commented on GitHub (Oct 13, 2022):

Alright, it took longer than expected to iron out all the bugs, but I'm pretty happy with the result:

https://user-images.githubusercontent.com/34448969/195632461-49d226ae-d393-453d-8f04-1e44b073234c.mp4

There is some catches though which I couldn't work around so far:

  • Gradio doesn't expose folders, only files. So the script needs an extra file which I simply called wildcardNames.txt. The script can only request the files based on their name there, but that also allows excluding specific ones if you don't want them.
  • Wildcards can contain spaces, but typing a space cancels the autocompletion, since you're starting a new word. So you can only search for single words at the moment. I might allow underscores as space replacements during wildcard search later, but don't have time for it today.
<!-- gh-comment-id:1277764591 --> @DominikDoom commented on GitHub (Oct 13, 2022): Alright, it took longer than expected to iron out all the bugs, but I'm pretty happy with the result: https://user-images.githubusercontent.com/34448969/195632461-49d226ae-d393-453d-8f04-1e44b073234c.mp4 There is some catches though which I couldn't work around so far: - Gradio doesn't expose folders, only files. So the script needs an extra file which I simply called `wildcardNames.txt`. The script can only request the files based on their name there, but that also allows excluding specific ones if you don't want them. - Wildcards can contain spaces, but typing a space cancels the autocompletion, since you're starting a new word. So you can only search for single words at the moment. I might allow underscores as space replacements during wildcard search later, but don't have time for it today.
Author
Owner

@DominikDoom commented on GitHub (Oct 13, 2022):

I pushed & released the changes just now, hope you enjoy!
Also, as per the notice in the readme:
Since not everyone has it, it's disabled by default. So you need to enable it in the config and edit the wildcardNames.txt file I mentioned above to add/uncomment your wanted tags.

<!-- gh-comment-id:1277805027 --> @DominikDoom commented on GitHub (Oct 13, 2022): I pushed & released the changes just now, hope you enjoy! Also, as per the [notice in the readme](https://github.com/DominikDoom/a1111-sd-webui-tagcomplete#new---wildcard-support): Since not everyone has it, it's disabled by default. So you need to enable it in the config and edit the `wildcardNames.txt` file I mentioned above to add/uncomment your wanted tags.
Author
Owner

@horribleCodes commented on GitHub (Oct 13, 2022):

Thanks a bunch!

<!-- gh-comment-id:1277958072 --> @horribleCodes commented on GitHub (Oct 13, 2022): Thanks a bunch!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
DominikDoom/a1111-sd-webui-tagcomplete#1
No description provided.