[OS X Emacs] Delay opening HTML files from a shell

[Braun, Michael]

Thanks.  I can confirm this behavior on my computer as well.  The release version ran as it should.  The nightly build behaved as it should when run as a binary from the Terminal, but not when launched through the GUI.


I did run into the following issues, however.

1.  When running the app directly from Terminal, Aquamacs was looking for libTIFF.dylib, libJPEG.dylib and libPng.dylib in /usr/local/lib.  Those files were not there, but among the System files.  Once I added symlinks, the application was able to launch, and files would open instantly, as they should. But this did not solve the problem when launching from the GUI.

2.  Even though the app does launch and run from the Terminal, I got the following error

mbraun: ~/Downloads $ ./Aquamacs.app/Contents/MacOS/Aquamacs
2019-07-16 08:50:15.131 Aquamacs[25407:8580522] Failed to initialize color list unarchiver: Error Domain=NSCocoaErrorDomain Code=4864 "*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: non-keyed archive cannot be decoded by NSKeyedUnarchiver" UserInfo={NSDebugDescription=*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: non-keyed archive cannot be decoded by NSKeyedUnarchiver}

It didn’t seem to affect running of the app, at least in my short test.  But maybe that’s relevant.

3.  As stated earlier in this thread, I cannot build Aquamacs on my own at the moment.  Also, I do not do much developing, so I’m not sure what’s involved in signing an application.  So unfortunately I cannot test that.

But it does appear that seeing if signing the nightly build would be the next step in debugging this.





On Jul 15, 2019, at 9:07 PM, Jamie Taylor <Jamie.Taylor at pobox.com<mailto:Jamie.Taylor at pobox.com>> wrote:

I attempted to send this a month ago, but the list mail server rejected it, and I didn't get around to sending it again from a different source.  I'd be interested to know if any of this helps.

 ----

Some googling and brief experimentation has lead me to believe
that this behavior is related to the code signature (or the lack
thereof) on the application.  Specifically, I observed the
following three data points:

The current released version of Aquamacs, which is signed, does
not exhibit this behavior.

A nightly that I happened to have lying around (2018-02-23), which
is not signed, does exhibit the slow "open" command behavior.

However, if that same nightly is opened by running its binary
directly rather than opening it as normal (i.e., running
$  ~/Desktop/Aquamacs\ 2018-02-23\ nightly.app/Contents/MacOS/Aquamacs
rather than double-clicking its icon), everything is speedy again.

So my hypothesis is that if you either a) sign the app bundle that you
built, or b) launch it by running the binary from the terminal rather
than opening the app bundle, then you will get your speedy "open"
behavior back.


If anyone wants to go down the rabbit hole of trying to figure out
why it works this way, here are a couple of search terms and links that
might be of interest:  Mojave TCC, Attribution Chain
https://github.com/macvim-dev/macvim/issues/763
https://eclecticlight.co/2019/02/01/solving-problems-with-mojaves-privacy-protection/ (the most interesting bits are in the comment thread)


_____________________________________________________________
MacOSX-Emacs mailing list
MacOSX-Emacs at email.esm.psu.edu<mailto:MacOSX-Emacs at email.esm.psu.edu>
https://email.esm.psu.edu/mailman/listinfo/macosx-emacs
List Archives: http://dir.gmane.org/gmane.emacs.macintosh.osx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://email.esm.psu.edu/pipermail/macosx-emacs/attachments/20190716/8cf4d32a/attachment.html>