From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: Should this package be included into the NS port? Date: Sat, 19 May 2018 11:33:29 +0100 Message-ID: <20180519103329.GB31853@breton.holly.idiocy.org> References: <20180515183631.GB27909@breton.holly.idiocy.org> <20180518193632.GA31241@breton.holly.idiocy.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1526725933 12205 195.159.176.226 (19 May 2018 10:32:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 May 2018 10:32:13 +0000 (UTC) User-Agent: Mutt/1.9.3 (2018-01-21) Cc: emacs-devel@gnu.org, George Plymale II , monnier@iro.umontreal.ca To: Nick Helm Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 19 12:32:08 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 1fJz9k-00035i-8I for ged-emacs-devel@m.gmane.org; Sat, 19 May 2018 12:32:08 +0200 Original-Received: from localhost ([::1]:42491 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJzBr-0007Zd-AV for ged-emacs-devel@m.gmane.org; Sat, 19 May 2018 06:34:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJzB9-0007ZU-Qh for emacs-devel@gnu.org; Sat, 19 May 2018 06:33:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fJzB8-0000EY-Ha for emacs-devel@gnu.org; Sat, 19 May 2018 06:33:35 -0400 Original-Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:50610) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fJzB8-0000E6-6U for emacs-devel@gnu.org; Sat, 19 May 2018 06:33:34 -0400 Original-Received: by mail-wm0-x242.google.com with SMTP id t11-v6so18031328wmt.0 for ; Sat, 19 May 2018 03:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Igt53syjUcFgjrSFTPytijXpgzmSUUndGtI8fPzk4OU=; b=LJdPsbD9NR22nTHZGy3CUEhvQxZW8vyPOY/bhOQWzeb0rAcp792UbbTmrj8hHCZmXj Gy26GkXF7HbQFiDvAagoiHzIFqmtGVp+uc57+CKMIn0dGp8Jf58O7uz9xPG9eBbqS0Ql 7RpFdxPB1JRjRCdTJQS+hQQ58czLxG7+QTysVUKrnwRr11mttEAAQgTv4jIbZMixWjI2 ToXMTXBAY5fbzZwtlhOPaHv/hNUpWs+c+eNxhdMwiom6En7oVH7Nddk42qNcINyw4Mg5 uCcf5K2QhqQI/Un0klNoUPRlVa7iPF2NJ9kOYMOneaLXL0wAk4kTCMW3bvdaYJvP1kWf nDtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Igt53syjUcFgjrSFTPytijXpgzmSUUndGtI8fPzk4OU=; b=ptvyxSX6RXhNfN6apJOYKog8L8RJuR9NbJh98WDwYA1v/xtpmBI12K3DMsFAvGGInC w+cP7vG4EL1wAlPZ+pDB2KK+qujdIcpj6ScbFZUXiGno7Y4jU5Ge1fU7AOuhKxcRduKR VrO/S5DsZvP16qcxgQPKgn0KRZGJ2LYtfBS4XPSp0Qu4XyG9a1Y3Sxpo+eBYTGMdmwV7 IDvEOnFu4x+u0/hLS1Fo79ufJhlvU9yCaKaumyvHt4uNPi/4zwyWx0PBtJRngFT0Jd2I NUpEP7R6q6w7eSTAYnfB+UMaLL4rAHmMRzjlotoUUm7DTkZeif73PRo5UEN2Z+Hz1/IZ DaQA== X-Gm-Message-State: ALKqPwdWNQbtS4sd/cCoZngN2Ja3lHB8kKT/phBpl8sXhe0FnTOxAF8t BUOWJmTmctfVcZn/Kvf7Dss= X-Google-Smtp-Source: AB8JxZqXhEiaMmb5gRxAtJZ9WxmnYhtGZTG8A5xiyR5+s3H+EZx4ysegotxA3cnZQYOsaAy9i5FVCw== X-Received: by 2002:a1c:c6ca:: with SMTP id w193-v6mr6584976wmf.68.1526726013045; Sat, 19 May 2018 03:33:33 -0700 (PDT) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-3195-ed66-b02d-6c9f.holly.idiocy.org. [2001:8b0:3f8:8129:3195:ed66:b02d:6c9f]) by smtp.gmail.com with ESMTPSA id u20-v6sm9010383wru.33.2018.05.19.03.33.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 May 2018 03:33:32 -0700 (PDT) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::242 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:225433 Archived-At: 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’t updated, so I think > > they’ll be the menus as defined for the last frame. They should > > probably be cut right back to just the ‘Emacs’ menu, and perhaps > > ‘help’. > > This is interesting. I think we could tweak the EmacsMenu side of things > 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’m not sure if the ‘Emacs’ 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 appMenu > 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’s no frame? > > * Dock Menu > > > > This has a ‘new frame’ option but just plain doesn’t work. I think the > > problem is the way it’s trying to create a new frame:... > > > > This seems to rely on there being an existing NS frame, but we’ve > > deleted the last one. I assume if we were clever we’d 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’s embedded in ns_select 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’s 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’ 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’t 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’t solve everything, but it would make some of our problems easier. We can’t easily do that, though, as the inter‐thread communication systems provided in Objective‐C are either a pain to implement with complex types like Lisp_Object, or aren’t 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‐n‐drop stuff definitely does. In an ideal world (and I believe the Mac port has gone this way) we TL;DR: Emacs internal architecture doesn’t fit well into the standard NS application architecture. -- Alan Third