[Lazarus] RE : RE : RE : RE : LCL and custom keyboard layouts

[Mark Morgan Lloyd]

Ludo Brands wrote:
>> Except that that's /not/ Unicode at the application level, it's 8-bit > KAPL encoding. This whole area is somewhat messy, since most APL > implementations- not to mention the software that they > execute- go back > to the days of Selectrics and EBCDIC card punches. Apart from > the things > I've been tinkering with over the last few weeks the only other > implementation that I know is based on UTF-8 is Paraplegic > http://code.google.com/p/paraplegic/, the rest are mired in backwards > compatibility issues.> 
> I'm not trying to sell anything:) I'm just starting from the principle that whatever you can do on the keyboard layer is transparent for the app and is all benefit. Using OnKeyDown is a messy solution once you get into actually implementing it. The shift state is a serious complication. An example: I don't know if this is a bug but the 'AltGr' key (the lvl3 XKB key) is not showing up in the Shift:TShiftState on linux. So on my french keyboard I can 't make the distinction between 'e' and '€' or '(' and '['. Another difficulty is that the caps state isn't correctly reflected in the shift state. The caps key is correctly detected when pressed but the shift state doesn't reflect it. Hard to track if you don't know what its state is when you enter the app...

Might be worth looking at xmodmap output. It's a long time since I've 
had to fiddle with this sort of thing (except in the context of APL), 
but even with UK keyboards I find a certain amount of variability 
particularly in the context of the Alt and Alt Gr keys.

>> You probably didn't notice that a few weeks ago I asked whether FPC > could handle things like ⍴ as a function name. At the time I was > wondering whether APL's functionality could be supplied as Pascal > functions, I've got various numeric analysis jobs where a > fusion of APL > and a grid containing the result of a database query could be > very useful.> > I've found a couple of possible issues relating to Unicode > handling in > (Sorokin's) TRegExpr and in TStringList, I'll try to get them > reported > with test code over the next few days now that I've got the > bulk of the > parser/evaluator out of the way, and before I start on the > Lazarus app > with probable refactoring.> 
> If you have characters outside the 16 bit range, why don't you stick to utf8? The utf8 routines in the LCL make parsing utf8 strings almost as easy as parsing widestrings. And TRegExpr and TStringList work fine with utf8.

Noted, but there's also an outer parser which resembles Smalltalk more 
than APL, and that relies very heavily on lookahead and lookback- pretty 
nasty code to get it doing "the right thing" in most cases. What I've 
got is adequate to allow keywords/selectors to be defined in e.g. Far 
Eastern scripts, and I'm fairly sure UTF-8 would get very messy.

Anyway, after all this messing around perhaps my resistance to the idea 
of an EBCDIC-based FPC port is a bit more explicable :-)

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]