Counter-intuitive double key press needed to input diacritic characters (instead of regular diacritic+space key combination)

[Alfredo Fernández Díaz]

Fixing ticket #79 introduced this one.

In most languages other than English, some characters are overlaid on regular letters to form "combined" characters, f.e.: ¨ + o = ö through the use of "dead keys". Dead keys are not supposed to produce character output, this should happen only if a valid regular character is typed afterwards, and then a single combined character is produced. The fix for #79 drops all diacritic characters as typed, thus they can't be combined with a space to produce a standalone (non-diacritic) character when one is needed in the standard way all typists are used to.

This defect is minor compared to #79, as the current PM implementation offers a simple yet counter-intuitive workaround: hitting a dead key twice will still type the standalone character, f.e. ^ + ^ = ^. Still, this should be fixed.

Proposed fix: create a 1-char buffer to store diacritic characters as they are entered. The next time a space is typed, check for the right 'combined' flag, and output the last diacritic stored in the buffer instead.

[Andreas Schnellbacher]

Hi Alfredo,

won't it be easier to let PM handle those key combinations? That probably requires eFTE2 to differ PM-processed keys and own (command) keys.

That's the way I did it with NEPMD, but additionally, I decided to process all defined key commands as accel keys. (That is most likely not the usual way for an app. I had to exclude single char-producing keys and a few PM key combinations from processing, but, as advantage, accel keys work also with open menus.)

Andreas

[Alfredo Fernández Díaz]

Andreas :-))

I am just planning to fix a minor annoying side effect of fixing a major bug in input handling (please check #79), with as little code changes as possible: this is not "my" project, just something I need fixed in the PM version of a tool that 'works perfectly' otherwise (because VIO has a completely different input mechanism that just works, and who knows what code for the other platforms even does). If you have a better way to this, that does not require to re-implement key handling wholesale, please speak up (:

The problem lies precisely in PM handling logic -- If the user presses some 'dead key' (f.e. ¨) eFTE2 code gets the DEADKEY flag from PM, so it knows it should expect a composite character next. Now, if "A" is pressed next, PM passes 'me' (to eFTE2 code) an "Ä" character, with COMPOSITE flag. So far, so good -- I don't even need to keep the ¨ because PM did the combining for me, and I certainly should have not included it in output as an independent character (which was the fix to #79). Now, my problem is, if a user presses ¨ followed by space (to get the character "¨") PM sets the COMPOSITE flag but does not do the combining this time, and the character it passes along is a regular space instead of "¨".

So if I want to honor in output the expected combination "¨" (or any "dead" key) + space = "¨" (char) when it is typed, I need to check for the COMPOSITE flag in spaces, and type the last diacritic entered instead, hence the need to 'remember' what it was.

[Gregg Young]

CS[250]