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

[Rob Davenport]

> 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