From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jeff Walsh Newsgroups: gmane.emacs.devel Subject: Re: emacs for pure Gtk3 Date: Tue, 28 Apr 2020 13:19:04 +1000 Message-ID: <1588043944.2848.14@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=-Fi8DI6uqSKhccgKM3d0k" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="40554"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 28 05:20:01 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jTGmu-000AQS-Nw for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Apr 2020 05:20:00 +0200 Original-Received: from localhost ([::1]:40964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTGmt-0003RK-Pj for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Apr 2020 23:19:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49340) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTGmF-0002sH-1y for emacs-devel@gnu.org; Mon, 27 Apr 2020 23:19:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTGmD-00025I-00 for emacs-devel@gnu.org; Mon, 27 Apr 2020 23:19:18 -0400 Original-Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:36986) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTGm7-00024R-TR; Mon, 27 Apr 2020 23:19:12 -0400 Original-Received: by mail-pg1-x52b.google.com with SMTP id r4so9638312pgg.4; Mon, 27 Apr 2020 20:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:mime-version; bh=rTQpDwBZYvTv/XeUcLWLhzHtp8zrsEHDiJ/aWf/ivrE=; b=ToLjWV7KfzONyWkqp+gYj5nEXedZPHBM3byxrBPcr0KOUO3IRY4zjz9IyHUyZ+jDKN lE1W1vYAqL/Mi+x7f4itdTwORawkJ5S2zc7Ox3ePMEbZ4CkLnIpHqqKkBdUVt9R1misc zCaYH+tB0LgupRZsvn7ro1g5bTltMVGKeNz611+k2+b31Dq3k2Vt/ud7LGsmzX6xrPLI fp3Vxin3KZXnYNEJbFsaSUtZqmOn2m/8LOK2nxOjZ8vpi3zbQ4UpL2sCdBPY7l6nvl9F YFTPvjsCfD2mVI8y0WQPoDuC/INHydcqq2hIkotl5jbTwUeHcGv2Mgws6l1wm2X6cDv6 Pctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:mime-version; bh=rTQpDwBZYvTv/XeUcLWLhzHtp8zrsEHDiJ/aWf/ivrE=; b=G1/oG1leoPbG9VsuCdAA/INCvBuSkHyPEvrQgkc+WIUKJ1W1wxAL87j/ZNs4ekRz9w gW0R4RyMfe6M/rK9WH6aMzU/xDoPyibYrLXgLVuiJmU+PnRkU1OzSNaTfb7c8waUb1D1 nbw0CYaALBfMv4jsvhx2+MmxbFyPRlpQH/PcqxdJrR2DTZojPaU6Vi0H1JvE/fapBud6 vK/fqsrJjpocLz0mMA8vt5Mc2Ssl/aVu0kadjbfhb2mdBevLN/TcINUfJVXwVjjH6P/u D6XAUquJDPFq99CucXxr+ioUO6H7efgzdwElPPRg+kV4rcS6hFvxRun8oTY2NkdLM2uF GUVg== X-Gm-Message-State: AGi0PuZCRcExG4nMUI2vEbjQmMpbiqBzXe3ClGihGN7a0y8COhQ6Bj28 1nUhALplhTJKyRuC5tgpeWrJAwhV X-Google-Smtp-Source: APiQypLc8kS+poPfWP3TbZrFpU93z5LGdkRJVnBady/RIHrVTMiQ+zVP7WlwdOL2lAidzVkOAaWovg== X-Received: by 2002:a63:6342:: with SMTP id x63mr22532584pgb.185.1588043949883; Mon, 27 Apr 2020 20:19:09 -0700 (PDT) Original-Received: from [192.168.1.11] (124-171-221-222.dyn.iinet.net.au. [124.171.221.222]) by smtp.gmail.com with ESMTPSA id h5sm638439pjv.4.2020.04.27.20.19.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 20:19:09 -0700 (PDT) X-Mailer: geary/3.34.2 Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=fejfighter@gmail.com; helo=mail-pg1-x52b.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::52b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247993 Archived-At: --=-Fi8DI6uqSKhccgKM3d0k Content-Type: text/plain; charset=us-ascii; format=flowed > *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 / > >/ / > >/ > . 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,/ > >/ ./ > >/ 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. > > >/ 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) --=-Fi8DI6uqSKhccgKM3d0k Content-Type: text/html; charset=us-ascii

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)









--=-Fi8DI6uqSKhccgKM3d0k--