DominikDoom / a1111-sd-webui-tagcomplete

Booru style tag autocompletion for AUTOMATIC1111's Stable Diffusion web UI

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Making tagcomplete compatible with wildcard parser-wrap string changes

NDWaffles opened this issue · comments

Had to change 'string to use as wrap for parser wildcard' from __ to ++ in settings, to get dynamicprompts and aDetailer to cooperate.

This came with the cost of tagcomplete not recognizing when I was trying to enter a wildcard with '++'

I was able to figure out a few changes in 'ext_wildcards.js' I could make to make the dropdown for the wildcards themselves, and could get them autocompleted.
I could NOT figure out what to change to make the dropdown for the wildcard's contents appear.

My question to you is: Would it be possible to add a field in settings to change 'string to use as wrap for parser wildcard' like in dynamicprompts settings?

Or, more easy: What all would I need to change in .js files to make it so wildcards will display properly with '++' instead of '__'

Haven't tried yet, but I think it would be enough to just replace all occurrences of __ in both tagAutocomplete.js and _ext_wildcards.js
The __ prefix isn't used anywhere else but those two files, and only in context of wildcards.
The dropdown for the wildcard's contents is also handled by ext_wildcards.js, but the reason for it not working after your tries is probably that it wasn't recognized as one single tag, which is handled by the main file.

I can add a settings option, but probably won't be able to get to it today. So in the meantime, try just replacing all __ in those files and tell me if it works.

Replacing all instances of '__' with '++' in 'ext_wildcards.js' and 'extAutocomplete.js' seems to break autocomplete for wildcards.

Specifically, it seems to break wildcard autocomplete when I replace the '__' in

// Regex
const WC_REGEX = /\b__([^,]+)__([^, ]*)\b/g;

in ext_windcards.js
and

const COMPLETED_WILDCARD_REGEX = /[^\s,_][^\t\n\r,_]*[^\s,_][^\s,_]*/g;

in tagautocomplete.js

Changing everything else is how I got the wildcards to appear with '++', but still won't have the dropdown displaying contents when fully completed.

Ah sorry, yeah, the REGEX parts need some special considerations I forgot to mention. + is a special control character for Regex, it means "at least one or more of the character(s) coming before it". To specify it as a normal character instead, you have to escape it with \. Also, I tried it just now, and sadly it needs a slightly more indepth adjustment too, you need to remove the \bs from WC_REGEX as well. These normally tell it to look for a word boundary, but contrary to __, ++ will not count as part of a word there, so it fails.

After that WC_REGEX should look like this: /\+\+([^,]+)\+\+([^, ]*)/g; instead. You should be able to copy-paste that into ext_wildcards.js. I confirmed that it works with ++ afterwards.
As a hacky manual fix for the meantime this won't be an issue, but due to the \b needing to be removed as well, I will need to do some more testing for unwanted side effects and potential other workarounds to make it a proper settings option. I'll likely only be able to get to that on the weekend.

Edit: Of course, COMPLETED_WILDCARD_REGEX in tagAutocomplete.js will need the \+\+ too:
/\+\+[^\s,_][^\t\n\r,_]*[^\s,_]\+\+[^\s,_]*/g;

Alright! That works for me.
Thanks a ton for your help, and for making such a useful extension :)

It should be fully automatic now, so you can try overwriting your local modifications with the latest version.

There is no TAC-specific setting, instead it just grabs the dynamic prompts setting value if it exists and otherwise defaults to "__".
This of course was an assumption on my side that the dynamic prompts extension you talked about was the original https://github.com/adieyal/sd-dynamic-prompts, other extensions that allow the same thing might still be incompatible due to potentially using different option names. Maybe I will change to a separate settings option later if the demand is there, but for now this seemed the most elegant.

There is one thing that will not work automatically with this, which is nested / recursive wildcards. Most of these I've seen directly hardcode the sub-wildcards with the full __...__ format so the parser steps through on its own, but that's of course out of my control since it requires changing the wildcard file contents themselves.