w32-pass-rwindow-to-system

w32-pass-rwindow-to-system

[MON KEY]

Can anyone confirm if setting the following variables to `nil' is
working correctly on w32:

w32-pass-rwindow-to-system
w32-pass-lwindow-to-system

I have the following set and working as expected for multi key sequences:
(setq-default w32-lwindow-modifier 'super
w32-rwindow-modifier 'hyper)

E.g.  s-s and H-s return `*-s is undefined' in the minibuffer
 So, I know that Emacs is catching on <super> and <hyper> key sequences.

Is it normal/expected behavior for the w32 System to open 'Start' on
vanilla lwindow rwindow key preses without a modifer?
The docstring on the respective functions shows that this is a fairly
low level interaction and suggests looking at the
`w32-phantom-key-code' docs. The docs suggest that Emacs is passing a
"phantom" type values when pressing lwindow rwindow while Emacs is
active.

C-h v w32-phantom-key-code shows my system with the value of
`w32-phantom-key-code' at 255.

System is:
GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)  of 2008-10-23 on
LENNART-69DE564 (patched)
CUA is not enabled.
Using Happy Hacking Keyboard Lite with dipswitches set to 1101 i.e.
[win][alt][space][alt][win] config.

Re: w32-pass-rwindow-to-system

[Juanma Barranquero]

On Wed, Jan 21, 2009 at 02:57, MON KEY <monkey@sandpframing.com> wrote:

> Is it normal/expected behavior for the w32 System to open 'Start' on
> vanilla lwindow rwindow key preses without a modifer?

With w32-pass-[lr]window-to-system set to nil, pressing either Windows
key does not open the Start menu (while Emacs is the active app, of
course).

> System is:
> GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)  of 2008-10-23 on
> LENNART-69DE564 (patched)

Lennart's EmacsW32 has changes to the keyboard handling stuff. Does
happen to you with the non-patched version?

    Juanma

Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Jan 21, 2009 at 02:57, MON KEY <monkey@sandpframing.com> wrote:
>
>> Is it normal/expected behavior for the w32 System to open 'Start' on
>> vanilla lwindow rwindow key preses without a modifer?
>
> With w32-pass-[lr]window-to-system set to nil, pressing either Windows
> key does not open the Start menu (while Emacs is the active app, of
> course).

This is not guaranteed according to MS documentation.

With the patched version of Emacs+EmacsW32 this should work, but only
if you follow the extra documentation there. Just setting
w32-pass-[lr]window-to-system is not enough.

>> System is:
>> GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)  of 2008-10-23 on
>> LENNART-69DE564 (patched)
>
> Lennart's EmacsW32 has changes to the keyboard handling stuff. Does
> happen to you with the non-patched version?

Re: w32-pass-rwindow-to-system

[Juanma Barranquero]

On Wed, Jan 21, 2009 at 10:48, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> This is not guaranteed according to MS documentation.
>
> With the patched version of Emacs+EmacsW32 this should work, but only
> if you follow the extra documentation there. Just setting
> w32-pass-[lr]window-to-system is not enough.

OK, let's say this: I set both variables to nil, I use lwindow for
super- modifier and rwindow for hyper- modifier, super- and hyper-
keybindings work OK, pressing lwindow or rwindow alone does not open
Start.

In fact, my whole w32 key-related config is:

  (setq w32-lwindow-modifier                  'super
        w32-rwindow-modifier                  'hyper
        w32-pass-lwindow-to-system            nil
        w32-pass-rwindow-to-system            nil
        w32-pass-multimedia-buttons-to-system nil)

If the OP sees something different, that seems like a bug (or a
feature) of EmacsW32.

    Juanma

Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Wed, Jan 21, 2009 at 10:55 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Jan 21, 2009 at 10:48, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> This is not guaranteed according to MS documentation.
>>
>> With the patched version of Emacs+EmacsW32 this should work, but only
>> if you follow the extra documentation there. Just setting
>> w32-pass-[lr]window-to-system is not enough.
>
> OK, let's say this: I set both variables to nil, I use lwindow for
> super- modifier and rwindow for hyper- modifier, super- and hyper-
> keybindings work OK, pressing lwindow or rwindow alone does not open
> Start.
>
> In fact, my whole w32 key-related config is:
>
>  (setq w32-lwindow-modifier                  'super
>        w32-rwindow-modifier                  'hyper
>        w32-pass-lwindow-to-system            nil
>        w32-pass-rwindow-to-system            nil
>        w32-pass-multimedia-buttons-to-system nil)
>
> If the OP sees something different, that seems like a bug (or a
> feature) of EmacsW32.

No. I have said numerous times that this is a bug in Emacs. It might
work (as for you), but it is not guaranteed to do it.

Re: w32-pass-rwindow-to-system

[Juanma Barranquero]

On Wed, Jan 21, 2009 at 11:12, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> No. I have said numerous times that this is a bug in Emacs. It might
> work (as for you), but it is not guaranteed to do it.

Doesn't seem to be many bug reports about it, so if this is a real
problem, it's quite infrequent.

But, in any case, if it *is* a real problem, please send a patch.
AFAIR, you have a keyboard related patch, but it is not a bug fix; it
adds functionality. Am I remembering correctly?

    Juanma

Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Wed, Jan 21, 2009 at 11:26 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Jan 21, 2009 at 11:12, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> No. I have said numerous times that this is a bug in Emacs. It might
>> work (as for you), but it is not guaranteed to do it.
>
> Doesn't seem to be many bug reports about it, so if this is a real
> problem, it's quite infrequent.
>
> But, in any case, if it *is* a real problem, please send a patch.
> AFAIR, you have a keyboard related patch, but it is not a bug fix; it
> adds functionality. Am I remembering correctly?

I have done several patches to the keyboard and menu code. The one we
are talking about here is a bug fix IMO.

At the moment I do not have time to dig out that part. I have spent
quite a lot of time trying to get this fix into Emacs, but the
resistance has been too strong for the limited time I have so I have
run out of time for this. (Feel free to grab the patch from my
patches.)

Beside this anyone who want this to work can use the patched version
of Emacs+EmacsW32. (If there is any bug there I will of course fix
it.)

Re: w32-pass-rwindow-to-system

[Juanma Barranquero]

On Wed, Jan 21, 2009 at 11:59, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I have done several patches to the keyboard and menu code. The one we
> are talking about here is a bug fix IMO.

A pointer to it?

> At the moment I do not have time to dig out that part. I have spent
> quite a lot of time trying to get this fix into Emacs, but the
> resistance has been too strong for the limited time I have so I have
> run out of time for this.

"[T]he resistance has been too strong" is loaded language. Nobody
would argue against a correct, clean fix for a known bug. So, either
the bug is not acknowledged as such by everybody involved, or the
patch was not deemed correct, or clean. (For any other possibilities
I'm leaving out, please explain.)

> (Feel free to grab the patch from my
> patches.)
>
> Beside this anyone who want this to work can use the patched version
> of Emacs+EmacsW32. (If there is any bug there I will of course fix
> it.)

This seems like you were saying that you can't bother to get the patch
into the repository, but you don't mind if others pick the pieces. Not
very encouraging.

There's another posibility: open a bug report, post your patch
(against the current sources), let the bug discussion follow its
natural flow.

    Juanma

Re: w32-pass-rwindow-to-system

[grischka]

Juanma Barranquero wrote:
> "[T]he resistance has been too strong" is loaded language. Nobody
> would argue against a correct, clean fix for a known bug.

That is definitely an highly optimistic point of view.  I've seen
people here fighting to protect their bugs against fixes by any
means including obviously false arguments or even loss in common
standards of politeness.

Reason seems to be that bugs like any code are considered copyrighted
work and the only way for people to gain credit in an unpaid project is
to see their work included in history.  And of course bugs will produce
more feedback by far than something that works flawlessly.

So why should anyone be interested to throw away own work that is so
well suited to get attention of the world as are bugs?

Re: w32-pass-rwindow-to-system

[Jason Rumney]

Lennart Borgman wrote:
> At the moment I do not have time to dig out that part. I have spent
> quite a lot of time trying to get this fix into Emacs, but the
> resistance has been too strong for the limited time I have so I have
> run out of time for this. (Feel free to grab the patch from my
> patches.)
>   

You have never once made the effort to separate out the bugfixes from 
your extensive patch that modifies a number of unrelated aspects of 
Emacs behaviour. Are you surprised that there is resistance when we 
always get told "take it all or sort through it yourself"?

Re: w32-pass-rwindow-to-system

[Juanma Barranquero]

On Wed, Jan 21, 2009 at 14:05, grischka <grishka@gmx.de> wrote:

> That is definitely an highly optimistic point of view.

Hmm... well, OK ;-)

> I've seen
> people here fighting to protect their bugs against fixes by any
> means including obviously false arguments or even loss in common
> standards of politeness.

I don't remember obviously false arguments (in the sense of the poster
knowing that they are false), though I've seen "loss [...] of
politeness" a few times.

> Reason seems to be that bugs like any code are considered copyrighted
> work and the only way for people to gain credit in an unpaid project is
> to see their work included in history.  And of course bugs will produce
> more feedback by far than something that works flawlessly.
>
> So why should anyone be interested to throw away own work that is so
> well suited to get attention of the world as are bugs?

Sorry, I'm unable to take such a cynical view of Emacs development.
Perhaps you're right by calling me "highly optimistic".

    Juanma

Re: w32-pass-rwindow-to-system

[Juanma Barranquero]

On Wed, Jan 21, 2009 at 15:09, Jason Rumney <jasonr@gnu.org> wrote:

> You have never once made the effort to separate out the bugfixes from your
> extensive patch that modifies a number of unrelated aspects of Emacs
> behaviour. Are you surprised that there is resistance when we always get
> told "take it all or sort through it yourself"?

My point exactly.

    Juanma

Re: w32-pass-rwindow-to-system

[Jason Rumney]

Lennart Borgman wrote:
> On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
>   
>> With w32-pass-[lr]window-to-system set to nil, pressing either Windows
>> key does not open the Start menu (while Emacs is the active app, of
>> course).
>>     
>
> This is not guaranteed according to MS documentation.
>   

Do you have an example where it specifically mentions that it won't 
work, or are you meaning the lack of Microsoft documentation regarding 
Windows key handling means it might not be guaranteed?

AFAIK, the current workaround was discovered by Andrew Innes after much 
experimentation when the MS docs were found inadequate, and this is the 
first bug report I have seen saying that it doesn't work for suppressing 
the Start Menu as documented. But since the user is using your patched 
version, I can only suppose that it is your changes to low level Windows 
key handling that are causing this problem.

Re: w32-pass-rwindow-to-system

[grischka]

Juanma Barranquero wrote:
> On Wed, Jan 21, 2009 at 14:05, grischka <grishka@gmx.de> wrote:
>> [...]
>> So why should anyone be interested to throw away own work that is so
>> well suited to get attention of the world as are bugs?
> 
> Sorry, I'm unable to take such a cynical view of Emacs development.
> Perhaps you're right by calling me "highly optimistic".
> 
>     Juanma

Well, of course it goes without saying that no bug can draw attention
unless it's embedded with a good bunch of features that keep the
program quite usable, still ;)

--- grischka

Re: w32-pass-rwindow-to-system

[MON KEY]

I apologize for the commotion.

I forgot to mention in the OP that I am running XKeymacs Version 3.47.
 Xkeymacs is not active (disabled) when Emacs is active.

After exiting XKeymacs completely everything works as expected and
Emacs catches the Windows keypresses before they hit the system.

So, presumably XKeymacs isn't completely disabling when it
`deactivates' when i switch into Emacs :(


On Wed, Jan 21, 2009 at 9:23 AM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <lekktu@gmail.com>
>> wrote:
>>
>>>
>>> With w32-pass-[lr]window-to-system set to nil, pressing either Windows
>>> key does not open the Start menu (while Emacs is the active app, of
>>> course).
>>>
>>
>> This is not guaranteed according to MS documentation.
>>
>
> Do you have an example where it specifically mentions that it won't work, or
> are you meaning the lack of Microsoft documentation regarding Windows key
> handling means it might not be guaranteed?
>
> AFAIK, the current workaround was discovered by Andrew Innes after much
> experimentation when the MS docs were found inadequate, and this is the
> first bug report I have seen saying that it doesn't work for suppressing the
> Start Menu as documented. But since the user is using your patched version,
> I can only suppose that it is your changes to low level Windows key handling
> that are causing this problem.
>
>
>
>

Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Wed, Jan 21, 2009 at 3:23 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <lekktu@gmail.com>
>> wrote:
>>
>>>
>>> With w32-pass-[lr]window-to-system set to nil, pressing either Windows
>>> key does not open the Start menu (while Emacs is the active app, of
>>> course).
>>>
>>
>> This is not guaranteed according to MS documentation.
>>
>
> Do you have an example where it specifically mentions that it won't work, or
> are you meaning the lack of Microsoft documentation regarding Windows key
> handling means it might not be guaranteed?

When we discussed this 3.5 y ago before I implemented this in the
patched version of Emacs+EmacsW32 I sent a an url with a simple
overview of the different techniques that MS have made available for
handling things like this. All the older versions where rather bad in
my opinion, but with lowlevel keyboard hooks they got it right.

I do not remember now, but I believe the "references" links at the
bottom of that page goes to more documentation like descriptions.
Otherwise just look for LowLevelKeyboardProc in msdn.

 Here is the thread and the url to the overview:

  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00448.html
  http://www.codeproject.com/KB/winsdk/AntonioWinLock.aspx

> AFAIK, the current workaround was discovered by Andrew Innes after much
> experimentation when the MS docs were found inadequate, and this is the
> first bug report I have seen saying that it doesn't work for suppressing the
> Start Menu as documented. But since the user is using your patched version,
> I can only suppose that it is your changes to low level Windows key handling
> that are causing this problem.

It might be that the lowlevel keyboard hooks where not available when
Andrew did this. I think they first showed up in W2k.

Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Wed, Jan 21, 2009 at 3:09 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> At the moment I do not have time to dig out that part. I have spent
>> quite a lot of time trying to get this fix into Emacs, but the
>> resistance has been too strong for the limited time I have so I have
>> run out of time for this. (Feel free to grab the patch from my
>> patches.)
>>
>
> You have never once made the effort to separate out the bugfixes from your
> extensive patch that modifies a number of unrelated aspects of Emacs
> behaviour. Are you surprised that there is resistance when we always get
> told "take it all or sort through it yourself"?

I looked through what I wrote and maybe you are right, see this thread:

  http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01604.html

As you can see in this last message there where quite a few things fixed there.

I am not sure how to proceed. I think it all should go in one parcel.
You may of course have comments on my coding style etc. Feel free to
comment on that.

Since this has been in use for 3 y now I think it could be considered
rather stable.

The best way to get the patch now is from the patch I upload for
Emacs+EmacsW32. It is the files

  src/w32fns.c
  src/w32menu.c
  src/w32term.h
  w32-meta.el (new, not in the patch)

The latest patch is from 2009-01-15. The patches are here

  http://ourcomments.org/Emacs/DL/EmacsW32/src/

Re: w32-pass-rwindow-to-system

[MON KEY]

I've been playing around more with the super and hyper assigned to
[lr]windows key.  One thing that still isn't working on my systems is
(with or without XKeymacs) is s-Tab H-Tab... which BTW is the reason i
started mucking around for additional prefix modifiers in teh first
place as ALT-TAB is not easily (nor effectively) overridden by Emacs
on w32.

Likewise, this has become more of an issue with the most recent
versions of GNOME as well

The need to reasonably bind super and hyper is definitely an issue in
SCM libraries like DVC where the binding has an immediate use case.

Presumably this particular issue will resurface quite a bit in the
coming months with the switch to Bazaar and others on w32 will start
looking for a better  way to rebind super than:

;;; C-x @ s		event-apply-super-modifier
;;; C-x @ h		event-apply-hyper-modifier


On Wed, Jan 21, 2009 at 4:58 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Wed, Jan 21, 2009 at 3:23 PM, Jason Rumney <jasonr@gnu.org> wrote:
>> Lennart Borgman wrote:
>>>
>>> On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <lekktu@gmail.com>
>>> wrote:
>>>
>>>>
>>>> With w32-pass-[lr]window-to-system set to nil, pressing either Windows
>>>> key does not open the Start menu (while Emacs is the active app, of
>>>> course).
>>>>
>>>
>>> This is not guaranteed according to MS documentation.
>>>
>>
>> Do you have an example where it specifically mentions that it won't work, or
>> are you meaning the lack of Microsoft documentation regarding Windows key
>> handling means it might not be guaranteed?
>
> When we discussed this 3.5 y ago before I implemented this in the
> patched version of Emacs+EmacsW32 I sent a an url with a simple
> overview of the different techniques that MS have made available for
> handling things like this. All the older versions where rather bad in
> my opinion, but with lowlevel keyboard hooks they got it right.
>
> I do not remember now, but I believe the "references" links at the
> bottom of that page goes to more documentation like descriptions.
> Otherwise just look for LowLevelKeyboardProc in msdn.
>
>  Here is the thread and the url to the overview:
>
>  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00448.html
>  http://www.codeproject.com/KB/winsdk/AntonioWinLock.aspx
>
>> AFAIK, the current workaround was discovered by Andrew Innes after much
>> experimentation when the MS docs were found inadequate, and this is the
>> first bug report I have seen saying that it doesn't work for suppressing the
>> Start Menu as documented. But since the user is using your patched version,
>> I can only suppose that it is your changes to low level Windows key handling
>> that are causing this problem.
>
> It might be that the lowlevel keyboard hooks where not available when
> Andrew did this. I think they first showed up in W2k.
>

Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Thu, Jan 22, 2009 at 12:03 AM, MON KEY <monkey@sandpframing.com> wrote:
> I've been playing around more with the super and hyper assigned to
> [lr]windows key.  One thing that still isn't working on my systems is
> (with or without XKeymacs) is s-Tab H-Tab... which BTW is the reason i
> started mucking around for additional prefix modifiers in teh first
> place as ALT-TAB is not easily (nor effectively) overridden by Emacs
> on w32.

Not quite sure now, but I believe that ALT-TAB can not be overriden on
w32. Not even with a low-level keyboard hook.

That was one of the reason for me to write the patch I mentioned
elsewhere in this thread. I use the windows keys as meta.

> Likewise, this has become more of an issue with the most recent
> versions of GNOME as well
>
> The need to reasonably bind super and hyper is definitely an issue in
> SCM libraries like DVC where the binding has an immediate use case.
>
> Presumably this particular issue will resurface quite a bit in the
> coming months with the switch to Bazaar and others on w32 will start
> looking for a better  way to rebind super than:
>
> ;;; C-x @ s             event-apply-super-modifier
> ;;; C-x @ h             event-apply-hyper-modifier
>
>
> On Wed, Jan 21, 2009 at 4:58 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Wed, Jan 21, 2009 at 3:23 PM, Jason Rumney <jasonr@gnu.org> wrote:
>>> Lennart Borgman wrote:
>>>>
>>>> On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <lekktu@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> With w32-pass-[lr]window-to-system set to nil, pressing either Windows
>>>>> key does not open the Start menu (while Emacs is the active app, of
>>>>> course).
>>>>>
>>>>
>>>> This is not guaranteed according to MS documentation.
>>>>
>>>
>>> Do you have an example where it specifically mentions that it won't work, or
>>> are you meaning the lack of Microsoft documentation regarding Windows key
>>> handling means it might not be guaranteed?
>>
>> When we discussed this 3.5 y ago before I implemented this in the
>> patched version of Emacs+EmacsW32 I sent a an url with a simple
>> overview of the different techniques that MS have made available for
>> handling things like this. All the older versions where rather bad in
>> my opinion, but with lowlevel keyboard hooks they got it right.
>>
>> I do not remember now, but I believe the "references" links at the
>> bottom of that page goes to more documentation like descriptions.
>> Otherwise just look for LowLevelKeyboardProc in msdn.
>>
>>  Here is the thread and the url to the overview:
>>
>>  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00448.html
>>  http://www.codeproject.com/KB/winsdk/AntonioWinLock.aspx
>>
>>> AFAIK, the current workaround was discovered by Andrew Innes after much
>>> experimentation when the MS docs were found inadequate, and this is the
>>> first bug report I have seen saying that it doesn't work for suppressing the
>>> Start Menu as documented. But since the user is using your patched version,
>>> I can only suppose that it is your changes to low level Windows key handling
>>> that are causing this problem.
>>
>> It might be that the lowlevel keyboard hooks where not available when
>> Andrew did this. I think they first showed up in W2k.
>>
>
>
>