|
From: | Rob Davenport |
Subject: | Re: [h-e-w] Windows 10 Taskbar Behavior |
Date: | Thu, 22 Oct 2015 03:29:39 +0000 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |