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

Previous Next

Full log

Message #70 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: Fri, 27 Jun 2025 23:08:25 -0400

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

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.

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.

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.


        Stefan

Previous Next

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