Substitution of ' to " in TextEditor>>shiftEnclose

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Substitution of ' to " in TextEditor>>shiftEnclose

Max Bareis
Hi,

I am wondering if the upper part of 

TextEditor>>shiftEnclose: aKeyboardEvent
"Insert or remove bracket characters around the current selection."

| char left right startIndex stopIndex oldSelection which text |
char := aKeyboardEvent keyCharacter.
char = $9 ifTrue: [ char := $( ].
char = $, ifTrue: [ char := $< ].
char = $[ ifTrue: [ char := ${ ].
char = $' ifTrue: [ char := $" ].

is a bug or a feature. For german keyboards it causes that pressing the single Apostroph (which is reached via shift-#) is substituted to ". So enclosing a textblock and pressing ' leads to comments around the block, which is really annoying.

I am curious, because this substitution does not make any sense to me. The keyCharacter is always the "real" character ( $( instead of $9 ). Also it seems that this substitution reduces the keyboard to the en-Layout, therefore breaks the separation of concerns.

Is there any reason, why this substitution takes place?

Regards

Max
Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Nicolai Hess
2014-08-27 15:12 GMT+02:00 Maximilian Bareis <[hidden email]>:
Hi,

I am wondering if the upper part of 

TextEditor>>shiftEnclose: aKeyboardEvent
"Insert or remove bracket characters around the current selection."

| char left right startIndex stopIndex oldSelection which text |
char := aKeyboardEvent keyCharacter.
char = $9 ifTrue: [ char := $( ].
char = $, ifTrue: [ char := $< ].
char = $[ ifTrue: [ char := ${ ].
char = $' ifTrue: [ char := $" ].

is a bug or a feature. For german keyboards it causes that pressing the single Apostroph (which is reached via shift-#) is substituted to ". So enclosing a textblock and pressing ' leads to comments around the block, which is really annoying.

I am curious, because this substitution does not make any sense to me. The keyCharacter is always the "real" character ( $( instead of $9 ). Also it seems that this substitution reduces the keyboard to the en-Layout, therefore breaks the separation of concerns.

Is there any reason, why this substitution takes place?

Regards

Max



I hope this gets resolved, as it is really annoying with a german Keyboard.

And look at the issues:
11436 and


Nicolai
Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

stepharo

is a bug or a feature. For german keyboards it causes that pressing the single Apostroph (which is reached via shift-#) is substituted to ". So enclosing a textblock and pressing ' leads to comments around the block, which is really annoying.

I am curious, because this substitution does not make any sense to me. The keyCharacter is always the "real" character ( $( instead of $9 ). Also it seems that this substitution reduces the keyboard to the en-Layout, therefore breaks the separation of concerns.

Is there any reason, why this substitution takes place?

Regards

Max



I hope this gets resolved, as it is really annoying with a german Keyboard.

And look at the issues:
11436 and

Should the core team take action?

Stef



Nicolai

Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Max Bareis
<quote author="stepharo">

>
>     I am curious, because this substitution does not make any sense to
>     me. The keyCharacter is always the "real" character ( $( instead
>     of $9 ). Also it seems that this substitution reduces the keyboard
>     to the en-Layout, therefore breaks the separation of concerns.
>
>
>
> I hope this gets resolved, as it is really annoying with a german
> Keyboard.
>
> And look at the issues:
> 11436 <https://pharo.fogbugz.com/default.asp?11436> and
> 4646 <https://pharo.fogbugz.com/default.asp?4646>
>
>Should the core team take action?
>
>Stef

For me, there is no urgency. I sent it to the mailing list, because I used the wrong words for the issue search and didn't find any issue. As it is already on the issue list and I have a workaround (replacing the method in my download bash file for zeroconf) it is ok.

Max


Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Nicolas Cellier
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.

This version rather use a normal #enclose:
A (ParagraphEditor initialize) postscrip is necessary.

=============== Diff against ST80-ul.135 ===============



2014-08-27 17:11 GMT+02:00 Max Bareis <[hidden email]>:


>
>     I am curious, because this substitution does not make any sense to
>     me. The keyCharacter is always the "real" character ( $( instead
>     of $9 ). Also it seems that this substitution reduces the keyboard
>     to the en-Layout, therefore breaks the separation of concerns.
>
>
>
> I hope this gets resolved, as it is really annoying with a german
> Keyboard.
>
> And look at the issues:
> 11436 &lt;https://pharo.fogbugz.com/default.asp?11436&gt; and
> 4646 &lt;https://pharo.fogbugz.com/default.asp?4646&gt;
>
>Should the core team take action?
>
>Stef

For me, there is no urgency. I sent it to the mailing list, because I used
the wrong words for the issue search and didn't find any issue. As it is
already on the issue list and I have a workaround (replacing the method in
my download bash file for zeroconf) it is ok.

Max






--
View this message in context: http://forum.world.st/Substitution-of-to-in-TextEditor-shiftEnclose-tp4775052p4775087.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Nicolas Cellier
I don't remember how the issue ended, or even if it properly ended...
(That's where an issue tracker should shine, but Squeak one is not really used/maintained).


2014-08-27 17:27 GMT+02:00 Nicolas Cellier <[hidden email]>:
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.

This version rather use a normal #enclose:
A (ParagraphEditor initialize) postscrip is necessary.

=============== Diff against ST80-ul.135 ===============



2014-08-27 17:11 GMT+02:00 Max Bareis <[hidden email]>:



>
>     I am curious, because this substitution does not make any sense to
>     me. The keyCharacter is always the "real" character ( $( instead
>     of $9 ). Also it seems that this substitution reduces the keyboard
>     to the en-Layout, therefore breaks the separation of concerns.
>
>
>
> I hope this gets resolved, as it is really annoying with a german
> Keyboard.
>
> And look at the issues:
> 11436 &lt;https://pharo.fogbugz.com/default.asp?11436&gt; and
> 4646 &lt;https://pharo.fogbugz.com/default.asp?4646&gt;
>
>Should the core team take action?
>
>Stef

For me, there is no urgency. I sent it to the mailing list, because I used
the wrong words for the issue search and didn't find any issue. As it is
already on the issue list and I have a workaround (replacing the method in
my download bash file for zeroconf) it is ok.

Max






--
View this message in context: http://forum.world.st/Substitution-of-to-in-TextEditor-shiftEnclose-tp4775052p4775087.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Eliot Miranda-2
In reply to this post by Nicolas Cellier



On Wed, Aug 27, 2014 at 4:27 PM, Nicolas Cellier <[hidden email]> 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?).
 

This version rather use a normal #enclose:
A (ParagraphEditor initialize) postscrip is necessary.

=============== Diff against ST80-ul.135 ===============



2014-08-27 17:11 GMT+02:00 Max Bareis <[hidden email]>:



>
>     I am curious, because this substitution does not make any sense to
>     me. The keyCharacter is always the "real" character ( $( instead
>     of $9 ). Also it seems that this substitution reduces the keyboard
>     to the en-Layout, therefore breaks the separation of concerns.
>
>
>
> I hope this gets resolved, as it is really annoying with a german
> Keyboard.
>
> And look at the issues:
> 11436 &lt;https://pharo.fogbugz.com/default.asp?11436&gt; and
> 4646 &lt;https://pharo.fogbugz.com/default.asp?4646&gt;
>
>Should the core team take action?
>
>Stef

For me, there is no urgency. I sent it to the mailing list, because I used
the wrong words for the issue search and didn't find any issue. As it is
already on the issue list and I have a workaround (replacing the method in
my download bash file for zeroconf) it is ok.

Max






--
View this message in context: http://forum.world.st/Substitution-of-to-in-TextEditor-shiftEnclose-tp4775052p4775087.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.





--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Henrik Sperre Johansen
In reply to this post by Nicolas Cellier

On 27 Aug 2014, at 9:19 , Nicolas Cellier <[hidden email]> wrote:

I don't remember how the issue ended, or even if it properly ended...
(That's where an issue tracker should shine, but Squeak one is not really used/maintained).

That’s not really a bug in the VM or anything, but a lossy translation from Ctrl -> Shift + Alt in the image…
Only the modifier keys are … modified, while the key character is left unchanged.
Thus, when one uses Ctrl + ‘ (on those layouts where " is its shifted value), the = ‘ ifTrue: [:= "] part is a hack around that, hardcoded to a single layout. 
When using Shift + ‘ , the VM return the keyValue of ", and no translation is needed.

My 2C: Remove the workarounds, as well as the option of translating Ctrl -> Shift + Alt.
In order for it to work *properly* without external hacks, you’d need to implement all keyboard layouts image side, and translate the key character as well as modifier keys. 
The alternative would be to change the VM to include the properly shifted character in each keyboard event, which seems a bit excessive for supporting such a feature. (If such support functions even exist)

Cheers,
Henry


signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

Henrik Sperre Johansen

On 28 Aug 2014, at 10:58 , Henrik Johansen <[hidden email]> wrote:


On 27 Aug 2014, at 9:19 , Nicolas Cellier <[hidden email]> wrote:

I don't remember how the issue ended, or even if it properly ended...
(That's where an issue tracker should shine, but Squeak one is not really used/maintained).

That’s not really a bug in the VM or anything, but a lossy translation from Ctrl -> Shift + Alt in the image…
Only the modifier keys are … modified, while the key character is left unchanged.
Thus, when one uses Ctrl + ‘ (on those layouts where " is its shifted value), the = ‘ ifTrue: [:= "] part is a hack around that, hardcoded to a single layout. 
When using Shift + ‘ , the VM return the keyValue of ", and no translation is needed.

My 2C: Remove the workarounds, as well as the option of translating Ctrl -> Shift + Alt.
In order for it to work *properly* without external hacks, you’d need to implement all keyboard layouts image side, and translate the key character as well as modifier keys. 
The alternative would be to change the VM to include the properly shifted character in each keyboard event, which seems a bit excessive for supporting such a feature. (If such support functions even exist)

Cheers,
Henry


AFAICT, Pharo already removed this option, so removing shiftEnclose: shouldn’t have any nasty lingering side-effects.
It’s a relatively small change as well, I attached the .cs to the existing issue: 

Comments like these (from TextEditor >> initializeBasicShiftCmdKeyShortcuts) just make me wince:
"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.»

Why would you ever need use command + shift instead of just shift to make those characters? 
I guess Cmd -> Ctrl -> Shift + Alt might be an option in Squeak… but why not just use shift if that’s what you wanted in the first place?

(Full disclosure: on my keyboard layout, '(' is on 8)

Cheers,
Henry

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Substitution of ' to " in TextEditor>>shiftEnclose

J. Vuletich (mail lists)
In reply to this post by Eliot Miranda-2
Hi Folks,

(below)

Quoting Eliot Miranda <[hidden email]>:

> On Wed, Aug 27, 2014 at 4:27 PM, Nicolas Cellier
> <[hidden email]> 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

Thanks,
Juan Vuletich