> Yes, but how was that instance of Emacs launched? From the Start menu or in > some other way?
>From the command-line using runemacs.exe. No shortcut involved. > 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? I was surprised as well. Launched Emacs via command-line runemacs, then pinned, and saw Explorer.exe process open and read the GNU Emacs.lnk in the Start Menu before creating the Emacs.lnk in the taskbar user-pinned directory. Changing the AppID in the Start Menu shortcut changed the value in the pinned shortcut. When it was "GNU.Emacs" in the Start Menu, it created lnk with "GNU.Emacs" in pinned directory. When I changed the Start Menu app id to something else, it did *not* put the app id in the pinned shortcut (it was then blank). Could test this by pinning some other program besides Emacs and see if it looks through the start menu for a shortcut before pinning. But it still seems to do so, and explains why on Win10, I was then getting pinned shortcuts with the app id already in them. I suspect Windows looks through Start Menu shortcuts for any that contain the executable name in the target of the shortcut. What does it do if there are multiple hits, I don't know. If you had two with different command-line parameters but same executable, I don't know which it would choose or why. > Documentation is easy to change. Be my guest. I'm just saying it's there and users are being told they can use addpm because of it. > 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. Yes, and I would think a very high percentage of Emacs users on Windows know how to do that even if they're not too fond of Windows. But I think we then get into a philosophical debate on whether or not Emacs should support running on Windows *more* (better integration, easier for 'normal Windows users' to use) or *less* (making any concessions to running on Windows separate from standard Emacs and require extra work to include). That's up to RMS et al. and I'll follow their lead. For now addpm is part of Emacs and Windows has changed around it, so I think it could use an update. > No, it doesn't add environment variables. It adds Registry keys that serve > the same duty. No, environment variables *are* registry entries. And it does add environment variables - cf. the env_vars array in addpm.c. > 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. Ah, so these behaviors are what upset you. These can easily be changed as well - and I would think making them options would be a good idea, to provide more flexibility. And even making them non-default options as well, so you only use them if you find you need them. If Emacs on Windows native support for image libraries has improved, then yes, I can see not needing to surreptitiously adjusting the DllPath for Emacs. I hadn't realized it did that. And I agree that putting the EMACSLOADPATH in the registry is limiting. Again, making it a non-default option would be my preference. And making just those little changes wouldn't negatively impact many people I would think. (Except maybe the few that added that code to addpm in the first place.) You make some good points about those behaviors. I still like the idea of addpm as the 'installer' - one that is optional, is part of Emacs, doesn't need to be maintained with each release, and as the tool to add Windows (and taskbar) integration in a standardized way. But changing the GTK and EMACSLOADPATH bits I can agree with. >Not in a MinGW compiled C program, it isn't, AFAIK. In an MSVC-compiled C++ >program, yes, it's easy. I was saying in an *MSI* it's easy. I'm still working on getting a MinGW environment set up (any pointers to good setup instructions?). > 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. No, there is no installer, I was saying it serves some of the same functions in that it creates the shortcuts and updates env vars, as typical Windows installers do. It's providing integration into Windows. In that vein, I think the shortcut it creates should add the App ID to better integrate with the taskbar in Windows 10 (if not 7 and 8). Your assertion that *should* not have an installer (or installer-like) program gets back to that philosophical argument again. I'm fine with changing addpm to make the GTK and EMACSLOADPATH 'features' optional as that makes the integration better for more users. I'll let you argue it's existence with the important people. :) It would be interesting it there were a package manager for windows like apt et al. that could take care of the installation/integration stuff - including removal - I heartily agree that the registry gets lots of barnacles from old software. A true 'installer' would take care of removing those when uninstalling. I've looked a little at Chocolatey, maybe that would work. Though I think it would need an MSI underneath and need to be rebuilt with each Emacs release. But worth considering if it decouples Emacs from it's installation and integration with the environment. > I meant optional even on systems that do support AppID. That's what I was saying - only systems (Win 7, 8 and 10) support the IPropertyStory on the IShellLink's IPersistFile interface, so if that interface isn't found, we don't try to add the app id, and thus it is only attempted to be installed on supporting systems. > I want addpm gone, so I'd rather not advertise it too much. So you feel *all* integration with Windows (shortcuts, env vars, registry settings (beyond env.vars - like context menu integration), taskbar integration, etc.) should not be anywhere in Emacs itself, but solely documented for users to locate and apply by hand? I can understand the separation, but I do like a standard way to do said integration (with support for removing it). Rather than having to deal with inconsistent environments and trying to remember and rediscover all the little tricks. But it could all be done with better user control. You get to pick what things to do - add this shortcut or that one, but not this other one, etc. Maybe that's a better approach than changing addpm. I'd want such a tool to be an (optional) part of Emacs distribution though so it's widely available. But that gets back to the philosophy again. Regards, Rob
