Re: w32-pass-rwindow-to-system

[Lennart Borgman]

On Thu, Jan 22, 2009 at 12:03 AM, MON KEY <address@hidden> 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
> <address@hidden> wrote:
>> On Wed, Jan 21, 2009 at 3:23 PM, Jason Rumney <address@hidden> wrote:
>>> Lennart Borgman wrote:
>>>>
>>>> On Wed, Jan 21, 2009 at 10:29 AM, Juanma Barranquero <address@hidden>
>>>> 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.
>>
>
>
>