From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Should this package be included into the NS port? Date: Sat, 19 May 2018 13:51:21 +0200 Message-ID: References: <20180515183631.GB27909@breton.holly.idiocy.org> <20180518193632.GA31241@breton.holly.idiocy.org> <20180519103329.GB31853@breton.holly.idiocy.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b55e4b056c8db088" X-Trace: blaine.gmane.org 1526730621 11655 195.159.176.226 (19 May 2018 11:50:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 May 2018 11:50:21 +0000 (UTC) Cc: Nick Helm , George Plymale II , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 19 13:50:17 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fK0NM-0002uK-Kw for ged-emacs-devel@m.gmane.org; Sat, 19 May 2018 13:50:16 +0200 Original-Received: from localhost ([::1]:42685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fK0PS-0000RX-6W for ged-emacs-devel@m.gmane.org; Sat, 19 May 2018 07:52:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fK0Of-0000RR-1G for emacs-devel@gnu.org; Sat, 19 May 2018 07:51:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fK0Od-0005Fn-Dc for emacs-devel@gnu.org; Sat, 19 May 2018 07:51:37 -0400 Original-Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]:34710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fK0Od-0005Ff-6R for emacs-devel@gnu.org; Sat, 19 May 2018 07:51:35 -0400 Original-Received: by mail-oi0-x22e.google.com with SMTP id l1-v6so9386543oii.1 for ; Sat, 19 May 2018 04:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SCA4FUBSOc+haM34MRFutGwlfCM0LyJwh2EuhtVKZAc=; b=gyaz7Upaq/VT2E7OZ4B76Mz2/rSGtV7BFUdJl7hiynqiLSKB3oJoz1cnd4BwQeUUD8 TAbvedF7bQXG0fCSBQaaHJF6CZ30ImIH5adQ/Z8UcOr2Er3uRbMT9WF5B/Ztr6915JmY mNLBlF4UTETHWAkudEvZfafFjou0ak/TcZfQ2mMgFMkIRzKSv0HDgWrLG8XI4+/WB/Vt RIkR7BCrvzmovUU6EzO7P6+U/a3N3q/7bOKO5Y2WfYInWZrVj9KPukbLIuqdZRAjDHOO YtdgmZ+AIISkAbLQEnPBBVVjOUPHkaMsrJjWQQyJVwFDiZwwBdAwLwhfukylldIJB+28 9cTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SCA4FUBSOc+haM34MRFutGwlfCM0LyJwh2EuhtVKZAc=; b=IIGeCX8CXUeh0qdkn2jf0HlE7LQy8ipmH9bMh+TfxkiosKGK4oUk9aiXg3mLd/Dl49 KBXpBsV0Z+i84RizpquHD0moWzimXkeziQaOtyMF4vFyAi+iptBlyLK6OfBVvCEX0NUL fbLK6vc2YVoLlqfwvXMP9lBdFsglUbDlPNE0qAxvJnOhTISg3npqHTT3GLebt8R8X2pg 6Uem10HVgdTsSIEsyDwwo1qioC59DcTcVrzhj9o3jNilNuTzMN9XssSfIiMUslX+vgNp cXAfq/GUX1vWdC7W+V2mc14Oz+klx1zi/Df9nxnjng6GwVBm80141EbuF7jes8ZyvSFX eFdw== X-Gm-Message-State: ALKqPwegmwmMOAVr/Z/org+lp/qFKMHlc0HxrFSfREYMEQ6yhpM8Hs6x Vii4FB462DbRLWsVM8rG7S00voF1RtESnGI5yK8= X-Google-Smtp-Source: AB8JxZp8FkezCfb9CYVFYYAvQ84tJLRQXmLTcJjautrdYw08qRRxStgmvXppdbETLNPsuY0CjL6jK1sYY31X/3XIHv0= X-Received: by 2002:aca:3f04:: with SMTP id m4-v6mr7689581oia.198.1526730694415; Sat, 19 May 2018 04:51:34 -0700 (PDT) In-Reply-To: <20180519103329.GB31853@breton.holly.idiocy.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225435 Archived-At: --000000000000b55e4b056c8db088 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alan Third schrieb am Sa., 19. Mai 2018 um 12:34 Uhr: > On Sat, May 19, 2018 at 04:42:54PM +1200, Nick Helm wrote: > > On Sat, 19 May 2018 at 07:36:32 +1200, Alan Third wrote: > > > > > There are two problems, though. > > > > > > * Application Menu > > > > > > When the last NS frame is deleted the menus aren=E2=80=99t updated, s= o I think > > > they=E2=80=99ll be the menus as defined for the last frame. They shou= ld > > > probably be cut right back to just the =E2=80=98Emacs=E2=80=99 menu, = and perhaps > > > =E2=80=98help=E2=80=99. > > > > This is interesting. I think we could tweak the EmacsMenu side of thing= s > > to do this, even with the current code. We'd want to make sure to > > include some kind of new frame command somewhere. > > > > These menus are derived dynamically from Lisp though, and it might be > > difficult to convince it to provide valid entries when no frame is > > selected. > > I=E2=80=99m not sure if the =E2=80=98Emacs=E2=80=99 menu is derived from = lisp. If you turn off > menus completely it still exists. > > > One way around that might be to create a new menu containing > > static NSMenu versions of File and Help, much like we do for the appMen= u > > now. When no frame is selected and there are no Lisp menu entries, we > > switch mainMenu to this new menu. When a frame is created, we switch > > back. > > Perhaps we could modify ns_update_menubar to handle the case where > there=E2=80=99s no frame? > > > > * Dock Menu > > > > > > This has a =E2=80=98new frame=E2=80=99 option but just plain doesn=E2= =80=99t work. I think the > > > problem is the way it=E2=80=99s trying to create a new frame:... > > > > > > This seems to rely on there being an existing NS frame, but we=E2=80= =99ve > > > deleted the last one. I assume if we were clever we=E2=80=99d be able= to use > > > the, still open, terminal frame. > > > > With all of this discussion, I feel like I'm missing something really > > fundamental. Putting emacsclient aside for a moment, if we were dealing > > with a standard Cocoa app, the window server and NSApp loop would keep > > running in the background and we could close everything, then create a > > new frame (as a view on an NSWindow instance) as needed. > > FWIW, the NSApp loop does keep running, but it=E2=80=99s embedded in ns_s= elect > and ns_read_socket. We can, in theory, create a new frame directly, > but it needs to run through Emacs first. > > > How is the architecture of Emacs on NS so different from standard Cocoa > > that these kinds of workarounds are necessary? > > The fundamental issue in the NS port is that we have two bosses: the > NSApp run loop, and Emacs lisp, and we need to mediate between them. > > A standard Cocoa app responds to events from the NSApp loop, and > that=E2=80=99s pretty much it. As I understand it you can make a complete= app > without very much work this way. The NSApp loop is the boss. > > Emacs=E2=80=99 architecture expects everything to go through lisp and it = makes > decisions on what we do with our GUI. Emacs lisp is the boss. > > We can=E2=80=99t react directly to NS events like a normal NS app. We get > input from the NSApp loop and send it to lisp. Lisp might tell us to > do something any time. We also need to know how Emacs expects to do > things (the GUI code was originally written for a completely different > platform after all) and then try and make Cocoa/GNUstep handle it > correctly. > > In an ideal world (and I believe the Mac port has gone this way) we > would put the NSApp run loop in one thread, and Emacs lisp in another > and let them communicate with each other asynchronously. This wouldn=E2= =80=99t > solve everything, but it would make some of our problems easier. > > We can=E2=80=99t easily do that, though, as the inter=E2=80=90thread comm= unication > systems provided in Objective=E2=80=90C are either a pain to implement wi= th > complex types like Lisp_Object, or aren=E2=80=99t compatible with GCC and= /or > GNUstep (Grand Central Dispatch). > > Additionally I think we sometimes have workarounds fixing workarounds > fixing hacks, all written by different people, and the simplest > solution is to strip it right back to the basics. I have a feeling the > menus fall somewhat into this category, and the drag=E2=80=90n=E2=80=90dr= op stuff > definitely does. > > > In an ideal world (and I believe the Mac port has gone this way) we > TL;DR: Emacs internal architecture doesn=E2=80=99t fit well into the stan= dard > NS application architecture. > FWIW, this problem description and the solution seem the same on every OS/toolkit: the Lisp interpreter should always run in a background thread and communicate with the UI thread asynchronously through message passing. --000000000000b55e4b056c8db088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Alan T= hird <alan@idiocy.org> schrieb= am Sa., 19. Mai 2018 um 12:34=C2=A0Uhr:
On Sat, May 19, 2018 at 04:42:54PM +1200, Nick Helm wrote:
> On Sat, 19 May 2018 at 07:36:32 +1200, Alan Third wrote:
>
> > There are two problems, though.
> >
> > * Application Menu
> >
> > When the last NS frame is deleted the menus aren=E2=80=99t update= d, so I think
> > they=E2=80=99ll be the menus as defined for the last frame. They = should
> > probably be cut right back to just the =E2=80=98Emacs=E2=80=99 me= nu, and perhaps
> > =E2=80=98help=E2=80=99.
>
> This is interesting. I think we could tweak the EmacsMenu side of thin= gs
> to do this, even with the current code. We'd want to make sure to<= br> > include some kind of new frame command somewhere.
>
> These menus are derived dynamically from Lisp though, and it might be<= br> > difficult to convince it to provide valid entries when no frame is
> selected.

I=E2=80=99m not sure if the =E2=80=98Emacs=E2=80=99 menu is derived from li= sp. If you turn off
menus completely it still exists.

> One way around that might be to create a new menu containing
> static NSMenu versions of File and Help, much like we do for the appMe= nu
> now. When no frame is selected and there are no Lisp menu entries, we<= br> > switch mainMenu to this new menu. When a frame is created, we switch > back.

Perhaps we could modify ns_update_menubar to handle the case where
there=E2=80=99s no frame?

> > * Dock Menu
> >
> > This has a =E2=80=98new frame=E2=80=99 option but just plain does= n=E2=80=99t work. I think the
> > problem is the way it=E2=80=99s trying to create a new frame:...<= br> > >
> > This seems to rely on there being an existing NS frame, but we=E2= =80=99ve
> > deleted the last one. I assume if we were clever we=E2=80=99d be = able to use
> > the, still open, terminal frame.
>
> With all of this discussion, I feel like I'm missing something rea= lly
> fundamental. Putting emacsclient aside for a moment, if we were dealin= g
> with a standard Cocoa app, the window server and NSApp loop would keep=
> running in the background and we could close everything, then create a=
> new frame (as a view on an NSWindow instance) as needed.

FWIW, the NSApp loop does keep running, but it=E2=80=99s embedded in ns_sel= ect
and ns_read_socket. We can, in theory, create a new frame directly,
but it needs to run through Emacs first.

> How is the architecture of Emacs on NS so different from standard Coco= a
> that these kinds of workarounds are necessary?

The fundamental issue in the NS port is that we have two bosses: the
NSApp run loop, and Emacs lisp, and we need to mediate between them.

A standard Cocoa app responds to events from the NSApp loop, and
that=E2=80=99s pretty much it. As I understand it you can make a complete a= pp
without very much work this way. The NSApp loop is the boss.

Emacs=E2=80=99 architecture expects everything to go through lisp and it ma= kes
decisions on what we do with our GUI. Emacs lisp is the boss.

We can=E2=80=99t react directly to NS events like a normal NS app. We get input from the NSApp loop and send it to lisp. Lisp might tell us to
do something any time. We also need to know how Emacs expects to do
things (the GUI code was originally written for a completely different
platform after all) and then try and make Cocoa/GNUstep handle it
correctly.

In an ideal world (and I believe the Mac port has gone this way) we
would put the NSApp run loop in one thread, and Emacs lisp in another
and let them communicate with each other asynchronously. This wouldn=E2=80= =99t
solve everything, but it would make some of our problems easier.

We can=E2=80=99t easily do that, though, as the inter=E2=80=90thread commun= ication
systems provided in Objective=E2=80=90C are either a pain to implement with=
complex types like Lisp_Object, or aren=E2=80=99t compatible with GCC and/o= r
GNUstep (Grand Central Dispatch).

Additionally I think we sometimes have workarounds fixing workarounds
fixing hacks, all written by different people, and the simplest
solution is to strip it right back to the basics. I have a feeling the
menus fall somewhat into this category, and the drag=E2=80=90n=E2=80=90drop= stuff
definitely does.


In an ideal world (and I believe the Mac port has gone this way) we
TL;DR: Emacs internal architecture doesn=E2=80=99t fit well into the standa= rd
NS application architecture.

FWIW, this problem description and the sol= ution seem the same on every OS/toolkit: the Lisp interpreter should always= run in a background thread and communicate with the UI thread asynchronous= ly through message passing.=C2=A0
--000000000000b55e4b056c8db088--