Comment by manish_gill | Hacker News Reader

Comment by manish_gill | Hacker News Reader

Parent Full thread

Emacs is the one environment that I've been a fan of from afar. I recognize the brilliance and power of it, but a few things have always kept me away from using it on the Mac. And I've put in serious attempts, including going emacs-only, then a custom evil mode, then spacemacs -

- The server mode compatibility with the way Mac applications are set up. I'd ideally want an emacs server running in the background, and a client app open/close seamlessly whenever I'd like. What actually ends up happening is that I close the client windows but the app never "quits". So it's a zombie icon always hanging around my cmd+tab list.

- "Windows" (or Frames?) have generally not worked seamlessly for me. I've to always put in hacks in my config to ensure the emacs windows work like other apps do for mac. They're either too small and then size up when config is applied (which has some latency so it's noticeable when it happens), or they don't work at all.

- Font rendering. There is some minute rendering difference in the way the same fonts that renders on Vim/iTerm/Macvim/Sublime/VSCode/IntelliJ, but it's the worse by far on my emacs. :(

- All of these complaints are for the GUI mode tbh, which I prefer to use since I like to keep my terminal separate from my editor. Terminal-only emacs is something I tried a few years ago and I remember getting annoyed by keybinding issues etc.

Maybe all of the above are old issues that are no longer present, or maybe I was doing things the wrong way. It just never felt like it was a seamlessly integrated application on the Mac. I hope that has changed or will change. :)

> - Font rendering.

Worth double-checking, but I think that's one area Mituharu's is better than standard Emacs. I definitely recall some font rendering issues with some past version.

As for your other points, they aren't resolved. FWIW, I work around them:

> The server mode compatibility

I just have one long-running Emacs session. I have some colleagues who have experimented with using a launchd LaunchAgent to start emacs server in the background when they login. I haven't kept up with their results and I don't know if there are any side-effects.

> "Windows" (or Frames?) have generally not worked seamlessly for me

Since I have a long-running session, this isn't much of a problem for me. That said, when I do start up Emacs on first login, it indeed takes upwards of 5 seconds to startup, including a window re-themeing and resizing. It's not great, but like I said, it's only once at startup for me. Furthermore, because I came from a tiling window manager on Linux (AwesomeWM), I required similar behavior on macOS. I use SizeUp [1] with shortcuts configured to move my windows to side/corners of the screen. It's far from being as good as a true tiling window manager, but I've had to be satisfied with what I can get.

[1] https://www.irradiatedsoftware.com/sizeup/ (there are alternatives like Moom)

If you haven't seen it before, you might be interested in something like chunkwm[1], a tiling window manager for MacOS. I've been using it for a couple of years now and its been fantastic and works almost exactly like a linux-based tiling wm.

[1] https://github.com/koekeishiya/chunkwm

Thanks! I've eyed chunkwm, but was put off by its externalized keyboard-shortcut system. skhd scares me a bit, and I figure that since chunkwm is macOS only, it should be handling its shortcuts itself rather than abstract it out.

Totally fair objection, but I believe the author made that decision primarily because skhd can do arbitrary keybindings. I have skhd set up to open up iTerm by pressing cmd-RET for example.

Issue #1 was annoying for me, so I hacked together the following solution: write an emacs function that detects situations where you feel emacs should quit (e.g., no windows left) and have it kill itself and the server when this happens. Then, write a launch agent to poll if the server is running and start it if not (pgrep is cheap enough that you can do this every few seconds). Finally, write an Automator app that will be your launch point for emacs, which receives files and opens them using the server.

It’s an annoying fix but when done right it feels exactly like emacs is a native app.

If you could package it up nicely, maybe one of the Emacs distributions would consider upstreaming your solution. I doubt that the pure-GNU Emacs maintainers would be too happy about it considering RMS’s choice to remove Mac- and Windows- specific API usages since they gave the nonfree OSs an “advantage”.

I have written a "pseudo-daemon" mode for Mac that solves the server mode issue[1]. All it does is create a new frame and hide the application when you close the last frame, so next time you activate Emacs, the frame is un-hidden and it looks like it was just created. It works surprisingly well at emulating a daemon for such a simple hack.

[1]: https://github.com/DarwinAwardWinner/mac-pseudo-daemon

I use aquaemacs on Mac.

http://aquamacs.org

It’s a very impure emacs but I like it as it interstates in macOS well. (Drag file into icon and it opens. The cut/paste from Mac works well).

A lot of my emacs use is ssh into remote server based so I use that most of the time.

Straight emacs handles drag events and integrates well with the system clipboard, FYI.

Oh yeah, the server mode thing makes me a little crazy. Whenever I want to reboot my Mac, I have to force-quit Emacs.

Reply on news.ycombinator.com