[Cuis-dev] Diacritical marks in Smalltalk code

[Juan Vuletich]

Hi Boris, Folks,

I just pushed a change to keyboard input. Now the full range of Unicode 
keyboard input as supplied by the OS should work.

I tried it with the on screen keyboards provided by MacOS, and code 
points not in the Latin charset (but included in the font set in the 
Cuis text editor) seem to work well.

Boris, please try with this, and tell how it works for you

Thanks!

On 12/20/2022 1:01 PM, Juan Vuletich via Cuis-dev wrote:
> Hi Boris,
>
> A quick follow up on this.
>
> In #fetchMoreEventsDiscardingMouseEvents:, following the call to 
> #primGetNextEvent:, add `eventBuffer first = 2 ifTrue: [eventBuffer 
> print].`. This will show the raw data we get from the VM for every 
> keyboard event.
>
> In #generateKeyboardEvent: you have the full complexity of processing 
> those buffers in Cuis. This hasn't been updated since before Unicode 
> in Cuis, so calls to #iso8859s15CodeForUnicodeCodePoint: and 
> #macRomanToLatin1: are probably a bad idea today. We need to just take 
> the CodePoint in the sixth position in the Array. Will work a bit on 
> this and keep you posted.
>
> Thanks,
>
> On 12/20/2022 11:09 AM, Juan Vuletich via Cuis-dev wrote:
>> Hi Boris,
>>
>> On 12/20/2022 9:42 AM, Boris Shingarov via Cuis-dev wrote:
>>> What is the preferred way to debug what happens when a keyboard key 
>>> is pressed?  I am observing some strange non-orthogonality in the 
>>> latest Cuis: some Greek letters appear to be "more equal" than others.
>>
>> Try `Sensor kbdTest` and `Sensor test`. Have the Transcript visible. 
>> Both end with [x]. Hack them as needed.
>>
>>>
>>> Let me explain.
>>>
>>> I use Unicode for mathematical notation heavily in various systems 
>>> which all differ how this Unicode is keyed in.  They all revolve 
>>> around the same idea of LaTeX-like conventions, but from 
>>> LiquidHaskell to ProofGeneral to Coqtail to 
>>> whatever-I-tried-in-Smalltalk there is enough difference in the 
>>> details to ruin the muscle-memory experience.  So I gave up on all 
>>> application-specific schemes and have set up an xkbd layout which, 
>>> while again being similar to all of the above, behaves consistently 
>>> because it's an OS-level "input method".  (It's an ".XCompose" 
>>> script for X11).
>>
>> Cool.
>>
>>> So for Greek letters it just sends Unicode Greek to Cuis.  This 
>>> works well with *almost* all Greek letters, but *some*, such as θ, 
>>> seem to somehow not result in any input. 
>>
>> The above could be of help.
>>
>>> I remember Juan was showing me some magic where some codepoints were 
>>> translated into a "special Cuis codepage", is this something that 
>>> still happens?
>>
>> That was in the old days. Now Cuis is fully Unicode capable, and 
>> strings are actually instances of UnicodeString that holds UTF-8 bytes.
>>
>>> the transition to full Unicode would remove all that complexity, 
>>> right?  what's the best way to step through what happens to a key 
>>> event in the Debugger in Cuis?
>>>
>>
>> There still be some problem, though. Cuis is fully Unicode capable, 
>> but the keyboard input is taken from whatever the VM delivers to us. 
>> `Sensor test` will show what the VM is delivering us. Most likely 
>> we'll need to understand how that relates to the input you're sending 
>> with your XCompose script, and how to make sense of it.
>>
>> HTH,
>>
>
>


-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich