Open kgrossjo opened 7 years ago
+1
Other input sources like Chinese pinyin does not work either:
The Chinese character selection menu will pop up once and then disappear immediately, making it impossible to type non-latin characters.
I've tested the new version and it fixed the umlaut problem. However, I still cannot input correctly using Chinese pinyin input source. Should I open another issue separately?
By the way, I saw that the KeyUp event is used. Is it possible to trigger the method only when text is changed? I have little knowledge about Objective-C, but from my experiences on frontend programming it seems more robust against non-latin languages.
@yarray I tested the Chinese Pinyin keyboard and confirmed what you reported.
The autocompletion method I coded is the standard way of doing things on the Mac. I had to create a few tweaks to make it work properly with todo.txt syntax. Handing + and @ properly in ranges required some workarounds, for example.
After a good deal of experimentation with the keyUp
method in the TTMFieldEditor
class, I determined the cause of the problem. What dismisses the Pinyin input window appears to be the mere referencing the rangeForUserCompletion
property of the TTMFieldEditor
class. I tried removing my custom implementation of that property getter, and just using the default implementation from NSTextView
, and the Pinyin input window was dismissed just the same.
I need the rangeForUserCompletion
value to determine what the substring is that the app could autocomplete. What I am afraid of is that Apple's implementation of that property getter causes the Pinyin menu to be dismissed, and there may be nothing I can do about it. So, right now, I am not sure how to solve the problem.
Many thanks for your detailed explanation! It is a pity that the standard way does not consider non-latin languages.
It seems that nvALT has implemented autocompletion for both latin and non-latin languages. Would it be helpful to learn from its code? I have not dive deep but the related code seems in https://github.com/ttscoff/nv/blob/master/DualField.m and some related files. The not-so-good thing is that nvALT seems quite complicated (maybe also with some hacking). I'm not sure if it worths the effort.
Maybe a viable workaround now is to provide an option in preferences to disable autocompletion so that a user using non-latin languages can still has a usable software, although without the autocompletion feature.
Using TodoTxtMac 2.4.0 (2032), I observe that the "US International - PC" keyboard layout shortcuts for inserting non-Ascii characters don't work. For example, hitting the two keys
"a
should result inä
, but I get"a
. Also, the normal US keyboard shortcuts don't work, either: withalt-U
followed bya
, I get¨a
instead of the expectedä
.(Note that
"a
andalt-U a
produce"a
and¨a
, respectively, slightly different character sequences.)Using SwiftoDo Desktop 2.6.0 (2041), I observe similar but slightly different behavior:
"a
produces"a
instead of the expectedä
(same as TodoTxtMac), butalt-U a
correctly produces the expectedä
.For all of the above, in both programs, I tried both the "new entry" text field and the "search" text field.
A final remark:
alt-U a
is the key combination that works with the US layout, as well; but the"a
combination doesn't, for this one you need "US International - PC".