bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Richard Copley]

In recent builds of the emacs-25 branch, when an Emacs frame is in the
foreground, it intercepts the left Windows key (and the windowing
system does not react to the key event).

My two most recent emacs-25 builds are from revisions:
  ab182c624868fcc0ed97597db669911099d4bd28 (commit time 2016-06-12
17:33:52 UTC),
  788c9b69e1801dd883dbe603281571ef3c78a724 (commit time 2016-05-31
06:17:55 UTC).
The bug is present in the 2016-06-12 build and absent in the 2016-05-31 build.

To reproduce:

Run emacs -Q.
Make sure the Emacs frame is the active foreground window.
Press the left Windows key.
Expected result: the start menu opens (depends on users's settings).
Actual result: Emacs receives the keypress instead (this can be verified
by typing [C-h k lwindow]).

In GNU Emacs 25.1.50.1 (x86_64-w64-mingw32)
 of 2016-06-13 built on [redacted]
Repository revision: ab182c624868fcc0ed97597db669911099d4bd28
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix /C/emacs/emacs-20160612-173352 --enable-checking
 --with-modules --without-imagemagick --disable-dependency-tracking
 --enable-locallisppath=%emacs_dir%/../site-lisp 'CFLAGS=-Og -g -ggdb'
 CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny seq byte-opt gv bytecomp
byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify dbusbind w32 multi-tty
make-network-process emacs)

Memory information:
((conses 16 98764 8768)
 (symbols 56 20613 0)
 (miscs 48 41 87)
 (strings 32 18921 4980)
 (string-bytes 1 580024)
 (vectors 16 13363)
 (vector-slots 8 441864 3974)
 (floats 8 181 78)
 (intervals 56 253 11)
 (buffers 976 11))

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Wed, 22 Jun 2016 19:22:01 +0100
> 
> In recent builds of the emacs-25 branch, when an Emacs frame is in the
> foreground, it intercepts the left Windows key (and the windowing
> system does not react to the key event).
> 
> My two most recent emacs-25 builds are from revisions:
>   ab182c624868fcc0ed97597db669911099d4bd28 (commit time 2016-06-12
> 17:33:52 UTC),
>   788c9b69e1801dd883dbe603281571ef3c78a724 (commit time 2016-05-31
> 06:17:55 UTC).
> The bug is present in the 2016-06-12 build and absent in the 2016-05-31 build.

These two commits are not on the emacs-25 branch.

> To reproduce:
> 
> Run emacs -Q.
> Make sure the Emacs frame is the active foreground window.
> Press the left Windows key.
> Expected result: the start menu opens (depends on users's settings).
> Actual result: Emacs receives the keypress instead (this can be verified
> by typing [C-h k lwindow]).
> 
> In GNU Emacs 25.1.50.1 (x86_64-w64-mingw32)
>  of 2016-06-13 built on [redacted]

This is not the emacs-25 branch, this is master.  Could you please
clarify this confusion?

The keyboard handling on Windows was changed on master in February, so
I don't see how some change in the beginning of June could have done
anything about that.  I'm probably missing something.

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Richard Copley]

On 22 June 2016 at 19:45, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Wed, 22 Jun 2016 19:22:01 +0100
>>
>> In recent builds of the emacs-25 branch, when an Emacs frame is in the
>> foreground, it intercepts the left Windows key (and the windowing
>> system does not react to the key event).
>>
>> My two most recent emacs-25 builds are from revisions:
>>   ab182c624868fcc0ed97597db669911099d4bd28 (commit time 2016-06-12
>> 17:33:52 UTC),
>>   788c9b69e1801dd883dbe603281571ef3c78a724 (commit time 2016-05-31
>> 06:17:55 UTC).
>> The bug is present in the 2016-06-12 build and absent in the 2016-05-31 build.

> These two commits are not on the emacs-25 branch.

Sorry for the confusion.
I don't want to jump to conclusions but assuming you're right then I
must have built from master and forgotten about it.

Is it possible you're only half right and that one of those two
commits is on emacs-25 and the other is not?
I ask because I get the following values inside the two builds:

(emacs-version) "GNU Emacs 25.0.94.1 (x86_64-w64-mingw32)
 of 2016-05-31"
emacs-repository-version "788c9b69e1801dd883dbe603281571ef3c78a724"

resp.

(emacs-version) "GNU Emacs 25.1.50.1 (x86_64-w64-mingw32)
 of 2016-06-13"
emacs-repository-version "ab182c624868fcc0ed97597db669911099d4bd28"

Can you please tell me how to verify whether a commit is on a branch
for myself (so I'm less likely to make mistakes like this in the
future)?
What I did is this:
  (in Git CMD in repository root): git checkout emacs-25 && git pull
  (in Emacs in repository root): C-x v L ;; vc-print-root-log
then searched for and found both commits' checksums.
The root log starts (HEAD -> emacs-25, origin/master, origin/HEAD,
master). Maybe it's actually a combined log. I'm more familiar with
Subversion and perhaps I made unwarranted assumptions about Git's log.

>> To reproduce:
>>
>> Run emacs -Q.
>> Make sure the Emacs frame is the active foreground window.
>> Press the left Windows key.
>> Expected result: the start menu opens (depends on users's settings).
>> Actual result: Emacs receives the keypress instead (this can be verified
>> by typing [C-h k lwindow]).
>>
>> In GNU Emacs 25.1.50.1 (x86_64-w64-mingw32)
>>  of 2016-06-13 built on [redacted]
>
> This is not the emacs-25 branch, this is master.  Could you please
> clarify this confusion?

I can try, but the main thing I have learned is that I am indeed confused.

> The keyboard handling on Windows was changed on master in February, so
> I don't see how some change in the beginning of June could have done
> anything about that.  I'm probably missing something.

I'm not sure but it seems likely the earlier build is emacs-25 and the
later is master, which one might find explains that.

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Óscar Fuentes]

Richard Copley <rcopley@gmail.com> writes:

>>> My two most recent emacs-25 builds are from revisions:
>>>   ab182c624868fcc0ed97597db669911099d4bd28 (commit time 2016-06-12
>>> 17:33:52 UTC),
>>>   788c9b69e1801dd883dbe603281571ef3c78a724 (commit time 2016-05-31
>>> 06:17:55 UTC).
>>> The bug is present in the 2016-06-12 build and absent in the 2016-05-31 build.
>
>> These two commits are not on the emacs-25 branch.
>
> Sorry for the confusion.
> I don't want to jump to conclusions but assuming you're right then I
> must have built from master and forgotten about it.
>
> Is it possible you're only half right and that one of those two
> commits is on emacs-25 and the other is not?

oscar@qcore:~/dev/emacs/emacs$ git branch -a --contains ab182c624868fcc0ed97597db669911099d4bd28
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/scratch/gnus-cloud
oscar@qcore:~/dev/emacs/emacs$ git branch -a --contains 788c9b69e1801dd883dbe603281571ef3c78a724
* emacs-25
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/emacs-25
  remotes/origin/master
  remotes/origin/scratch/gnus-cloud

So 788c9b69e1801dd883dbe603281571ef3c78a724 is in both emacs-25 and master.

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Wed, 22 Jun 2016 20:33:34 +0100
> Cc: 23830@debbugs.gnu.org
> 
> >> My two most recent emacs-25 builds are from revisions:
> >>   ab182c624868fcc0ed97597db669911099d4bd28 (commit time 2016-06-12
> >> 17:33:52 UTC),
> >>   788c9b69e1801dd883dbe603281571ef3c78a724 (commit time 2016-05-31
> >> 06:17:55 UTC).
> >> The bug is present in the 2016-06-12 build and absent in the 2016-05-31 build.
> 
> > These two commits are not on the emacs-25 branch.
> 
> Sorry for the confusion.
> I don't want to jump to conclusions but assuming you're right then I
> must have built from master and forgotten about it.
> 
> Is it possible you're only half right and that one of those two
> commits is on emacs-25 and the other is not?
> I ask because I get the following values inside the two builds:
> 
> (emacs-version) "GNU Emacs 25.0.94.1 (x86_64-w64-mingw32)
>  of 2016-05-31"
> emacs-repository-version "788c9b69e1801dd883dbe603281571ef3c78a724"

Yes, this commit indeed started on emacs-25.  Which explains why you
say it doesn't have the problem: the emacs-25 branch doesn't have that
problem at all, to this day.

It also means that the problem appeared on master much earlier,
probably when the changes were done in February.

> Can you please tell me how to verify whether a commit is on a branch
> for myself (so I'm less likely to make mistakes like this in the
> future)?
> What I did is this:
>   (in Git CMD in repository root): git checkout emacs-25 && git pull
>   (in Emacs in repository root): C-x v L ;; vc-print-root-log
> then searched for and found both commits' checksums.
> The root log starts (HEAD -> emacs-25, origin/master, origin/HEAD,
> master). Maybe it's actually a combined log. I'm more familiar with
> Subversion and perhaps I made unwarranted assumptions about Git's log.

We merge from emacs-25 to master, so commits from emacs-26 eventually
appear on master as well.

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Richard Copley]

Eli, sorry for replying to you personally instead of to the bug.
Eli said:
> We merge from emacs-25 to master, so commits from emacs-26 eventually
> appear on master as well.

I said:
> What still confuses me is that the other revision ab182c6 which is not on
> emacs-25 appears in the log.

The problem was that my local emacs-25 branch was pointing to master.
I had "git branch --set-upstream-to=origin $branch" in my build script.
Should have been "git branch --set-upstream-to=origin/$branch $branch".
Having fixed that the root log starts "(HEAD -> emacs-25,
origin/emacs-25)" and contains 788c9b6 but not ab182c6 which is what I
expected.

Oscar, thanks for "git branch -a --contains", noted.

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 23 Jun 2016 12:03:44 +0100
> Cc: 23830@debbugs.gnu.org
> 
> Eli, sorry for replying to you personally instead of to the bug.
> Eli said:
> > We merge from emacs-25 to master, so commits from emacs-26 eventually
> > appear on master as well.
> 
> I said:
> > What still confuses me is that the other revision ab182c6 which is not on
> > emacs-25 appears in the log.
> 
> The problem was that my local emacs-25 branch was pointing to master.
> I had "git branch --set-upstream-to=origin $branch" in my build script.
> Should have been "git branch --set-upstream-to=origin/$branch $branch".
> Having fixed that the root log starts "(HEAD -> emacs-25,
> origin/emacs-25)" and contains 788c9b6 but not ab182c6 which is what I
> expected.

OK.  The bug was caused by a silly typo, now fixed.

Thanks.

bug#23830: 25.0.94; Emacs eats left Windows key on Windows 7

[Richard Copley]

On 23 June 2016 at 15:34, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Thu, 23 Jun 2016 12:03:44 +0100
>> Cc: 23830@debbugs.gnu.org
>>
>> Eli, sorry for replying to you personally instead of to the bug.
>> Eli said:
>> > We merge from emacs-25 to master, so commits from emacs-26 eventually
>> > appear on master as well.
>>
>> I said:
>> > What still confuses me is that the other revision ab182c6 which is not on
>> > emacs-25 appears in the log.
>>
>> The problem was that my local emacs-25 branch was pointing to master.
>> I had "git branch --set-upstream-to=origin $branch" in my build script.
>> Should have been "git branch --set-upstream-to=origin/$branch $branch".
>> Having fixed that the root log starts "(HEAD -> emacs-25,
>> origin/emacs-25)" and contains 788c9b6 but not ab182c6 which is what I
>> expected.
>
> OK.  The bug was caused by a silly typo, now fixed.

Well spotted! Thanks.