Package Details: emacs-lucid 29.3-1

Git Clone URL: (read-only, click to copy)
Package Base: emacs-lucid
Description: The extensible, customizable, self-documenting real-time display editor (Lucid toolkit version)
Upstream URL:
Licenses: GPL3
Conflicts: emacs
Provides: emacs
Submitter: favadi
Maintainer: snackattack
Last Packager: snackattack
Votes: 25
Popularity: 0.53
First Submitted: 2012-07-23 16:07 (UTC)
Last Updated: 2024-03-24 21:59 (UTC)

Required by (319)

Sources (2)

Latest Comments

1 2 3 4 5 6 Next › Last »

Aftermath commented on 2024-03-24 18:18 (UTC)

NOTE: I'm writing this because I'm sure there exist other users in Arch having the same questions about Emacs-lucid, unanswered, and some of them would not even dare to ask them here or somewhere else in the Arch Linux environment.

@snackattack Wow, wow, wow! That was a long but very enlightening thread! That also led me to read some other threads. I'm an Emacs newcomer.

So, according to the Emacs developers, Lucid build of Emacs is pretty stable. It's much more stable than Emacs-gtk and Emacs-pgtk. There are many long living bugs that still exist in those two to this day (the daemon/server issue is just one of them.), but never existed in Lucid or got fixed years before now.

It's also clear that it's not going to be dropped from upstream any time before GTK or PGTK being dropped.1

The only caveat is that Lucid's scroll, menu, and tool bars are old looking and certainly not matching any DE's style/theme. That can be a showstopper for some newcomers, which was the only reason they didn't make it the default build of Emacs. BUT, wait a second! Aren't those the ones that a user searches about how to disable them right after Emacs installation?

However, compared to PGTK, Lucid works only under X.Org or Xwayland.

snackattack commented on 2024-03-22 17:48 (UTC)

As far as I know the daemon/server issue is the primary reason to prefer lucid, and is the reason I use it personally.

However, you may also find this long discussion from 1.5 years ago relevant:

Aftermath commented on 2024-03-22 04:08 (UTC)

Thanks for maintaining this package.

I didn't expect it to build at first, but the PKGBUILD is well-maid!

I have a question that I couldn't find any answer for it on the internet. (All answers were too old)

And that is, despite the daemon/server issue. What is the difference of Emacs with lucid toolkit and the regular Emacs provided without lucid?

Sorry for the noise and thank you in advance.

snackattack commented on 2023-09-24 23:46 (UTC) (edited on 2023-09-24 23:47 (UTC) by snackattack)

For nativecomp, I've decided to fork this into a separate package:

snackattack commented on 2023-09-08 00:40 (UTC) (edited on 2023-09-08 00:42 (UTC) by snackattack)

I don't think there is strong consensus about --with-native-compilation yet. Some users report much better performance with it, but others report little performance difference (especially after emacs optimizations in recent years) and annoyances (excessive warnings, recompilations) [1].

Among the official emacs packages, emacs and emacs-nox don't enable native compilation, while emacs-wayland and emacs-nativecomp do. The unofficial emacs-git does enable it but provides a variable in the PKGBUILD to disable it.

If the official emacs package plans to enable nativecomp, then certainly I'll enable it here too. Otherwise, I'm undecided -- I am open to Doom's POV that it should be enabled, but have to think about it more.

I'm curious whether other distros generally enable nativecomp -- in particular Fedora, Debian, NixOS, and Tumbleweed.


carlosal1015 commented on 2023-09-06 13:51 (UTC)

Hi, I have a question, after install emacs-lucid and use doom emacs framework, I look this message:

> Checking for great Emacs features...
! Emacs was not built with native compilation support
  Users will see a substantial performance gain by building Emacs with
  native compilation support, availible in emacs 28+.You must install a
  prebuilt Emacs binary with this included, or compile Emacs with the
  --with-native-compilation option.

Is it beneficial for this flag to include PKGBUILD?

snackattack commented on 2023-08-14 17:22 (UTC)

I've updated this to emacs29 now.

Note: On my initial commit I forgot to reset the pkgrel, so the version was 29.1-7 instead of 29.1-1. I fixed it in ~2 minutes, but anyone who updated within that 2 minute window may need to take manual action to get the correct version.

snackattack commented on 2023-05-03 05:32 (UTC)

I think that is better specified on the user end by setting the MAKEFLAGS environment variable. Like this:

MAKEFLAGS='-j8' makepkg -si

Should also work with yay, aurutils, etc.

BossCode45 commented on 2023-05-03 05:03 (UTC)

Could you add -j$(nproc) to the make args? (that just tells make to use all your threads instead of just one)

snackattack commented on 2023-05-03 04:59 (UTC) (edited on 2023-05-03 05:00 (UTC) by snackattack)

I've adopted this, and updated to emacs-28.2.

I also disabled nativecomp, because the default emacs package doesn't have it -- there's a separate emacs-nativecomp for that. I was considering to provide emacs-lucid-nativecomp as a split package of this, like how emacs/emacs-nativecomp are built together in extra, but the downside is that it would double the build time of the PKGBUILD. So I decided against a split package -- I think it would be better to have a standalone emacs-lucid-nativecomp package for those who want it.