From: Eli Zaretskii
Subject: Re: emacs for pure Gtk3
Date: Mon, 27 Apr 2020 18:03:54 +0300 
> Date: Mon, 27 Apr 2020 21:37:27 +0900 (JST)
> Cc: address@hidden
> From: Yuuki Harano <address@hidden>
> 
> >   . You don't seem to have a copyright assignment on file.  This would
> >     be a significant contribution to Emacs, for which we must have
> >     such an assignment from you before bringing this code into the
> >     Emacs repository.  Would you be willing to start the legal
> >     paperwork now?  If so, I will send you the form to fill.
> 
> Yes.  Please send me it.
Form sent off-list.
> By the way, this fork contains much code written by @fejfighter.
> He said "for now: Yes I do agree to assign my code to the FSF." here,
> https://github.com/masm11/emacs/pull/11#issuecomment-600856858 .
> What to do?
He should fill the form I sent to you, separately, and email it
according to instructions.

No worries, happy to do so.

> Because I was not going to merge to mainline when I started porting,
> older commit messages are in Japanese.  If you don't like Japanese
> messages, I can make one big commit instead of existing commits.
That's probably the best.  But there's time before that happens, and
you can meanwhile keep the original log messages while the code is on
the branch.
> Since pgtk emacs is configured with '--without-x', existing X code
> is disabled.  If configured with '--with-x', the existing X support
> should be enabled as before.
Would configuring --with-x disable Pgtk support code?  That is, do the
X and Pgtk support contradict each other, and cannot live in the same
binary?  Or maybe I don't have a clear idea what exactly gets disabled
when building with Pgtk -- can you elaborate?
I think this may need a little more work in configure.ac
In essence it's not that different to --with-ns or --with-w32.
it just happens to re-use a chunk of the gtkutil.c code where possible.

Effectively it selects pgtkterm.h instead of xterm.h



> Pgtk emacs supports X window system too through Gtk library.
> It can handle Wayland, X window system, and TTY in the same session.
> But segmentation fault may occur when running on X and Wayland
> in the same session.
I guess those segfaults need to be fixed, because having a GUI Emacs
that can only run on Wayland would be a limitation that users might be
unhappy about?

it will run on wayland or xwayland or X11 from the same binary, but not on wayland and X11 concurrently.

I'm not sure of a use-case for this, but I'm hoping someone is able to provide one.
<
 div>
> I don't know about Lisp threads.  I have never supported it explicitly.
> Pgtk emacs may not support it.
Well, for starters see if test/src/thread-tests.el runs and succeeds
in your Pgtk build.

I get:

make lisp/thread-tests     
make[1]: Entering directory '/home/fejfighter/dev/emacs-gtk/test'
  GEN      lisp/thread-tests.log
Running 3 tests (2020-04-28 12:52:55+1000, selector `(not (tag :unstable))')
  skipped  1/3  thread-tests-list-threads-error-when-not-configured (0.000133 sec)
   passed  2/3  thread-tests-thread-list-send-error (0.000488 sec)
   passed  3/3  thread-tests-thread-list-show-backtrace (0.014913 sec)

Ran 3 tests, 2 results as expected, 0 unexpected, 1 skipped (2020-04-28 12:52:55+1000, 0.015803 sec)

1 skipped results:
  SKIPPED  thread-tests-list-threads-error-when-not-configured

make[1]: Leaving directory '/home/fejfighter/dev/emacs-gtk/test'



which matches a master build checkout from e49d3a45cd4a0554aa98c45f0976ed513c500951 (approx 1300 Aus EST)



> Gtk supports w32, but I have never tested on w32.
This would be nice, but is much less important, IMO.  The most
important task is to keep users of Posix systems happy with the Pgtk
build.
Thanks.

FWIW, this seems to work fine with gtk-broadway, the in-browser implementation of GTK3, aside from keystroke-clashes with firefox.
it may be some indication of a minimally "X'd" emacs, but a w32 version would be better proof.

Regards,

Jeff Walsh
(fejfighter)