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