Hacker News Reader

Comment by sokoloff | Hacker News Reader

I took the opposite extreme approach (and I think this is fairly common):

Launch emacs once ever and use emacsclient for the typical short-duration invoke/shutdown use cases.

Likewise. I start emacs --daemon from systemd, and have aliases for using emacsclient to open emacs in a new frame, in the current terminal, or in a new screen window.

If you have any details, links, hints about how to accomplish this (for instance, where does one find a proper "emacsclient.service" file?) please consider yourself emboldened

Starting from systemd is a league beyond what I've done. But you might like this script:

    #!/bin/sh
    emacsclient -t $@ || (emacs --daemon && emacsclient -t $@)

You'll want something like

    (unless (server-running-p)
      (server-start))

in your init file.

Or use

    emacsclient -t --alternative-editor=""

and emacsclient will start the daemon if it hasn't already been started. You can also set the ALTERNATIVE_EDITOR environment variable to "" to achieve the same effect.

After some investigation I found that the option and the env var are called "alternate editor" and not "alternative editor".

Sorry, brainfart!

I don't have a systemd example, but here's a GNU dmd service that I use which shows how to properly start/stop the daemon:

https://git.dthompson.us/dotfiles.git/blob/HEAD:/dotfiles/.d...

I had a slightly different approach in that I made a script to launch Emacs server on-demand: https://github.com/qiushihe/dotpiles/blob/master/emacs/emacs...

I use the system service (emacs@.service) from [this blog post][0]. I used 'systemctl enable emacs@myusername.service' so that emacs is always started on boot.

I have a one-liner shell script called 'em' that just runs 'emacsclient -t $*' so that it can be set as $VISUAL and used by whatever command line tools use that.

[0]: http://blog.refu.co/?p=1296

Me too. Well, once per reboot. Even under very good circumstances, Emacs' startup time is worse than mg or vi. And having it run in the background, keeping its state, open buffers, shell history, etc. is very convenient.

Since I moved to spacemacs, I've been doing this.

However, I am bummed by emacsclient's inability to open multiple files from the command line.

And apparently the total lack of a Tab-like experience on Emacs in general. I used to use "vim -p" SO MUCH.

what's wrong with http://www.emacswiki.org/emacs/TabBarMode ?

Tab bar mode conflicts with a bunch of other modes. So a lot of times you will switch to a buffer and and the tabs will disappear. It also doesn't support 'most recent' tab ordering.

Seems like that only really works for GUI emacs. I use command line. I tried enabling it and it doesn't seem to, y'know, work.

I've also tried evil-tabs, which doesn't work with spacemacs, at all. And eyebrowse doesn't actually use tabs (also it doesn't maintain working directory state when opening a new workspace, fun!)

I dunno, emacs is very much, "Here's a half-implemented solution that pays zero attention to ergonomics. Just... y'know, fix the rest of it so it doesn't totally suck."

And I just don't have the experience to do that yet. Which is why I'm using Spacemacs. Which more or less actually tries to do the ergonomics correctly.

edit: I'm also hoping Cunningham's Law works in my favor here.

In the spirit of Cunningham's Law, you can open multiple files using emacsclient. Just list them after emacsclient (e.g. 'emacsclient file1.txt file2.txt'). This will open each file in its own buffer (roughly the equivalent to tabs).

Since I'm not very familiar with vim tabs, I'm curious what you get using using vim tabs that you don't get out of emacs buffers?

The buffer list is shared across the entire emacs daemon. So if I have many files already open in different client sessions and start running buffer next commands, I'm cycling through a very long list.

Because you never ever start vim in a daemon mode, opening with -p creates a local list of files that you can cycle amongst. Additionally, the top line tells you which file you have open and which files are next and previous in the list of files you cycle through.

I've always just found it rather nice since I tend to jump around between the same handful of files while I'm working and hitting gt two or three times is often faster and more mindless than remembering the keystrokes to invoke helm-projectile-find-file and also the name of the file I want to switch to.

That makes sense. I actually never use daemon mode because I don't want to share buffers. If want a faster start up time but don't want to share buffers you may want to look at use-package[1] which will lazy load plugins. Also, if you want a easy way to cycle through buffers that also works in the terminal I recommend iflipb[2]. When you start cycling, it shows a list of buffers in the mini-buffer. Both of those are available as packages in Melpa.

[1] - https://github.com/jwiegley/use-package [2] - https://github.com/jrosdahl/iflipb

iflipb sounds like it more or less scratches the thing that makes me itchy even if it's not quite my old itch scratcher. Thanks!

> In the spirit of Cunningham's Law, you can open multiple files using emacsclient. Just list them after emacsclient (e.g. 'emacsclient file1.txt file2.txt'). This will open each file in its own buffer (roughly the equivalent to tabs).

emacs buffers are (almost exactly) equivalent to vim buffers. vim tabs don't really have an analogue in emacs, but imagine several layouts of (emacs) windows (each window showing a single buffer) you can switch between in a single frame.

That's actually how emacs frames work on the terminal. There's no built-in equivalent on GUI. You could use either multiple GUI frames and a tiling window manager, or there are several packages on melpa for switching between window configurations.

This. This emacsclient startup time is excellent. The complaint that each launched client shares the same buffers is hardly sufficient to justify the effort of lazy loading to achieve only mediocre performance.

Reply on news.ycombinator.com