Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

US International keyboard layout doesn't work #125

Open
kgrossjo opened this issue Jun 5, 2017 · 4 comments
Open

US International keyboard layout doesn't work #125

kgrossjo opened this issue Jun 5, 2017 · 4 comments
Assignees
Labels

Comments

@kgrossjo
Copy link

kgrossjo commented Jun 5, 2017

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
Copy link

yarray commented Jun 23, 2017

+1

Other input sources like Chinese pinyin does not work either:

2017-06-23 12_16_45

The Chinese character selection menu will pop up once and then disappear immediately, making it impossible to type non-latin characters.

@mjdescy mjdescy self-assigned this Jun 27, 2017
@mjdescy mjdescy added the bug label Jun 27, 2017
mjdescy added a commit that referenced this issue Jun 27, 2017
- Updates copyright to extend to year 2017.
- Bumped version number.
@mjdescy mjdescy closed this as completed Jun 27, 2017
@yarray
Copy link

yarray commented Jun 27, 2017

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 mjdescy reopened this Jun 27, 2017
@mjdescy
Copy link
Owner

mjdescy commented Jun 28, 2017

@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
Copy link

yarray commented Jun 28, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants