Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Emacs, everything looks like a service

yummymelon.com

Post reply on HN
Print view View original

81–90 of 127 posts

Re: In Emacs, everything looks like a service

#81

Post by BeetleB »

kleiba2 wrote: 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.

Not really. If they mandated all team members use telnet instead of ssh, would you say their position is valid?

Anyway, the important thing to learn is "You're not supposed to ask if you can use Emacs. Just use it!"

Incidentally, do they have a mandated general text editor? And if they do, will you get in trouble for firing up Notepad?

Do they have a mandated TODO tool (for your own tracking of work, not something like Jira meant for the whole group)? I've yet encountered a place that did.

Basically, find some category that Emacs does that they've not mandated, and then install Emacs and tell people you're using it for that category :-)

Re: In Emacs, everything looks like a service

#82

Post by kickingvegas »

SoftTalker wrote: post #58

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 socket, but the client still only sends simple control commands.

Re: In Emacs, everything looks like a service

#83

Post by regexorcist »

archargelod wrote: post #18
driva wrote: post #11

It's a shell not an operating system but the concept of a shell isn't commonly understood.

I see shell as an instrument through which you use other tools. In that sense, vi feels much more like a shell, because you have to use other standard unix programs with `:.!` for much functionality. Where Emacs comes with all bells and whistles included in one big distribution, much like an operating system.

Most people aren't using vim that way. For your example, tmux would be more like emacs in the sense that you live in it, manages your windows, etc. Vim is just another tool in some window along with others.

Re: In Emacs, everything looks like a service

#84

Post by TylerE »

isityettime wrote: post #79
kleiba2 wrote: 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…

What about the job is so good as to make you tolerate this?

Taken a look at the job market lately? Unless you’re like the top 1% (which most people aren’t), it’s extremely bleak.

Re: In Emacs, everything looks like a service

#85

Post by BeetleB »

tom_alexander wrote: post #35
wtetzner wrote: post #33

Earlier quoted context omitted.

> 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?

In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do. For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more…

I can somewhat sympathize - I guess the debatable aspect is to what extent should you teach?

If someone knows no development tools, then yes, it is good if someone in the team knows Visual Studio Code and can guide them. In my previous job, another senior person knew it and helped out (VSCode was not mandated, and they were free to use some other tool).

I tend to focus on training people on the concepts (code navigation, debugging, version control, etc), and tell them that they're free to use whatever tool they like, but it's on them to learn how to use those tools to apply those concepts. I usually recommend VSCode and tell them there are plenty of videos/sites that explain them.

Then if I see them doing something very inefficiently, I do a quick Google search to see if the more efficient approach is supported in their tool and send them a link.

It's important to hire people who can learn on their own (with guidance on what to learn).

> For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".

Inspired by a submission some years ago on HN, I came up with a different approach in my last job.

Everything the team did (including onboarding), had to be done via a just[1] recipe. No longer did we rely on outdated docs. just recipes, by definition, cannot be outdated because then we wouldn't be able to do our work.

For onboarding, we had recipes that automated as much of the configuration as possible. For things that required manual work, the recipe would print instructions, and prompt the user to press Enter when they had completed the task.

Sure, onboarding stuff can go stale as people don't onboard often, but we had a policy that if any senior team member had to help a newbie because the recipe was broken, then the senior member needed to fix the recipe and check it in.

I left the job, but I still talk to some of the folks there. They still love the recipes.

[1] https://github.com/casey/just

Re: In Emacs, everything looks like a service

#86

Post by BeetleB »

kleiba2 wrote: post #37
jerf wrote: post #28

Earlier quoted context omitted.

... how would they tell?

By looking at my screen? But also, why would you disobey a direct instruction from you super?

> But also, why would you disobey a direct instruction from you super?

Because they disobey their superior (and if they don't, recurse).

But yeah, if I were new to the job, I would wait until I'm fairly competent before playing those games.

Re: In Emacs, everything looks like a service

#87

Post by mvc »

bcjdjsndon wrote: post #13
kandros wrote: post #5

One of the pivotal moments in my career has been when I used Emacs just enough to truly understand what "Emacs is an operating system" means, not just as a joke but as something I could believe in

But you already had an operating system and you could already code... Did Emacs really give YOU any capability you didn't have before? Don't forget this is a text editor, not an IDE or some general purpose automation harness You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic

> You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic

Yes exactly! https://docs.gimp.org/3.2/en/gimp-using-script-fu-tutorial.h...

Re: In Emacs, everything looks like a service

#88

Post by tikhonj »

tom_alexander wrote: post #35
wtetzner wrote: post #33

Earlier quoted context omitted.

> 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?

In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do. For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more…

When I've been in that position, I've just trusted junior folks to figure out the tooling-specific way to do things like that, and it's worked out perfectly well. If anything, it leaves people happier and learning more.

And, instead, I can focus on the fuzzier, higher-level things that involve non-trivial tacit knowledge rather than things somebody can resolve with a Google search (or just ask Claude).

Re: In Emacs, everything looks like a service

#89

Post by tikhonj »

bcjdjsndon wrote: post #13
kandros wrote: post #5

One of the pivotal moments in my career has been when I used Emacs just enough to truly understand what "Emacs is an operating system" means, not just as a joke but as something I could believe in

But you already had an operating system and you could already code... Did Emacs really give YOU any capability you didn't have before? Don't forget this is a text editor, not an IDE or some general purpose automation harness You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic

Emacs is, in fact, an IDE and some general purpose automation harness. And some other stuff.

That's the point.

Re: In Emacs, everything looks like a service

#90

Post by shakow »

kleiba2 wrote: post #41
shakow wrote: post #39

Earlier quoted context omitted.

At some point, shouldn't installing a venv be a pre-requisite to actually be hired as a dev?

That was just an example. The point of the parent is that in an ideal situation, where everything works without flaw, theoretically it makes no difference which tools everyone uses. In real life, you having a homogeneous setup across a team makes the sysadmin's job a lot easier.

But sysadmins should be there to deploy stuff and make sure the infra does its job, not get bogged down handholding some dev that can't even compile a project.
Post reply on HN