From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Should this package be included into the NS port? Date: Wed, 23 May 2018 18:26:14 +0300 Message-ID: <83k1rucs15.fsf@gnu.org> References: <20180515183631.GB27909@breton.holly.idiocy.org> <20180518193632.GA31241@breton.holly.idiocy.org> <20180519103329.GB31853@breton.holly.idiocy.org> Reply-To: Eli Zaretskii 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 1527089085 12713 195.159.176.226 (23 May 2018 15:24:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 May 2018 15:24:45 +0000 (UTC) Cc: alan@idiocy.org, emacs-devel@gnu.org, georgedp@orbitalimpact.com, monnier@iro.umontreal.ca To: Nick Helm Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 23 17:24:40 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 1fLVd2-0003AY-1B for ged-emacs-devel@m.gmane.org; Wed, 23 May 2018 17:24:40 +0200 Original-Received: from localhost ([::1]:34096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLVf9-0007EL-6e for ged-emacs-devel@m.gmane.org; Wed, 23 May 2018 11:26:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLVeW-0007E2-Cg for emacs-devel@gnu.org; Wed, 23 May 2018 11:26:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLVeR-0001M4-Mo for emacs-devel@gnu.org; Wed, 23 May 2018 11:26:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLVeR-0001Lt-Jt; Wed, 23 May 2018 11:26:07 -0400 Original-Received: from [176.228.60.248] (port=2146 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fLVeR-0000o9-1I; Wed, 23 May 2018 11:26:07 -0400 In-reply-to: (message from Nick Helm on Wed, 23 May 2018 17:11:35 +1200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:225608 Archived-At: > From: Nick Helm > Date: Wed, 23 May 2018 17:11:35 +1200 > > > 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. FWIW, that's what the w32 port does. > > 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). Why do you need to have the communications between the threads be in terms of Lisp objects? In the w32 port, they communicate in C objects, and the communications pipe is the read_socket_hook. So in a nutshell, the GUI event thread sends input to the Lisp interpreter as if it was the other end of a socket through which window-system events, including keyboard, mouse, and everything else, are coming. > Putting emacsclient aside again, Emacs as a process (the Lisp loop) is > intrinsically linked to the concept of a Lisp frame, right? In other > words, no Lisp frame, no Emacs. No, that's not true. Why did you think that? > And, I guess, how does emacsclient beat this one-frame-must-exist > limitation – does it maintain some kind of fake frame that it hides from > the windowing system? That's exactly why your notion of frame-centric Emacs is inaccurate.