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

[Rob Davenport]

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

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


> Although I'd recommend that people stop using addpm altogether, and instead 
> use the standard ways of adding Emacs to the Start menu, because addpm does
> more than just add a shortcut there.  Or maybe send patches for making the 
> other stuff optional, controlled by some command-line switches.

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)

GNU Emacs on Windows doesn't have the customary Windows-style installation 
program like an MSI.  But addpm.exe does a very similar job - adding the start 
menu shortcut, and adjusting environment variables (emacs_dir, EMACSLOADPATH, 
SHELL, TERM, etc.).  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.    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.

Or we can create an MSI that installs the Emacs shortcuts and registry changes 
- that certainly could be done.  I *assume* we could GPL the MSI source but I'm 
not sure.  However, it would need to be maintained and updated with each Emacs 
release and Windows users would expect it to install *everything*, not just 
make shortcuts.  But maintenance would be additional work for each release, 
though building the MSI could be part of the process of building Emacs on 
Windows.   I like addpm in that it is already optional, and part of Emacs 
distributions and doesn't add to the work to make a release on Windows.  It is 
"non-standard" for Windows applications and does require users find out about 
it and how to run it.  But so far (15+ years?) Emacs users have either found 
out or done without.   Making an MSI that normal Windows users understand could 
help evangelize Emacs, but that is certainly not my call.  I would gladly help, 
having some professional experience with Windows installers, but being a 
'command-line bigot' and GNU and Emacs proponent, I prefer an optional addpm to 
'install' Emacs' Windows integration if desired.  (Or do it by hand which I 
normally do.)  Or we could create an MSI that only does the Windows integration 
tasks and requires Emacs already be installed but that's essentially what addpm 
is.  (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...)

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.  So it should still work fine on 
older Windows (including the documented versions Emacs is known to run on: 98, 
NT, 2003, XP, etc.), but provide better taskbar integration for Windows 7, 8 
and 10 (and Server 08 and 12).

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.



-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Eli Zaretskii
Sent: Monday, October 26, 2015 11:55 AM
To: Rob Davenport <address@hidden>
Cc: address@hidden; address@hidden; address@hidden
Subject: Re: [h-e-w] Windows 10 Taskbar Behavior

> Date: Mon, 26 Oct 2015 00:02:34 -0400
> From: Rob Davenport <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, "address@hidden" <address@hidden>, 
>       David Vanderschel <address@hidden>
> 
> OK. I figured my mystery out. I ran the process monitor when pinning 
> and saw Windows looking through the Start Menu for GNU Emacs.lnk.

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

> So if we fix AddPM to put the app id into the shortcut it creates in 
> the Start Menu, Windows 10 should find it and create the correct 
> shortcut when you pin Emacs to the taskbar.

If we find a way to do that from a MinGW-compiled C program, we will.

Although I'd recommend that people stop using addpm altogether, and instead use 
the standard ways of adding Emacs to the Start menu, because addpm does more 
than just add a shortcut there.  Or maybe send patches for making the other 
stuff optional, controlled by some command-line switches.