add multi-tty support to be on par with GNU Emacs proper

#2 Open

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

git checkout master
git remote add ylluminarious/emacs-mac-multi-tty
git fetch ylluminarious/emacs-mac-multi-tty
git merge --no-ff -m 'Merged in ylluminarious/emacs-mac-multi-tty (pull request #2)' remotes/ylluminarious/emacs-mac-multi-tty/master
  1. George P. II

This removes some code which disallows the quite useful multi-tty feature which exists in the NS port of GNU Emacs proper. There was no real reason to add this code in the first place, except that without it, Emacs' behavior can be confusing for users who do the following sequence of actions:

  • Open GUI instance
  • start server
  • run ‘emacsclient -t’ in the terminal
  • close GUI frame

But, this problem can be avoided as long as the user does not close all GUI frames, or if they use this package:

I propose that we merge the aforementioned package into the Emacs Mac Port so that we can have multi-tty support without the weird behavior that I described above which exists in the NS port.

Comments (3)

  1. Mitsuharu Yamamoto repo owner

    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.

  2. George P. II author

    @mituharu I will ask them, but I doubt whether they will accept my request. It would depend on whether Ryan C. Thompson (the creator of the package) has signed the copyright paperwork and whether RMS et al. are willing to let features into the mainline that are specific to OS X. They would probably also want to revamp the package to bring it more up to snuff, but we shall see. Once I start the thread on emacs-devel, I will post it here in case you want to join the conversation as well.

  3. George P. II author

    @mituharu As I was preparing to send that message to emacs-devel, I noticed a bug in my patch that did not exist before and does not exist in an official build. The bug is reproducible and consistent. When a terminal client is connected via emacsclient -t and it runs the Lisp command menu-bar-open (bound to F10), the Emacs server suddenly dies and both clients are immediately killed. That is to say, Emacs completely crashes. It seems that there is some GUI code running on the terminal frame which is not appropriate for the terminal frame. At least that is what I believe from the backtrace. Do you know what is going wrong? Here is the backtrace which I obtained from a system popup that said "Emacs quit unexpectedly."

  4. George P. II author

    @mituharu Any thoughts on my bug report? I'm having a hard time figuring it out myself.

  5. George P. II author

    @mituharu Never mind, I figured out a solution on my own and committed it. I’ll go ahead and post that question on emacs-devel now.

  6. Kent Rakip

    Did this end up getting resolved upstream? If that doesn’t look like it will happen, would it be reasonable to include the proposed fix in this port after all?

    1. George P. II author

      @Kent Rakip No, unfortunately I have not yet integrated the pseudo-daemon package into Emacs' upstream. I actually made a blog post recently which explains why it hasn’t been resolved yet and other details about this issue.

      It is possible that I won’t be able to work on integrating that package into the upstream for a while still. So yes, I think it’s reasonable to include this fix in the Mac Port now.