Hi,
Thanks very much for keeping me from thinking I'm crazy- at least in this way.
I don't think your workaround would work because it may be incorrect: Glyphs (displayed chars) may not display correctly in UTF8 for the UTF16 counterparts.
While I couldn't seem to search for the code point correctly in text view, I have worked around the issue with this workflow:
- Switch UTF16 file to hex view
- Search with Regex
- Switch back to Text View and locate cursor
At first I was not sure I could properly identify the character (since 2 bytes are involved and the find could happen in first or second byte), but then I inserted the character using the hex codes then switched back to text view to see if I got it.
Overall I was able to identify several "Risky" UTF16 characters through this exercise that contained the ascii codes of Windows PATH control chars.
I hope this is useful to someone dealing with UTF16. I don't think changing the behavior as you mentioned will help but it's good to know you can switch back and forth from hex view to get the same result as the cursor is updated.