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

[Eli Zaretskii]

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