US International keyboard layout doesn't work

[kgrossjo]

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: with alt-U followed by a, I get ¨a instead of the expected ä.

(Note that "a and alt-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), but alt-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".

[yarray]

+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.

[yarray]

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.

[mjdescy]

@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.

[yarray]

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.