[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lennart Borgman (gmail)
Subject: Re: [h-e-w] MS Windows Keybinding
Date: Tue, 30 Oct 2007 18:48:59 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070728 Thunderbird/ Mnenhy/

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,

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

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).

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);
            case VK_RWIN:
                bHandle = NILP(Vw32_pass_rwindow_to_system);
            case VK_CAPITAL:
                bHandle = NILP(Vw32_enable_caps_lock);
            case VK_NUMLOCK:
                bHandle = NILP(Vw32_enable_num_lock);
      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);

reply via email to

[Prev in Thread] Current Thread [Next in Thread]