OK. I figured my mystery out. I ran the process monitor when pinning and saw Windows looking through the Start Menu for GNU Emacs.lnk. And it found one. I had run addpm recently and updated *that* shortcut with the GNU Emacs app id. So Windows found it and used it when pinning Emacs. If I remove that shortcut, then try to pin Emacs, it doesn't get the app id. If I put the shortcut back into the start menu and then try to pin Emacs, it does get the correct app id. Seems pretty conclusive.
So if we fix AddPM to put the app id into the shortcut it creates in the Start Menu, Windows 10 should find it and create the correct shortcut when you pin Emacs to the taskbar. On Sun, Oct 25, 2015 at 10:29 PM, Rob Davenport <rob.davenp...@gmail.com> wrote: > This is odd. On my Windows 10 laptop here, I unpinned Emacs (after having > fussed with it over the last couple weeks), verified there was no lnk file > left. > Started emacs with runemacs. Lnk file was created and with lnk_parser I > could see the AppUserModelID of GNU.Emacs had been set in the shortcut. > Starting another instance of Emacs resulted in two icons correctly grouped > in the taskbar. > > I know when I first tried pinning Emacs on Win10 a couple weeks ago to > test it for David, it did *not* do that. I'm suspect some other registry > entry is still there even after unpinning it. (Like the AppPaths registry > entry.) And that is helping Windows determine the AppUserModelID. If we > knew what doing that and we could do that. > > Rob > > On Fri, Oct 23, 2015 at 11:42 PM, Juanma Barranquero <lek...@gmail.com> > wrote: > >> On Fri, Oct 23, 2015 at 4:14 PM, Eli Zaretskii <e...@gnu.org> wrote: >> >> > So the conclusion is AFAIU this: Windows 10 changed the behavior wrt >> > the AppID of the shortcuts pinned to the taskbar: where previous >> > versions "inherited" the AppID of the application that was pinned, >> > Windows 10 doesn't. Is that correct? >> >> Yes, I think so. >> >> > Maybe someone could ask on some Microsoft forum whether indeed there >> > was a change in behavior here, and if so, what is its rationale. It >> > could even be a bug in Windows 10. >> >> Certainly it seems like a bug. It's hard to imagine how the new behavior >> would be useful. >> >> >
