Hacker News Reader

Comment by yakubin | Hacker News Reader

I’ve been using Emacs for 6 years now. But recently it became clear to me that it’s really optimised for Linux and doesn’t work as well on Mac and Windows[1]. On top of that I kept running into performance issues with large files.

It took me a while, but I’ve finally adjusted to Sublime and am quite satisfied for now. It’s snappy and doesn’t break as easily. The only issue I have is that, unlike Vim and Emacs, Sublime macros seem to record movement by characters, not text objects. So if I move cursor by words inside a macro and then replay it in another place, where words have different lengths, the macro won’t do what it should. For those cases I’ll still switch to Vim probably.

[1]: On Windows my config doesn’t work at all. I have no idea why. I didn’t have the energy to debug it.

View on HN

> I’ve been using Emacs for 6 years now. But recently it became clear to me that it’s really optimised for Linux and doesn’t work as well on Mac and Windows[1].

The Emacs devs definitely are biased in favor of free platforms, that’s true. However something like 30% of users are on MacOS and I’ve personally never noted any deficiency there. The native Windows builds definitely don’t run as well though. A big part of that is because NTFS is poorly suited to Emacs IO patterns.

I use the same config for all three, but I did have to disable certain parts when running on Windows. One that immediately comes to mind is the vterm package.

> The Emacs devs definitely are biased in favor of free platforms

This strikes me as shortsighted. Most of us don't have much control over the platform we use.

I, for example, was a very happy (even mildly evangelistic) emacs user up until my last job change. The new company issued me a Windows laptop. After a couple days of fussing with trying to get it to work acceptably well on either native Windows or WSL, I finally gave up and switched to vscode.

This probably spells the doom of my use of emacs for hobby work, too. Virtually all of my programming time happens at work these days, so my emacs proficiency is rapidly declining. Soon not even nostalgia will be able to overcome the inconvenience of using an editor that's becoming decreasingly familiar by the day.

I suppose I am only one person and I don't speak for everyone, but being able to spare at least a little more love for Windows users might have prevented at least this one developer from attriting out of the community.

>This strikes me as shortsighted. Most of us don't have much control over the platform we use.

Well, that's the thing.

This is NOT my POV, but I have definitely heard true-believer libre/Free software people opine that making it too easy to use Free software on nonFree platforms isn't desirable.

I think this is a silly perspective, but it's definitely one that's out there.

What I worry about there is that letting it become too inconvenient to use Free development tools on non-Free platforms will eventually harm the Free Software community's ability to produce competitive Free software, by encouraging a brain drain in the communities that develop Free development tools.

It's not an "eventually" thing. It's happening now, and has been happening for a long time.

I don't use much libre software in my day to day (desktop) life because most of it is only good enough if you feel strongly that libre is a value unto itself, and worth hassle. I mostly don't. I mean, in some places, there's definite parity or even advantages on the libre side, but holy crap on the desktop it's bleak.

> This strikes me as shortsighted.

More likely it simply reflects the platform they use.

Agreed. You'd have to pay me to improve software under Windows, because I do my best to never have to use it.

Biased is too weak a concept. It is a deliberate, principled choice of FSF/GNU/Emacs to advocate against Windows usage. They are, overall, in favor of some Windows support only in order to show Windows users the benefits and virtues of free software. The ultimate goal is that those users will move away from Windows, not that their Windows experience will be enriched. They knowingly favor these principles over greater success in the Windows world.

https://www.gnu.org/software/emacs/download.html#nonfree

Whether this is a realistic, good, or successful point of view, will clearly be debated endlessly, but Emacs' intentions should be understood clearly.

IMO, there is a gray area between "such a bad experience that many Windows users will not see its value" and "so good that it's just another piece of good Windows software". Finding a practical balance, if it's even possible, would be another area for debate. There are surely mailing list archives that cover this, but I think the project would always strictly prioritize "avoid enriching the Windows experience" over "show Windows users how good Emacs is."

AFAIK the balance they try to keep is that users of non-free OSs should not have a better experience than those of free OSs. That doesn't mean they will cripple the experience on non-free OSs, but they won't implement features not implementable, say, on linux nor specifically optimize for non-free OSs.

> On Windows my config doesn’t work at all. I have no idea why. I didn’t have the energy to debug it.

I'm a Linux person, but need Windows for work. I've used Emacs on Windows for over a decade now, and with the exception of magit, everything works just as fine as on my Linux machine. In fact, I have the same config for both, with only a few lines dealing with Linux vs Windows specifics.

So it may be worth debugging your config.

I use emax64, BTW: https://github.com/m-parashar/emax64

> doesn’t work as well on Mac

What specific issues do you face? I've been using Emacs both on Mac and Linux for >= 10 years and never really had any problem. Genuinely want to know what problems other Emacs users on Mac face?

One issue is there are competing forks for mac and it’s not clear which to chose.

In general, emacs locks up on me in OS X but not so in linux. I don’t have more info than that, but I find I have to restart emacs more than pycharm

Eli Zaretskii, one of the emacs lead maintainers, develops mostly on a windows platform, if I'm not mistaken. As such it may be worth a shot to report windows-specific issues to their bug tracker.

On Macs I use Aquamacs (http://aquamacs.org/), which seems quite nicely adapted to the macOS environment and I'm comfortable with it. Switching between macOS and Linux is easy for me, but if I have to use a Windows machine, I feel lost most of the time.

During my stint at MS, I used to use emacs on windows and it was ok. I do not remember whether the vanilla variant, the cygwin variant, msys2 or some other custom build, were the best though.

Yeah, I know some people do use it on Windows. But I already felt that I sunk lots of time into debugging my config on multiple occasions, so when on Windows basically nothing from my config worked I lost any will to debug it yet again.

Have you tried emacs-plus[1]? That's what I've been using for years now on macOS and never ran into issues. Opening big files is a different topic though I believe it doesn't work much better on Linux too.

[1] https://github.com/d12frosted/homebrew-emacs-plus

I've been using emacs on mac for decades.

check out: https://emacsformacosx.com/

That said, occasionally upgrading doesn't work as expected, and I stay with the previous version. I'm on 27.2 because something didn't work on 28.x and I haven't debugged it.

Performance is a killer for me also. I suspect once better tree parsing is implemented many of those issues will be solved. Then it’s just the lack of threading in the gui thread, and a few other nitpicks.

Given that Emacs worked for me alright on a 20MHz 386 30 years ago, I must ask, what in the world are you doing with Emacs that its performance turns out to be inadequate on current hardware?

Probably syntax and long line parsing. I also run in daemon mode.

I imagine emacs 28 wouldn’t run well on those specs with a default confit.

But also the biggest killer is probably the lack of code trees, forward/backward searches to do syntax highlighting etc is pretty expensive.

Reply on news.ycombinator.com