bug#23163: 25.1.50; w32-lwindow-modifier "unset" while running GDB

bug#23163: 25.1.50; w32-lwindow-modifier "unset" while running GDB

[martin rudalics]

In my .emacs for Windows I have for many years the following settings.

(setq w32-pass-lwindow-to-system nil)
(setq w32-lwindow-modifier 'hyper)	; lwindow is hyper
(global-set-key [(control hyper meta b)] 'break-point-insert)

‘break-point-insert’ is a command that inserts a breakpoint into the
*gud-emacs.exe* buffer.  This command works fine in emacs-25 but fails
in master when running GDB.  In particular, it fails _after_ focus has
shifted to the debugged frame and I shifted it back to the debugger
frame.  The command actually executed by C-H-M b is then ‘backward-sexp’
which means that apparently ‘w32-lwindow-modifier’ has been unset and my
modifier given back to the system.

I believe that I have seen similar "unsettings" in other occasions as
well but the example given here is the only one I can confirm.

In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
  of 2016-03-30 built on MACHNO
Repository revision: 292c4753923a468e6c29733ef8701cf2c6680aa8
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
Configured using:
  'configure --prefix=/c/emacs-git/opt CFLAGS=-O3'

martin

bug#23163: 25.1.50; w32-lwindow-modifier "unset" while running GDB

[Eli Zaretskii]

> Date: Wed, 30 Mar 2016 19:32:49 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> In my .emacs for Windows I have for many years the following settings.
> 
> (setq w32-pass-lwindow-to-system nil)
> (setq w32-lwindow-modifier 'hyper)	; lwindow is hyper
> (global-set-key [(control hyper meta b)] 'break-point-insert)
> 
> ‘break-point-insert’ is a command that inserts a breakpoint into the
> *gud-emacs.exe* buffer.  This command works fine in emacs-25 but fails
> in master when running GDB.  In particular, it fails _after_ focus has
> shifted to the debugged frame and I shifted it back to the debugger
> frame.  The command actually executed by C-H-M b is then ‘backward-sexp’
> which means that apparently ‘w32-lwindow-modifier’ has been unset and my
> modifier given back to the system.
> 
> I believe that I have seen similar "unsettings" in other occasions as
> well but the example given here is the only one I can confirm.

Probably due to changes in 97d7a0b.  Jussi, could you please take a
look?

bug#23163: 25.1.50; w32-lwindow-modifier "unset" while running GDB

[Jussi Lahdenniemi]

>> Date: Wed, 30 Mar 2016 19:32:49 +0200
>> From: martin rudalics <rudalics@gmx.at>
>>
>> In my .emacs for Windows I have for many years the following settings.
>>
>> (setq w32-pass-lwindow-to-system nil)
>> (setq w32-lwindow-modifier 'hyper)	; lwindow is hyper
>> (global-set-key [(control hyper meta b)] 'break-point-insert)
>>
>> ‘break-point-insert’ is a command that inserts a breakpoint into the
>> *gud-emacs.exe* buffer.  This command works fine in emacs-25 but fails
>> in master when running GDB.  In particular, it fails _after_ focus has
>> shifted to the debugged frame and I shifted it back to the debugger
>> frame.  The command actually executed by C-H-M b is then ‘backward-sexp’
>> which means that apparently ‘w32-lwindow-modifier’ has been unset and my
>> modifier given back to the system.
>>
>> I believe that I have seen similar "unsettings" in other occasions as
>> well but the example given here is the only one I can confirm.

Does it help if you add
(w32-register-hot-key [H-])
after the (global-set-key ...) line in your .emacs?

-- 
Jussi Lahdenniemi

bug#23163: 25.1.50; w32-lwindow-modifier "unset" while running GDB

[martin rudalics]

 > Does it help if you add
 > (w32-register-hot-key [H-])
 > after the (global-set-key ...) line in your .emacs?

No.  Even worse, this breaks my ahk settings: Here, for example,
C-H-M-left is bound (via ahk) to a script that makes any Windows window
occupy the left half of my display.  This allows XP do what Aero does
later and also binds it to a different key, because Windows 7 broke my
old standard Emacs binding for S-H-up (or whatever old binding Aero was
usurping here, I don't recall at the moment).  It's not sufficient for
me to rebind keys in Emacs only - keys for resizing Windows windows must
be obviously uniform.

I believe the problem I see with GDB is due to refocussing during
debugging.  More precisely, the binding is hidden only _after_ I start
running an Emacs instance via GDB, the Windows window of the debugged
Emacs instance pops up, a breakpoint gets hit and I manually refocus the
Windows window of the debugging Emacs instance (using the mouse or
Alt-TAB, for example) in order to continue debugging.  The binding is
restored as soon as I quit GDB.

Please tell me if you have problems understanding this description (I
might have omitted some crucial detail).

Thanks, martin