Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over

From: Po Lu <[email-masked]>
Date: Sat, 28 Jun 2025 22:33:58 +0800

Stefan Monnier <[email-masked]> writes:

>>> IIUC on Android, the first time the users run their Emacs, you run
>>> a special session started from `temacs` with `dump-mode=nil` but where
>>> you do perform a dump at the end of `loadup` and then continue on to
>>> a normal GUI startup?
>>>
>>> In that case, I'd expect that this first GUI session works correctly
>>> (w.r.t `custom-reevaluate-setting`), but indeed the subsequent runs
>>> (which presumably make use of the generated pdmp file) will fail to
>>> reevaluate the settings.
>>>
>>> Is that what you saw?
>>
>> I believe so, yes, though there is no `temacs' binary, just a shared
>> object that is loaded into `/system/bin/app_process' and which is used
>> to load dumped and undumped sessions alike.
>
> 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.

> BTW, the above reminds me that when I tried Emacs on my phone, I found
> it unbearably slow.  I assumed it was because my phone is underpowered
> but now that I think of it, it did startup much more quickly the second
> time.  I assumed it was faster the second time around because it was
> still in RAM or somesuch, but maybe the excruciatingly slow startup was
> because it was doing the preload+dump and the faster startup is the more
> normal case.

Yes, that's correct.  My phone is about to see its 10th anniversary and
Emacs is absolutely serviceable.

> 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.

> 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
can name no computer program in general that aborts on initial startup,
let alone an Android app...