fails to form a complete Korean letter inside search bar

[exploitJ]

Issue

Every keystroke is separated when typing Korean

For example, 강 comprised with ㄱ + ㅏ + ㅇ in correct order.
One thing to notice is that unlike chinese or japanese its combined on-the-fly. (in other words there's no IME overlay menu involved)

However, search bar only takes ㄱㅏㅇ(3 separated symbol) and not 강.

Copy & pasting works, I just can't type a complete word.

[p0deje]

I don't use Korean so it's hard for me to debug, can you please provide as detailed as possible steps to reproduce the bug?

[exploitJ]

I don't use Korean so it's hard for me to debug, can you please provide as detailed as possible steps to reproduce the bug?

Korean Input Method's layout is no different to Standard English layout.
It doesn't matter if you're using English keyboard. (I'm using it too, btw.)
You may add Korean IME via System Preferences > Keyboard > Input Sources
Add "2-Set Korean" and you're good to go.

In order to input 강물, press r-k-d-a-n-f, you can try it somewhere else to see for yourself.
Now, head over to Maccy's search bar.
The text in the search bar would look like "ㄱㅏㅇㅁㅜㄹ" instead.

[p0deje]

I can reproduce the issue and know why it happens, not sure how to fix yet.

[exploitJ]

I can reproduce the issue and know why it happens, not sure how to fix yet.

Can you elaborate on why it's happening? also potential ideas on fixing if you have one.
I've started looking through your code base and tried some measures today.

Modifying processSingleCharacter inside MenuHeaderView.swift was no luck; String.precomposedStringWithCompatibilityMapping didn't fix the issue.

I'm out of ideas right now.

[p0deje]

I think the reason it's happening is because the search field loses focus after every character. This focus loss needs to happen because Maccy needs to give it to the history menu items so that the user could press Enter to select an item or arrow keys to navigate the menu.

I believe we might try to throttle this behavior so that the focus is kept for a short period of time. This would at least improve the situation for fast typing. However, I am yet to find any docs about this behavior - maybe there is a hint somewhere there.

[p0deje]

For the time being, I've pushed a small workaround that fixes this as long as the search is not fired (400 ms). There should probably be a better solution (e.g. we call some AppKit API to evaluate the string of characters and replace them) but I am yet to find it.

[p0deje]

I didn't manage to find a reliable solution, please try using 0.25 and re-open if it's still not good enough. Hopefully, I can then make it better over time.