emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remote development or emacs as a server


From: Eli Zaretskii
Subject: Re: Remote development or emacs as a server
Date: Mon, 18 May 2020 18:04:43 +0300

> Date: Mon, 18 May 2020 01:24:11 -0700
> From: Ian W <address@hidden>
> 
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]