[darwin] requesting the X11 version of emacs

[robohack]

I would like to request the X11 variant for emacs25 in the Darwin build(s).

BTW, I can't even get the current emacs25 package to work without starting it with -nw -- keyboard focus seems to stay on the tty where it was invoked, even if that's an xterm, while a window opens on the normal Aqua desktop. Clicking in an emacs pane makes the emacs cursor blink, but typing still goes to the terminal window.

I would say this is really a bug in pkgsrc itself since in my opinion there is really no good reason for Darwin builds to choose "nextstep" instead of "x11" when most of pkgsrc uses X11, and this is especially the case for emacs where the "nextstep" build is essentially unusable in GUI mode.

You probably need to add "PKG_OPTIONS.emacs+= x11" to your mk.conf file for Darwin builds, though you may also need to do something to disable nextstep builds. Perhaps this should be done in general with "PKG_DEFAULT_OPTIONS += -nextstep". I for one would not complain if every Darwin package were built only with X11 support wherever possible.

[jperkin]

This appears to work for me, at least installing the emacs25 package and running "emacs" in an Xquartz session opens a window that appears to work. I'm not an emacs user so can't verify that everything works as expected, but I think this is what you requested.

[robohack]

Hi Jonathan, thanks for looking at this issue!

Unfortunately the commits you've made which reference this issue don't seem to have anything to do with it -- perhaps a typo in the issue number?

Also, these recent builds (shown from the directory listing) still use the nextstep option and don't actually work with X11. When I start emacs after upgrading it from your servers with pkgin the emacs window opens on the native macOS desktop, not in my X11 session.

https://pkgsrc.joyent.com/packages/Darwin/trunk/x86_64/All/
emacs25-25.3nb13.tgz                               08-Mar-2019 18:13            52081222
emacs26-26.1nb6.tgz                                08-Mar-2019 01:40            53636182

11:14 [0.677] # pkgin pbd emacs26-26.1nb6 | fgrep PKG_OPTIONS
PKG_OPTIONS=dbus gconf gnutls gtk3 nextstep svg xaw3d xft2 xml
11:15 [0.678] # pkgin pbd emacs25-25.3nb13 | fgrep PKG_OPTIONS
PKG_OPTIONS=dbus nextstep svg xft2 xml

The only sure way to test emacs under XQuartz on a macOS machine alone is to set XQuartz to full-screen mode (under the X11 menu) -- without doing that it is impossible to know which window is opened using which window system.

The other way to test is of course to open a remote X11 session, e.g. by ssh in (with -Y) to the macOS system from a system using plain X11 and start emacs see if a new emacs window opens on the originating Xserver or not.

Either way nextstep will have to be replaced by x11 in the PKG_OPTIONS for it to work.

[jperkin]

Ah ok, I see - I hadn't tried running it outside of an X11 session. I'll take another look.

The irrelevant commits are an unfortunate side-effect of GitHub auto tagging issues whenever the issue ID is mentioned in a commit, which happens frequently with pkgsrc commits that include changelogs. I've had a bug open with them for many years asking for an option to limit this to "/#issuenum" instead of simply "#issuenum" which obviously matches far too easily, but they have so far ignored it.

[robohack]

Hi Jonathan,

Can I convince you to add PKG_DEFAULT_OPTIONS += -nextstep to the mk.conf file used for building darwin/macOS packages?

(I don't really want to kill nextstep support for macOS pkgsrc users, but from what I currently know I don't think it'll make any difference to anyone, other than possibly starting a background X11 server sometimes when otherwise it wouldn't be started.)

[robohack]

Perhaps another case of GitHub cross-referencing the wrong issue number from an unrelated commit?

[jperkin]

Stupid GitHub auto-close.

[robohack]

Yet another case of GitHub cross-referencing the wrong issue number from an unrelated commit?

[robohack]

Yet another case of GitHub cross-referencing the wrong issue number from an unrelated commit?

[jperkin]

Yeh