bug#11732: 24.1; Microsoft IME Japanese input problem

bug#11732: 24.1; Microsoft IME Japanese input problem

[xavier.dahan]

Problem to use the native Microsoft IME Japanese input tool to write in
Japanese within Emacs.

Japanese keyboard.

Windows 7, fully in Japanese (locale, language).

Switching to Japanese IME input in Emacs makes the user "blind".
Can not see what we are typing (like when typing a password) until is pressed:

- either 2 times "space". Then the small IME window displaying the kanji
  choices corresponding to what has been typeset (blind) appears on the
  bottom-right of the screen.

- either "enter". Then the hiragana that have been typeset (blind) are printed
  in Emacs.   

That's all. Best regards, Xavier.
--------------------------------------------------------------------------

In GNU Emacs 24.1.1 (i386-mingw-nt6.1.7601)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: JPN
  value of $XMODIFIERS: nil
  locale-coding-system: cp932
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-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

Recent input:
<language-change> C-c C-c M-x b u <tab> g - r e <tab> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> r e 
p o r t - e m a <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-mode easymenu view time-date
japan-util tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#11732: 24.1; Microsoft IME Japanese input problem

[Fujii Hironori]

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

WM_IME_STARTCOMPOSITION should be passed to DefWindowProc.


On Mon, 18 Jun 2012 14:20:37 +0900,
xavier.dahan@gmail.com wrote:
>
> Problem to use the native Microsoft IME Japanese input tool to write in
> Japanese within Emacs.
>
> Japanese keyboard.
>
> Windows 7, fully in Japanese (locale, language).
>
> Switching to Japanese IME input in Emacs makes the user "blind".
> Can not see what we are typing (like when typing a password) until is pressed:
>
> - either 2 times "space". Then the small IME window displaying the kanji
>   choices corresponding to what has been typeset (blind) appears on the
>   bottom-right of the screen.
>
> - either "enter". Then the hiragana that have been typeset (blind) are printed
>   in Emacs.
>
> That's all. Best regards, Xavier.
> --------------------------------------------------------------------------
>
> In GNU Emacs 24.1.1 (i386-mingw-nt6.1.7601)
>  of 2012-06-10 on MARVIN
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
>  `configure --with-gcc (4.6) --cflags
>  -ID:/devel/emacs/libs/libXpm-3.5.8/include
>  -ID:/devel/emacs/libs/libXpm-3.5.8/src
>  -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
>  -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
>  -ID:/devel/emacs/libs/giflib-4.1.4-1/include
>  -ID:/devel/emacs/libs/jpeg-6b-4/include
>  -ID:/devel/emacs/libs/tiff-3.8.2-1/include
>  -ID:/devel/emacs/libs/gnutls-3.0.9/include'
>
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: JPN
>   value of $XMODIFIERS: nil
>   locale-coding-system: cp932
>   default enable-multibyte-characters: t
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
>   tooltip-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
>
> Recent input:
> <language-change> C-c C-c M-x b u <tab> g - r e <tab>
> <backspace> <backspace> <backspace> <backspace> <backspace>
> <backspace> <backspace> <backspace> <backspace> <backspace>
> <backspace> <backspace> <backspace> <backspace> r e
> p o r t - e m a <tab> <return>
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Making completion list...
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
> mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
> gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums
> mm-util mail-prsvr mail-utils help-mode easymenu view time-date
> japan-util tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
> disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe
> lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
> mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
> utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
> japanese hebrew greek romanian slovak czech european ethiopic indian
> cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
> minibuffer loaddefs button faces cus-face files text-properties overlay
> sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process multi-tty emacs)
>
>
>
>

[-- Attachment #2: a.patch --]
[-- Type: application/octet-stream, Size: 1120 bytes --]

diff --git a/src/w32fns.c b/src/w32fns.c
index 08000d8..3b0213d 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -3295,12 +3295,12 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 	     field being reset to nil.  */
 	  f = x_window_to_frame (dpyinfo, hwnd);
 	  if (!(f && FRAME_LIVE_P (f)))
-	    break;
+	    goto dflt;
 	  w = XWINDOW (FRAME_SELECTED_WINDOW (f));
 	  /* Punt if someone changed the frame's selected window
 	     behind our back. */
 	  if (w != w32_system_caret_window)
-	    break;
+	    goto dflt;
 
 	  form.dwStyle = CFS_RECT;
 	  form.ptCurrentPos.x = w32_system_caret_x;
@@ -3318,17 +3318,17 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 
 	  /* Punt if the window was deleted behind our back.  */
 	  if (!BUFFERP (w->contents))
-	    break;
+	    goto dflt;
 
 	  context = get_ime_context_fn (hwnd);
 
 	  if (!context)
-	    break;
+	    goto dflt;
 
 	  set_ime_composition_window_fn (context, &form);
 	  release_ime_context_fn (hwnd, context);
 	}
-      break;
+      goto dflt;
 
     case WM_IME_ENDCOMPOSITION:
       ignore_ime_char = 0;

bug#11732: 24.1; Microsoft IME Japanese input problem

[Eli Zaretskii]

> Date: Tue, 17 Feb 2015 19:26:41 +0900
> From: Fujii Hironori <fujii.hironori@gmail.com>
> 
> WM_IME_STARTCOMPOSITION should be passed to DefWindowProc.

Thanks, but can you explain the details?

I can understand why we should defer to DefWindowProc if we refrain
from processing this message, for some reason.  But this last part of
your patch:

> @@ -3318,17 +3318,17 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
>  
>  	  /* Punt if the window was deleted behind our back.  */
>  	  if (!BUFFERP (w->contents))
> -	    break;
> +	    goto dflt;
>  
>  	  context = get_ime_context_fn (hwnd);
>  
>  	  if (!context)
> -	    break;
> +	    goto dflt;
>  
>  	  set_ime_composition_window_fn (context, &form);
>  	  release_ime_context_fn (hwnd, context);
>  	}
> -      break;
> +      goto dflt;
>  
>      case WM_IME_ENDCOMPOSITION:
>        ignore_ime_char = 0;

Passes the message to DefWindowProc even if we succeeded to handle
WM_IME_STARTCOMPOSITION by calling ImmSetCompositionWindow.  Why is
that needed?

bug#11732: 24.1; Microsoft IME Japanese input problem

[Fujii Hironori]

Thank your for reviewing the patch, Eli.

On Thu, Feb 19, 2015 at 12:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 17 Feb 2015 19:26:41 +0900
>> From: Fujii Hironori <fujii.hironori@gmail.com>
>>
>> WM_IME_STARTCOMPOSITION should be passed to DefWindowProc.
>
> Thanks, but can you explain the details?
>
> I can understand why we should defer to DefWindowProc if we refrain
> from processing this message, for some reason.  But this last part of
> your patch:
>
>> @@ -3318,17 +3318,17 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
>>
>>         /* Punt if the window was deleted behind our back.  */
>>         if (!BUFFERP (w->contents))
>> -         break;
>> +         goto dflt;
>>
>>         context = get_ime_context_fn (hwnd);
>>
>>         if (!context)
>> -         break;
>> +         goto dflt;
>>
>>         set_ime_composition_window_fn (context, &form);
>>         release_ime_context_fn (hwnd, context);
>>       }
>> -      break;
>> +      goto dflt;
>>
>>      case WM_IME_ENDCOMPOSITION:
>>        ignore_ime_char = 0;
>
> Passes the message to DefWindowProc even if we succeeded to handle
> WM_IME_STARTCOMPOSITION by calling ImmSetCompositionWindow.  Why is
> that needed?

If Emacs processes WM_IME_STARTCOMPOSITION itself,
default composition window won't be shown.

Please see the document for the detail.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd374143%28v=vs.85%29.aspx

| Remarks
|
| This message is a notification to an IME window to open its
| composition window. An application should process this message if it
| displays composition characters itself.
|
| If an application has created an IME window, it should pass this
| message to that window. The DefWindowProc function processes the
| message by passing it to the default IME window.

bug#11732: 24.1; Microsoft IME Japanese input problem

[Eli Zaretskii]

> Date: Thu, 19 Feb 2015 11:03:58 +0900
> From: Fujii Hironori <fujii.hironori@gmail.com>
> Cc: 11732@debbugs.gnu.org
> 
> >>         set_ime_composition_window_fn (context, &form);
> >>         release_ime_context_fn (hwnd, context);
> >>       }
> >> -      break;
> >> +      goto dflt;
> >>
> >>      case WM_IME_ENDCOMPOSITION:
> >>        ignore_ime_char = 0;
> >
> > Passes the message to DefWindowProc even if we succeeded to handle
> > WM_IME_STARTCOMPOSITION by calling ImmSetCompositionWindow.  Why is
> > that needed?
> 
> If Emacs processes WM_IME_STARTCOMPOSITION itself,
> default composition window won't be shown.
> 
> Please see the document for the detail.
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd374143%28v=vs.85%29.aspx
> 
> | Remarks
> |
> | This message is a notification to an IME window to open its
> | composition window. An application should process this message if it
> | displays composition characters itself.
> |
> | If an application has created an IME window, it should pass this
> | message to that window. The DefWindowProc function processes the
> | message by passing it to the default IME window.

Yes, I've read that, but it's still not clear to me what that mean in
practice.  Are you saying that ImmSetCompositionWindow only sets the
position of the composition window, but it will not be shown unless we
pass WM_IME_STARTCOMPOSITION to DefWindowProc?  In that case, how will
Windows know that the composition window we positioned is "the default
IME window"?

Or are you saying we should be calling ImmSetCompositionWindow at all?
That call was introduced as result of solving bugs #2570 and #2569, so
I think the call or its equivalent should stay.

Sorry I'm asking all these questions, but I don't know enough about
IME programming, and need to understand this in order to see that the
patch doesn't break anything else.

Thanks.

bug#11732: 24.1; Microsoft IME Japanese input problem

[Eli Zaretskii]

> Date: Thu, 19 Feb 2015 19:40:18 +0900
> From: Fujii Hironori <fujii.hironori@gmail.com>
> 
> >> | Remarks
> >> |
> >> | This message is a notification to an IME window to open its
> >> | composition window. An application should process this message if it
> >> | displays composition characters itself.
> >> |
> >> | If an application has created an IME window, it should pass this
> >> | message to that window. The DefWindowProc function processes the
> >> | message by passing it to the default IME window.
> >
> > Yes, I've read that, but it's still not clear to me what that mean in
> > practice.  Are you saying that ImmSetCompositionWindow only sets the
> > position of the composition window, but it will not be shown unless we
> > pass WM_IME_STARTCOMPOSITION to DefWindowProc?
> 
> Yes, I am.
> 
> > In that case, how will
> > Windows know that the composition window we positioned is "the default
> > IME window"?
> 
> I don't understand what this means.
> The default IME window is not a composition window, but opens its
> composition window.
> 
> In SDK document, there are some hints what the default IME window is.
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd318561(v=vs.85).aspx
> 
> | The operating system creates a default IME window for every
> | thread. The window is created based on the IME class.
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd318170(v=vs.85).aspx
> 
> | IME Window Class
> |
> | The IME window class is a predefined system global class that defines
> | the appearance and behavior of the standard IME windows. The class is
> | similar to common control classes in that the application creates a
> | window of this class by using the CreateWindowEx function. Like static
> | controls, an IME window does not respond to user input by
> | itself. Instead, it notifies the IME of user input actions and
> | processes control messages sent to it by the IME or applications to
> | carry out a response to the user action.
> 
> > Or are you saying we should be calling ImmSetCompositionWindow at all?
> > That call was introduced as result of solving bugs #2570 and #2569, so
> > I think the call or its equivalent should stay.
> 
> I don't understand what this means.
> ImmSetCompositionWindow should be called, of course.
> 
> > Sorry I'm asking all these questions, but I don't know enough about
> > IME programming, and need to understand this in order to see that the
> > patch doesn't break anything else.
> 
> Current Emacs's IME implementation has this bug.
> It's almost imposible to input desired text because of the invisible
> composition window.
> This patch is nice improvement.

Thanks, I installed your change in the development sources, as commit
37e3549, and I'm marking this bug "done".

bug#11732: 24.1; Microsoft IME Japanese input problem

[Eli Zaretskii]

> Date: Thu, 19 Feb 2015 13:44:29 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 11732-done@debbugs.gnu.org
> 
> Thanks, I installed your change in the development sources, as commit
> 37e3549, and I'm marking this bug "done".

Unfortunately, it looks like that change has a devastating effect on
dialog boxes.  Try clicking File->Open File, and then click anywhere
inside the file selection dialog that opens: the dialog will disappear
from the display!

Can you suggest how to fix this new problem?  If we cannot find a
solution, I'm afraid we will have to revert that commit.

Thanks.

bug#11732: 24.1; Microsoft IME Japanese input problem

[Fujii Hironori]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

I'm sorry. i'll investigate the problem. But, no time now. Please revert it.
2015/03/07 5:29 "Eli Zaretskii" <eliz@gnu.org>:

> > Date: Thu, 19 Feb 2015 13:44:29 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 11732-done@debbugs.gnu.org
> >
> > Thanks, I installed your change in the development sources, as commit
> > 37e3549, and I'm marking this bug "done".
>
> Unfortunately, it looks like that change has a devastating effect on
> dialog boxes.  Try clicking File->Open File, and then click anywhere
> inside the file selection dialog that opens: the dialog will disappear
> from the display!
>
> Can you suggest how to fix this new problem?  If we cannot find a
> solution, I'm afraid we will have to revert that commit.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1169 bytes --]

bug#11732: 24.1; Microsoft IME Japanese input problem

[Eli Zaretskii]

> Date: Sat, 7 Mar 2015 07:37:57 +0900
> From: Fujii Hironori <fujii.hironori@gmail.com>
> Cc: 11732@debbugs.gnu.org
> 
> I'm sorry. i'll investigate the problem. But, no time now. Please revert it.

Thanks, I reverted only the part of the change that passed the message
to DefWindowProc if handling of WM_IME_STARTCOMPOSITION was
successful.  That seems to fix the problem with selection dialogs.

I will reopen the bug to show that it is not yet fixed.

bug#11732: 24.1; Microsoft IME Japanese input problem

[Fujii Hironori]

On Sat, Mar 7, 2015 at 5:29 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Unfortunately, it looks like that change has a devastating effect on
> dialog boxes.  Try clicking File->Open File, and then click anywhere
> inside the file selection dialog that opens: the dialog will disappear
> from the display!

I don't see such problem. I'm testing on Windows 7.
Could you tell me your Windows version.

This is my environment:

  In GNU Emacs 25.0.50.2 (x86_64-unknown-cygwin)
   of 2015-03-09 on win7-pc
  Repository revision: 6b134bcba9de5605086ee9382c0be13174480cac
  Windowing system distributor `Microsoft Corp.', version 6.1.7601
  Configured using:
   `configure --prefix=/cygdrive/c/home/fujii/opt/emacs --with-w32'

I applied a following patch to test:

diff --git a/src/w32fns.c b/src/w32fns.c
index 6abb433..685d30c 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -3330,7 +3330,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM
wParam, LPARAM lParam)
  dialog boxes, such as the file selection dialog or font
  selection dialog.  So something else is needed to fix the
  former without breaking the latter.  See bug#11732.  */
-      break;
+      goto dflt;

     case WM_IME_ENDCOMPOSITION:
       ignore_ime_char = 0;

bug#11732: 24.1; Microsoft IME Japanese input problem

[Eli Zaretskii]

> Date: Mon, 9 Mar 2015 11:13:43 +0900
> From: Fujii Hironori <fujii.hironori@gmail.com>
> Cc: 11732@debbugs.gnu.org
> 
> On Sat, Mar 7, 2015 at 5:29 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Unfortunately, it looks like that change has a devastating effect on
> > dialog boxes.  Try clicking File->Open File, and then click anywhere
> > inside the file selection dialog that opens: the dialog will disappear
> > from the display!
> 
> I don't see such problem. I'm testing on Windows 7.
> Could you tell me your Windows version.

I originally saw this on 32-bit XP, but now tried on 64-bit Windows 7,
and I see the same problem there.  So I don't think the Windows
version is a factor here.

> This is my environment:
> 
>   In GNU Emacs 25.0.50.2 (x86_64-unknown-cygwin)
>    of 2015-03-09 on win7-pc
>   Repository revision: 6b134bcba9de5605086ee9382c0be13174480cac
>   Windowing system distributor `Microsoft Corp.', version 6.1.7601
>   Configured using:
>    `configure --prefix=/cygdrive/c/home/fujii/opt/emacs --with-w32'

You are using a 64-bit Cygwin-w32 build.  I'm using a 32-bit MinGW
build:

  In GNU Emacs 25.0.50.232 (i686-pc-mingw32)
   of 2015-03-07 on HOME-C4E4A596F7
  Repository revision: 35e2b6ab4d28547ec079de18cf1cf65623e6909a
  Windowing system distributor `Microsoft Corp.', version 5.1.2600
  Configured using:
   `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3''

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

So either the way Cygwin implements reading of Windows messages from
/dev/windows, or the 64- vs 32-bit difference, is somehow responsible
for the differences in behavior.

Yet another difference is that I compiled without optimizations, but I
doubt if that could cause such an effect.

> I applied a following patch to test:
> 
> diff --git a/src/w32fns.c b/src/w32fns.c
> index 6abb433..685d30c 100644
> --- a/src/w32fns.c
> +++ b/src/w32fns.c
> @@ -3330,7 +3330,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM
> wParam, LPARAM lParam)
>   dialog boxes, such as the file selection dialog or font
>   selection dialog.  So something else is needed to fix the
>   former without breaking the latter.  See bug#11732.  */
> -      break;
> +      goto dflt;

Me too.

bug#11732: Follow-up to bug#11732

[Masayuki Hatta]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

Hi!

Recently I built Emacs 26.1 on Windows 10 (w/ MSYS2 64bit) with the
patch as mentioned earlier.  It works as expected and seems to bring
no lousy side effects anymore.

This problem has been making Emacs on Windows almost unusable for
Japanese users (so most of them use their patched binary).  Thus I
appreciate if you apply the patch again.

Best regards,
MH

-----
What I did:

Following the instruction in INSTALL.W64 almost verbatim, using the
latest (as of Jun. 26, 2018) MSYS2 64bit on Windows 10 Pro 1803.

Applied the attached patch (this is against 26.1, but I am pretty sure
you can apply it to HEAD) and build.

Tested with "File -> Open File" dialog and "(w32-font-select)" dialog.
Both seem to work.

Also tested with Microsoft IME, ATOK 2017, Google Japanese Input and
SKKFEP (those are popular Japanese input system for Windows).

Please let me know if you want me to do additional info, tests, etc.

-- 
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mhatta@gnu.org  / mhatta@debian.org / mhatta@opensource.jp /
hatta.masayuki@surugadai.ac.jp

[-- Attachment #2: diff --]
[-- Type: application/octet-stream, Size: 492 bytes --]

diff -urN emacs-26.1.orig/src/w32fns.c emacs-26.1/src/w32fns.c
--- emacs-26.1.orig/src/w32fns.c	2018-06-22 21:19:49.476879400 +0900
+++ emacs-26.1/src/w32fns.c	2018-06-26 18:00:54.780661600 +0900
@@ -4551,7 +4551,7 @@
 	 dialog boxes, such as the file selection dialog or font
 	 selection dialog.  So something else is needed to fix the
 	 former without breaking the latter.  See bug#11732.  */
-      break;
+      goto dflt;
 
     case WM_IME_ENDCOMPOSITION:
       ignore_ime_char = 0;

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> From: Masayuki Hatta <mhatta@gmail.com>
> Date: Tue, 26 Jun 2018 18:10:26 +0900
> 
> Recently I built Emacs 26.1 on Windows 10 (w/ MSYS2 64bit) with the
> patch as mentioned earlier.  It works as expected and seems to bring
> no lousy side effects anymore.
> 
> This problem has been making Emacs on Windows almost unusable for
> Japanese users (so most of them use their patched binary).  Thus I
> appreciate if you apply the patch again.
> 
> Tested with "File -> Open File" dialog and "(w32-font-select)" dialog.
> Both seem to work.

By "work", do you mean that clicking on anywhere inside these dialogs
leaves the dialogs visible?  On 2 different systems where I tried
this, after applying the patch, clicking anywhere in the dialog box
after it opens causes the dialog box to disappear: it is moved in z
order behind the frame from which the dialog was started.

It's possible that this is somehow related to the fact that I have my
Windows systems configured to enable "active window tracking"
(a.k.a. "focus follows mouse"), but even so, I'd like to be able to
avoid that adverse side effect on systems that are so configured.

Martin, could you perhaps look into this?  I tried various
"solutions", and the best I could come up with is the patch below.  If
it looks right to you (I'm really out of my depth here), then how do
we solve a similar problem in x-select-font?  It doesn't have a
callback function, and if I try adding one, the appearance of the
dialog changes(??) and the OK and CANCEL buttons no longer work.

Also, w32_dialog_in_progress seems to try to solve some similar
problem, but is not really working?  I guess I simply don't understand
why the dialog is lowered when I click on it.

Here's the patch for file_dialog_callback I came up with:

--- src/w32fns.c~	2018-06-11 06:32:21.000000000 +0300
+++ src/w32fns.c	2018-06-27 18:22:27.104228200 +0300
@@ -7520,6 +7520,12 @@ file_dialog_callback (HWND hwnd, UINT ms
 	  HWND list = GetDlgItem (dialog, FILE_NAME_LIST);
 	  int hdr_code;
 
+	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
+			SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
+			| SWP_NOOWNERZORDER);
+	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
+			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
+
 	  /* At least on Windows 7, the above attempt to get the window handle
 	     to the File Name Text Field fails.	 The following code does the
 	     job though.  Note that this code is based on my examination of the

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > Martin, could you perhaps look into this?

I'm afraid I won't be of much help in this matter.  IIUC there is a
patch I have to apply first and that patch breaks interaction with
dialog boxes on Windows in some way.  Which one is the patch I have to
apply?

martin

bug#11732: Follow-up to bug#11732

[Masayuki Hatta]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

Hi,

All you need is patches I attached, "diff" or "diff2" (not both).

Best regards,
MH
2018年6月28日(木) 17:04 martin rudalics <rudalics@gmx.at>:
>
>  > Martin, could you perhaps look into this?
>
> I'm afraid I won't be of much help in this matter.  IIUC there is a
> patch I have to apply first and that patch breaks interaction with
> dialog boxes on Windows in some way.  Which one is the patch I have to
> apply?
>
> martin



-- 
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mhatta@gnu.org  / mhatta@debian.org / mhatta@opensource.jp /
hatta.masayuki@surugadai.ac.jp

[-- Attachment #2: diff --]
[-- Type: application/octet-stream, Size: 492 bytes --]

diff -urN emacs-26.1.orig/src/w32fns.c emacs-26.1/src/w32fns.c
--- emacs-26.1.orig/src/w32fns.c	2018-06-22 21:19:49.476879400 +0900
+++ emacs-26.1/src/w32fns.c	2018-06-26 18:00:54.780661600 +0900
@@ -4551,7 +4551,7 @@
 	 dialog boxes, such as the file selection dialog or font
 	 selection dialog.  So something else is needed to fix the
 	 former without breaking the latter.  See bug#11732.  */
-      break;
+      goto dflt;
 
     case WM_IME_ENDCOMPOSITION:
       ignore_ime_char = 0;

[-- Attachment #3: diff2 --]
[-- Type: application/octet-stream, Size: 470 bytes --]

diff -urN emacs-26.1.orig/src/w32fns.c emacs-26.1/src/w32fns.c
--- emacs-26.1.orig/src/w32fns.c	2018-06-22 21:19:49.476879400 +0900
+++ emacs-26.1/src/w32fns.c	2018-06-28 17:55:48.237802900 +0900
@@ -4544,6 +4544,7 @@
 
 	  set_ime_composition_window_fn (context, &form);
 	  release_ime_context_fn (hwnd, context);
+	  goto dflt;
 	}
       /* We should "goto dflt" here to pass WM_IME_STARTCOMPOSITION to
 	 DefWindowProc, so that the composition window will actually

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > All you need is patches I attached, "diff" or "diff2" (not both).

Thank you.  I will try them (but certainly not on Windows 10 which I
don't have).

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Thu, 28 Jun 2018 14:25:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eliz@gnu.org, 11732@debbugs.gnu.org
> 
>  > All you need is patches I attached, "diff" or "diff2" (not both).
> 
> Thank you.  I will try them (but certainly not on Windows 10 which I
> don't have).

FWIW, I tried on XP and on Windows 7.

bug#11732: Follow-up to bug#11732

[Masayuki Hatta]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Hi, thanks for your reply!

2018年6月28日(木) 0:54 Eli Zaretskii <eliz@gnu.org>:
> > Tested with "File -> Open File" dialog and "(w32-font-select)" dialog.
> > Both seem to work.
>
> By "work", do you mean that clicking on anywhere inside these dialogs
> leaves the dialogs visible?

Yes, I was clicking around inside the dialog.

I made an animated GIF from screen capture.  Its size is around 8MB,
so I won't attach it to this mail.  Please see:

https://www.mhatta.org/test.gif

Also, I made a basically-the-same-but-a-bit-different patch.  In this
"diff2", I preserved break. I don't think it changes anything,
though...

> It's possible that this is somehow related to the fact that I have my
> Windows systems configured to enable "active window tracking"
> (a.k.a. "focus follows mouse"), but even so, I'd like to be able to
> avoid that adverse side effect on systems that are so configured.

Could you tell me how to set up "active windows tracking" on Windows
10?  I could find some information on the Net, but still not sure how
to do.

Best regards,
MH

--
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mhatta@gnu.org  / mhatta@debian.org / mhatta@opensource.jp /
hatta.masayuki@surugadai.ac.jp

[-- Attachment #2: diff2 --]
[-- Type: application/octet-stream, Size: 470 bytes --]

diff -urN emacs-26.1.orig/src/w32fns.c emacs-26.1/src/w32fns.c
--- emacs-26.1.orig/src/w32fns.c	2018-06-22 21:19:49.476879400 +0900
+++ emacs-26.1/src/w32fns.c	2018-06-28 17:55:48.237802900 +0900
@@ -4544,6 +4544,7 @@
 
 	  set_ime_composition_window_fn (context, &form);
 	  release_ime_context_fn (hwnd, context);
+	  goto dflt;
 	}
       /* We should "goto dflt" here to pass WM_IME_STARTCOMPOSITION to
 	 DefWindowProc, so that the composition window will actually

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> From: Masayuki Hatta <mhatta@gmail.com>
> Date: Thu, 28 Jun 2018 19:11:10 +0900
> Cc: rudalics@gmx.at, 11732@debbugs.gnu.org
> 
> > By "work", do you mean that clicking on anywhere inside these dialogs
> > leaves the dialogs visible?
> 
> Yes, I was clicking around inside the dialog.
> 
> I made an animated GIF from screen capture.  Its size is around 8MB,
> so I won't attach it to this mail.  Please see:
> 
> https://www.mhatta.org/test.gif

Thanks.  It could be that Windows 10 works differently.  Or it could
be some effect of the fact that you use a Japanese input method.  (Is
it feasible for you to check on a system without IME installed?)

> Also, I made a basically-the-same-but-a-bit-different patch.  In this
> "diff2", I preserved break. I don't think it changes anything,
> though...

You are right, it doesn't.

> > It's possible that this is somehow related to the fact that I have my
> > Windows systems configured to enable "active window tracking"
> > (a.k.a. "focus follows mouse"), but even so, I'd like to be able to
> > avoid that adverse side effect on systems that are so configured.
> 
> Could you tell me how to set up "active windows tracking" on Windows
> 10?  I could find some information on the Net, but still not sure how
> to do.

Try these links, one of them will do the trick, I hope:

  https://joelpurra.com/projects/X-Mouse_Controls/
  https://winaero.com/blog/turn-on-xmouse-active-window-tracking-focus-follows-mouse-pointer-feature-in-windows-8-1-windows-8-and-windows-7/
  https://answers.microsoft.com/en-us/windows/forum/windows_10-start-winpc/active-window-tracking-in-windows-10/86c73d65-9d3e-4616-ab17-6d5c5624f777

bug#11732: Follow-up to bug#11732

[Noam Postavsky]

On 28 June 2018 at 09:28, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks.  It could be that Windows 10 works differently.  Or it could
> be some effect of the fact that you use a Japanese input method.  (Is
> it feasible for you to check on a system without IME installed?)

>> > It's possible that this is somehow related to the fact that I have my
>> > Windows systems configured to enable "active window tracking"
>> > (a.k.a. "focus follows mouse"), but even so, I'd like to be able to
>> > avoid that adverse side effect on systems that are so configured.
>>
>> Could you tell me how to set up "active windows tracking" on Windows
>> 10?  I could find some information on the Net, but still not sure how
>> to do.
>
> Try these links, one of them will do the trick, I hope:
>

I couldn't find any problem in dialog boxes on my Windows 10 box after
applying the patch, I don't have Japanese IME enabled/installed, as
far as I know.

>   https://winaero.com/blog/turn-on-xmouse-active-window-tracking-focus-follows-mouse-pointer-feature-in-windows-8-1-windows-8-and-windows-7/

I tried also after applying the "activate a window by hovering over it
with a mouse", and it made no difference (to Emacs, that is).

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 28 Jun 2018 15:17:34 -0400
> Cc: Masayuki Hatta <mhatta@gmail.com>, 11732@debbugs.gnu.org
> 
> I tried also after applying the "activate a window by hovering over it
> with a mouse", and it made no difference (to Emacs, that is).

Thanks for trying.  Nevertheless, the effect is 100% reproducible on 2
different systems where I regularly work, so I'd like to try to get to
the bottom of that.

bug#11732: Follow-up to bug#11732

[Masayuki Hatta]

Hi,

I also tried XMouse settings[*] on Windows 10 Pro 1803 64bit.  It
seems the patched binary's dialog boxes work as expected.  I guess
there are some bugs in XP and Win7 but not in Win10.

[*] I installed Winaero Tweaker
(https://winaero.com/comment.php?comment.news.1836) and set XMouse
Options' "Enable window tracking" and "Enable window raising".  Added
bonus, now I understand what XMouse means ;-)

Best regards,
MH

2018年6月29日(金) 4:24 Eli Zaretskii <eliz@gnu.org>:
>
> > From: Noam Postavsky <npostavs@gmail.com>
> > Date: Thu, 28 Jun 2018 15:17:34 -0400
> > Cc: Masayuki Hatta <mhatta@gmail.com>, 11732@debbugs.gnu.org
> >
> > I tried also after applying the "activate a window by hovering over it
> > with a mouse", and it made no difference (to Emacs, that is).
>
> Thanks for trying.  Nevertheless, the effect is 100% reproducible on 2
> different systems where I regularly work, so I'd like to try to get to
> the bottom of that.



--
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mhatta@gnu.org  / mhatta@debian.org / mhatta@opensource.jp /
hatta.masayuki@surugadai.ac.jp

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > I also tried XMouse settings[*] on Windows 10 Pro 1803 64bit.  It
 > seems the patched binary's dialog boxes work as expected.  I guess
 > there are some bugs in XP and Win7 but not in Win10.

If worse comes to worst we could make this optional.

 > [*] I installed Winaero Tweaker
 > (https://winaero.com/comment.php?comment.news.1836) and set XMouse
 > Options' "Enable window tracking" and "Enable window raising".  Added
 > bonus, now I understand what XMouse means ;-)

Can you try without "Enable window raising" (that's what Eli has)?

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Fri, 29 Jun 2018 10:43:27 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@gmail.com, 11732@debbugs.gnu.org
> 
>  > I also tried XMouse settings[*] on Windows 10 Pro 1803 64bit.  It
>  > seems the patched binary's dialog boxes work as expected.  I guess
>  > there are some bugs in XP and Win7 but not in Win10.
> 
> If worse comes to worst we could make this optional.

Nah, it doesn't sound justified.  I have a workaround, so the problem
is not acute enough to justify a knob in Emacs.

>  > [*] I installed Winaero Tweaker
>  > (https://winaero.com/comment.php?comment.news.1836) and set XMouse
>  > Options' "Enable window tracking" and "Enable window raising".  Added
>  > bonus, now I understand what XMouse means ;-)
> 
> Can you try without "Enable window raising" (that's what Eli has)?

Yes, windows get focus here without raising them.

bug#11732: Follow-up to bug#11732

[Masayuki Hatta]

Hi,

2018年6月29日(金) 17:43 martin rudalics <rudalics@gmx.at>:

>  > [*] I installed Winaero Tweaker
>  > (https://winaero.com/comment.php?comment.news.1836) and set XMouse
>  > Options' "Enable window tracking" and "Enable window raising".  Added
>  > bonus, now I understand what XMouse means ;-)
>
> Can you try without "Enable window raising" (that's what Eli has)?

I tried enabling window tracking without window raising, and Emacs
dialogs still work okay (and window tracking works as expected, too).

Best regards,
MH

--
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mhatta@gnu.org  / mhatta@debian.org / mhatta@opensource.jp /
hatta.masayuki@surugadai.ac.jp

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> From: Masayuki Hatta <mhatta@gmail.com>
> Date: Sat, 30 Jun 2018 12:14:28 +0900
> Cc: eliz@gnu.org, Noam Postavsky <npostavs@gmail.com>, 11732@debbugs.gnu.org
> 
> >  > [*] I installed Winaero Tweaker
> >  > (https://winaero.com/comment.php?comment.news.1836) and set XMouse
> >  > Options' "Enable window tracking" and "Enable window raising".  Added
> >  > bonus, now I understand what XMouse means ;-)
> >
> > Can you try without "Enable window raising" (that's what Eli has)?
> 
> I tried enabling window tracking without window raising, and Emacs
> dialogs still work okay (and window tracking works as expected, too).

Did you have other non-minimized windows on the desktop when you tried
that?  Or were Emacs's the only windows?  Please try with other
windows open and overlapping the Emacs's windows.

Thanks.

bug#11732: Follow-up to bug#11732

[Masayuki Hatta]

Hi,

2018年6月30日(土) 16:46 Eli Zaretskii <eliz@gnu.org>:

> > I tried enabling window tracking without window raising, and Emacs
> > dialogs still work okay (and window tracking works as expected, too).
>
> Did you have other non-minimized windows on the desktop when you tried
> that?  Or were Emacs's the only windows?  Please try with other
> windows open and overlapping the Emacs's windows.

I prepared another screen capture anime GIF:

https://www.mhatta.org/test2.gif

Note that I can scroll up/down a background Firefox thanks to window
tracking sans raising.

Best regards,
MH

-- 
Masayuki Hatta
Associate Professor, Faculty of Economics and Management, Surugadai
University, Japan

http://about.me/mhatta

mhatta@gnu.org  / mhatta@debian.org / mhatta@opensource.jp /
hatta.masayuki@surugadai.ac.jp

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> From: Masayuki Hatta <mhatta@gmail.com>
> Date: Fri, 29 Jun 2018 16:39:36 +0900
> Cc: npostavs@gmail.com, 11732@debbugs.gnu.org
> 
> I also tried XMouse settings[*] on Windows 10 Pro 1803 64bit.  It
> seems the patched binary's dialog boxes work as expected.  I guess
> there are some bugs in XP and Win7 but not in Win10.

Thanks for testing.  FWIW, I doubt these are bugs in Windows.  I think
this is something we do that is not 100% TRT, and it sometimes
misfires.

Anyway, let's see what Martin will uncover based on my attempts, and
if the conclusion is that this is something specific to my personal
configurations, we will install the change.  I have (a slightly
annoying) workaround for the problem anyway, I just wish it didn't
happen at all.

bug#11732: Follow-up to bug#11732

[martin rudalics]

 >> Tested with "File -> Open File" dialog and "(w32-font-select)" dialog.
 >> Both seem to work.
 >
 > By "work", do you mean that clicking on anywhere inside these dialogs
 > leaves the dialogs visible?  On 2 different systems where I tried
 > this, after applying the patch, clicking anywhere in the dialog box
 > after it opens causes the dialog box to disappear: it is moved in z
 > order behind the frame from which the dialog was started.
 >
 > It's possible that this is somehow related to the fact that I have my
 > Windows systems configured to enable "active window tracking"
 > (a.k.a. "focus follows mouse"), but even so, I'd like to be able to
 > avoid that adverse side effect on systems that are so configured.

I now tried on my standard XP machine and do not see any adverse
effects with file, directory and font dialog boxes.  Maybe it's
related to the fact that I have "focus follows mouse" plus
"autoraise".  Could you try with such a setting?  I am very reluctant
to change mine becaue I have some additional mouse software working as
well.

 > +	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
 > +			SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
 > +			| SWP_NOOWNERZORDER);
 > +	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
 > +			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);

What was the more or less precise rationale for this unless it was
pure experimenting (in particular the SWP_NOACTIVATE in the first
call)?  The patch does not have any (adverse) effects here so if it
solves the problem for you, I see no problem applying it.

 > then how do
 > we solve a similar problem in x-select-font?  It doesn't have a
 > callback function, and if I try adding one, the appearance of the
 > dialog changes(??) and the OK and CANCEL buttons no longer work.

Can you send me the code you tried?

 > Also, w32_dialog_in_progress seems to try to solve some similar
 > problem, but is not really working?  I guess I simply don't understand
 > why the dialog is lowered when I click on it.

In w32_dialog_in_progress I tried to solve a relatively simple
problem: When a frame is in the TOPMOST group and I start a dialog,
that frame would obscure the dialog box.  So I temporarily remove the
frame from the TOPMOST group and move it back when the dialog ends.

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Fri, 29 Jun 2018 10:43:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 11732@debbugs.gnu.org
> 
> I now tried on my standard XP machine and do not see any adverse
> effects with file, directory and font dialog boxes.  Maybe it's
> related to the fact that I have "focus follows mouse" plus
> "autoraise".  Could you try with such a setting?

Will do, just not today.

>  > +	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
>  > +			SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
>  > +			| SWP_NOOWNERZORDER);
>  > +	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
>  > +			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
> 
> What was the more or less precise rationale for this unless it was
> pure experimenting (in particular the SWP_NOACTIVATE in the first
> call)?

SWP_NOACTIVATE was just a copy-paste from similar calls elsewhere.
The rationale for the code was to tell windows to put the frame from
which the file-selection dialog popped behind the dialog.  If
w32_dialog_in_progress is meant to do that, I don't understand how it
does that; can you explain?

(Btw, as long as we are discussing this: the above-suspended value of
the z-group frame parameter appears to be completely undocumented.)

> The patch does not have any (adverse) effects here so if it
> solves the problem for you, I see no problem applying it.

OK.

>  > then how do
>  > we solve a similar problem in x-select-font?  It doesn't have a
>  > callback function, and if I try adding one, the appearance of the
>  > dialog changes(??) and the OK and CANCEL buttons no longer work.
> 
> Can you send me the code you tried?

Below.  It's possible I've put the code in the wrong WM_* message, but
I'm really stabbing in the dark in these matters.

> In w32_dialog_in_progress I tried to solve a relatively simple
> problem: When a frame is in the TOPMOST group and I start a dialog,
> that frame would obscure the dialog box.  So I temporarily remove the
> frame from the TOPMOST group and move it back when the dialog ends.

Can you show me some Lisp to try this situation?

Here's the patch I used with the font-selection dialog:

--- src/w32font.c~	2018-01-03 13:09:26.000000000 +0200
+++ src/w32font.c	2018-06-27 18:19:04.140101200 +0300
@@ -2505,6 +2505,24 @@ compute_metrics (HDC dc, struct w32font_
     metrics->status = W32METRIC_FAIL;
 }
 
+static UINT_PTR CALLBACK
+font_dialog_callback (HWND hdlg, UINT msg, WPARAM wParam, LPARAM lParam)
+{
+  static HWND cf_hwnd;
+
+  if (msg == WM_INITDIALOG)
+    cf_hwnd = ((CHOOSEFONT *)lParam)->hwndOwner;
+
+  if (msg == WM_NOTIFY)
+    {
+      SetWindowPos (hdlg, HWND_NOTOPMOST, 0, 0, 0, 0,
+		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
+		    | SWP_NOOWNERZORDER);
+      SetWindowPos (cf_hwnd, hdlg, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
+    }
+  return 0;
+}
+
 DEFUN ("x-select-font", Fx_select_font, Sx_select_font, 0, 2, 0,
        doc: /* Read a font name using a W32 font selection dialog.
 Return fontconfig style font string corresponding to the selection.
@@ -2527,7 +2545,8 @@ in the font selection dialog. */)
 
   cf.lStructSize = sizeof (cf);
   cf.hwndOwner = FRAME_W32_WINDOW (f);
-  cf.Flags = CF_FORCEFONTEXIST | CF_SCREENFONTS | CF_NOVERTFONTS;
+  cf.Flags = CF_FORCEFONTEXIST | CF_SCREENFONTS | CF_NOVERTFONTS | CF_ENABLEHOOK;
+  cf.lpfnHook = font_dialog_callback;
 
   /* If exclude_proportional is non-nil, limit the selection to
      monospaced fonts.  */

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > Will do, just not today.
 >
 >>   > +	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
 >>   > +			SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
 >>   > +			| SWP_NOOWNERZORDER);
 >>   > +	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
 >>   > +			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
 >>
 >> What was the more or less precise rationale for this unless it was
 >> pure experimenting (in particular the SWP_NOACTIVATE in the first
 >> call)?
 >
 > SWP_NOACTIVATE was just a copy-paste from similar calls elsewhere.
 > The rationale for the code was to tell windows to put the frame from
 > which the file-selection dialog popped behind the dialog.

IMO these two calls are not entirely kosher - after all the dialog box
is in the topmost group and the selected frame not.  So some other
application that interrupts the dialog might mess things up.  Anyway,
I would try moving the SWP_NOACTIVATE from the dialog to the selected
frame call like

	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
			SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
			| SWP_NOACTIVATE);

Note that I can't test it because nothing is broken here in the first
place.

 > If
 > w32_dialog_in_progress is meant to do that, I don't understand how it
 > does that; can you explain?

All w32_dialog_in_progress does is moving frames from and to the
topmost group.  I don't like putting frames in the topmost group - but
if one doesn't use child frames and wants a support frame on top of a
normal frame, setting just the z-order is not enough: You run into an
eternal loop where Emacs tries to put the support frame above the
normal one and Windows immediately reverses that because I obviously
want the normal frame to retain focus.

 > (Btw, as long as we are discussing this: the above-suspended value of
 > the z-group frame parameter appears to be completely undocumented.)

Conceptually, users should never see it: It is set only during
dialogs.  But if you think it should be documented I'll do that.

 > Below.  It's possible I've put the code in the wrong WM_* message, but
 > I'm really stabbing in the dark in these matters.
 >
 >> In w32_dialog_in_progress I tried to solve a relatively simple
 >> problem: When a frame is in the TOPMOST group and I start a dialog,
 >> that frame would obscure the dialog box.  So I temporarily remove the
 >> frame from the TOPMOST group and move it back when the dialog ends.
 >
 > Can you show me some Lisp to try this situation?
 >
 > Here's the patch I used with the font-selection dialog:

 > +  if (msg == WM_NOTIFY)
 > +    {
 > +      SetWindowPos (hdlg, HWND_NOTOPMOST, 0, 0, 0, 0,
 > +		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
 > +		    | SWP_NOOWNERZORDER);

The HWND_NOTOPMOST doesn't look good - dialog boxes should be topmost.
Could you try with

static UINT_PTR CALLBACK
font_dialog_callback (HWND hdlg, UINT msg, WPARAM wParam, LPARAM lParam)
{
   static HWND cf_hwnd;

   if (msg == WM_INITDIALOG)
     cf_hwnd = ((CHOOSEFONT *)lParam)->hwndOwner;

   if (msg == WM_NOTIFY)
     {
       SetWindowPos (hdlg, HWND_TOPMOST, 0, 0, 0, 0,
		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
       SetWindowPos (cf_hwnd, hdlg, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
		    | SWP_NOACTIVATE);
     }
   return 0;
}

It doesn't show any strange effects here, at least.

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Sat, 30 Jun 2018 10:06:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
>  > SWP_NOACTIVATE was just a copy-paste from similar calls elsewhere.
>  > The rationale for the code was to tell windows to put the frame from
>  > which the file-selection dialog popped behind the dialog.
> 
> IMO these two calls are not entirely kosher - after all the dialog box
> is in the topmost group and the selected frame not.  So some other
> application that interrupts the dialog might mess things up.  Anyway,
> I would try moving the SWP_NOACTIVATE from the dialog to the selected
> frame call like
> 
> 	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
> 			SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
> 	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
> 			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
> 			| SWP_NOACTIVATE);
> 
> Note that I can't test it because nothing is broken here in the first
> place.

I think I tried with HWND_TOPMOST, but what it does (and I see it now
with your suggestion) is it doesn't allow raising any other
(non-Emacs) window above the file-selection dialog (in the z-order).
The original code didn't behave that way, so I looked for a better
option, and HWND_NOTOPMOST seemed to do the job...

>  > If
>  > w32_dialog_in_progress is meant to do that, I don't understand how it
>  > does that; can you explain?
> 
> All w32_dialog_in_progress does is moving frames from and to the
> topmost group.  I don't like putting frames in the topmost group - but
> if one doesn't use child frames and wants a support frame on top of a
> normal frame, setting just the z-order is not enough: You run into an
> eternal loop where Emacs tries to put the support frame above the
> normal one and Windows immediately reverses that because I obviously
> want the normal frame to retain focus.

By "support frame" here you mean the dialog box?  If not, then why is
this function called every time we are about to show a dialog box?

>  > (Btw, as long as we are discussing this: the above-suspended value of
>  > the z-group frame parameter appears to be completely undocumented.)
> 
> Conceptually, users should never see it: It is set only during
> dialogs.  But if you think it should be documented I'll do that.

If it's an internal setting that should never be seen outside the C
sources, then it should be documented in the commentary preceding
x_set_z_group, and the comment should tell this value is internal, so
that whoever reads the code will understand what each setting wants to
achieve.

>  > +  if (msg == WM_NOTIFY)
>  > +    {
>  > +      SetWindowPos (hdlg, HWND_NOTOPMOST, 0, 0, 0, 0,
>  > +		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
>  > +		    | SWP_NOOWNERZORDER);
> 
> The HWND_NOTOPMOST doesn't look good - dialog boxes should be topmost.
> Could you try with
> 
> static UINT_PTR CALLBACK
> font_dialog_callback (HWND hdlg, UINT msg, WPARAM wParam, LPARAM lParam)
> {
>    static HWND cf_hwnd;
> 
>    if (msg == WM_INITDIALOG)
>      cf_hwnd = ((CHOOSEFONT *)lParam)->hwndOwner;
> 
>    if (msg == WM_NOTIFY)
>      {
>        SetWindowPos (hdlg, HWND_TOPMOST, 0, 0, 0, 0,
> 		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
>        SetWindowPos (cf_hwnd, hdlg, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
> 		    | SWP_NOACTIVATE);
>      }
>    return 0;
> }

This looks good on XP, I will try on Windows 7 later.  Curiously,
HWND_TOPMOST here doesn't prevent raising other windows above the
dialog box, as it does with file selector.

> It doesn't show any strange effects here, at least.

I think the problems I saw were on Windows 7.  Will check.

Thanks.

bug#11732: Follow-up to bug#11732

[martin rudalics]

 >> 	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
 >> 			SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
 >> 	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
 >> 			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
 >> 			| SWP_NOACTIVATE);
 >>
 >> Note that I can't test it because nothing is broken here in the first
 >> place.
 >
 > I think I tried with HWND_TOPMOST,

You had HWND_TOPMOST here in the patch you attached to the first
message I read.  I only moved the SWP_NOACTIVATE from the dialog
window to that of the selected frame.

 > but what it does (and I see it now
 > with your suggestion) is it doesn't allow raising any other
 > (non-Emacs) window above the file-selection dialog (in the z-order).
 > The original code didn't behave that way, so I looked for a better
 > option, and HWND_NOTOPMOST seemed to do the job...

I probably don't understand the original problem sketched as

	 But doing so causes trouble with displaying
	 dialog boxes, such as the file selection dialog or font
	 selection dialog.

A dialog box uses a modal window on top of the owning window.
Anything else will almost certainly cause problems with any windowing
system we use.

 > By "support frame" here you mean the dialog box?

No.  I mean a frame that in many regards acts like a child frame but
uses a top-level window instead of a child window.

 > If not, then why is
 > this function called every time we are about to show a dialog box?

Because a dialog box should appear on top of any support frame.  And
it doesn't necessarily do that when both are in the topmost group.
That's why I temporarily remove the support frame from that group.

 > If it's an internal setting that should never be seen outside the C
 > sources, then it should be documented in the commentary preceding
 > x_set_z_group, and the comment should tell this value is internal, so
 > that whoever reads the code will understand what each setting wants to
 > achieve.

OK.  I'll do that.

 > This looks good on XP,

Your initial patch for the font dialog showed many bad symptoms
(buttons not responding, couldn't drag the dialog box, combo box for
script dropping down beneath the dialog box) on XP.

 > I will try on Windows 7 later.  Curiously,
 > HWND_TOPMOST here doesn't prevent raising other windows above the
 > dialog box, as it does with file selector.

The windows of other applications (including other Emacs instances) or
that of the Emacs instance involved in the dialog?

Note that Emacs waits for the dialog to finish and doesn't redisplay
in this time.  Hence if during a dialog I temporarily show another
window on top of the dialog and remove that other window, the text in
the Emacs frame is usually garbled until the dialog finishes.

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Sat, 30 Jun 2018 14:51:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
>  >> 	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
>  >> 			SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
>  >> 	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
>  >> 			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
>  >> 			| SWP_NOACTIVATE);
>  >>
>  >> Note that I can't test it because nothing is broken here in the first
>  >> place.
>  >
>  > I think I tried with HWND_TOPMOST,
> 
> You had HWND_TOPMOST here in the patch you attached to the first
> message I read.

Right, sorry.  The issue still stands, though.

>  > but what it does (and I see it now
>  > with your suggestion) is it doesn't allow raising any other
>  > (non-Emacs) window above the file-selection dialog (in the z-order).
>  > The original code didn't behave that way, so I looked for a better
>  > option, and HWND_NOTOPMOST seemed to do the job...
> 
> I probably don't understand the original problem sketched as
> 
> 	 But doing so causes trouble with displaying
> 	 dialog boxes, such as the file selection dialog or font
> 	 selection dialog.
> 
> A dialog box uses a modal window on top of the owning window.

I didn't mean the owing window, I meant the other windows on the
desktop, belonging to applications other than Emacs.  Using
HWND_TOPMOST makes me unable to raise any window of another
application above the dialog box in the z-order.  The existing code
does allow that.

>  > If not, then why is
>  > this function called every time we are about to show a dialog box?
> 
> Because a dialog box should appear on top of any support frame.  And
> it doesn't necessarily do that when both are in the topmost group.
> That's why I temporarily remove the support frame from that group.

OK, so the call to w32_dialog_in_progress has nothing to do with the
z-order of the dialog wrt its owning frame, right?

>  > I will try on Windows 7 later.  Curiously,
>  > HWND_TOPMOST here doesn't prevent raising other windows above the
>  > dialog box, as it does with file selector.
> 
> The windows of other applications (including other Emacs instances) or
> that of the Emacs instance involved in the dialog?

The former.

> Note that Emacs waits for the dialog to finish and doesn't redisplay
> in this time.  Hence if during a dialog I temporarily show another
> window on top of the dialog and remove that other window, the text in
> the Emacs frame is usually garbled until the dialog finishes.

Yes, I know.  That wasn't what I was worried about.

Thanks.

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > I didn't mean the owing window, I meant the other windows on the
 > desktop, belonging to applications other than Emacs.  Using
 > HWND_TOPMOST makes me unable to raise any window of another
 > application above the dialog box in the z-order.  The existing code
 > does allow that.

Because it leaves the entire z-order handling to Windows.  The idea of
using a dialog box is that you tell Windows to glue together the frame
with the dialog box and let no other window enter the z-order in
between these two.  How Windows implements that has likely never been
analyzed so we won't know.  But I suppose that Windows simply
intercepts all (implicit) z-reorder requests to let no other window
in.

Now if Masayuki's proposal breaks this relationship please tell me
exactly how.  IIUC you mean to say that with focus follows mouse sans
autoraise the two Emacs windows (always) appear on top of other
applications.  But sans autoraise means that the z-order should not
change when you move the mouse so you apparently clicked into another
application's window or tried to Alt-tab to it.  Please clarify this
giving us the precise steps you used.

In either case having Emacs fiddle with the z-order and activation of
dialog box windows is dangerous and should be avoided in the first
place.  Also, the code below is creepy and certainly not what a
well-behaved application is supposed to do:

	      EnableWindow (edit_control, FALSE);
	      /* Note that at least on Windows 7, the above call to EnableWindow
		 disables the window that would ordinarily have focus.	If we
		 do not set focus to some other window here, focus will land in
		 no man's land and the user will be unable to tab through the
		 dialog box (pressing tab will only result in a beep).
		 Avoid that problem by setting focus to the list here.	*/
	      if (hdr_code == CDN_INITDONE)
		SetFocus (list);

 > OK, so the call to w32_dialog_in_progress has nothing to do with the
 > z-order of the dialog wrt its owning frame, right?

Right.  I meanwhile tried to document this better.  Please have a
look.

 >> Note that Emacs waits for the dialog to finish and doesn't redisplay
 >> in this time.  Hence if during a dialog I temporarily show another
 >> window on top of the dialog and remove that other window, the text in
 >> the Emacs frame is usually garbled until the dialog finishes.
 >
 > Yes, I know.  That wasn't what I was worried about.

I know.  My note was just a reminder that moving other windows above
the Emacs frame while a dialog is in progress doesn't result in a
pleasant user experience anyway.

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Sun, 01 Jul 2018 11:00:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
>  > I didn't mean the owing window, I meant the other windows on the
>  > desktop, belonging to applications other than Emacs.  Using
>  > HWND_TOPMOST makes me unable to raise any window of another
>  > application above the dialog box in the z-order.  The existing code
>  > does allow that.
> 
> Because it leaves the entire z-order handling to Windows.  The idea of
> using a dialog box is that you tell Windows to glue together the frame
> with the dialog box and let no other window enter the z-order in
> between these two.  How Windows implements that has likely never been
> analyzed so we won't know.  But I suppose that Windows simply
> intercepts all (implicit) z-reorder requests to let no other window
> in.

Got it, thanks.

> Now if Masayuki's proposal breaks this relationship please tell me
> exactly how.  IIUC you mean to say that with focus follows mouse sans
> autoraise the two Emacs windows (always) appear on top of other
> applications.  But sans autoraise means that the z-order should not
> change when you move the mouse so you apparently clicked into another
> application's window or tried to Alt-tab to it.  Please clarify this
> giving us the precise steps you used.

The dialog appears on top of the frame from which it was invoked as
usual, and as expected (since Windows raises the frame when you click
on its menu, the frame is indeed usually on top of the other apps,
modulo apps like Task Manager that force themselves on top of
everything).  Then any click _anywhere_ inside the dialog causes the
dialog to disappear, because the owning frame is raised to cover it.
A second click at the same coordinates causes the dialog to be shown
blinking, as when you click on some part outside the dialog.  My
workaround for that is to drag the dialog outside of its owning frame,
and then use it as usual.

Did I explain the situation clearly?

Btw, I have now established that focus follows mouse causes this: if I
disable it, the problem disappears.  And autoraise doesn't affect the
issue in any way.  I tried both X-Mouse Controls and Winaero Tweaker,
on 2 different Windows 7 systems, with the same result: enabling
focus-follows-mouse causes the issue, disabling it makes the issue go
away.  (Of course, both Windows 7 systems were configured by yours
truly, so maybe there's some other factor acting as a catalyst.  But
all else being equal, just turning on and off focus-follows-mouse
causes the problem to appear or disappear on those 2 systems.)

>  > OK, so the call to w32_dialog_in_progress has nothing to do with the
>  > z-order of the dialog wrt its owning frame, right?
> 
> Right.  I meanwhile tried to document this better.  Please have a
> look.

LGTM, thanks.

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > The dialog appears on top of the frame from which it was invoked as
 > usual, and as expected (since Windows raises the frame when you click
 > on its menu, the frame is indeed usually on top of the other apps,
 > modulo apps like Task Manager that force themselves on top of
 > everything).  Then any click _anywhere_ inside the dialog causes the
 > dialog to disappear, because the owning frame is raised to cover it.
 > A second click at the same coordinates causes the dialog to be shown
 > blinking, as when you click on some part outside the dialog.

Confirmed (finally, it took me some time to get my Windows 7 version
up and running again) with the autoraising option set.  The blinking
might be caused by some z-order fight maybe stopped by some timeout.

 > My
 > workaround for that is to drag the dialog outside of its owning frame,
 > and then use it as usual.

That's no workaround on my Thinkpad.  The two windows will always
overlap each other and I cannot shrink any of them because Windows
does not allow it.

 > Did I explain the situation clearly?

You did.

 > Btw, I have now established that focus follows mouse causes this: if I
 > disable it, the problem disappears.  And autoraise doesn't affect the
 > issue in any way.  I tried both X-Mouse Controls and Winaero Tweaker,
 > on 2 different Windows 7 systems, with the same result: enabling
 > focus-follows-mouse causes the issue, disabling it makes the issue go
 > away.  (Of course, both Windows 7 systems were configured by yours
 > truly, so maybe there's some other factor acting as a catalyst.  But
 > all else being equal, just turning on and off focus-follows-mouse
 > causes the problem to appear or disappear on those 2 systems.)

No further explanations needed, the problem is clearly visible here
now.  Do you have any explanation why calling DefWindowProc when
handling WM_IME_STARTCOMPOSITION causes this aberrant behavior and not
any of the other cases where we call DefWindowProc?

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Tue, 03 Jul 2018 10:29:59 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
> No further explanations needed, the problem is clearly visible here
> now.  Do you have any explanation why calling DefWindowProc when
> handling WM_IME_STARTCOMPOSITION causes this aberrant behavior and not
> any of the other cases where we call DefWindowProc?

None whatsoever.

Moreover, I sometimes see the same problem in my "normal" Emacs
session running 26.1 sources where this change was not done (but in
"emacs -Q" I cannot trigger the problem unless I make the change).

So I think it's not the proposed change that does it, it's something
we don't do entirely correctly that interacts badly with
focus-follows-mouse configuration.  Which is why I said that unless
you have ideas how to fix this, we should simply install the proposed
change, and deal with the dialog problems separately, perhaps using
the changes I tried and you fixed.

bug#11732: Follow-up to bug#11732

[Tak Kunihiro]

> Which is why I said that unless you have ideas how to fix this, we
> should simply install the proposed change, and deal with the dialog
> problems separately, perhaps using the changes I tried and you fixed.

The proposed change is very beneficial for me.  Then I can ask people
using MS Windows to type in Japanese character using Emacs in a Texinfo
document.  Could you install it!?

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> From: Tak Kunihiro <homeros.misasa@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>,  11732@debbugs.gnu.org,  mhatta@gmail.com
> Cc: tkk@misasa.okayama-u.ac.jp
> Date: Sat, 07 Jul 2018 16:45:31 +0900
> 
> > Which is why I said that unless you have ideas how to fix this, we
> > should simply install the proposed change, and deal with the dialog
> > problems separately, perhaps using the changes I tried and you fixed.
> 
> The proposed change is very beneficial for me.  Then I can ask people
> using MS Windows to type in Japanese character using Emacs in a Texinfo
> document.  Could you install it!?

I'm waiting for Martin to tell whether he has some ideas about the
negative effects this has on popup dialogs.  We will install the
change after that, with or without the remedies for those problems.

bug#11732: Follow-up to bug#11732

[martin rudalics]

 > Moreover, I sometimes see the same problem in my "normal" Emacs
 > session running 26.1 sources where this change was not done (but in
 > "emacs -Q" I cannot trigger the problem unless I make the change).

On XP or 7?

 > So I think it's not the proposed change that does it, it's something
 > we don't do entirely correctly that interacts badly with
 > focus-follows-mouse configuration.  Which is why I said that unless
 > you have ideas how to fix this, we should simply install the proposed
 > change, and deal with the dialog problems separately, perhaps using
 > the changes I tried and you fixed.

These changes are not yet fixed.  At least here the selected frame
remains topmost even after the dialog finished which is even worse
than the disease it tried to cure.  I have to remove the frame from
that group, probably in w32_dialog_in_progress.

 >> The proposed change is very beneficial for me.  Then I can ask people
 >> using MS Windows to type in Japanese character using Emacs in a Texinfo
 >> document.  Could you install it!?
 >
 > I'm waiting for Martin to tell whether he has some ideas about the
 > negative effects this has on popup dialogs.  We will install the
 > change after that, with or without the remedies for those problems.

Please install without any remedies.  If I find a way to fix this I'll
get back to you.

martin

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Sat, 07 Jul 2018 12:21:35 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 11732@debbugs.gnu.org, mhatta@gmail.com
> 
>  > Moreover, I sometimes see the same problem in my "normal" Emacs
>  > session running 26.1 sources where this change was not done (but in
>  > "emacs -Q" I cannot trigger the problem unless I make the change).
> 
> On XP or 7?

Both.

>  > I'm waiting for Martin to tell whether he has some ideas about the
>  > negative effects this has on popup dialogs.  We will install the
>  > change after that, with or without the remedies for those problems.
> 
> Please install without any remedies.  If I find a way to fix this I'll
> get back to you.

Done.

I'm closing the bug, as the problem with focus-follows-mouse are
probably not directly related.

Thanks.

bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Sat, 30 Jun 2018 14:32:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 11732@debbugs.gnu.org, mhatta@gmail.com
> 
> >  > +  if (msg == WM_NOTIFY)
> >  > +    {
> >  > +      SetWindowPos (hdlg, HWND_NOTOPMOST, 0, 0, 0, 0,
> >  > +		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
> >  > +		    | SWP_NOOWNERZORDER);
> > 
> > The HWND_NOTOPMOST doesn't look good - dialog boxes should be topmost.
> > Could you try with
> > 
> > static UINT_PTR CALLBACK
> > font_dialog_callback (HWND hdlg, UINT msg, WPARAM wParam, LPARAM lParam)
> > {
> >    static HWND cf_hwnd;
> > 
> >    if (msg == WM_INITDIALOG)
> >      cf_hwnd = ((CHOOSEFONT *)lParam)->hwndOwner;
> > 
> >    if (msg == WM_NOTIFY)
> >      {
> >        SetWindowPos (hdlg, HWND_TOPMOST, 0, 0, 0, 0,
> > 		    SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
> >        SetWindowPos (cf_hwnd, hdlg, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
> > 		    | SWP_NOACTIVATE);
> >      }
> >    return 0;
> > }
> 
> This looks good on XP, I will try on Windows 7 later.  Curiously,
> HWND_TOPMOST here doesn't prevent raising other windows above the
> dialog box, as it does with file selector.
> 
> > It doesn't show any strange effects here, at least.
> 
> I think the problems I saw were on Windows 7.  Will check.

Tested the above on Windows 7.  Seems to work well, with 2 caveats:

 . The dialog and its frame are raised to be topmost, so no other
   application window can be put above them, something that the
   current code allows.  Not sure if this will annoy people.

 . The font selection dialog looks somewhat differently on Windows 7
   from the dialog shown by the existing code -- the layout is
   slightly different, and the link "Show more fonts" is not there.

Unless you have some new ideas about the problem, given what I
described in my other message, I guess we should disregard the
problems that somehow only I can reproduce, and go with the original
change.  It would be nice to avoid the problems I have, but if not,
they are not critical and shouldn't block the main issue of this bug
report.

Thanks.