Should this package be included into the NS port?

[George Plymale II]

Hi all,

I recently submitted a couple of patches to the Emacs Mac Port by
Mitsuharu Yamamoto. The pull request can be seen here:
https://bitbucket.org/mituharu/emacs-mac/pull-requests/2/add-multi-tty-support-to-be-on-par-with/diff

These patches were basically the continuation of this thread that I
started back in January:
https://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00373.html

Yet, there is a problem with all this which is mentioned in Alan Third's

Open GUI instance
start server
run ‘emacsclient -t’ in the terminal
close GUI frame
You can’t open a new GUI frame, even though the GUI instance with the
server is still running. You can see it in the dock, and access the
menus, but I can’t find any way to create a new frame.

( https://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00430.html )

The same issue occurs with my patches to the Mac Port and it seems to be
a problem with macOS's dock. Fortunately, there is an Elisp package by
Ryan C. Thompson which addresses this problem:
https://github.com/DarwinAwardWinner/osx-pseudo-daemon

If you've ever tried to use Emacs in daemon mode on Mac OS, you might
have noticed that after you close the last graphical Emacs client
frame, the Emacs dock icon and menu bar become non-functional until
you create a new graphical frame. This package implements nearly
identical behavior to daemon mode using a simple hack: whenever the
last graphical frame is closed, a new hidden frame is created. The
next time Emacs is activated, the hidden frame is revealed. The result
is essentially the same as using daemon mode, but without the
drawbacks.

I actually have been using this package constantly for a couple of years
now and it is a very reliable hack which basically solves this issue. I
asked Yamamoto in my above pull request whether he would want to include
this package in the Mac Port in order to solve the issue (re)introduced
by my patches, and he suggested that I present it to the Emacs upstream

How about proposing inclusion of osx-pseudo-daemon upstream (for the
NS port, of course)? I'd like to avoid enabling premature/unstable
multi-tty with GUI as well as diverging from upstream for easier
maintenance.

So here I am :)

Ryan C. Thompson's package is licensed under the GPLv3 so I suppose that
it could be included into the NS port if he signs the copyright
paperwork. It may also need a bit more firming-up before heading into
the mainline, but I think it's pretty solid as-is.

Thoughts?

Thanks,
- George Plymale II

[Stefan Monnier]

Post by George Plymale II
Ryan C. Thompson's package is licensed under the GPLv3 so I suppose that
it could be included into the NS port if he signs the copyright
paperwork. It may also need a bit more firming-up before heading into
the mainline, but I think it's pretty solid as-is.

The Gtk port has a somewhat similar hack in the C code to avoid closing
the display (to try and delay the infamous multi-display Gtk bug).

So I think it might make sense to add such a workaround for this OSX bug
much more directly in the core (rather than via defadvice).


Stefan

[Alan Third]

Post by Stefan Monnier

Post by George Plymale II
Ryan C. Thompson's package is licensed under the GPLv3 so I suppose that
it could be included into the NS port if he signs the copyright
paperwork. It may also need a bit more firming-up before heading into
the mainline, but I think it's pretty solid as-is.

The Gtk port has a somewhat similar hack in the C code to avoid closing
the display (to try and delay the infamous multi-display Gtk bug).
So I think it might make sense to add such a workaround for this OSX bug
much more directly in the core (rather than via defadvice).

It might be worth investigating exactly why the NS port can’t open a
new frame in this situation, but I’ve not got round to it yet. It
seems rather strange to me.

[George Plymale II]

Post by Alan Third
It might be worth investigating exactly why the NS port can’t open a
new frame in this situation, but I’ve not got round to it yet. It
seems rather strange to me.

Yes, I agree. I would also very much like to know the cause of this bug,
but alas I'm a bit strapped for time as well. I've done some casual,
fruitless experimentation with it in the past yet I've gotten no closer
to the cause. If anyone would be willing to take up the torch for this
and do some detective work, that would be awesome.

Thanks,
- George Plymale II

[George Plymale II]

Post by Stefan Monnier
The Gtk port has a somewhat similar hack in the C code to avoid closing
the display (to try and delay the infamous multi-display Gtk bug).
So I think it might make sense to add such a workaround for this OSX bug
much more directly in the core (rather than via defadvice).

That sounds great to me. I wasn't aware of the Gtk bug that you mention
(I've never used a Linux desktop with multiple monitors, so that's
probably why) but it's good to know that this macOS issue isn't entirely
unique. And yes, I agree that it would make sense to add this workaround
into the core. That would probably be a better choice, all things considered.

I was afraid that the developers here would be unwilling to include this
package or anything like it so I'm glad that I stand corrected.

Thanks,
- George Plymale II