On Wed, Oct 28, 2015 at 5:28 PM, Rob Davenport <address@hidden
abb.com> wrote:
> That seems fine. Though it might be useful to include runemacs.exe and emacsclient[w].exe as well.
IMHO, none (including the one for emacs.exe) are "useful", ie, I don't think addpm should even touch them.
> Interesting. Those are some things I didn’t know about. Could be moderately useful *if* we wanted
> non-default drop target behavior, or passing a URL instead of the shell downloading the document
> and using a local copy.
There are other things that could be done to make Emacs integrate better with Windows (for example, having a jumplist / task list in the taskbar icon, showing an icon in the tray notification area when daemonized, etc), but I don't think they are worth the effort. Not to mention that if that functionality doesn't (more or less) exist in other window environments, you'd have a hard sell in emacs-devel.
> Now I see that addpm only *updates* those registry values (EMACSLOADPATH, emacs_dir,
> EMACSPATH, EMACSDATA, EMACSDOC, SHELL and TERM) – they must already exist.
This is another recent change. All released versions do add them unconditionally if the registry key (not values) already exists.
> It seems the only useful features of addpm are:
>
> - Adding emacs.exe entry to AppPaths key.
Which I wouldn't call "useful". I happen to have my own App Path entries and addpm "blind overwriting" style messes with them. All just to be able to run emacs.exe without having it in the PATH. Bah.
> - Add a shortcut to the Windows common or user Start Menu folder
And we (AppID issue apart) don't really need an application for that.
So I'd tend to agree with Eli, addpm is a relic and should be left to die.
J