From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Mon, 31 Oct 2016 08:59:11 -0700 Message-ID: <32899811-83bb-e1f0-4f82-3e41846d7d0c@dancol.org> References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> <11E61536-1345-4B81-999D-2E17F8B14C62@dancol.org> <83a8dkpl67.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477931676 25002 195.159.176.226 (31 Oct 2016 16:34:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 31 Oct 2016 16:34:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: raeburn@raeburn.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 31 17:34:29 2016 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 1c1FWx-0000wO-EC for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2016 17:33:51 +0100 Original-Received: from localhost ([::1]:36855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1FWz-0005HH-Rj for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2016 12:33:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1Ezf-0007oF-4r for emacs-devel@gnu.org; Mon, 31 Oct 2016 11:59:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1Ezb-0002uJ-7R for emacs-devel@gnu.org; Mon, 31 Oct 2016 11:59:27 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:43994) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c1Eza-0002qZ-Ud; Mon, 31 Oct 2016 11:59:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=6tlvSf3p6T8RUwb2K52/Ene8A827lo1+UhxmSENhDME=; b=kMMQrLRLPqo8JZTqTG8USefxm5oxNdE2YyKminFeO9MqDVqkYzo64zX4SbFtq/n8XF60Antj1TPmXxs11IUhcNGLCA+o600oVkY9IBjA9kko10i3vy19G9Oxurg1Lk8KHFcYHQWyph/YXon5uY0FXtDt6EOy5YGRApEMYSQHkKNMcLT2s65OoLW0jX5GT4Hw259nl6bUD/HD3oTdy0j1HWzZ0++bjuhuxuN6jSDPPnLg5/xTLFb25z7xKsmedqOy0a6m3Fck1V7VBgee7uDl9S471txy+BjBGwrTfkogN8Hn3R6rjQEGeTAUkLT9OeB7iddb7qhCiYxRlILWbgVg0A==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1c1EzS-0002pZ-Oc; Mon, 31 Oct 2016 08:59:14 -0700 In-Reply-To: <83a8dkpl67.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209024 Archived-At: On 10/31/2016 08:56 AM, Eli Zaretskii wrote: >> From: Daniel Colascione >> Date: Sun, 30 Oct 2016 15:49:02 -0700 >> Cc: emacs-devel@gnu.org >> >> Agreed. That's basically how IntelliJ works too. We can do even better too: >> there's no reason these parts need to run in the same process it even the same >> machine. > > I think we should be careful when comparing Emacs with systems that > have a different basic design. In Emacs, almost everything is driven > by changes in buffer text and the data structures that accompany > buffer text, and the Lisp interpreter is inherent in many > display-related features. > > For example, this: > >> But this scheme won't really eliminate the coupling between redisplay and lisp >> though, since the former calls into the latter. The redisplay thread has to >> block waiting on lisp anyway. > > is a major issue that those other systems might not have. > >> Anyway, I strongly encourage you to look at the React Native rendering model. >> It's the most elegant way I've seen of constructing GUIs in general. > > Where's that model described in enough technical detail to be able to > compare it with what we do in Emacs? > >> The key insight there is that we shouldn't have redisplay *lock* the display >> matrix and render it. The lisp universe should send a *copy* of the matrix set, >> then go about its business. This way, redisplay can go display that copy and >> everything is decoupled. You turn the system into an Erlang like message >> passing environment. > > There's probably some confusion or misunderstanding here: the Lisp > code in Emacs has no access to the glyph matrices, so it does not (and > cannot) "send the display matrix" to the display engine. Thus, the > fact that the display engine can lock the glyph matrices is due to its > being their sole writer and reader. The communication between the > Lisp universe and the display engine is solely via the buffer text and > the auxiliary data structures (text properties, overlays, etc.). The "lisp universe" is a terrible name for what I had in mind. Sorry for the confusion. Stefan is proposing splitting Emacs into at least two parts: one part that responds to OS-level events: repainting, input, and so on; and one part that runs lisp code, changes buffer text, and so on. It's this latter part I've been calling the "lisp universe", but it's more than that. Of course there's no direct access to glyph matrices, but you can imagine a scheme where both of the two parts above each have an idea of what desired layout should be.