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).. I believe the issue is that by default, when pinning Emacs, the shortcut that gets created does *not* have the AppID set, and therefore looks different to the Windows shell. I don't know if pinning other applications would get the correct AppID or not - and if it does maybe Windows is looking for something in the exe that it's not finding in emacs.exe to create the shortcut with the AppID. There is a tool called 'lnk-parser' which could also be useful. < https://code.google.com/p/lnk-parser/> It's a command-line tool that dumps the contents of a shortcut (lnk file) and includes the AppId. And I just tried this test. I ran lnk-parser on my (working) pinned Emacs shortcut and it shows the AppID of "GNU.Emacs". I unpinned it, ran runemacs and pinned it again, and now the lnk-parser shows that the shortcut does *not* contain any AppID. Maybe there's a way to help Windows create the shortcuts correctly when pinning by providing other info in the emacs processes, or we can write a program like win7appid that can be used similarly (and GPL'd) to let users manually update the shortcuts. Rob p.s. Another way to (manually) edit the app id of a shortcut... add the following string registry entry to HKCR\lnkfile: [HKEY_CLASSES_ROOT\lnkfile] "FullDetails"="prop:System.PropGroup.Description;System.ItemTypeText;System.Comment;System.Link.TargetParsingPath; System.AppUserModel.ID ;System.ItemFolderPathDisplay;prop:System.PropGroup.FileSystem;System.ItemNameDisplay;System.Size;System.DateCreated;System.DateModified;System.FileAttributes;*System.OfflineAvailability;*System.OfflineStatus;*System.SharedWith;*System.FileOwner;*System.ComputerName" Then doing the Properties on a shortcut file, in the Details tab, the AppUserModelID is displayed - and is editable. I fixed my repinned emacs shortcut with this. (You could just set "FullDetails" to be *just* "prop:SystemAppUserModel.ID" but then the details tab will *only* show the app id. On Fri, Oct 9, 2015 at 3:40 AM, Eli Zaretskii <e...@gnu.org> wrote: > > Date: Thu, 8 Oct 2015 23:09:18 -0400 > > From: Rob Davenport <rob.davenp...@gmail.com> > > Cc: "help-emacs-windows@gnu.org" <help-emacs-windows@gnu.org> > > > > This issue intrigued me so I kept looking into it and here's what I've > found. > > Thank you for your research. > > > In Windows 7 and newer, the shell (Explorer.exe) changed the behavior of > the > > taskbar, and groups taskbar items (processes, files, windows, etc.) to > make it > > easier to find what you're working on (and share features like the > jumplists > > and taskbar preview). In order to do that, the shell needs a way of > identifying > > what to group.It does this using the "Application User Model ID". (See > > > https://msdn.microsoft.com/en-us/library/windows/desktop/dd378459(v=vs.85).aspx > > and http://blogs.msdn.com/b/oldnewthing/archive/2012/08/20/10341464.aspx > for > > some good details.) > > > > The Windows shell uses some heuristics to try to identify what should be > > grouped but it isn't perfect. For example, for programs started via > shortcuts, > > the target in the shortcut must be the same. So if you have two > shortcuts to > > the same program but with different command line parameters, they would > be > > considered different and not be grouped. For processes it assumes only > > processes with the same name should be grouped. And that's the situation > with > > Emacs - emacs.exe and runemacs.exe aren't considered the same by the > Windows > > shell and it doesn't group the icons on the taskbar and similar undesired > > behavior we see. > > > > Microsoft says the way to solve this is to explicitly set an AppID which > > overrides the heuristics. So for better behavior in Windows 7 and later, > all > > emacs processes (emacs.exe, runemacs.exe, emacsclientw.exe, etc.) should > be > > modified to call SetCurrentProcessExplicitAppUserModelID() during their > > startup. > > Yes, that's true. However, Emacs on Windows has been doing precisely > that, i.e. calling SetCurrentProcessExplicitAppUserModelID, since > 2009, i.e. since Emacs 23.2 at least. And IME it works fine on > Windows 7. The question is, why doesn't it on Windows 10? > > IOW, the issue is not the changes in Windows 7, which we already > handle, AFAIK, but the changes in Windows 10. >
