GNU bug report logs - #78637
30.1.90; Calling setopt during init loads cus-start over and over

Previous Next

Full log

Message #79 received at 78637 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 78637 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 app-emacs-dev <at> janestreet.com, azeng <at> janestreet.com
Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start
 over and over
Date: Sat, 28 Jun 2025 11:54:27 -0400

>> I wouldn't be surprised if there are other places where we presume that
>> `dump-mode = nil` means that we won't dump (or have already dumped).
> There were till I eliminated all of those I discovered which impacted
> the Android port.

The `dump-mode` test in `cus-start` that was present before the
recent `custom-reevaluate-setting` *did* impact the Android port, but we
just didn't notice because the impact was sufficiently minor.

>> From this experience, I wonder if the Android port shouldn't be more "in
>> your face" about the preload&dump, i.e. tell the users about it, so they
>> don't get false ideas about Emacs startup being ridiculously slow, like
>> I did.
> Sure, although this is the first instance I've encountered of this
> particular complaint.

Yeah, maybe it's just me.  But note that I didn't bother to complain
(until just now that I finally figured what had happened), so maybe
others have just been put off and moved on.

>> Also, It could even exit after the dump, I think, telling the users to
>> just start again (or maybe even doing the restart on its own), so it
>> could use a more "normal" value of `dump-mode` which would save it from
>> triggering old bugs like the one above.
> Doing so would create a much more alarming surprise for users, IMHO.

I think a well chosen message should avoid such alarm.  E.g.

    Performing the 2nd part of the install (the «dump»)...
    Done!  You can start the real Emacs now, thanks!

Of course, if we can `exec` ourselves right away, we'd avoid the need to
ask users to retry, but I don't know Android enough to if that can
be done.

> I can name no computer program in general that aborts on initial
> startup, let alone an Android app...

It's not common, indeed, but there are a few somewhat related
precedents:

- When you upgrade F-Droid from F-Droid, the application exits.
  Nowadays it's reasonably clean, but in the past it would appear to
  crash (exit abrubtly), and restarting it right away would silently
  fail (IIUC it would fail for the duration of the actual install of the
  new version, which took place invisibly, in the background).

- When registering as a new user on most websites, the registration
  process ends by "OK, you can now try to log in".

In any case, it was just a suggestion.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.