Re: [h-e-w] MS Windows Keybinding

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
> > Date: Mon, 29 Oct 2007 21:23:22 +0100
> > From: "Lennart Borgman (gmail)" <address@hidden>
> > Cc: Juanma Barranquero <address@hidden>, address@hidden,
> >         address@hidden
> >
> > > FWIW, I'm quite opposed to low-level keyboard hooks, because they
> > > bring in an enormous complexity when one wants to deal with non-ASCII
> > > keyboard input.
> > I do not believe that.
>
> That's a strange way of convincing.  I'm talking from actual
> experience here; saying that it's a lie or a dream is not a good way
> of learning from experience.

I know you have (too much?) experience of the complexities involved in 
keyboard handling, but wonder if you are misunderstanding this a bit. I 
will try to explain better below.

> > It does not affect other keyboard keys.
>
> Of course, it does.  You examine each key and decide which ones to
> handle and which not.  But at that low level looking at an individual
> keystroke is not good enough for that decision, when some other
> software, perhaps in Windows itself, has hooked the keyboard at a
> similarly low level, or lower.  IOW, you could easily err to recognize
> what the user is typing, because you don't know enough, at that low
> level, about higher-level translations of the key sequence being
> typed.

The guts of my patch is a low level keyboard hook. This is the only 
recommended way to catch any keyboard key in Windows. A slightly 
simplified version of the hook function I use is found below. As you can 
see from the code most keyboard input just passes by this hook. That is 
why I say that it does not raise the complexity for that input. Most 
keyboard input is handled just as today in Emacs with my patch.

However if the keyboard input event contains VK_LWIN etc it might be 
handled here (depends on w32-pass-lwindow-to-system etc). What is done 
then is simply that the default handling of that key is bypassed and the 
message is translated and put in Emacs input queue again.

Next time Emacs sees that keyboard input event it looks like the input 
events Emacs recieves today. So it is all about this little change in an 
input layer below the one Emacs use today. Not much complexity is 
introduced in the latter layer (but a bit more code since more keys are 
handled).


LRESULT
LowLevelKeyboardProc(INT nCode, WPARAM wParam, LPARAM lParam)
{
  if (nCode == HC_ACTION)
    {
      switch (wParam)
        {
        case WM_KEYUP:
        case WM_SYSKEYUP:
          previous_state = 1;
        case WM_KEYDOWN:  // This was not in the MS example, why??
        case WM_SYSKEYDOWN:
          switch (pkbdllhook->vkCode)
            {
            case VK_LWIN:
              {
                bHandle = NILP(Vw32_pass_lwindow_to_system);
                break;
              }
            case VK_RWIN:
              {
                bHandle = NILP(Vw32_pass_rwindow_to_system);
                break;
              }
            case VK_CAPITAL:
              {
                bHandle = NILP(Vw32_enable_caps_lock);
                break;
              }
            case VK_NUMLOCK:
              {
                bHandle = NILP(Vw32_enable_num_lock);
                break;
              }
            }
        }
      if (bHandle) {
        // Just to be sure check we are in the right thread
        if (GetCurrentThreadId() == dwWindowsThreadId) {
          // Do we have keyboard focus?
          HWND hwnd = GetFocus();
          if (0 != hwnd) {
            WPARAM wParamMsg;
            LPARAM lParamMsg;
            ... translate from wParam -> wParamMsg etc
            SendMessage (hwnd, msg, wParamMsg, lParamMsg);
            return TRUE;
          }
        }
      }



    }
  // This sends the keyboard input event to the next layer. Some will
  // go to Emacs some, like VK_LWIN, will go to Windows.
  HHOOK hhook; return CallNextHookEx(hhook, nCode, wParam, lParam);
}