|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
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|