Thanks for reporting.
How I see it, the number of combinations (OS * EC/OC * Preferences
flags * different versions...) is beyond testability (unless we could
automate user interaction tests ?).
I always disable "Smart Characters", they upset me so much, but I'll
give it a try, hoping we share same OC.

In this context, an implementation composed of multi-layered hacks of
different ages does not help to perform an analysis of impacts of
changes. In this context, no one dare to change code because it gets
intricated, except by putting one more workaround here and there,
bypassing or breaking the initial contracts and making things worse...
In my sense, this claims a carefull rewrite, where care should
concentrate on identifying the features.

Nicolas

2011/8/9 Alexander Lazarević <laza at blobworks.com>:
> The latest changes also seem to affect OCompletion in a way. Pressing ) or ]
> produces a DNU. Disabling "Smart Characters" clearly helps.
>
> Alex
>
> 2011/8/9 Chris Muller <asqueaker at gmail.com>
>>
>> In Linux, it used to be, I could type Control in lieu of Shift+Alt.
>> For example, I used to type Control+( to surround with parentheses.
>> Control+[ to surround with curly-braces {}.
>>
>> Now I have to type Alt+Shift+( and Alt+Shift+[ for those.
>>
>> Is there any way to get the Control+( back?
>>
>>  - Chris
>>
>> On Thu, Aug 4, 2011 at 3:15 AM, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> > I'm typing this message on a mac French keyboard.
>> > That means I can obtain the holy brackets [ | ] only through weird
>> > keystroke combinations
>> > | = shit+option+L
>> > [ = shift+option+( where shift+5 is (
>> >
>> > Enclosing a text in square brackets would require some finger torture
>> > both in Squeak/Pharo
>> > shift+option+command+(
>> > But this does not work because of #shiftEnclose: rules encountered in
>> > #initializeShiftCmdKeyShortcuts
>> > (found both ParagraphEditor class and TextEditor class)
>> >
>> >        "Note: Command key overrides shift key, so, for example,
>> > cmd-shift-9
>> > produces $9 not $("
>> >        '9[,''' do: [ :char | cmdMap at: (char asciiValue + 1) put:
>> > #shiftEnclose: ].       "({< and double-quote"
>> >        "Note: Must use cmd-9 or ctrl-9 to get '()' since cmd-shift-9 is
>> > a
>> > Mac FKey command."
>> >
>> > shiftEnclose: is badly designed because it does hardcode the keyboard
>> > layout (see below).
>> > This is not compatible with modern VMs, at least the mac ones, because
>> > they deliver a unicode codePoint for $[ or $|, not a raw keycode.
>> > It's easy to remove this anachronism and correct the mapping:
>> >
>> >        "On some keyboards, these characters require a shift"
>> >        '([<{|"''' do: [:char | cmdMap at: char asciiValue + 1 put:
>> > #enclose:].
>> >
>> > To avoid pushing a mac-centric change in trunk, I need to know if the
>> > Linux/Windows VM would support above modification.
>> > Can anyone check for me ?
>> >
>> > Nicolas
>> >
>> >
>> >
>> >
>> >
>> > Example of hardcoded keyboard layout:
>> > TextEditor>>shiftEnclose: aKeyboardEvent
>> >        "Insert or remove bracket characters around the current
>> > selection.
>> >         Flushes typeahead."
>> >
>> >        | char left right startIndex stopIndex oldSelection which text |
>> >        char := aKeyboardEvent keyCharacter.
>> >        char = $9 ifTrue: [ char := $( ].
>> >        char = $, ifTrue: [ char := $< ].
>> >        char = $[ ifTrue: [ char := ${ ].
>> >        char = $' ifTrue: [ char := $" ].
>> >        char asciiValue = 27 ifTrue: [ char := ${ ].    "ctrl-["
>> > snip...
>> >
>> >
>>
>
>
>
>
>