> From: Rob Davenport <rob.davenp...@us.abb.com> > CC: "lek...@gmail.com" <lek...@gmail.com>, "d...@austin.rr.com" > <d...@austin.rr.com>, "help-emacs-windows@gnu.org" > <help-emacs-windows@gnu.org> > Date: Mon, 26 Oct 2015 19:26:54 +0000 > > > Does Windows look at that shortcut only if you invoke Emacs from the Start > > menu, or does it do that for all the other ways of invoking Emacs, like the > > cmd > > prompt, a desktop shortcut, the Run dialog, etc.? > > I was only watching what happened during the pinning action on Windows 10. > Windows definitely looked at the shortcut it found in the Start Menu.
Yes, but how was that instance of Emacs launched? From the Start menu or in some other way? > I just tried watching (on Win7) when launching Emacs via the command-line > (runemacs) and I saw no similar activity - nothing looked for the shortcut. > Runemacs.exe loaded, searched for and found emacs.exe and started it. > > And I just tried watching when launching Emacs via a shortcut on the desktop. > Also no activity looking for the shortcut in the Start Menu. Runemacs > launches emacs. > > I believe it is only during the pinning of the running process that Windows > examines the Start Menu for a compatible shortcut to use. It may look in > other locations, or the registry but I didn't notice any (other than the list > of apps and exe names that Windows *excludes* from pinning like setup.exe, > MSI files, etc.). We are miscommunicating. I was asking whether the place which Windows examines for the AppID hen you pin Emacs depends on the method used to launch the Emacs instance you are pinning. I can understand why Windows would look in the Start menu shortcut when you pin an application that was launched via the Start menu -- for Windows, that shortcut "represents" the application. But I'd be surprised to hear that Windows looks at the AppID of the Start menu shortcut when you pin an application that was launched by some other way -- how would Windows even know that there is a shortcut for the application there? > Addpm is still the (or a) documented way of creating a start menu shortcut. > (q.v. > http://www.gnu.org/software/emacs/manual/html_node/emacs/MS_002dWindows-Registry.html > and > http://www.gnu.org/software/emacs/manual/html_mono/efaq-w32.html#Installing-binaries > , and on emacswiki.org: http://www.emacswiki.org/emacs/CategoryWThirtyTwo, > and http://www.emacswiki.org/emacs/MsWindowsInstallation) Documentation is easy to change. > GNU Emacs on Windows doesn't have the customary Windows-style installation > program like an MSI. I'm sure I'm not the only one who knows how to create a Start menu shortcut for a program without using any programs. You just go to the directory "Start Menu" and create a shortcut there, that's all. No installer needed. > But addpm.exe does a very similar job - adding the start menu shortcut, and > adjusting environment variables (emacs_dir, EMACSLOADPATH, SHELL, TERM, etc.). No, it doesn't add environment variables. It adds Registry keys that serve the same duty. And it oh-so-helpfully also changes PATH that Emacs will see if it finds a GTK installation (this particular part was removed from the development sources, but the released versions still have it). And adding EMACSLOADPATH to Registry means that you cannot easily run 2 different versions of Emacs on the same system, because each version needs its own EMACSLOADPATH. Etc. etc. -- addpm does more harm than help, and it does that subtly, so that most users will not even realize what's going on. > It is almost trivial to add an AppUserModelID to a shortcut created in an MSI > and Microsoft expects applications to have installers to do that. Not in a MinGW compiled C program, it isn't, AFAIK. In an MSVC-compiled C++ program, yes, it's easy. > Since addpm functions as Emacs' installer on Windows and already creates the > Start Menu shortcut, I think updating it to add the AppUserModelID is the > correct place to add it. addpm was never intended to serve as an Emacs installer. Emacs does not have an installer, and should not need one. Programs that modify the Registry are pests, because those Registry entries stay there long after the program was uninstalled/deleted. Our Registries are full of junk because of that. > (And I remember addpm from when it was first created as the tool to add Emacs > to the "presentation manager" - the ancient Windows 'shell' name related to > the old OS/2...) Exactly! addpm is a relic from old times, something that should have died long ago, together with Windows 3.x. > As for adding code to addpm to set the AppUserModelID of the shortcut it > creates, that will already be "optional" - we query the IShellLnk for the > IPersistFile and IPropertyStore interfaces and if the version of Windows > doesn't support them, it won't try to add it. I meant optional even on systems that do support AppID. > Perhaps better documentation about addpm emphasizing it's optionality? The > FAQ link above does start out by stating "You can run Emacs without any extra > steps [after unpacking the binary], but if you want icons in your Start > Menu..." There could be additional documentation there about how to do > things manually - shortcuts, environment variables, registered file types, > shell content menu integration, etc. Currently I mine emacswiki for that > info but it could be added to the official FAQ - then maybe fewer people > would use addpm but add what they want by hand. But adding the > AppUserModelID for taskbar support is not trivial so I still would like to > see it added to addpm. Maybe we could add additional switches to addpm to > make more of what it does optional and user-controlled? That would be good I > think. I want addpm gone, so I'd rather not advertise it too much.
