bug#68756: bug#67667: bug#68756: Uninstalling emacs does not remove Start Menu entries created during the installation

[Corwin Brust]

On Thu, Feb 15, 2024 at 1:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> No, PROBLEMS is not a good place, I think.
>

Does it make sense to get the word out that running any version of the
installer so far published will remove all Emacs versions installed
under the chosen installation path (<Program FIles>\Emacs, by
default)?  If so, I'm not sure how.  (PROBLEMS is what I could think
of).

> But why cannot you remove those old shortcuts/submenus when the new
> Emacs version is installed?
>

Perhaps I can.  I agree to try.  To confirm, the goal would be to
remove any *broken* shortcuts, I think. (We do not currently create
submenus unless the user specifies the pathing manually.) We might
also consider deleting older uninstallers, however I'll come back to
this point.

If that is correct, a question would be if we can confine ourselves to
looking at the user's selected Start Menu folder, during install, or
if we should instead traverse the user's entire Start Menu hierarchy
looking for broken shortcuts to runemacs.exe (and maybe old
uninstallers), and deleting them.

Yet another option here would be scanning for older versions and
asking what to do with them.    This would be more of my preferred
option, however I don't expect to be fast creating and testing a
net-new feature created in a language I'm just learning, for this
work.  I guess I'll be racing to be ready for Emacs 30.1 pretests, if
we take all that on.

For this reason (there are much better solutions but I cannot create
and test them quickly), I think we should apply what we have so far
and I should produce a new set of binaries which installer will not
unconditionally uninstall older Emacs versions.  Users who want to
delete things can do so, but an unexpected recursive delete feels like
a very serious problem.

Do you have reservations, Eli?