Re: windows installer

[Eli Zaretskii <eliz@gnu.org>]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: jostein@secure.kjonigsen.net,  jostein@kjonigsen.net,  emacs-devel@gnu.org
> Date: Fri, 10 Nov 2017 23:27:49 +0000
> 
> >> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
> >> >  by concatenating HOMEDRIVE and HOMEPATH ).
> >> 
> >> I'll fix this.
> >
> > Just to make this more complex: the Windows platform conventions frown
> > upon installing stuff in that directory; you are supposed to create a
> > subdirectory and install there.
> >
> > And programs should not end up there, they should be under
> > %ProgramFiles% instead.  The user's directory is for files, not for
> > programs.
> 
> The disadvantage with ProgramFiles is that it requires elevation, which
> user profile does not, although user profiles gets mixed up with
> roaming. Although, elevation is pretty normal for installation. But I
> didn't want to it straight away in case I made the uninstaller
> accidentally delete my windows installation.

I don't think I understand the last sentence.

For the rest, installing into the user's profile because doing TRT is
harder is not a sufficient reason in my book.  If you want to avoid
elevation (which I don't think you should, given that this is "normal"
Windows behavior nowadays), then install into a directory that is
neither user profile nor Program Files (and maybe not even drive C:,
if there is another drive).  But going to the user profile is highly
unusual, to say the least.

> > They _will_ want to add it to PATH if they want to install packages
> > from the likes of ELPA, which frequently come with Makefiles that
> > invoke Emacs to compile the Lisp files.
> 
> Really?

AFAIU, yes.

And even if ELPA packages have alternatives which don't invoke Make,
there will be other situations where building a package with Emacs
support will want to invoke Emacs.  One such example is GNU ID-utils.

IOW, Emacs is not just a GUI application used interactively, it is
also a program that supports batch-mode invocation, and that mode is
at times used by other programs.  Keeping the Emacs binary off the
users' system PATH is therefore less than ideal, because the users
will then bump into subtle problems whereby Emacs seems "unavailable".