Lowercase alpha mode left / right shifted don't work

[evgaster]

Using the simulator and DM42n with version 0.9.15.

I wanted to use lowercase greek letters.
I put the program in lowercase alpha mode by 🟨 ENTER 🟨 ENTER. The indicator is "abc".
SIN, without shift, gives me "j".
🟦 SIN doesn't give me "λ" but "≤". 🟨 SIN doesn't give me "J" but "<".

Looks like lowercase alpha mode with left / right shift looses the lowercase and falls back to uppercase.

[evgaster]

Taking a closer look at the keymap in config/db48x.48k.

The plane numbers in the file differ from the description at Key positions. I will correct those and add a bit of description. That won't solve the issue but will help understanding the keymap file(s).

I noticed a few other strange things, which I would appreciate feedback on:

1. plane 5: uppercase alfa mode, left shifted: has on the LN key the "ρ" (Greek lowercase "rho") character. On my keyboard overlay it has "σ" (Greek lowercase "sigma"). The key doesn't give what is in the keymap but ... "σ". I suspect this is coming from static const unicode shifted[] in src/user_interface.cc. Why does this overrule the keymap? Isn't there a better way by using the keymap? By the way, the keymap should be corrected.
2. Plane 6: uppercase alfa mode, right shifted: has on the + key the "!'. Note the string starts with a double qoute and ends with a single quote. I have looked at bool user_interface::load_keymap(cstring name) in in src/user_interface.cc. It seems to handle double quote only. If I change the single to a double quote and try to load (in the simulator) the keymap file I get a message origination from record(keymap_warning, "%s: [%s] is too long",. What is going on here?

[evgaster]

I think I found the cause of number 2. It's the @ on the uppercase alfa mode, right shifted 2 key. It is handled as a comment character.

I have a fix for that.

No progress with 1 yet.

[evgaster]

Committed the fix mentioned above.

[evgaster]

When I change "A" to "Alpha" in "Plane 4: uppercase alpha mode", reload the keymap file ... I don't get "Alpha" but "A".
It looks as if the keymap file isn't used.

[evgaster]

Taking a detour to understand key mapping better.

If I execute the example "assign Greek letters to the shifted keys A through F when in alpha mode" with the StoreKeys command ...

{ "α" 21.5 "β" 22.5 "γ" 23.5 "δ" 24.5 "ε" 25.5 "φ" 26.5 }
STOKEYS

Note: row = 2, plane = 5 = "uppercase alfa mode, left shifted".
Note: apparently rows are counted from 1, starting with the menu / function keys, from top to bottom.
Note: apparently columns are counted from 1, from left to right.
These notes are confirmed by reviewing .../src/dmcp/target.cc.

I do get a KeyMap variable. It contains:

Directory {
	401
		"α"
	402
		"β"
	403
		"γ"
	404
		"δ"
	405
		"ε"
	406
		"φ"
}

Note: the numbers are not the rc.ph. These are platform_keyid values.
Note: a keyword Directory followed by a list of pairs of keyid and value. I find this, in the rpl / postfix realm, rather odd. I would go for a list of pairs of value and keyid_variable_name followed by a, postfix, Directory command.

I still don't get the Greek letters but the regular plane 5 characters. Again, it looks as if the KeyMap isn't used.
Then it struck me: UserMode! If I activate that I do get the Greek letters ... from this key mapping.

Returning from this detour to investigating the original issue.

[mipa83]

Confirm the behaviour with loading the keymap. Check out my pull request or repository for having loaded all plants from the keymaps (.k48) files. Note: Comments are now with // and end with newline, so that @ sign works properly. Waiting for feedback.

[evgaster]

@mipa83 haven't looked at you pull request yet, but will do so (later).

I do already have some feedback about your other remark.

The @ character is the db48x / rpl comment character. Each keymap can be seen as rpl source with, for each plane, an array with mappings. From that angle I don't like you changing the start of comment character. Nor do I understand the choice for //. I agree that @ is perhaps just as arbitrary. But introducing an other character sequence for this purpose is also introducing inconsistency with other parts of db48x.

I had already found a, fairly elegant I think, solution for 2. For now I intend to stick with that and will mover forward from there.

[evgaster]

Committed the fix mentioned above.

That included only the db48x.48k keymap file.
The others have the same issue.
Will update those and add them to the PR.

[evgaster]

@mipa83 haven't looked at you pull request yet, but will do so (later).

See #1619 (comment)

[c3d]

OK, sorry, but you are going "in the wrong direction" here 😉

Regarding lowercase, the lowercase mode is when typing without shift. In other words, it is expected and intentional behaviour that shifted keys will give the same symbols whether in uppercase or lowercase.

Regarding Greek and Cyrillic data entries, use the Greek or Cyrillic menus under the char menu (🟦F). If in uppercase or lowercase alpha mode, when the Greek menu is selected, typing ABC will get you "ΑΒΧ" or "αβχ" respectively. Same with Cyrillic. This is implemented in characters. cc. The goal is to make it relatively easy to type Greek and Cyrillic quickly.

Regarding accented and other variations on a character, this is with the character catalog, which you get with the + key (or 🟨 CAT). For example, hit 🟦_ENTER_ to get double quotes, then A, then + then F2, you would get "ặ". You can get all the variations around the "A" shape that way.

In other words, insofar as there are quick ways to enter lowercase or uppercase alpha in various languages, including greek, I am not convinced you need to change the existing mapping code.

[evgaster]

OK, sorry, but you are going "in the wrong direction" here 😉

If that's what you think, then I haven't made my direction clear (enough).

Regarding lowercase, the lowercase mode is when typing without shift. In other words, it is expected and intentional behaviour that shifted keys will give the same symbols whether in uppercase or lowercase.

Please point me to the documentation about this "expected and intentional behaviour".

The content of the keymap file config/db48x.48k suggests something else. Just look at the last 3 planes.
This issue is about not getting the "λ" (last plane, second row, 4th position) but "≤".

If I change those characters in the keymap file to "lambda: λ" and "less or equal: ≤", I still get "≤".

Investigation showed an error in the keymap files. There was a "!' string (unbalanced and mixed quotes). It also showed an error with the comment handling in the load_keymap function. So far I fixed those errors.
I also (internally) documented db48x.48k and fixed a few things that deviated from the keyboard layout / overlay.
That's what is in the PR ... at the moment.

Further investigation shows that the keymap file is overruled by a lot of the user_interface code, particularly the handle_* functions. I am looking at using the keymap better and simplifying some of this code.
That 's the direction I am heading, carefully, small steps.

[mipa83]

@evgaster see my last pull request. Tried to simplify code in user_interface. Just some proposal. Have a look.

[c3d]

OK, @evgaster, I believe that I misunderstood your intent then. I will take another look, but I want to cut a 0.9.16 release today, and I won't be able to integrate that specific change.

[evgaster]

@c3d please proceed with the new release. I guess many are looking forward to it.

My advice is not to integrate #1617 nor #1641. They need more work.