Re: Windows 10 Taskbar Behavior
Eli Zaretskii <[email protected]>
| Newsgroups | gmane.emacs.windows |
|---|---|
| Message-ID | <[email protected]> |
> From: Rob Davenport <[email protected]> > CC: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Date: Mon, 26 Oct 2015 21:46:06 +0000 > 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). One more reason to not use addpm, if you ask me. And thanks for the information about this misfeature of Windows 10. > > 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. These variables are added to the Registry as entries for Emacs to read. They are not added to the Registry in a way that would push them into the environment of the Emacs process; Emacs does that itself in its application code during startup. > I'm still working on getting a MinGW environment set up (any > pointers to good setup instructions?). See nt/INSTALL in the Emacs source tree. > > 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). In my experience, these features are very rarely used and almost completely unknown to users. Keeping them is a maintenance burden that is hardly justified by its use.