w32-pass-lwindow-to-system does not work as expected

w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

When discussing AltGr I noticed that w32-pass-lwindow-to-system probably 
does not due what the author intended. The documentation is correct, no 
Start Menu is opened if the variable is nil. However I would believe 
that the author wanted to use this key in Emacs. It is however still not 
possible, the key is tighed to Explorer still.

To overcome this a low level keyboard hook must be used. A good starting 
point summary is found at 
http://www.codeproject.com/win32/AntonioWinLock.asp. Look under subtitle 
"Hooks".

This is of course applicable to the rwindow counterpart too. This also 
applies to the function w32-register-hot-key which is not able to 
register hot keys for those keys because they are already registered by 
Explorer.

I think the variables and the function should be either removed or the 
behavior corrected.

Re: w32-pass-lwindow-to-system does not work as expected

[Juanma Barranquero]

On 7/5/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> The documentation is correct, no
> Start Menu is opened if the variable is nil. However I would believe
> that the author wanted to use this key in Emacs. It is however still not
> possible, the key is tighed to Explorer still.

Did you set `w32-lwindow-modifier'? I have it set to hyper and I've
been using H-key bindings for quite a long time.

It is true that some bindings are "stolen" by Windows: H-b, H-d, H-e,
H-f, H-l, H-m, H-r and H-u, AFAIK (also H-Pause, which brings the
System control panel applet). But you still have the rest, and all S-
and C- modified keys).

-- 
                    /L/e/k/t/u

Re: w32-pass-lwindow-to-system does not work as expected

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> When discussing AltGr I noticed that w32-pass-lwindow-to-system
> probably does not due what the author intended. The documentation is
> correct, no Start Menu is opened if the variable is nil. However I
> would believe that the author wanted to use this key in Emacs. It is
> however still not possible, the key is tighed to Explorer still.

w32-pass-lwindow-to-system should be used in combination with
w32-lwindow-modifier. The default of nil for the latter gives you a
lwindow key, not an lwindow modifier. Perhaps that is why you are
thinking it doesn't work.

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Juanma Barranquero wrote:

>On 7/5/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>  
>
>>The documentation is correct, no
>>Start Menu is opened if the variable is nil. However I would believe
>>that the author wanted to use this key in Emacs. It is however still not
>>possible, the key is tighed to Explorer still.
>>    
>>
>
>Did you set `w32-lwindow-modifier'? I have it set to hyper and I've
>been using H-key bindings for quite a long time.
>
>It is true that some bindings are "stolen" by Windows: H-b, H-d, H-e,
>H-f, H-l, H-m, H-r and H-u, AFAIK (also H-Pause, which brings the
>System control panel applet). But you still have the rest, and all S-
>and C- modified keys).
>
Very nice, but it would be even better if it actually did the right thing.

Re: w32-pass-lwindow-to-system does not work as expected

[Juanma Barranquero]

On 7/5/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Very nice, but it would be even better if it actually did the right thing.

Well, certainly your claim that `w32-pass-lwindow-to-system' does not
work as documented is just wrong. It does. The fact that Windows
reclaims some of these bindings is another matter altogether, and yes,
perhaps it could be circumvented (not "fixed", unless you're talking
of fixing Windows) via a keyboard hook. I would recommend against it,
at this moment. This would be new, low level code, to fix a misfeature
of Windows, and there seem to be no much user request for it.

It's not like there's a shortage of bindings. You can bind [apps],
[lwindow], [rwindow] and a lot of combinations of them.

If I had to single out a keyboard feature that I would like changed,
is being able to block [language-change]. It currently have it set to
a message box to show when it happens, but it *is* irritating.

-- 
                    /L/e/k/t/u

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Jason Rumney wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>  
>
>>When discussing AltGr I noticed that w32-pass-lwindow-to-system
>>probably does not due what the author intended. The documentation is
>>correct, no Start Menu is opened if the variable is nil. However I
>>would believe that the author wanted to use this key in Emacs. It is
>>however still not possible, the key is tighed to Explorer still.
>>    
>>
>
>w32-pass-lwindow-to-system should be used in combination with
>w32-lwindow-modifier. The default of nil for the latter gives you a
>lwindow key, not an lwindow modifier. Perhaps that is why you are
>thinking it doesn't work.
>
Thanks, but no. I think it does not work because Explorer still jumps in 
with these settings. Try the settings you suggested and type 
<lwindow>+e. Windows Explorer will start.

As I have said the only way to avoid this is to use a lower level 
keyboard hook.

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Juanma Barranquero wrote:

>Well, certainly your claim that `w32-pass-lwindow-to-system' does not
>work as documented is just wrong. It does. The fact that Windows
>reclaims some of these bindings is another matter altogether, and yes,
>perhaps it could be circumvented (not "fixed", unless you're talking
>of fixing Windows) via a keyboard hook. I would recommend against it,
>at this moment. This would be new, low level code, to fix a misfeature
>of Windows, and there seem to be no much user request for it.
>  
>
I think it is wrong. The documentation says:

   w32-pass-lwindow-to-system's value is nil

  Non-nil if the left "Windows" key is passed on to Windows.
  When non-nil, the Start menu is opened by tapping the key.

The first sentence is wrong. The second is correct.

Perhaps there is not much need because users on ms windows may find that 
this does not work as expected (after much work) and then decide that it 
does not seem as Emacs work as documented. Then they leave to other 
options. (A story many times told - I believe I have seen such cases.)

I tried to use <lwindow> for Meta because that would be nice. Then I 
could access the menu as in other w32 programs (and that is certainly a 
something a novice user expects). So there could be request for it, I 
believe.

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Eli Zaretskii wrote:

>>Date: Tue, 05 Jul 2005 21:14:34 +0200
>>From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>
>>To overcome this a low level keyboard hook must be used. A good starting 
>>point summary is found at 
>>http://www.codeproject.com/win32/AntonioWinLock.asp. Look under subtitle 
>>"Hooks".
>>    
>>
>
>Watch out for the caveats of using low-level keyboard interfaces: what
>the hook gets is the scan code of the key and various bit masks for
>the modifier keys.  That means that the application (us) will have to
>take care of the key translation machinery, such as mapping the same
>keys to different characters depending on the language, translation of
>AltGr + KEY combinations to produce special non-ASCII characters, etc.
>Eventually, it is quite possible that we will have to introduce
>translation code and tables into Emacs for each supported keyboard
>input language.  See msdos.c for an example of where this could lead;
>that way lies madness.  (The MSDOS port had no good alternative, since
>too many useful key combinations would be unavailable for Emacs if it
>were to use only the standard keyboard interface.  But I wouldn't
>recommend going that way just to fix some obscure misfeature which
>most users won't even notice unless explicitly told about.)
>  
>
I would not suggest using it if I believed that. I have seen what 
trouble it could be handling keyboard keys. The nice thing here is 
however that not much might be required. Look at the example here: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xpvisualstyles.asp

Would it not be possible to detect for example <lwindow> here and send 
an Emacs specific message to the Emacs thread that recieves the keyboard 
input?

BTW that page says that is has to be systemwide, but the page I sent 
before shows how to avoid that.

Re: w32-pass-lwindow-to-system does not work as expected

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> If I had to single out a keyboard feature that I would like changed,
> is being able to block [language-change]. It currently have it set to
> a message box to show when it happens, but it *is* irritating.

It can be turned off. In every version of Windows they move it around,
so it might be difficult to find.

On XP you get to it via the "Regional Settings" control panel,
"Languages" tab, "Details..." button, which opens another window, on
which there is a "Key Settings..." button. You can disable the key
sequence, or change it to something else, though the options are
limited and probably all conflict with some Emacs bindings.

Re: w32-pass-lwindow-to-system does not work as expected

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Thanks, but no. I think it does not work because Explorer still jumps
> in with these settings. Try the settings you suggested and type
> <lwindow>+e. Windows Explorer will start.

That is slightly clearer than your previous statement that the setting
be removed completely because it doesn't work.

There are a few specific key combinations that the system grabs before
Emacs gets a chance to see them. This does not mean that the variables
Emacs uses to try to give the user more control over their keyboard
do not work at all.

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Jason Rumney wrote:

>There are a few specific key combinations that the system grabs before
>Emacs gets a chance to see them. This does not mean that the variables
>Emacs uses to try to give the user more control over their keyboard
>do not work at all.
>
Sorry for the somewhat harsh statement. What I really mean is that this 
can be very irritating and annoyning to a user if it is not clearly 
documented. Otherwise I think the intent is good.

Actually what we have been discussing now is related to the problem with 
Alt-Tab. Whatever we do and decide this things should be documented and 
understood.

Re: w32-pass-lwindow-to-system does not work as expected

[Eli Zaretskii]

> Date: Tue, 05 Jul 2005 21:14:34 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> To overcome this a low level keyboard hook must be used. A good starting 
> point summary is found at 
> http://www.codeproject.com/win32/AntonioWinLock.asp. Look under subtitle 
> "Hooks".

Watch out for the caveats of using low-level keyboard interfaces: what
the hook gets is the scan code of the key and various bit masks for
the modifier keys.  That means that the application (us) will have to
take care of the key translation machinery, such as mapping the same
keys to different characters depending on the language, translation of
AltGr + KEY combinations to produce special non-ASCII characters, etc.
Eventually, it is quite possible that we will have to introduce
translation code and tables into Emacs for each supported keyboard
input language.  See msdos.c for an example of where this could lead;
that way lies madness.  (The MSDOS port had no good alternative, since
too many useful key combinations would be unavailable for Emacs if it
were to use only the standard keyboard interface.  But I wouldn't
recommend going that way just to fix some obscure misfeature which
most users won't even notice unless explicitly told about.)

Re: w32-pass-lwindow-to-system does not work as expected

[Juanma Barranquero]

On 7/5/05, Jason Rumney <jasonr@gnu.org> wrote:

> It can be turned off. In every version of Windows they move it around,
> so it might be difficult to find.

Thanks!

I knew that it could be changed, but somehow I was under the false
idea that it could not be turned off. You've just saved me... don't
know, about two/three minutes a month for the rest of my life (or
Windows', whichever finish sooner) ;-)

-- 
                    /L/e/k/t/u

Re: w32-pass-lwindow-to-system does not work as expected

[Juanma Barranquero]

On 7/5/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

>   Non-nil if the left "Windows" key is passed on to Windows.
>   When non-nil, the Start menu is opened by tapping the key.
> 
> The first sentence is wrong. The second is correct.

I don't see. When the variable is non-nil, Emacs does not pass the
lwindow key to Windows. Windows grabs it at a lower level; that's
unrelated to what Emacs does or says it does.

> Perhaps there is not much need because users on ms windows may find that
> this does not work as expected (after much work) and then decide that it
> does not seem as Emacs work as documented. Then they leave to other
> options. (A story many times told - I believe I have seen such cases.)

I've seen that too. But in this case, and speaking from my experience
only, I tested it, quickly discovered that some keys where always
intercepted by Windows, and happily started using the ones that it
didn't grab. Most users don't read docs, but the ones that do usually
are able to do a little experimenting, don't you think?

> Then I
> could access the menu as in other w32 programs (and that is certainly a
> something a novice user expects). So there could be request for it, I
> believe.

There could be, yes. I was pointing out that there *is not*, so
changing the keyboard code at this moment for a not-clear, not-so-big
gain seems, to my admittedly uninformed opinion, unwise.

-- 
                    /L/e/k/t/u

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Juanma Barranquero wrote:

>I don't see. When the variable is non-nil, Emacs does not pass the
>lwindow key to Windows. Windows grabs it at a lower level; that's
>unrelated to what Emacs does or says it does.
>  
>
It is not on a lower level in that sense. Emacs can (I believe) prevent 
the key to pass to windows, but it does not.

>I've seen that too. But in this case, and speaking from my experience
>only, I tested it, quickly discovered that some keys where always
>intercepted by Windows, and happily started using the ones that it
>didn't grab. Most users don't read docs, but the ones that do usually
>are able to do a little experimenting, don't you think?
>  
>
It is a matter of time I think.

>gain seems, to my admittedly uninformed opinion, unwise.
>  
>
We are all trying to make good guesses of course ;-)

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Eli Zaretskii wrote:

>Watch out for the caveats of using low-level keyboard interfaces: what
>the hook gets is the scan code of the key and various bit masks for ...
>  
>
I took a look at the code in w32fns.c again. It looks to me everything 
is in place to handle the <lwindow> key, except for that low level 
keyboard hook. Everything the keyboard hook has to to is to avoid 
sending anything to the system when <lwindow> is typed and Emacs wants it.

So if it works at all it should perhaps be very little trouble:

1) add the hook at thread startup
2) the hook prevents sending any VK_LWIN events further if Emacs wants 
them, otherwise not.
3) remove the hook at thread termination.

Below is code for doing this. I have assumed that NILP and 
Vw32_pass_lwindow_to_system are actually available in the input thread. 
(Or did I read that wrong?)

But as I said I am not a guru on this, I just read the docs and the 
code. Am I misunderstanding something here?

*** Adding the low level keyboard hook to the main thread at thread startup:
hLowKBhook = SetWindowsHookEx(WH_KEYBOARD_LL, LowLevelKeyboardProc, NULL, dwMainThreadId);

*** Removing the low level keyboard hook at the main thread tear down:
UnhookWindowsHookEx(hLowKBhook);

*** The hook procedure. This runs in the context of the thread.

LRESULT LowLevelKeyboardProc(INT nCode, WPARAM wParam, LPARAM lParam)
{
    BOOL fHandled = FALSE;

    if (nCode == HC_ACTION)
    {
        KBDLLHOOKSTRUCT *pkbdllhook = (KBDLLHOOKSTRUCT *)lParam;

        switch (wParam)
        {
            case WM_KEYUP:
            case WM_KEYDOWN:  // This was not in the MS example, why??
            case WM_SYSKEYUP:
            case WM_SYSKEYDOWN:
                switch (pkbdllhook->vkCode)
                {
                    case VK_LWIN:
                    {
                        // the user pressed the <lwindow> key
                	if (!NILP (Vw32_pass_lwindow_to_system))
                        fHandled = TRUE;
                        break;
                    }
                }
        }
    }

    return (fHandled ? TRUE : CallNextHookEx(hhook, nCode, wParam, lParam));
}

Re: w32-pass-lwindow-to-system does not work as expected

[Eli Zaretskii]

> Date: Tue, 05 Jul 2005 22:54:22 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: emacs-devel@gnu.org
> 
> I would not suggest using it if I believed that.

I cannot do anything about your beliefs.  I wrote about the caveats
because my experience taught me that low-level keyboard hooks bring
maintenance headaches in the long run.

For example, even the simple hook you posted could conceivably raise
some issues, if the user did some tweaking of her keyboard operation
wrt the lwindow key (e.g., the scan code map can be modified via the
registry).

On more general grounds, when Emacs users on other systems complain
about trouble with key assignments, they are told to use system tools
to reassign keys; we never try to solve such problems in Emacs.  Why
do that for MS-Windows?  Shouldn't we simply advise users to use some
key remapping tool if they want this feature so badly?

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Eli Zaretskii wrote:

>I cannot do anything about your beliefs.  I wrote about the caveats
>because my experience taught me that low-level keyboard hooks bring
>maintenance headaches in the long run.
>  
>
Of course you have more experience with this.

>For example, even the simple hook you posted could conceivably raise
>some issues, if the user did some tweaking of her keyboard operation
>wrt the lwindow key (e.g., the scan code map can be modified via the
>registry).
>  
>
I never seen this possibility to enter the scan code before. From the 
documentation I read that this is new inW2k and XP. I also read that
"the mappings stored in the registry work at system level and apply to 
all users. These mappings cannot be set to work differently depending on 
the current user".

As far as understand this is not something you then can use for problems 
specific to Emacs.

And - or do I misunderstand this - more important: what you refer to are 
remapping the *scan codes* and my code used the *virtual keycodes*. That 
is what is used in Emacs today.

>On more general grounds, when Emacs users on other systems complain
>about trouble with key assignments, they are told to use system tools
>to reassign keys; we never try to solve such problems in Emacs.  Why
>do that for MS-Windows?  Shouldn't we simply advise users to use some
>key remapping tool if they want this feature so badly?
>
Perhaps, but is not that on another level? Are we not adressing issues 
within Emacs and how Emacs interacts with the system?

Re: w32-pass-lwindow-to-system does not work as expected

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> *** Removing the low level keyboard hook at the main thread tear down:
> UnhookWindowsHookEx(hLowKBhook);

You also need to remove the hook whenever Emacs crashes. That is more
difficult, and the reason why I would be reluctant to start playing
with Low Level hooks within Emacs.

>                     case VK_LWIN:
>                     {
>                         // the user pressed the <lwindow> key
>                 	if (!NILP (Vw32_pass_lwindow_to_system))
>                         fHandled = TRUE;
>                         break;
>                     }
>                 }
>         }
>     }
>
>     return (fHandled ? TRUE : CallNextHookEx(hhook, nCode, wParam, lParam));

If my reading of the docs is correct, this will prevent Emacs from
seeing lwindow keys altogether. If you return true from a low level
keyboard hook, you must handle the key inside the hook. Since you want
to use lwindow as a modifier key, you'll then need to handle all the
keys that it modifies in the hook as well, and you'll end up doing all
your own keyboard mapping, as Eli said.

Re: w32-pass-lwindow-to-system does not work as expected

[LENNART BORGMAN]

From: Jason Rumney <jasonr@gnu.org>

> You also need to remove the hook whenever Emacs crashes. That is more
> difficult, and the reason why I would be reluctant to start playing

Yes, that is very important I guess. Are there not any exception handlers capable of handling this in Emacs?


> If my reading of the docs is correct, this will prevent Emacs from
> seeing lwindow keys altogether. If you return true from a low level
> keyboard hook, you must handle the key inside the hook. Since you want
> to use lwindow as a modifier key, you'll then need to handle all the
> keys that it modifies in the hook as well, and you'll end up doing all
> your own keyboard mapping, as Eli said.

Eh, thanks, forgot to send it on. Argumenting is not always easy when you get much resistance.

As I said earlier this could perhaps be done with a private message that is the equivalence of WM_KEYDOWN for just <lwindow>. But maybe then the modifiers must be handled as well?

Could the message instead just be repackaged and sent on to the emacs keyboard thread for <lwindow>? Does that interfere with message order if SendMessage is used?

Re: w32-pass-lwindow-to-system does not work as expected

[Lennart Borgman]

Eli Zaretskii wrote:

>The low-level hook you referred to is documented to get scan codes.
>  
>
Yes, scan code AND virtual key codes. I do not mean to process the scan 
codes (I would not dare ;-)

>See also Jason's message: if lwindow is to be used as a modifier, then
>we will have to process other keys in the low-level hook as well.
>  
>
I took a look at how RegisterHotKey was used in Emacs. It post the 
message back as a WM_KEYDOWN with just the virtual key code and no 
modifiers. Could not the same thing be done in the low level hook I have 
suggested? Or is there something I do not know that must be done?

>Unfortunately, in this case, this particular system doesn't want Emacs
>to get at that key and some other special key combinations.  Since
>Emacs users are not the only ones who are pissed off by this
>inflexibility, I'm sure there are lots of small proggies written and
>floating on the Internet that will remap lwindow and other special
>keys such that applications, including Emacs, can receive them.  I say
>let's advise our users to solve their problems outside Emacs, like we
>do on GNU/Linux, where we tell them to use loadkeys and xmodmap.
>  
>
Maybe you are right, but my gut feeling is that users on w32 expect the 
program the use to do this. There are at least some example of code 
doing things similar to my suggestion.

And it looks to me like things have changed over the years. The low 
level keyboard hook I have suggested that we use is not available in 
older versions of ms windows. (If I remember correctly it is available 
from w2k and onwards.)

Re: w32-pass-lwindow-to-system does not work as expected

[Eli Zaretskii]

> Date: Wed, 06 Jul 2005 08:54:39 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: emacs-devel@gnu.org
> 
> And - or do I misunderstand this - more important: what you refer to are 
> remapping the *scan codes* and my code used the *virtual keycodes*. That 
> is what is used in Emacs today.

The low-level hook you referred to is documented to get scan codes.

See also Jason's message: if lwindow is to be used as a modifier, then
we will have to process other keys in the low-level hook as well.

> >On more general grounds, when Emacs users on other systems complain
> >about trouble with key assignments, they are told to use system tools
> >to reassign keys; we never try to solve such problems in Emacs.  Why
> >do that for MS-Windows?  Shouldn't we simply advise users to use some
> >key remapping tool if they want this feature so badly?
> >
> Perhaps, but is not that on another level? Are we not adressing issues 
> within Emacs and how Emacs interacts with the system?

Unfortunately, in this case, this particular system doesn't want Emacs
to get at that key and some other special key combinations.  Since
Emacs users are not the only ones who are pissed off by this
inflexibility, I'm sure there are lots of small proggies written and
floating on the Internet that will remap lwindow and other special
keys such that applications, including Emacs, can receive them.  I say
let's advise our users to solve their problems outside Emacs, like we
do on GNU/Linux, where we tell them to use loadkeys and xmodmap.