emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Should this package be included into the NS port?


From: George Plymale II
Subject: Should this package be included into the NS port?
Date: Tue, 15 May 2018 01:19:50 -0400

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
message on that thread:

> [...] if you do this on the NS port:

>      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

This package implements a "pseudo-daemon" which is described as such:

> 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
first. In his words:

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]