On Fri, Jan 17, 2020 at 06:49:20PM -0500, Michael Dixon wrote:
When I grep the source tree with the patch applied EmacsSavePanelisn’t found anywhere. Is it possible the patch didn’t apply correctly?Can you do a grep to see if it’s mentioned anywhere?-- Alan Third
On Jan 17, 2020, at 1:53 PM, Alan Third <address@hidden> wrote:
On Wed, Jan 15, 2020 at 04:48:56PM -0500, Michael Dixon wrote:
I suppose it just leaves the question of whether we disable this for
macOS 10.15, or if we just get rid of it altogether. My understanding
is that all it does is allow the use of C-g to quit the file open and
save dialogues. I don’t see much reason to keep it, but if anyone
actually uses this let me know.
And sorry, just to complicate things, it looks like the patch fixed
anything related to File > Open. But I just tried to use the menu to
do a File > Save as… and that still resulted in a crash. File > Save
worked fine though.
Can you send the crash report for this? It can’t be for the same Classes.
I’m going to attach the macOS crash report, which is just plain text.
The part I can understand does look the same as what I was seeing before:
Application Specific Information:
*** Terminating app due to uncaught exception 'NSObjectNotAvailableException', reason: 'EmacsSavePanel is not a supported subclass for sandboxing'
terminating with uncaught exception of type NSException
Is it possible EmacsSavePanel is used somewhere else?
I grepped the source tree, and I noticed EmacsSavePanel mentioned in what I believe were leftovers from previous builds. Files with names like emacs-126.96.36.199, emacs-188.8.131.52, etc., all with modify dates that seemed to align up with dates I would have done a make install. I tried cleaning them up manually (e.g. deleting them), and I was left with the only mentions of EmacsSavePanel being in the change log.
I rebuilt again and this time Save As no longer causes a crash.
I’m sorry Alan for making this such a fiasco.