(Just to be clear, the main problem I've been talking about is that, after pinning Emacs.exe to the taskbar (in Win7, 8, or 10), and clicking it to launch Emacs, an additional taskbar icon shows up. It is not grouped by Windows with the shortcut.)
I thought that under Windows 7, the fix was to change the target of the pinned shortcut from emacs.exe to runemacs.exe. (I could swear that worked. Though any of the many hotfixes MS has put out over the years could have changed the behavior.) Lately though (for me I think it is under Windows 8/8.1 and 10), that no longer worked. The additional icon still showed up, ungrouped. Now (8/8.1, 10 for me) it seems the fix is to set the application user model id property in the pinned shortcut. Trying it again on my Windows 7 work laptop, the runemacs change doesn't fix it. Setting the app id does. That is on Windows 7 SP1, 64-bit Enterprise Edition. My own laptop was running Windows 8.1 64-bit Professional Edition, and I thought the runemacs changed fixed it a year ago or so. It is now upgraded to Windows 10 64-bit Home Edition, where it was working after the upgrade, but after unpinning and repinning Emacs, it stopped working until I did set the shortcut app id. I've normally run the Emacs Windows builds available on ftp.gnu.org and am up to GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570. But I have also been trying GNU Emacs 25.0.50.1 (x86_64-w64-mingw32) of 2015-09-06 available from http://sourceforge.net/projects/emacsbinw64/files/release/emacs-bin-w64-24.5-1.7z/download, which claims to be built natively in 64-Bit Windows (x86_64) from unmodified, up-to-date (from git master and newest release) Emacs source. The taskbar behavior is the same regardless of which I run. Trying to think of what other environmental differences there could be, I normally run logged in to an account that's a member of the Administrators group, but haven't done anything like setting the emacs.exe properties to run as administrator.I wonder if that could be related. I would think the call to set the app id within Emacs is working, since by only changing the app id in the property store of the shortcut, the behavior changes. (But I'd like to figure out how to debug Emacs too, so maybe I can check that.) Rob On Sat, Oct 10, 2015 at 3:04 AM, Eli Zaretskii <e...@gnu.org> wrote: > > Date: Fri, 9 Oct 2015 16:57:22 -0400 > > From: Rob Davenport <rob.davenp...@gmail.com> > > > > Ah, thank you Eli. I had not yet looked into the Emacs source to > determine > > that. But I'm glad it's already there. Much more knowledgeable > developers have > > been at work. :) I see emacsclient.c, runemacs.c *and* w32term.c all call > > SetCurrentProcesExplicitAppUseModelID with L"GNU.Emacs". So it should > work. > > > > Though I do see the problem in Windows 7 too (not just Windows 8 or 10). > > For the record, what version of Emacs do you have? > > David said it worked for him on Windows 7. >
