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. > >
