keyboard code improvements (towards a free layout)

[mipa83]

Please see this this pull request only as a suggetion.
This pull focused on keyboard code improvements (towards a free layout)

Bug fixes

“*.k48” file is the BASIS for ALL keys and their plans: Comments in the .k48 file start with “//” and end with a newline. There was a conflict with the @ sign, because it is also used a character on the keyboard (key RS 2).
“.k48” file - new command for UINewLine (do_new_line())
config/db48x.48k: PLANE Numbers (+1), PLANE 8, PLANE 9 updated
config/legacy.48k: PLANE Numbers (+1), PLANE8, PLANE 9 updated

user-interface.h and user-interface.cc:
handle_alpha(int key) and handle_digits(int key) deleted.
Alpha keys are handled by handle_functions(key) and handle_CHS_EEX(key).
handle_search(int key) for search mode only.
handle_BASED overlay A-F keys

Clear unused static cstring keyboards[]
sim/sim-window.cpp
config/42style.48k: delete
config/true42.48k: delete
delete line 560 and 561 (42style.48k and true42.48k)
sim/sim.qrc
delete line 7,4,3

Open bugs: SEARCH Mode

Inserting characters and numbers (searching) and searching next (Key_F4) is working for now. Update will follow

[evgaster]

In #1616 (comment) you asked for feedback on this PR.

The changes you propose are pretty drastic. It takes quit a bit of imagination to connect them to the title "keyboard code improvements (towards a free layout)". I would appreciate a description of either the issue(s) you are trying to solve or/and functionality you are adding and how this improves db48x. What's the intended outcome? Then take and explain the design step(s) (assumptions; decisions; ...) that lead to the code changes.

In #1616 (comment) I already reflected on your comment character change. In summary: please, don't do it that way.

You remove config/42style.48k and config/true42.48k. Why?
Don't edit nor commit help/db48x.md. It is generated.

You are making changes to config/db48x.48k some that I can agree to but also some that I don't understand in view of all the documentation about the keyboard.

You introduce UINewLine. Why would you do such a thing for "\n" if you don't do it for other characters? Why can't it be left to the keymap + handle_functions?

To avoid unnecessary diff (and c3d remarks about it), avoid 1) indentation changes; 2) avoid moving stuff in the file. Also keep close to c3d's coding style.

About the handle_* functions ... as if you read my mind ... partly.
You are moving along similar lines as a I am for fixing #1616. The keymap seems to be ignored or overruled all over the place. Particularly handle_alpha en handle_digits and perhaps handle_shifts could be simplified. I will try and find inspiration in the changes you propose. I am just not ready (yet) to support them as they are.

[mipa83]

Thank you for your help and information about help/db48x.md.

Removing some k48 files --> There are almost no differences in the k48 files: not all menus are finished, so I thought focusing on two layouts would be enough.

I thought about using //, because most C and C ++ files use this coding for comments. I tried the newline character , but found out that the screen wasn't updated on the db48x sim... so I decided to write the UINewLine command.
Another advantage of UINewLine is that it might be independent of the line terminal sign of the k48 file, in case Linux / Windows /OS are indicating a new line differently .

This pull request is only an idea of how code could be improved - so there is no need to accept it.

[evgaster]

Removing some k48 files --> There are almost no differences in the k48 files: not all menus are finished, so I thought focusing on two layouts would be enough.

Focus on A isn't sufficient reason to throw away B. B might still be useful.
Honestly, I am not sure of the value of those 2 keymaps. I decided to just leave them as they are.

I thought about using //, because most C and C ++ files use this coding for comments.

I already thought those are your reasons.
But this is not about C or C++. It's about rpl and the choice for @ as the comment character.

This pull request is only an idea of how code could be improved - so there is no need to accept it.

It's not up to me, but c3d to accept (or reject) your PR(s).
I am just giving my feedback.

Don't get me wrong! I appreciate your contribution. Please keep up the good work. Many of your proposed changes save me a lot of work :-). Let's join forces.