GNU bug report logs -
#75013
Windows binary installer ignores user options for Start menu shortcuts
Previous Next
To reply to this bug, email your comments to 75013 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75013
; Package
emacs
.
(Sat, 21 Dec 2024 19:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Corwin Brust <corwin <at> bru.st>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 21 Dec 2024 19:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Thanks much for looking into issues/fixes with the binary installer
for Windows, Francis! "Promoting" your comments to a bug report here,
as I think you've uncovered an undocumented (and fixable + worth
fixing) thing.
On Sat, Dec 21, 2024 at 12:29 PM Francis Wright <f.j.wright <at> live.co.uk> wrote:
>
> Hi Corwin
>
> Thanks for working on this. The "greedy uninstaller" was a bit of a pain. I tried your installer []
> and the associated uninstaller seems to work correctly, i.e. it only uninstalls emacs-30.0.93, which is great. I didn't notice any of the other issues you listed.
>
Yay!
> However, I did notice a couple of problems. Firstly, Windows pops up a warning from Microsoft Defender SmartScreen, which is not a new problem and is easy to work around.
This I think I am not currently able to do much about, alas.
> Secondly, the installer did not install a shortcut folder. On the Choose Start Menu Folder dialogue, Emacs-30.0.93 was pre-selected, and I ensured that Do not create shortcuts was not selected. The only button available was the Close button, which I clicked. A shortcut for Emacs itself was installed but not the shortcut to the folder containing Emacs and the uninstaller. (I can add the folder shortcut by hand.)
>
Thanks for reporting this issue. I confirmed it exists also with the
29.4 released binary installer. When I select "show details" I can
see at the end of the unpacking ("installation") processing step it
creates start-menu short-cuts; however, the screen where we choose
whether or not we want to install short-cuts isn't shown until after
the unpacking step -which I now see does short-cut creation, but
shouldn't- is completed. There is some code in the nsi script which
might be doing the write thing in the wrong place, at first glance.
In any case, with the present (for some time) installer we get a
"hard-coded" incorrect value for a start menu shortcut that is always
created irrespective of relevant choices offered to the user by said
installer. Not great.
I'll look into fixing this for the 30.1 installer, also, replying back
in here if/when I have an "_3" that seems to warrant others' testing
effort.
Since this "short-cut page ignored" issue doesn't seem already to have
been captured in the bug tracker I have directed this reply such as to
create a new bug-report. I'll try to arrange to get additional
relevant comments I/we make back on devel show up in the new bug
report (I don't have the number yet, as I write this), but: feel free
to address replies back to original devel thread (or otherwise to this
new bug thread) as you think best.
> Best wishes,
> Francis
>
Gratefully,
Corwin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75013
; Package
emacs
.
(Sat, 21 Dec 2024 23:07:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 75013 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tags: patch
thanks
>
> I'll look into fixing this for the 30.1 installer, also, replying back
> in here if/when I have an "_3" that seems to warrant others' testing
> effort.
>
I'm attaching a (messy, quick) patch which appears to wrap fixing this
issue up with fixing those others I've just been asking others to help
me close (by testing out patched installers).
I will link devel (and OP) rather than here with the (transient,
available for some days at least) link to the new version of the
installer I've made applying the attached patch (under other cover).
I'll report back in (to this bug) with a "stand-alone" patch showing
just code needed to resolve this issue (probably for academic
purposes, given this consolidated patch works). It should apply to
virtually any branch (or release/pre-release source tarball).
FTR, it was easy enough to swap reorder things to ensure that the
shortcuts got created properly (according to user options, and not
prior to asking for input/confirmation of those preferences, as
before); however, I had to go to lengths to ensure the uninstaller
removes whatever shortcuts it creates. The resulting (seemingly
reliable) result is that we now delete empty parent folders (up to the
start menu application's folder root) when deleting whatever shortcuts
during uninstallation which the given installer had made. I can (and
probably should) give the same treatment to the applications folder,
removing empty parents of the User's selected install folder, but I
think we have enough to test for just now. (The same approach will
work; it won't be difficult to add. But let's confirm the recursive
delete method works reliably for others).
For anyone seeing this and interested in a (slightly) more durable
link from which one can follow (by seeing incremental/experimental
builds outside of links shared to devel) along, seeing my current
version of the attached patch and related binaries using the 30.0.93
(pre-release 3 for Emacs 30) tarball a starting-point, here's an index
page:
https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/?C=M;O=D
Note, when browsing the above link:
The "latest" and otherwise (not 30.0.93_N_or_bug) releases are the
latest snapshots taken from the emacs-30 branch (so, by now, more
recent than the release tarball mentioned above, and without
this/these patches, for now). Such builds are named based on the git
revision and include the sources used in the given folders. Builds
related to installer fixes based on Emacs 30/pretest #3 are within my
"Emacs 30 root folder", index to which is linked above.
[emacs.nsi.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75013
; Package
emacs
.
(Sun, 22 Dec 2024 18:30:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 75013 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
Francis reported that a binary built from the previous version of the
patch sent to this bug ticket worked but noted that Emacs (unlike many
other programs when running on Windows) cannot be uninstalled via Add
Remove Programs in the Windows Control Panel. The updated patch
(additionally) enables this method of uninstallation as well as
removing empty Program Files parent folders when uninstalling.
[emacs.nsi.patch (application/octet-stream, attachment)]
This bug report was last modified 177 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.