Hacker News Reader

Comment by andylynch | Hacker News Reader

I’m curious about whether the writer considered using emacsclient - it’s well suited for this application but I don’t see mention of it.

View on HN

That's definitely the way. When I used to use Emacs, it was always running, and my $EDITOR was set to emacsclient. I had two monitors, one fully dedicated to Emacs, the other to the rest.

Yep, likewise. I'm using emacsclient as $EDITOR too and it works well.

I find it helpful also not just because of the startup speed, but because I usually have one or more org buffers open taking notes on what I'm doing.

> I find it helpful also not just because of the startup speed, but because I usually have one or more org buffers open taking notes on what I'm doing.

As someone who lives in org, this is the way. I'm still shell bound for a lot of things, but M-x shell is far superior, there's just no contest. Only thing that is annoying is stupid things like git diff that think they know better than you and want to do their own paging resulting in "WARNING: terminal is not fully functional". Thankfully I use EGG, but when I forget (and other things do it too), it's annoying.

Yeah, it's a seamless experience to run a program in shell-mode that invokes $EDITOR and it just pops into a new buffer. Edit, hit C-x #, and you're back at the shell.

Wait, I'm confused, because you might have found a solution to something that's bothered me for a long time. I use emacsclient -t as $EDITOR and editor is invoked at a normal emulator, it opens a new buffer in the terminal. Great. But if I'm using vterm inside emacs anything that invokes editor then tries to open a buffer inside vterm and I'm now in a weird recursive state that locks up. Having some lisp that checks if I'm in vterm when editor is invoked and instead opens it in my current client session would be great. I searched for this at some point but gave up.

Have you considered overriding the Emacs process EDITOR variable via setenv? i.e.:

    (setenv "EDITOR" "/usr/bin/emacsclient -c")

If you do that, it should cause any child processes (e.g.: vterm) to inherit the replaced EDITOR variable and properly open new editor frames instead of trying to do a terminal takeover.

Well,this is extremely clever and simple. I tried that out from vterm in 29.1 and it crashed emacs...

Personally, I got tired of weird quirks like this with vterm and now bind this command to the key I used to have vterm on to spawn my actual terminal (st) in my current directory. It's probably not what most people want from vterm, but I prefer it.

  (defun open-term-here ()
    "open st in `default-directory`"
    (interactive)
    (call-process-shell-command
     (concat "st bash -c \"cd "
      default-directory
      " && exec zsh\"")
     nil 0))

I also do this, C-x t to open a tmux tab to whatever directory the current buffer is:

  (defun tmux-here ()
    (interactive)
    (if (not (eq (getenv "TMUX") ""))
        (shell-command (format "tmux new-window -c %s" default-directory))
      (error "Not inside a tmux session.")))

I know, I know, tmux is slow and should never be used. I like it, OK.

I like to use `emacsclient -t` as my $EDITOR (actually I have this in a small wrapper script in ~/bin/editor) so it runs a terminal-based frame rather than opening a new GUI frame. Also, setting alternate editor helps which will just run emacs if an emacs server isn't already running.

I run emacs as a daemon, but it doesn't have to be. You can also run `(server-mode)` from any emacs process. A nice snippet for the init.el is: `(or (server-running-p) (server-mode))` which works whether you run the daemon or not.

`(require 'server) (or (server-running-p) (server-mode))` :)

What's the difference between daemon and server-mode?

IIRC, daemon mode is a headless instance of the Emacs that the clients can connect to. Server-mode is just a standard, headful, user-session instance of Emacs that can also accept clients.

Daemon runs without a UI at all and can only be used with emacsclient. server-mode is used with a normal/non-daemon instance so emacsclients can connect to it. Combined with the --alternative option you can then run emacsclient without really thinking about it. The first one will start a full emacs instance and enable the server, subsequent ones will just connect to that server.

I used emacsclient for many years but these days, TBH emacs with the right knobs twiddled starts up at usually an entirely reasonable speed.

But definitely out of the box with a stock emacs install it seems too interested in doing a bunch of stuff that gets in the way.

My EDITOR has been just regular "emacs" for years now.

Speed is not the only thing `emacsclient` addresses. When your $EDITOR is `emacsclient`, the newly spawned frame will share state (kill ring, buffer list etc.) with your Emacs server. This might be helpful e.g. when you (like me) are a heavy user of `dabbrev-expand`, and also with numerous other little things.

My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw. Specifically I started using non-daemon Emacs processes alongside my main Emacs daemon to compartmentalize my work. Each non-trivial project, or "workspace", gets its own Emacs process, possibly with a persistent state with desktop-save & desktop-change-dir. The newish tab-bar-mode helps with that a lot as I cannot stand using multiple frames on a non-daemon Emacs due to it not always being obvious when I close just a frame and when I close the whole process.

Yeah I personally prefer to have the separation of buffer sets between tasks. Especially for something as transient as "write a git commit message" or do an interactive rebase, or write a quick note.

A personal preference is a personal preference, ofc, but what exactly are the actual benefits?

While project.el or projectile.el are good sometimes you don't want to see anything else except your current project. A new instance is an easy way to achieve that.

> My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw.

That is a fair point, though not really fitting my workflow. (Also, my Emacs needs ~20 seconds to start, and I tend to have Emacs uptime of several days or sometimes even weeks.)

> I cannot stand using multiple frames on a non-daemon Emacs due to it not always being obvious when I close just a frame and when I close the whole process.

This is strange. In my Emacs, C-x 5 0 on the last frame results in "Attempt to delete the sole visible or iconified frame". (And I have `(setq confirm-kill-emacs #'yes-or-no-p)` in my init.el anyway.)

Yes, C-x 5 0 is safe, but I often use my window manager's keybinding for closing a window instead. Customizing confirm-kill-emacs sounds like a great idea, I'll consider it, thanks!

I think your opinion as built is reasonable, but wouldn’t a better mechanism be an internal segregation concept?

Emacs supports a "projects" concept: https://www.gnu.org/software/emacs/manual/html_node/emacs/Pr...

This is useful for segregating groups of work related to a set of files but I would be interested if there's anything for arbitrary unsaved buffers in general.

Depends on what you mean by entirely reasonable.

I’m by no means a package maniac, and I lazyload with use-package almost entirely, but a cold start still takes a second or two. To me, a choice between a second or two and instantly is a no brainer.

emacsclient is addressed in another post: https://magnus.therning.org/2023-10-01-how-i-use-emacs.html

Of course it is their right, however I don’t understand their argument in this text. They can start Emacs in daemon mode and issue emacsclient -c to have their main graphical session. I not sure I see the added complexity.. if they need multiple different setups that’s also fine. I wonder if perhaps the perceived complexity comes because the author has not experienced the simplicity of Emacs working in combined terminal/shell/graphical modes through the invocation of emacsclient. There is almost no drawback in being able to share buffers if ever needed, and then they are not needed they are out of the way.

yeah, this is what i use, along with a specific instance of the emacs server session to avoid cluttering up my actual editor. i think the invocation is something like `emacsclient -A “cli” -nw `

Oh that's a great idea, this is the way. I don't use emacsclient because it has weird interaction with Doom's workspaces, but your way might solve this problem. Thanks!

Does it not just start a new Doom workspace for the new frame? I’m curious because I use Doom workspaces a lot and might consider setting EDITOR=emacsclient

ok, here's my actual invocation per my .zshrc:

`alias ec="emacsclient -s console -a '' -nw -r"`

It doesn't start a new doom workspace /most/ of the time. Sometimes i'll get a new one if i've got multiple editors opening up the same file, I think. But the `-s` flag starts a console server that at least keeps those out of my main emacs window (I use the gui version from emacs-plus)

It only creates a new workspace if you're connecting to your main Emacs' server. If you have a separate daemon launched with `emacs --fg-daemon=cli`, then connecting with `emacsclient --socket-name=cli` won't pollute your main Emacs with a new workspace:)

Reply on news.ycombinator.com