[Vm-dev] Re: [Pharo-dev] Substitution of ' to " in TextEditor>>shiftEnclose

J. Vuletich (mail lists) juanlists at jvuletich.org
Thu Aug 28 12:48:00 UTC 2014

Hi Folks,


Quoting Eliot Miranda <eliot.miranda at gmail.com>:

> On Wed, Aug 27, 2014 at 4:27 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> I encountered this in Squeak too, because French keyboard is not better
>> than german one :(
>> Nicolas Cellier uploaded a new version of ST80 to project The Trunk:
>> http://source.squeak.org/trunk/ST80-nice.136.mcz
>> ==================== Summary ====================
>> Name: ST80-nice.136
>> Author: nice
>> Time: 4 August 2011, 10:43:00.836 am
>> UUID: 6f8b2f4c-8c8c-48a8-ba32-              bb5b37d827d0
>> Ancestors: ST80-ul.135
>> #shiftEnclose: is hardcoding the keyboard layout, which is not
>> compatible with foreign keyboards and modern VM, and prevents correct
>> enclosing to work.
>      +1.  This is the issue that must be fixed.  It must be understood
> properly (is the VM answering adequate information or not?).

The information provided by the VMs in keystroke events is not  
perfect, and it could be enhanced. I see 2 main problems (in what  
follows, $x denotes Character x, and [x] denotes the physical keyboard  
key labelled 'x'):

Problem 1)
On the mac, when control or command are pressed, for any keystroke the  
unshifted code is returned, even if shift is pressed. For instance,  
let's assume an US keyboard. So, [shift]+[,] generates $< and  
[shift]+[.] generates $>. If you run 'Sensor kbdTest' and press  
[shift]+[,] you correctly get $<, but if you press  
[control]+[shift]+[,] or [command]+[shift]+[,] you get $,. This is  
bad, because to detect [command]+[<] or [control]+[<] you need to  
write code that not only needs to know about the platform, but also  
about the keyboard layout, as in many layouts $< is not generated by  
doing [shift]+[,], but by some other combination. The same happens  
with most non-alphabetic keys, that usually differ in different  
keyboard layouts.

Problem 2)
There is a completely separated issue, and it happens both in Windows  
and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the  
code. So, [ctrl]+[c] generates code 3. This is consistent with the  
traditional meaning of the ctrl key (in dumb terminals and DOS), but  
it makes impossible for the image to tell (for example) between  
[ctrl]+[Enter] and [ctrl]+[m]. The image might want to use these  
keystrokes for different things, so it would be much better not to  
substract 64 in the VM and let the image handle it. I know it could be  
done by handling key down and key up events, but this would also  
require code that is not only platform dependent but also needs to  
know the mapping between key codes and characters in each platform.

I haven't tested on Linux or platforms other than Windows and Mac, but  
things like these could also happen.

In general, [control], [command] and [alt/option] should not affect  
the character code of a keystroke, they should only set the  
appropriate flag so the image can decide what to do with them. The  
character code should be the same as if [control], [command] and  
[alt/option] were not pressed.

This is completely different for [shift], as [shift] does indeed  
modify the character generated, as [shift]+[8] means $* in some  
keyboards and $( on others. If [shift]+[someKey] is pressed, the  
keystroke character code should be the same as the user would get  
elsewhere in the platform, irrespectively of [control], [command]  
and/or [alt/option] being pressed or not.

Fixing these, and making the behavior consistent between platforms,  
would enable a few simplifications in the image. It would also enable  
the use of some keystroke combinations involving [command] and/or  
[control] that are problematic today.

> best,        Eliot

Juan Vuletich

More information about the Vm-dev mailing list