Re: [h-e-w] Windows 10 Taskbar Behavior

[David Vanderschel]

Apologies for the delay in responding.

On 10/11/2015 9:48 PM, Eli Zaretskii wrote:
> > From: David Vanderschel <address@hidden>
> > Date: Sun, 11 Oct 2015 18:16:50 -0500
> > Cc: address@hidden, address@hidden
> >
> > (One thing that is not clear to me is whether or not runemacs needs to
> > set it.)
> They both do.  Are you saying this might be a problem?
No.  I was only considering the possibility that things might still work 
correctly even if runemacs fails to set it.

Recall how I started this thread:

On 9/25/2015 12:46 PM, David Vanderschel wrote:
> In Windows 7 and 8.1, we had the following solution:  Start Emacs with 
> runemacs.exe, pin it, close it, bring up the Properties for the pinned 
> icon, and change the target from emacs.exe to runemacs.exe.  That 
> works as one would hope: either starting an instance of Emacs or 
> activating any existing instance.
For Windows 10, I did just double-click runemacs.exe in the /bin directory.

When it worked correctly for me back on my Windows 7 machine, it is 
conceivable that I used a shortcut created by addpm, but I don't think 
so; so I remain curious about why it does not work for Rob in Windows 
7.  However, I just repeated the experiment in Windows 8.1 using the 
runemacs.exe directly from the /bin directory, and everything still 
works correctly.

I still believe that it is a Windows 10 bug for failing to correctly 
infer an ID from either the runemacs or emacs executable.  However, 
teaching addpm to put the ID on a runemacs shortcut it creates could be 
a better workaround for Windows 10.

Regards,
  David V.