From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Remote development or emacs as a server Date: Mon, 18 May 2020 18:04:43 +0300 Message-ID: <83a7259tdg.fsf@gnu.org> References: <47bc4fe0-ff1c-4f33-b65f-b693c3eca448@Spark> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="19887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Ian W Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 17:06:15 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 1jahLL-00055X-S2 for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 17:06:15 +0200 Original-Received: from localhost ([::1]:48614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jahLK-0002Ao-UT for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 11:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jahJz-0000rK-1B for emacs-devel@gnu.org; Mon, 18 May 2020 11:04:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58670) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jahJy-0003BD-Li; Mon, 18 May 2020 11:04:50 -0400 Original-Received: from [176.228.60.248] (port=2305 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jahJx-0003BD-Ag; Mon, 18 May 2020 11:04:50 -0400 In-Reply-To: <47bc4fe0-ff1c-4f33-b65f-b693c3eca448@Spark> (message from Ian W on Mon, 18 May 2020 01:24:11 -0700) 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:250756 Archived-At: > Date: Mon, 18 May 2020 01:24:11 -0700 > From: Ian W > > I was wondering how difficult it would be to separate the display (front-end) and server (back-end) in emacs. > I’m not familiar with the emacs code base, but I poked around for a couple of hours, and couldn’t find any > centralized I/O abstraction, just #ifdefs (this difficulty was discussed in Unify the Platforms: > Cairo+FreeType+Harfbuzz Everywhere (except TTY)). I want emacs to have first class support for remote > development (running emacs as a server, and connecting a gui front end to it from another computer). This > seams like the first step. Any help would be appreciated. I'm not sure we are on the same page when we talk about "display and server" in this context. The design of the Emacs display engine is not client/server, it's more like master/slave. So maybe my answer below will make no sense to you, in which case please describe your mental model in more detail. AFAIU, the I/O abstraction you are looking for is the FRAME_RIF ("RIF" stands for "Redisplay InterFace") and FRAME_TERMINAL. These two structures hold terminal- and window-system-specific methods invoked by the display engine when it needs to do something that's done differently on different kinds of display. The simplest example is the method used to write a series of glyphs on the glass. FRAME_RIF is defined in dispextern.h ('struct redisplay_interface') and FRAME_TERMINAL is defined in termhooks.h ('struct terminal'). They are both filled by the respective implementations: xterm.c for X, w32term.c for MS-Windows, etc. The separation of the interface into two collections of methods is largely historic and could be ignored for your purposes. If you are thinking about physically separating these two layers, then there will be need for some protocol through which the two parts will talk. Also, be aware that the current display algorithms don't assume any significant delay between the command to the "slave" to do something and the actual effect, something that could be invalid for separate operation. HTH