Remote development or emacs as a server

Remote development or emacs as a server

[Ian W]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

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.

Sincerely Ian

[-- Attachment #2: Type: text/html, Size: 1053 bytes --]

Re: Remote development or emacs as a server

[tomas]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Mon, May 18, 2020 at 01:24:11AM -0700, Ian W wrote:
> I was wondering how difficult it would be to separate the display (front-end) and server (back-end) in emacs.

See chapter 39 "Using Emacs as a Server" in the Emacs manual
(if you prefer the browser, cf [1]).

Does this help for your use case?

Cheers
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Remote development or emacs as a server

[Eli Zaretskii]

> Date: Mon, 18 May 2020 10:45:38 +0200
> From: <tomas@tuxteam.de>
> 
> See chapter 39 "Using Emacs as a Server" in the Emacs manual
> (if you prefer the browser, cf [1]).

I doubt that this is the answer being sought: in this mode of
operation the display in its entirety is still handled by the
"server", we just draw the screen on a possibly remote terminal using
X or some other protocol.

Re: Remote development or emacs as a server

[tomas]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Mon, May 18, 2020 at 06:06:40PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 18 May 2020 10:45:38 +0200
> > From: <tomas@tuxteam.de>
> > 
> > See chapter 39 "Using Emacs as a Server" in the Emacs manual
> > (if you prefer the browser, cf [1]).
> 
> I doubt that this is the answer being sought: in this mode of
> operation the display in its entirety is still handled by the
> "server", we just draw the screen on a possibly remote terminal using
> X or some other protocol.

I'm not sure either -- so thanks for offering another POV.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Remote development or emacs as a server

[Eli Zaretskii]

> Date: Mon, 18 May 2020 01:24:11 -0700
> From: Ian W <ian@wahbe.com>
> 
> 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