Re: [h-e-w] Windows 10 Taskbar Behavior

[Rob Davenport]

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

True.  And looking at the code again, it does seem very odd to be putting those 
values in the App Paths key.  The App Paths keys are for Windows to more 
quickly locate an executable - not to hold extra data.   Huh.
I could have sworn it created a HKLM\Software\GNU\Emacs key - like where you 
can add xrdb entries to control things prior to the initial frame appearance.   
But you're right - that's an odd place to put the the data.

Btw, I got mingw installed and have successfully built Emacs.  Now to try 
modifying addpm.   I have to: at least to see if it can add the AppUserModelID 
- but you're right, what addpm does should be re-examined.   

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

I wouldn't call shortcuts rarely used and completely unknown.   (Editing the 
registry so you can right-click on a directory in Explorer and right-click and 
say "Dired" and have the right dired buffer pop up in Emacs is very cool 
though, but admittedly not popular.)
I will note that emacs source seems to already contain GNU/Linux type 
"shortcuts": the "emacs.desktop" file in 'etc'. (Well those aren't technically 
GNU/Linux but window manager-specific I think, but still...)   Too bad we can't 
just make a universal "emacs.lnk" file (with appid) and just include that and 
tell people to drop that in your start menu/desktop/pinned taskbar folder, etc.



-----Original Message-----
From: Eli Zaretskii [mailto:address@hidden 
Sent: Tuesday, October 27, 2015 3:07 PM
To: Rob Davenport <address@hidden>
Cc: address@hidden; address@hidden; address@hidden
Subject: Re: [h-e-w] Windows 10 Taskbar Behavior

> From: Rob Davenport <address@hidden>
> CC: "address@hidden" <address@hidden>, "address@hidden"
>       <address@hidden>, "address@hidden" <address@hidden>,
>       "address@hidden" <address@hidden>
> 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.