mirror of
https://github.com/DominikDoom/a1111-sd-webui-tagcomplete.git
synced 2026-11-05 00:17:25 +00:00
[GH-ISSUE #107] Doesn't trigger when typing directly after parenthesis/bracket? #76
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
low priority
low priority
pull-request
question
waiting for feedback
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
DominikDoom/a1111-sd-webui-tagcomplete#76
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @space-nuko on GitHub (Jan 8, 2023).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/107
Excuse me if this has a solution already, when I go to type a tag directly after one or more parenthesis or bracket the autocompletion doesn't seem to trigger. It does work with embeddings if you type
<after a parenthesis thoughUsually I don't mean to autocomplete a tag that itself contains a parenthesis, it's for the stable diffusion weights like
(some tag:0.75)or dynamic prompts syntax like{tag|other tag}, in the case of a space followed by parenthesis/brackets I want the completion to start after the first non parenthesis/bracket character (maybe taking into account tags like:3)I'd just put a space in between usually but it's muscle memory for me
Thanks for this extension by the way, I use it all the time
@DominikDoom commented on GitHub (Jan 8, 2023):
Yes, that is a limitation of how I detect tags. Tags can in theory continue after parentheses, so I have to use space to separate them.
Editing tags inside weight brackets should already work (at least if they don't contain spaces), but outside of them the regular detection needs space, commas or other special chars like | as separators. If I change it for outside, editing inside brackets would likely not work correctly. Embeddings use a different trigger mechanism and aren't affected in the same way.
Edit: This isn't meant to say that I won't work on this, just that it might take a while since I need to be careful about changing the parsing.
Other than that, because of the way CLIP converts your prompt to tokens, I'd suggest using spaces or commas after brackets as separators anyway. Same for dynamic prompts, at least as I understand it, it might lead to unwanted effects if the next tag comes after whatever dynamic prompts inserts without separation. But don't quote me on that.
@Sakura-Luna commented on GitHub (Mar 18, 2023):
@DominikDoom The tooltip functionality seems to be broken after an update, now it won't display the correct result after a "(".
I now have to add a space.
@DominikDoom commented on GitHub (Mar 18, 2023):
@Sakura-Luna This has never been the case. As I've written above as a limitation on how I detect tags it will currently always parse the ( as part of a tag which includes one. There is one exception to this, which is parentheses already closed. So typing after the b in "(b)" will show tags without parentheses due to it being parsed as prompt emphasis, not part of the word. Same for [] and the (xyz:1.0) notation.
Detects the
(bas part of the tag:Detects b alone as it is properly enclosed:
I know this can be annoying if you want to add emphasis before typing to the end, but I suggest instead normally typing the tag, then afterwards highlighting the text you want to empasize and using the CTRL+Up Arrow / Down Arrow hotkeys the webui provides. It is both faster and easier to modify if you get used to it. As that notation is also taken into account for emphasis parsing, it will allow editing the tags within normally:
@Sakura-Luna commented on GitHub (Mar 18, 2023):
@DominikDoom My actual usage scenario is to add prompt in brackets, do you think this is also in line with expectations?
@DominikDoom commented on GitHub (Mar 18, 2023):
@Sakura-Luna I didn't change anything regarding that as far as I know, but it is an easy fix to allow that. Since nobody starts typing a tag with parentheses from the very end, excluding the closing brackets there won't interfere with normal tag writing. Other way around is still a bit complicated though since e.g.
street_fightershows way less characters from the game than(street_fighter, since characters typically have the game/series they are from in parentheses.@Sakura-Luna commented on GitHub (Mar 18, 2023):
@DominikDoom I think it is better to treat prompts that contain and do not contain parentheses equally, because prompts should always be common first, and it also helps to simplify the logic.
@DominikDoom commented on GitHub (Mar 19, 2023):
@Sakura-Luna That is a possibility, but it's not as straightforward as it sounds. It's very hard to know when to ignore parentheses and when not to. Even if tags including parentheses are just treated as if they don't have any, the biggest remaining problem is replacing the word in the prompt.
The script looks for what the user typed in the vicinity of the text cursor, which enables it to replace only the part that was actually currently edited, instead of the first or even all occurrences. This is really important for tags with a common stem, else if you typed "hair" and completed it to "long hair", it would potentially replace other instances of "hair" as well, e.g. in "blonde hair". But if we ignore parentheses while searching, they are still typed in the textbox, so the script wouldn't be able to find the correct text in the prompt. And it's not a good idea to ignore parentheses there, else it would potentially replace those used for emphasis as well.
Same thing with other special characters that appear both in tags and for prompt steering, such as
:.The only proper way I see out of this issue would be to construct an actual syntax tree instead of "naive" regex, like an IDE would. But that is a pretty big task that is probably overblown for this minor inconvenience, and for which I also just don't have enough time.