subject:"\[racket\-users\] Re\: custom keybindings \(AltGr\)"

Re: [racket-users] Re: custom keybindings (AltGr)

2016-03-20 Thread Bert De Ketelaere

Everything works as expected.  Thanks!


Van: racket-users@googlegroups.com <racket-users@googlegroups.com> namens 
Matthew Flatt <mfl...@cs.utah.edu>
Verzonden: vrijdag 18 maart 2016 2:09
Aan: Bert De Ketelaere
CC: us...@racket-lang.org
Onderwerp: Re: [racket-users] Re: custom keybindings (AltGr)

I think the issue with Control-Alt-a is that Control-a is mapped to
"beginning-of-line" as "c:a". Probably that should be ":c:a".

A "c:a" binding doesn't show up in the keybindings dialog for Windows,
but it does for OS X. My guess is that the keybindings list is filtered
to omit combinations that are shadowed by menu shortcuts (even though I
have menu shortcuts disabled on Windows). The menu shortcut for "Select
All" is actually ":c:a", so that shortcut only partly shadows "c:a".
Then again, the "c:u" and "c:n" combinations do show up in the
keybindings dialog, so maybe my guess isn't quite right.

In any case, I've pushed the changes. When you start using the latest
(e.g., with the next snapshot build or later), you could go to
"Editing" -> "General Editing" in the preferences dialog, select "Treat
Control-Alt combination as AltGr", and then make sure things work as
expected.

At Thu, 17 Mar 2016 08:58:01 +, Bert De Ketelaere wrote:
> Hello,
>
> this does everything I want.
> The only difference is between your implementation and what I previously had
> done is that Ctrl+Alt+q is treated the same as AltGr+q (with the latter being
> a custom keybinding defined with "g:q").  I don't really care about this, but
> I thought it was nice that they were two distinct events.
>
> Looking deeper into this, there is some other weirdness, using your file (I've
> abandoned mine):
> for Ctrl+Alt+a, u or n doesn't produce anything
>   Ctrl+Alt+z, m  just prints z or m
>   Ctrl+Alt+t l ... opens menu Tabs, Language etc...
> It's the difference between the first two that surprises me.
> But defining "g:u" "g:n" "g:z" "g:t" ... as keybindings to some other letter
> works fine (with AltGr or Ctrl+Alt)
> Except for "g:a" or "c:m:a".  I can't find any reason why "a" is treated
> differently (if I look in the keybindings menu it doesn't seem different from
> for example "z".  Both have only one binding "c:z" for undo and "c:a" for
> select all.)
>
> The difference between these letters was also there when using the old key.rkt
>
> I'm using latest snapshot ( version 6.4.0.14--2016-03-16(d27bf66/a) [3m]) and
> following keybindings
> #lang s-exp framework/keybinding-lang
> (keybinding "g:q" (λ (x y) (send x insert #\◊)))
> (keybinding "g:a" (λ (x y) (send x insert #\A)))
>
> to test different keybindings.
> I also noticed that a "c:m:q" always trumps a "g:q" binding regardless of
> order.
> and a "g:q" always trumps "c:m:~g:q" (regardless of Ctrl+Alt or AltGr
> combination)
>
> Thanks for the file.  For what I want, it works just fine.
> Kind regards,
> Bert
> 
> Van: racket-users@googlegroups.com <racket-users@googlegroups.com> namens
> Matthew Flatt <mfl...@cs.utah.edu>
> Verzonden: donderdag 17 maart 2016 1:34
> Aan: Bert De Ketelaere
> CC: us...@racket-lang.org
> Onderwerp: Re: [racket-users] Re: custom keybindings (AltGr)
>
> Thanks for the helpful table!
>
> The problem with Control combinations was a mistake in my code, fixed
> in the enclosed "key.rkt".
>
> The problem with dead keys was harder. It seems that ToUnicode() has
> the same effect as TranslateEvent() for dead-key combinations, so using
> ToUnicode() multiple times and in addition to TranslateEvent() triggers
> the extra accents in your experiments. My new attempt uses ToUnicode()
> only when it's in a position to cancel a TranslateEvent() call ---
> which is always the case when we first want to get its result  and
> records the result instead of calling ToUnicode() again later.
>
> At Wed, 16 Mar 2016 08:53:48 +, Bert De Ketelaere wrote:
> > Thanks for looking into this!  My implementation worked somewhat, but I was
> > indeed not happy with the way I solved it. (State and losing the key release
> > events)
> > Just to be sure, I updated my patch a week ago for some errors I found in my
> > handling of key-events, the table below is based on that revision.
> >
> >
> >       old
> > bdeket mflat  desired
> > AltGr+qcustom keybinding   ◊  ◊  ◊

Re: [racket-users] Re: custom keybindings (AltGr)

2016-03-19 Thread Robby Findler

On Thu, Mar 17, 2016 at 8:09 PM, Matthew Flatt  wrote:
> A "c:a" binding doesn't show up in the keybindings dialog for Windows,
> but it does for OS X.

I've pushed a fix this. Thanks!

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: custom keybindings (AltGr)

2016-03-19 Thread Bert De Ketelaere

Hello,

this does everything I want.
The only difference is between your implementation and what I previously had 
done is that Ctrl+Alt+q is treated the same as AltGr+q (with the latter being a 
custom keybinding defined with "g:q").  I don't really care about this, but I 
thought it was nice that they were two distinct events.

Looking deeper into this, there is some other weirdness, using your file (I've 
abandoned mine):
for Ctrl+Alt+a, u or n doesn't produce anything
  Ctrl+Alt+z, m  just prints z or m
  Ctrl+Alt+t l ... opens menu Tabs, Language etc...
It's the difference between the first two that surprises me.
But defining "g:u" "g:n" "g:z" "g:t" ... as keybindings to some other letter 
works fine (with AltGr or Ctrl+Alt)
Except for "g:a" or "c:m:a".  I can't find any reason why "a" is treated 
differently (if I look in the keybindings menu it doesn't seem different from 
for example "z".  Both have only one binding "c:z" for undo and "c:a" for 
select all.)

The difference between these letters was also there when using the old key.rkt

I'm using latest snapshot ( version 6.4.0.14--2016-03-16(d27bf66/a) [3m]) and 
following keybindings
#lang s-exp framework/keybinding-lang
(keybinding "g:q" (λ (x y) (send x insert #\◊)))
(keybinding "g:a" (λ (x y) (send x insert #\A)))

to test different keybindings.
I also noticed that a "c:m:q" always trumps a "g:q" binding regardless of order.
and a "g:q" always trumps "c:m:~g:q" (regardless of Ctrl+Alt or AltGr 
combination)

Thanks for the file.  For what I want, it works just fine.
Kind regards,
Bert

Van: racket-users@googlegroups.com <racket-users@googlegroups.com> namens 
Matthew Flatt <mfl...@cs.utah.edu>
Verzonden: donderdag 17 maart 2016 1:34
Aan: Bert De Ketelaere
CC: us...@racket-lang.org
Onderwerp: Re: [racket-users] Re: custom keybindings (AltGr)

Thanks for the helpful table!

The problem with Control combinations was a mistake in my code, fixed
in the enclosed "key.rkt".

The problem with dead keys was harder. It seems that ToUnicode() has
the same effect as TranslateEvent() for dead-key combinations, so using
ToUnicode() multiple times and in addition to TranslateEvent() triggers
the extra accents in your experiments. My new attempt uses ToUnicode()
only when it's in a position to cancel a TranslateEvent() call ---
which is always the case when we first want to get its result  and
records the result instead of calling ToUnicode() again later.

At Wed, 16 Mar 2016 08:53:48 +, Bert De Ketelaere wrote:
> Thanks for looking into this!  My implementation worked somewhat, but I was
> indeed not happy with the way I solved it. (State and losing the key release
> events)
> Just to be sure, I updated my patch a week ago for some errors I found in my
> handling of key-events, the table below is based on that revision.
>
>
>       old
> bdeket mflat  desired
> AltGr+qcustom keybinding   ◊  ◊  ◊
>   
> Ctrl+Alt+q q  q  ◊  q  (normal is nothing)
>
> AltGr+<keyboard layout   \  \  \  \   
> Ctrl+Alt+< <  \  \  \
> AltGr+ùkeyboard layout
> dead key
>      ù  ´´     (my patch does 
> this ok if
> ù without modifier is used before ù with modifier, so it deserves some points,
> but probably negative ones, because of its inconsistency)
> followed by space
> ´  ù´ ´´´´
> followed by a
> á  ùá ´´áá
> AltGr+ekeyboard layout   €  €  €  €  (I 
> would
> expect the menu only to open for Alt+e)
> 
> Ctr+Alt+e  
> €  €  €
> Ctr+s  save              
> Ctrl+c copy              
> Alt+arrowright jump to end s-expr
>             
> Ctrl+Arrowright
> jump to end word
>             
>
>
> I'll look at your code when I have more time tomorrow or this weekend.
>
>
> Thanks again,
>
> Bert
>
> 
> Van: racket-users@googlegroups.com <racket-users@googlegroups.com> namens
> Matthew Flatt <mfl...@cs.utah.edu>
> Verzonden: woensdag 16 maart 2016 4:09
> Aan: Bert De Ketelaere
> CC: us...@racket-lang.org
> Onderwerp: Re: [racket-users] Re: custom keybindings (AltGr)
>
> Thanks for looking into this problem in depth! Although I'll suggest an
> alternate implementation, your patch was helpful for me to understand
> the problems and goals.
>
> To

Re: [racket-users] Re: custom keybindings (AltGr)

2016-03-19 Thread Matthew Flatt

I think the issue with Control-Alt-a is that Control-a is mapped to
"beginning-of-line" as "c:a". Probably that should be ":c:a". 

A "c:a" binding doesn't show up in the keybindings dialog for Windows,
but it does for OS X. My guess is that the keybindings list is filtered
to omit combinations that are shadowed by menu shortcuts (even though I
have menu shortcuts disabled on Windows). The menu shortcut for "Select
All" is actually ":c:a", so that shortcut only partly shadows "c:a".
Then again, the "c:u" and "c:n" combinations do show up in the
keybindings dialog, so maybe my guess isn't quite right.

In any case, I've pushed the changes. When you start using the latest
(e.g., with the next snapshot build or later), you could go to
"Editing" -> "General Editing" in the preferences dialog, select "Treat
Control-Alt combination as AltGr", and then make sure things work as
expected.

At Thu, 17 Mar 2016 08:58:01 +, Bert De Ketelaere wrote:
> Hello,
> 
> this does everything I want.
> The only difference is between your implementation and what I previously had 
> done is that Ctrl+Alt+q is treated the same as AltGr+q (with the latter being 
> a custom keybinding defined with "g:q").  I don't really care about this, but 
> I thought it was nice that they were two distinct events.
> 
> Looking deeper into this, there is some other weirdness, using your file 
> (I've 
> abandoned mine):
> for Ctrl+Alt+a, u or n doesn't produce anything
>   Ctrl+Alt+z, m  just prints z or m
>   Ctrl+Alt+t l ... opens menu Tabs, Language etc...
> It's the difference between the first two that surprises me.
> But defining "g:u" "g:n" "g:z" "g:t" ... as keybindings to some other letter 
> works fine (with AltGr or Ctrl+Alt)
> Except for "g:a" or "c:m:a".  I can't find any reason why "a" is treated 
> differently (if I look in the keybindings menu it doesn't seem different from 
> for example "z".  Both have only one binding "c:z" for undo and "c:a" for 
> select all.)
> 
> The difference between these letters was also there when using the old key.rkt
> 
> I'm using latest snapshot ( version 6.4.0.14--2016-03-16(d27bf66/a) [3m]) and 
> following keybindings
> #lang s-exp framework/keybinding-lang
> (keybinding "g:q" (λ (x y) (send x insert #\◊)))
> (keybinding "g:a" (λ (x y) (send x insert #\A)))
> 
> to test different keybindings.
> I also noticed that a "c:m:q" always trumps a "g:q" binding regardless of 
> order.
> and a "g:q" always trumps "c:m:~g:q" (regardless of Ctrl+Alt or AltGr 
> combination)
> 
> Thanks for the file.  For what I want, it works just fine.
> Kind regards,
> Bert
> 
> Van: racket-users@googlegroups.com <racket-users@googlegroups.com> namens 
> Matthew Flatt <mfl...@cs.utah.edu>
> Verzonden: donderdag 17 maart 2016 1:34
> Aan: Bert De Ketelaere
> CC: us...@racket-lang.org
> Onderwerp: Re: [racket-users] Re: custom keybindings (AltGr)
> 
> Thanks for the helpful table!
> 
> The problem with Control combinations was a mistake in my code, fixed
> in the enclosed "key.rkt".
> 
> The problem with dead keys was harder. It seems that ToUnicode() has
> the same effect as TranslateEvent() for dead-key combinations, so using
> ToUnicode() multiple times and in addition to TranslateEvent() triggers
> the extra accents in your experiments. My new attempt uses ToUnicode()
> only when it's in a position to cancel a TranslateEvent() call ---
> which is always the case when we first want to get its result  and
> records the result instead of calling ToUnicode() again later.
> 
> At Wed, 16 Mar 2016 08:53:48 +, Bert De Ketelaere wrote:
> > Thanks for looking into this!  My implementation worked somewhat, but I was
> > indeed not happy with the way I solved it. (State and losing the key release
> > events)
> > Just to be sure, I updated my patch a week ago for some errors I found in my
> > handling of key-events, the table below is based on that revision.
> >
> >
> >       old
> > bdeket mflat  desired
> > AltGr+qcustom keybinding   ◊  ◊  ◊  
> > 
> > Ctrl+Alt+q q  q  ◊  q  (normal is nothing)
> >
> > AltGr+<keyboard layout   \  \  \  \   
> > Ctrl+Alt+< <  \  \  \
> > AltGr+ùkeyboard layout
> > d

Re: [racket-users] Re: custom keybindings (AltGr)

2016-03-19 Thread Matthew Flatt

Thanks for the helpful table!

The problem with Control combinations was a mistake in my code, fixed
in the enclosed "key.rkt".

The problem with dead keys was harder. It seems that ToUnicode() has
the same effect as TranslateEvent() for dead-key combinations, so using
ToUnicode() multiple times and in addition to TranslateEvent() triggers
the extra accents in your experiments. My new attempt uses ToUnicode()
only when it's in a position to cancel a TranslateEvent() call ---
which is always the case when we first want to get its result  and
records the result instead of calling ToUnicode() again later.

At Wed, 16 Mar 2016 08:53:48 +, Bert De Ketelaere wrote:
> Thanks for looking into this!  My implementation worked somewhat, but I was 
> indeed not happy with the way I solved it. (State and losing the key release 
> events)
> Just to be sure, I updated my patch a week ago for some errors I found in my 
> handling of key-events, the table below is based on that revision.
> 
> 
>       old
> bdeket mflat  desired
> AltGr+qcustom keybinding   ◊  ◊  ◊
>   
> Ctrl+Alt+q q  q  ◊  q  (normal is nothing)
> 
> AltGr+<keyboard layout   \  \  \  \   
> Ctrl+Alt+< <  \  \  \
> AltGr+ùkeyboard layout
> dead key
>      ù  ´´     (my patch does 
> this ok if 
> ù without modifier is used before ù with modifier, so it deserves some 
> points, 
> but probably negative ones, because of its inconsistency)
> followed by space
> ´  ù´ ´´´´
> followed by a
> á  ùá ´´áá
> AltGr+ekeyboard layout   €  €  €  €  (I 
> would 
> expect the menu only to open for Alt+e)
> 
> Ctr+Alt+e  
> €  €  €
> Ctr+s  save              
> Ctrl+c copy              
> Alt+arrowright jump to end s-expr
>             
> Ctrl+Arrowright
> jump to end word
>             
> 
> 
> I'll look at your code when I have more time tomorrow or this weekend.
> 
> 
> Thanks again,
> 
> Bert
> 
> 
> Van: racket-users@googlegroups.com <racket-users@googlegroups.com> namens 
> Matthew Flatt <mfl...@cs.utah.edu>
> Verzonden: woensdag 16 maart 2016 4:09
> Aan: Bert De Ketelaere
> CC: us...@racket-lang.org
> Onderwerp: Re: [racket-users] Re: custom keybindings (AltGr)
> 
> Thanks for looking into this problem in depth! Although I'll suggest an
> alternate implementation, your patch was helpful for me to understand
> the problems and goals.
> 
> To generate an event when AltGr- doesn't produce a character, I
> think a better approach here is to call ToUnicode(). That seems to work
> as a check for whether a meaning is assigned to a key combination. It
> avoids using state to try to match key-up events with key-down events,
> and it should work better with key repeats.
> 
> For making Ctl-Alt- work as AltGr-, I think I see what you want,
> based on how programs like Notepad interpret key combinations. I think
> other users will still want to distinguish Ctl-Alt- and AltGr-
> for keyboard shortcuts, though, along the same lines that Emacs
> distinguishes them. So we'll probably need to make that an option,
> similar to the `special-option-key` setting for OS X.
> 
> Can you try the enclosed "key.rkt" to see whether it works the way you
> want? This version defines `control+alt-always-as-altgr?` as #t to
> simulate an option for making Ctl-Alt- work as AltGr-.
> 
> At Mon, 7 Mar 2016 15:16:23 +, Bert De Ketelaere wrote:
> > Hello,
> >
> >
> > after looking around trying to fix my previous
> > 
> problem<https://groups.google.com/d/topic/racket-users/_1i-zcfBaaM/discussion>
> > I found that DrRacket really is not sending any event for AltGr+(Key x)
> > combinations if this combination doesn't actually produces a char.
> >
> > I tried changing the win32/key.rkt file in gui-lib so DrRacket would get 
> these
> > events and en passant I tried to make DrRacket behave more like other Win
> > programs when it comes to keyboard input.
> >
> >
> > my attempt is at:
> >
> > https://github.com/bdeket/gui/commit/994a5655a9f913b7388e0c74c1b6203659b645d3
> >
> >
> > A few problems remain:
> >
> > Ctrl+Alt+(key x): where this combination doesn't produce a char, x is 
> produced
> > instead of nothing
> >
> > Ctrl+Alt+(key x) or AltGr+(key x):

Re: [racket-users] Re: custom keybindings (AltGr)

2016-03-15 Thread Matthew Flatt

Thanks for looking into this problem in depth! Although I'll suggest an
alternate implementation, your patch was helpful for me to understand
the problems and goals.

To generate an event when AltGr- doesn't produce a character, I
think a better approach here is to call ToUnicode(). That seems to work
as a check for whether a meaning is assigned to a key combination. It
avoids using state to try to match key-up events with key-down events,
and it should work better with key repeats.

For making Ctl-Alt- work as AltGr-, I think I see what you want,
based on how programs like Notepad interpret key combinations. I think
other users will still want to distinguish Ctl-Alt- and AltGr-
for keyboard shortcuts, though, along the same lines that Emacs
distinguishes them. So we'll probably need to make that an option,
similar to the `special-option-key` setting for OS X.

Can you try the enclosed "key.rkt" to see whether it works the way you
want? This version defines `control+alt-always-as-altgr?` as #t to
simulate an option for making Ctl-Alt- work as AltGr-.

At Mon, 7 Mar 2016 15:16:23 +, Bert De Ketelaere wrote:
> Hello,
> 
> 
> after looking around trying to fix my previous 
> problem
>  
> I found that DrRacket really is not sending any event for AltGr+(Key x) 
> combinations if this combination doesn't actually produces a char.
> 
> I tried changing the win32/key.rkt file in gui-lib so DrRacket would get 
> these 
> events and en passant I tried to make DrRacket behave more like other Win 
> programs when it comes to keyboard input.
> 
> 
> my attempt is at:
> 
> https://github.com/bdeket/gui/commit/994a5655a9f913b7388e0c74c1b6203659b645d3
> 
> 
> A few problems remain:
> 
> Ctrl+Alt+(key x): where this combination doesn't produce a char, x is 
> produced 
> instead of nothing
> 
> Ctrl+Alt+(key x) or AltGr+(key x): the release event is now hijacked and 
> sends 
> another keypress-event.
> 
> This is a problem, but I don't know how to fix this, and I prefer this 
> over the previous state where key-events where ignored
> 
> 
> Unfortunately I didn't understand all the code that was already there, and I 
> didn't find standard tests to test this.
> 
> Are there tests for the key-events?
> 
> 
> Kind regards,
> 
> Bert
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

key.rkt
Description: Binary data

[racket-users] Re: custom keybindings (AltGr)

2016-03-07 Thread Bert De Ketelaere

Hello,


after looking around trying to fix my previous 
problem 
I found that DrRacket really is not sending any event for AltGr+(Key x) 
combinations if this combination doesn't actually produces a char.

I tried changing the win32/key.rkt file in gui-lib so DrRacket would get these 
events and en passant I tried to make DrRacket behave more like other Win 
programs when it comes to keyboard input.


my attempt is at:

https://github.com/bdeket/gui/commit/994a5655a9f913b7388e0c74c1b6203659b645d3


A few problems remain:

Ctrl+Alt+(key x): where this combination doesn't produce a char, x is produced 
instead of nothing

Ctrl+Alt+(key x) or AltGr+(key x): the release event is now hijacked and sends 
another keypress-event.

This is a problem, but I don't know how to fix this, and I prefer this over 
the previous state where key-events where ignored


Unfortunately I didn't understand all the code that was already there, and I 
didn't find standard tests to test this.

Are there tests for the key-events?


Kind regards,

Bert

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: custom keybindings (AltGr)

Re: [racket-users] Re: custom keybindings (AltGr)

Re: [racket-users] Re: custom keybindings (AltGr)

Re: [racket-users] Re: custom keybindings (AltGr)

Re: [racket-users] Re: custom keybindings (AltGr)

Re: [racket-users] Re: custom keybindings (AltGr)

[racket-users] Re: custom keybindings (AltGr)

7 matches

Site Navigation

Mail list logo

Footer information