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

Previous Next

Full log

View this message in rfc822 format

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

Stefan Monnier <monnier <at> iro.umontreal.ca> 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...

Previous Next

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