Touch Layout Debugging with Keyman Developer

Keyman
#1

Greetings,

I’m seeking advice on how to pursue the following issue. I have a touch layout (A) where a composition fails, and another (B) where it works. To isolate what the issue might be I began cutting away .kmn code (in A), testing, and repeating until the .kmn file is near minimal. The problem remained.

I went to my working layout, B, and cut away the equivalent code and it continues working. I then copy & paste the working “B” code into “A” but “A” continues not to work. I next copy the “B” .keyman-touch-layout file to replace the “A” counterpart. Still not working.

I’ve tried a test sequence where I restart my machine, exit Keyman Desktop, launch Keyman Developer, then build the keyboard and launch in a local browser to test. I’ve also tried in an Incognito window. Nothing has helped, “A” cannot compose a sequence and “B” always can.

The difference between the two keyboards would be just a few identifier lines in the .kmn file and they have separate .kvks files.

What should I try next? Does Keyman Developer or the browser retain cache that should be deleted? I am using Keyman Developer 13.0.115.0 .

thanks!

#2

This is kind of “off the wall”, but make sure you are using UTF-8 format in Keyman Developer. I think the other issue I discovered once was a file like keyman-touch-layout or possibly kmn had a BOM when it shouldn’t or something along those lines.

#3

I have tested this in our latest beta version (14.0.214-beta). The same issue is observed.

Test files: B is named “for_makara” and A is the other one which contains all related files.

#4

Thanks for confirming @makara , this is a subtle bug that had me questioning my sanity :upside_down_face:

#5

I notice the gff_gurage.keyman-touch-layout has LINUX line endings and looking at other keyman-touch-layout files they have DOS line endings. I haven’t tested anything, just saying in case you want to test. I do remember some issues with encodings and line-endings which is why I’m following this track.

#6

I have a theory as to why this is going wrong: can you try compiling the A keyboard with the option Keyboard > Include Debug Information switched off and then test it again?

#7

I’ve documented this for resolution in the 14.0 beta cycle. For a workaround, use characters in the range a-z A-Z 0-9 _ for identifier names.

If a keyboard includes identifiers (stores or groups) that include characters outside the a-z A-Z 0-9 _ range, these characters are replaced by _ by the compiler when Include Debug Information is set to avoid potential issues with invalid characters in identifiers.

When no debug information is included, the store names are replaced with integer identifiers so this problem does not arise.