Live data from Hacker News

In Emacs, everything looks like a service

yummymelon.com

91–100 of 127 posts

Re: In Emacs, everything looks like a service

#91
post #24

This just proves that you can cram pretty much anything into the client/server dichotomy if you just define "client", "server" and "request" broad enough. Similarly, I remember how desperately people tried to argue that Emacs follows the "Unix philosophy" as long as your LISP functions are doing just one thing, and do them well. I don't know what you would gain from these things. Emacs follows the idea of LISP machin…

Emacs is a LISP refugee in Unixland. It doesn't follow the Unix philosophy, it follows the LISP philosophy. But it integrates.

Forgot where I found this.

Re: In Emacs, everything looks like a service

#92
post #27

I've been an Emacs user for over 25 years. But last year I switched employers and they won't let me use it even for tasks where it would absolutely shine. Their argument is that all team members should use the same tools, and I guess that is a valid point. Unfortunately, I failed to convince my employer to make everybody else switch to Emacs. So, now I'm using lots of one-purpose tools, one for each separate task, a…

> Their argument is that all team members should use the same tools, and I guess that is a valid point. Why is that a valid point?

It's just less effort all round to have everybody using the same supported set of tools. I don't know if I've ever worked on a project that's gone so far as to actually mandate this, but a "should" (possibly in the RFC sense) is fair enough I think. Every project I've worked on has ended up with everybody eventually settling on using the same tools, because it's just overall less hassle that way.

(Regarding Emacs, I'm typically using it anyway for org-mode, so if I need to do some one-off edit or other - probably some keyboard macro thing - then I can just load the problem file into Emacs and save it back out again afterwards. I've only once been in the situation of neither being allowed to install it nor remotely connect to another machine to use it.)

Re: In Emacs, everything looks like a service

#93
post #27

I've been an Emacs user for over 25 years. But last year I switched employers and they won't let me use it even for tasks where it would absolutely shine. Their argument is that all team members should use the same tools, and I guess that is a valid point. Unfortunately, I failed to convince my employer to make everybody else switch to Emacs. So, now I'm using lots of one-purpose tools, one for each separate task, a…

At a company I work for, they are doing various changes (and control) over the software we install as we transition to a larger company. I believe they are using Microsoft Intune so they can allow/deny what can be installed. I have not updated my laptop (or got a new one) because I am concerned they will not allow me to install or continue to use Emacs. Honestly, I can vision how that conversation goes:- [manager]: H…

Over the past 15 years, I worked for 4 different companies in 4 different industries and I never had any trouble getting Emacs approved.

They were all rather smallish, always around 200 employees, though.

Re: In Emacs, everything looks like a service

#94
post #61

Earlier quoted context omitted.

At a company I work for, they are doing various changes (and control) over the software we install as we transition to a larger company. I believe they are using Microsoft Intune so they can allow/deny what can be installed. I have not updated my laptop (or got a new one) because I am concerned they will not allow me to install or continue to use Emacs. Honestly, I can vision how that conversation goes:- [manager]: H…

Back in the day when i had a windows laptop for work you could just download the windows binary distribution of emacs and run that, has something changed?

Yes, running software that is not authorized can get you fired.

Re: In Emacs, everything looks like a service

#95

Emacs itself can run as a client and server. To start the server: emacs --daemon Then use `emacsclient` to connect to it. All `emacsclient` instances whether in terminals or GUI are using the same server and can access the same open files and buffers. Unfortunately it only works locally. I've tried to forward the emacs server socket over ssh to a remote client and it doesn't work.

Forwarding the socket doesn't work, but if you use X11 then you can use `ssh -X`, and the remote Emacs will open a frame on your local X server. Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.

`ssh -X` has awful performance for some reason. You can see each line render individually when invoking the Info manual on Emacs even while within LAN.

It's better if you enable TCP connections on your X11 server, setup a Wireguard VPN between your Emacs host and your X11 server host, and a firewall to only permit X11 connections over that. Throughput and latency then should be so good the remote Emacs window/frame will be indistinguishable from local ones (at least within LAN, haven't really tried over the internet).

> Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.

Guess I've used the good one. Haven't had this problem. What I do have is that if you open a frame in a host that you then put to sleep long enough for the X11 connection to timeout on the Emacs host, then `emacs --daemon` will crash. When I've used it, I've just made sure to save buffers often. systemd would start `emacs --daemon` again on its own.

`emacs --daemon` has no problem using multiple simultaneous X11 connections to different hosts, but it just doesn't handle the connections closing on their own. It also doesn't itself close X11 connections when all frames to an X11 server have been closed. So even if you close all of a machine's Emacs frames prior to putting it to sleep, it still causes `emacs --daemon` to crash.

Re: In Emacs, everything looks like a service

#96

Emacs itself can run as a client and server. To start the server: emacs --daemon Then use `emacsclient` to connect to it. All `emacsclient` instances whether in terminals or GUI are using the same server and can access the same open files and buffers. Unfortunately it only works locally. I've tried to forward the emacs server socket over ssh to a remote client and it doesn't work.

In retrospect, the name `emacsclient` was a poor one because in 2026 most folks new to Emacs expect it to act like a REST client, where runtime state is synchronized between the client and server over a network. Emacs' usage of ‘client’ and ‘server’ here refer to the usage of a Unix local domain (i.e. file system) socket for simple control commands from the socket client. This was later extended to support a network…

> Emacs' usage of ‘client’ and ‘server’ here refer to [...] simple control commands

Despite that, it still enables this:

> where runtime state is synchronized between the client and server over a network

On graphical X11 frames:

https://news.ycombinator.com/item?id=48864196

but it also enables having multiple TUI `emacsclient -c -nw` frames over SSH.

Re: In Emacs, everything looks like a service

#98
post #24

This just proves that you can cram pretty much anything into the client/server dichotomy if you just define "client", "server" and "request" broad enough. Similarly, I remember how desperately people tried to argue that Emacs follows the "Unix philosophy" as long as your LISP functions are doing just one thing, and do them well. I don't know what you would gain from these things. Emacs follows the idea of LISP machin…

Emacs is a LISP refugee in Unixland. It doesn't follow the Unix philosophy, it follows the LISP philosophy. But it integrates. Forgot where I found this.

Bash is a shell refugee in Unixland. It doesn't follow the Unix philosophy, it follows the Shell philosophy. But it integrates.

Why do you say such silly things?

Re: In Emacs, everything looks like a service

#99
post #17

Earlier quoted context omitted.

> Don't forget this is a text editor, not an IDE or some general purpose automation harness It's more correctly a Lisp execution environment with a text editor added as a bonus ;)

A lisp interpreter with text editing primitives.

And dynamic buffer local scoping.
Post reply on HN