local emacsclient to remote emacs server

local emacsclient to remote emacs server

[t]

Hi Emacs users.

Is there a way to connect local emacsclient to the remote emacs server? I am trying to figure out a way to leverage emacs for remote dev work, wherein the remote machine is my development server: files are there, processes run there (TRAMP therefore isn't enough). E.g. could be a containerized dev environment.

Kinda surprised that VSCode "just works" for that sort of thing, but perhaps I shouldn't be. After all it runs in the browser.

Yes, ssh + screen or tmux + terminal emacs kinda work, but feels wrong to have all of these intermediate layers when all I really care about is Emacs. I don't use shells much and when I do I prefer to do it from Emacs.

Ideally I wish I could run X version in all its GUI glory, but XQuartz on OSX can't handle hiDPI or I failed to figure a way to get reasonable resolution. Ditto `xpra`. Linux to Linux it actually works just fine.

Let's go with `caveman` version then. We'll start remote daemon and forward its Unix socket to our local machine:
> ssh -L /tmp/foomacs:/run/user/1000/foomacs remote
> emacs --daemon=foomacs --no-desktop

Local machine (OSX in my case):
> emacsclient -s /tmp/foomacs -t
> *ERROR*: could not open file: /dev/ttys007

Should I have reasonably expected this to work? Or was Emacs client/server not built for such usecase? Remote server running Emacs 28. Tried local emacsclient27 and emacsclient28 - same result.

Thanks

Re: local emacsclient to remote emacs server

[Eric S Fraga]

On Monday, 21 Mar 2022 at 16:15, t@fullmeta.me wrote:
> Yes, ssh + screen or tmux + terminal emacs kinda work, but feels wrong

Would "ssh -X emacsclient ..." do the job?  (I have no idea)
-- 
Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2

Re: local emacsclient to remote emacs server

[Manuel Giraud]

Hi,

I don't know if this is the purpose of the Emacs server but I think you
should read this info node : "(emacs) TCP Emacs server". It seems to
have everything: using TCP, fixing port, auth key (I still advise you to
run it over a ssh tunnel).

Best regards,
-- 
Manuel Giraud

Re: local emacsclient to remote emacs server

[Robert Pluim]

>>>>> On Mon, 21 Mar 2022 21:31:49 +0100, Manuel Giraud <manuel@ledu-giraud.fr> said:

    Manuel> Hi,
    Manuel> I don't know if this is the purpose of the Emacs server but I think you
    Manuel> should read this info node : "(emacs) TCP Emacs server". It seems to
    Manuel> have everything: using TCP, fixing port, auth key (I still advise you to
    Manuel> run it over a ssh tunnel).

I seem to remember that only working if the client and server systems
are similar ie GNU/Linux <-> GNU/Linux, not macOS <-> GNU/Linux (but
Iʼd be happy to be wrong).

Robert
-- 

Re: local emacsclient to remote emacs server

[Felix Dietrich]

Let me preface this reply with the note that I do not have access to a
computer with MacOS and have, therefore, no real clue.  I also do not
have a HiDPI display.  This is just a shot in the dark.

t@fullmeta.me writes:

> Ideally I wish I could run X version in all its GUI glory, but XQuartz
> on OSX can't handle hiDPI or I failed to figure a way to get
> reasonable resolution. Ditto `xpra`. Linux to Linux it actually works
> just fine.

I donʼt think I am able to properly picture your issue, but searching
for HiDPI in conjunction once with XQuartz and once with Emacs delivered
a couple of suggestions:

    1) Use xrandr to set the DPI [1] 

       Supposedly this requires to “enable full screen mode in XQuartz”.
       This site also states that “we canʼt make this permanent”, but I
       suspect that there is a script somewhere in which you could plug
       the xrandr command, or possibly a configuration option (see the
       next point).

       $ xrandr --output default --mode 5120x2880 --dpi 218

    2) Ways to set the DPI [2]

       This one is somewhat Linux specific, but maybe you can find a way
       to adjust file locations for the MacOS environment.

       - Set “Xft.dpi” in “$HOME/.Xresources”.

       - Monitor section in xorg.conf.d/40-dpi.conf

         # Will set your DPI to 141x141 if the screen is 1080p
         Section "Monitor"
             Identifier   "<default monitor>"
             DisplaySize  340 190    # In millimeters
         EndSection

      - “-dpi” argument to X

    3) Set a higher font size in Emacs [3]

        (let ((FONT "Droid Sans Mono-30"))
          (setf (alist-get 'font default-frame-alist) FONT)
          (set-face-attribute ’default t :font FONT))


There is also “x2go” which uses XQuartz, but its programmers may have
already figured out the correct settings to provide to it.

Had you already found and tried these?


Footnotes:
[1]  <https://xw.is/wiki/HiDPI_XQuartz>

[2]  <https://web.archive.org/web/20210115200209/https://linuxreviews.org/HOWTO_set_DPI_in_Xorg>

[3]  <https://unix.stackexchange.com/questions/242067/emacs-on-hidpi-screen-renders-unreadable-fonts-arch-Linux>

-- 
Felix Dietrich

Re: local emacsclient to remote emacs server

[t]

Hi Felix.

Thank you for suggestions.

>     1) Use xrandr to set the DPI [1] 
>
>        Supposedly this requires to “enable full screen mode in XQuartz”.
>        This site also states that “we canʼt make this permanent”, but I
>        suspect that there is a script somewhere in which you could plug
>        the xrandr command, or possibly a configuration option (see the
>        next point).
>
>        $ xrandr --output default --mode 5120x2880 --dpi 218

I've just tried that and was at least able to confirm that, yep, you can get hiDPI on OSX. You'd have to do the xrandr dance and really crank up face height in Emacs but it is possible and the text is crisp. Sadly, I was unable to have XQuartz recognize that I have two displays. xrandr reports a single one, XQuartz darkens both and lets you only drag a part of the window onto external display. Google is very quiet on all things XQuartz. Ditto their mailing list.

> There is also “x2go” which uses XQuartz, but its programmers may have
> already figured out the correct settings to provide to it.
>
> Had you already found and tried these?

I've not tried x2go, it doesn't have x2goserver package for Guix. I could probably try and build it from source. I have tried XPRA, which kinda worked but the author confirmed that HiDPI won't work on OSX, yet.

Best

Re: local emacsclient to remote emacs server

[Manuel Giraud]

Hi,

So like you did, I tried to setup an emacs server on one server and have
the emacsclient locally. I tried using TCP but ended up with the same
error as you:

Waiting for Emacs...
*ERROR*: Could not open file: /dev/ttyp3

… so I don't think that it is the intended usage of "Emacs server". It
is more an "editing server" (running locally).

Anyway, I think your best bet now is TRAMP. You can do a lot of things
in TRAMP including running remote commands.

Best regards,
-- 
Manuel Giraud

Re: local emacsclient to remote emacs server

[t]

> Anyway, I think your best bet now is TRAMP. You can do a lot of things
> in TRAMP including running remote commands.

Yes, this is another possible route, and FWIW once you figure out appropriate settings for TRAMP and your remote it mostly works. However, my need is complicated some by the remote environment I envision. So, here goes.

Are there any Emacs TRAMP users connecting to Guix machine here? My use case is this. I would like to be able to use said remote machine for all my dev work. Of course the selling point of Guix is that you can setup reproducible and minimal execution environments for your code and hacking - think Virtualenv pushed to its logical conclusion. So, typically I'd do the following:

1. mkdir myproj
2. drop a manifest.scm or guix.scm script inside that has input packages and sets up services, possibly entire OS definition in system.scm
3. spawn this programmed environment `guix shell -D -f guix.scm` or inside a container `guix shell -c` or if I really need to be close to production or run services spawn entire OS in a container `guix system -c system.scm`
4. start Emacs inside that environment

Now, do you see the problem with TRAMP? TRAMP is essentially an SSH session spawned from local Emacs already running. It ends up talking to your login shell over ssh basically. But we need this Guix induced or potentially even containerized environment. There needs to be some kind of "hop" or additional step after TRAMP establishes an ssh connection that puts its shell in appropriate environment. Is there a way to do that?

Re: local emacsclient to remote emacs server

[Robert Pluim]

>>>>> On Wed, 23 Mar 2022 12:55:34 +0100, Manuel Giraud <manuel@ledu-giraud.fr> said:

    Manuel> Hi,
    Manuel> So like you did, I tried to setup an emacs server on one server and have
    Manuel> the emacsclient locally. I tried using TCP but ended up with the same
    Manuel> error as you:

    Manuel> Waiting for Emacs...
    Manuel> *ERROR*: Could not open file: /dev/ttyp3

    Manuel> … so I don't think that it is the intended usage of "Emacs server". It
    Manuel> is more an "editing server" (running locally).

Right. Iʼve taken a look at the emacs code, it tries to open the tty
that emacsclient is running on, and obviously that doesnʼt work, since
thatʼs on a different machine than where emacs is running.

Robert
-- 

Re: local emacsclient to remote emacs server

[Robert Pluim]

>>>>> On Thu, 24 Mar 2022 11:09:30 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Wed, 23 Mar 2022 12:55:34 +0100, Manuel Giraud <manuel@ledu-giraud.fr> said:
    Manuel> Hi,
    Manuel> So like you did, I tried to setup an emacs server on one server and have
    Manuel> the emacsclient locally. I tried using TCP but ended up with the same
    Manuel> error as you:

    Manuel> Waiting for Emacs...
    Manuel> *ERROR*: Could not open file: /dev/ttyp3

    Manuel> … so I don't think that it is the intended usage of "Emacs server". It
    Manuel> is more an "editing server" (running locally).

    Robert> Right. Iʼve taken a look at the emacs code, it tries to open the tty
    Robert> that emacsclient is running on, and obviously that doesnʼt work, since
    Robert> thatʼs on a different machine than where emacs is running.

BTW, one other possible solution to this is to use the 'crdt' package:
it connects a local emacs to a remote emacs over tcp. You edit
locally, and it sends the changes to the remote emacs. Iʼve not used
it much, but it seems to work well enough.

Robert
-- 

Re: local emacsclient to remote emacs server

[Michael Albinus]

t@fullmeta.me writes:

Hi,

> Now, do you see the problem with TRAMP? TRAMP is essentially an SSH
> session spawned from local Emacs already running. It ends up talking
> to your login shell over ssh basically. But we need this Guix induced
> or potentially even containerized environment. There needs to be some
> kind of "hop" or additional step after TRAMP establishes an ssh
> connection that puts its shell in appropriate environment. Is there a
> way to do that?

Tramp does not support this (yet). But your use case is not the only
one; Python developers have asked also for Tramp support of virtual
environments.

I have no idea what the best solution will be. Maybe some additional
configuration means for SSH based Tramp methods. Or maybe an additional
"environment hop" for Tramp (interesting idea, btw).

I'm willing to work on that. However, I'm neither a Guix or Python user,
so I need support in order to understand what is needed.

In order to track this, it might help if you could write en Emacs bug.

Best regards, Michael.

Re: local emacsclient to remote emacs server

[Felix Dietrich]

t@fullmeta.me writes:

> I would like to be able to use said remote machine for all my dev
> work. Of course the selling point of Guix is that you can setup
> reproducible and minimal execution environments for your code and
> hacking - think Virtualenv pushed to its logical conclusion. So,
> typically I'd do the following:
>
> 1. mkdir myproj
> 2. drop a manifest.scm or guix.scm script inside that has input packages and sets up services, possibly entire OS definition in system.scm
> 3. spawn this programmed environment `guix shell -D -f guix.scm` or
> inside a container `guix shell -c` or if I really need to be close to
> production or run services spawn entire OS in a container `guix system
> -c system.scm`
> 4. start Emacs inside that environment
>
> Now, do you see the problem with TRAMP? TRAMP is essentially an SSH
> session spawned from local Emacs already running. It ends up talking
> to your login shell over ssh basically. […] There needs to be some
> kind of "hop" or additional step after TRAMP establishes an ssh
> connection that puts its shell in appropriate environment. Is there a
> way to do that?

I played around with Guix and Tramp a little over the last days.  Canʼt
say that I am not still confused, and canʼt really explain much of the
working of the following snippet, but maybe it can still serve you as a
base for your customisations – at least until someone comes up with a
proper solution.

  #+begin_src emacs-lisp
    (connection-local-set-profile-variables 'guix-shell-own-path-profile
      '((tramp-remote-path . (tramp-own-remote-path))))
  
    (connection-local-set-profiles
     '(:application tramp :protocol "guix-shell")
     'guix-shell-own-path-profile)
  
    (require 'tramp)
    (add-to-list 'tramp-methods
                 `("guix-shell"
                   (tramp-login-program "guix")
                   (tramp-login-args (("shell")
                                      ("-m")
                                      ("projects/%u/manifest.scm")))
                   (tramp-remote-shell "/bin/sh")
                   (tramp-remote-shell-args ("-c"))
                   (tramp-remote-shell-login (""))
                   ))
  #+end_src
  
With this evaluated, you can change to a Guix shell environment on a
remote host using:

    /ssh:me@remotehost|guix-shell:myproj@remotehost:/path/

As you can see this uses the user part of a tramp file name to select
the environment.  I first tried to use the host part, but it seems that
this part has to be the same on each hop (I received an error about
non-matching host parts).  If you look at the ‘tramp-login-args’ defined
above, this uses a predefined directory “projects” under which are
stored the environments in sub-directories.  This is the part you need
to adjust if you rather need to use the “-D” and “-f” switches to “guix
shell”.  ‘tramp-remote-shell-login’ is set to the empty string so that
tramp does not call /bin/shell with the “-l” switch, which would remove
the environment variables set up by “guix shell”.  Without
‘tramp-remote-shell’ and ‘tramp-remote-shell-args’ I received an error
(I believe it stated something like: “(stringp nil)”.).  I do not know
why.  Setting of the connection local variable ‘tramp-remote-path’ is
needed to instructed tramp to not override the PATH environment variable
with paths from ‘tramp-remote-path’ that tramp can determine to be
existing.

As I have indicated, I mostly fiddled with the values until something
seemed to work; it might no actually work correctly or be correct.  So:
no warranty ;).  It is also not general at all.

-- 
Felix Dietrich