Comment by danShumway | Hacker News Reader

Comment by danShumway | Hacker News Reader

Parent Full thread

Do the defaults in Emacs matter, at all? Doom Emacs, Spacemacs, and dozens of other default configs already exist. I've been using Emacs for years, I never learned the default keybindings. I used Evil mode right from the start.

I just don't see this as a real problem.

A small (incomplete) list of real problems:

- No timeline on Wayland support, Wayland will likely require substantial work and refactoring.

- Performance issues on long lines of text.

- Architectural/technical debt.

- etc...

Emacs is, fundamentally, a power-user editor. There are problems to solve, but "I had to change the default fonts" isn't one of them. Why would you use Emacs in the first place if you weren't interested in changing the default fonts? Maybe I'm out of touch, but I would never recommend a new Emacs user to just download Emacs directly. I assume they're starting with someone else's config.

Emacs fills a specific niche that other text editors today still aren't satisfying, and it should continue to fill that niche. What other text editor can I use as a window manager?

I haven't checked in a while, but I think Spacemacs solves literally every single problem that they're talking about, including prompting users whether they'd like to enable CUA mode by default. But Spacemacs can't solve the Wayland problem.

Don't forget syntax highlighting shortcomings. Sublime, VS Code, Syntect, Pygments, and other highlighting engines all get most languages right. Emacs and vim both do weak and incomplete jobs identifying tokens. It makes nice color schemes look bland because they skew toward only a few colors. At least neovim is working on treesitting which should improve this ability.

Right, I've noticed this while trying to update my vimrc for web development. Syntax highlighting is just not as nice as in vscode.

Wayland support is actually being actively worked on. It is done via "native" (no X widgets) GTK support. You can find it on: https://github.com/masm11/emacs

The plan is to get that merged upstream at some point, you can find out more about it on the official mailing lists.

The GTK fork is great, but it’s so slow - especially on HiDPI displays.

I tried it out on my 4K monitor and I felt a noticeable increase in typing latency. It started to feel a lot more like VS Code.

Ultimately I was about to get HiDPI support working in Xwayland in Sway with a series of patches and I ran Lucid Emacs, which was much faster and made the latency increase go away entirely.

Oh thank you for the link, I've had to discard emacs when I've switched to sway/wayland and I can't wait finally having emacs available for my muscle memory. Magit changed my life

That was touched on in the article:

> Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen. Emacs maintainer Eli Zaretskii complained that the creators of these distributions do not contribute their work back.

If the changes aren't being contributed back, any gain from them is lost for users of the default system. Creating an unnecessary fork within the user base, especially where the changes could be enabled via a configuration change (start with default, but prompt at first run to go to Doom Emacs or Spacemacs).

> Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen.

Spacemacs isn't an Emacs fork, it's a set of packages and configuration files that are provided transparently on top of an existing Emacs install.

It's not necessary (or desirable) to include Evil mode out of the box for bare-bones Emacs installs, and for the most part, new users shouldn't be using bare-bones Emacs installs. It's not important that Emacs be an amazing experience with fantastic defaults out-of-the-box.

This is like arguing that Linux is outdated because Gnome isn't built into the kernel. New users download a distro based on Linux, like Ubuntu. That's fine, it's not a problem that needs to be solved.

In the same way, new Emacs users download "distros" that include secondary packages like Evil mode. That is also fine, it's not a problem that needs to be solved.

> Emacs maintainer Eli Zaretskii complained that the creators of these distributions do not contribute their work back.

Even assuming that we would want to merge Spacemacs changes into the core Emacs codebase (which we don't), I still have zero sympathy on this point.

All of these downstream projects are Open Source -- they are contributing their work back. If the FSF refuses to merge compatible, Open Source code back into the Emacs codebase without developers signing away their ownership, that's the FSF's problem, not the downstream developer's.

I thought the whole point of Open Source licensing was that people didn't need to own the code to use it. Being a good Open Source community member is not conditional on anybody giving ownership of their code to the FSF, it is conditional on releasing that code under Open, compatible licenses.

The article also touched on why this is the case: Not everyone wants to assign copyright to the FSF.

I'm not convinced there's a lot from Doom/Spacemacs that could reasonably be contributed back to Emacs. It's mostly installing and configuring other packages to have a nice default setup.

Perhaps the startup speed tweaks provided by Doom, could be enabled by default. I have seen the concept of modules implemented in a few different distributions, as well as in some users configuration. Perhaps a built-in module system would be beneficial. Doom has a deterministic package management system.

Reply on news.ycombinator.com