6 ms·

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.

uxp8u61q 3y ago
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.
- ataylor284_ 3y ago
  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.
  - earthscienceman 3y ago
    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.
    - chaorace 3y ago
      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.
      - earthscienceman 3y ago
        Well,this is extremely clever and simple. I tried that out from vterm in 29.1 and it crashed emacs...
        Brentward 3y ago
        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))
        jrockway 3y ago
        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.
- wiktor-k 3y ago
  Yep, likewise. I'm using emacsclient as $EDITOR too and it works well.
  - User23 3y ago
    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.
    - npsimons 3y ago
      > 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.
cmrdporcupine 3y ago
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.
- oefrha 3y ago
  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.
- mbork_pl 3y ago
  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.
  - vifon 3y ago
    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.
    - cmrdporcupine 3y ago
      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.
globular-toast 3y ago
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.
- gray_-_wolf 3y ago
  `(require 'server) (or (server-running-p) (server-mode))` :)
- Scarbutt 3y ago
  What's the difference between daemon and server-mode?
  - a_e_k 3y ago
    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.
  - globular-toast 3y ago
    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.
gglitch 3y ago
emacsclient is addressed in another post: https://magnus.therning.org/2023-10-01-how-i-use-emacs.html https://magnus.therning.org/2023-10-01-how-i-use-emacs.html
- pama 3y ago
  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.
karmajunkie 3y ago
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 `
- bruh2 3y ago
  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!
  - senkora 3y ago
    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
    - karmajunkie 3y ago
      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)
    - bruh2 3y ago
      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:)

uxp8u61q 3y ago

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.

ataylor284_ 3y ago
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.
- earthscienceman 3y ago
  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.
  - chaorace 3y ago
    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.
    - earthscienceman 3y ago
      Well,this is extremely clever and simple. I tried that out from vterm in 29.1 and it crashed emacs...
      - Brentward 3y ago
        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))
        jrockway 3y ago
        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.
wiktor-k 3y ago
Yep, likewise. I'm using emacsclient as $EDITOR too and it works well.
- User23 3y ago
  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.
  - npsimons 3y ago
    > 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.

cmrdporcupine 3y ago

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.

oefrha 3y ago
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.
mbork_pl 3y ago
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.
- vifon 3y ago
  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.
  - cmrdporcupine 3y ago
    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.

globular-toast 3y ago

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.

gray_-_wolf 3y ago
`(require 'server) (or (server-running-p) (server-mode))` :)
Scarbutt 3y ago
What's the difference between daemon and server-mode?
- a_e_k 3y ago
  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.
- globular-toast 3y ago
  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.

gglitch 3y ago

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

pama 3y ago
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.

karmajunkie 3y ago

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 `

bruh2 3y ago
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!
- senkora 3y ago
  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
  - karmajunkie 3y ago
    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)
  - bruh2 3y ago
    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:)