Package Details: emacs-lucid 29.4-3

Git Clone URL: https://aur.archlinux.org/emacs-lucid.git (read-only, click to copy)
Package Base: emacs-lucid
Description: The extensible, customizable, self-documenting real-time display editor (Lucid toolkit version)
Upstream URL: http://www.gnu.org/software/emacs/emacs.html
Licenses: GPL3
Conflicts: emacs
Provides: emacs
Submitter: favadi
Maintainer: snackattack
Last Packager: snackattack
Votes: 25
Popularity: 0.002277
First Submitted: 2012-07-23 16:07 (UTC)
Last Updated: 2024-10-28 03:47 (UTC)

Required by (313)

Sources (2)

Latest Comments

1 2 3 4 5 6 Next › Last »

Aftermath commented on 2025-01-04 15:01 (UTC) (edited on 2025-01-04 15:02 (UTC) by Aftermath)

@snackattack By the time Emacs v31 is released with native compilation enabled by default, probably most maintained elisp packages are also fixed to produce less to no warning or error. Those warnings would be the main reason of someone not wanting native compilation by default.

So yes, emacs-lucid-nativecomp better to be retired or at least renamed to emacs-lucid-no-nativecomp (and disable default native compilation). Following the later case could be useful—perhaps until the next Emacs' bug fix release of V31 series—just to provide a grace period for ones who use packages slow on catching up with new changes, fixing their warnings and issues with native compilation.

snackattack commented on 2025-01-04 04:25 (UTC)

Thanks for the heads up. If native compilation is the default, it might be good to switch in the Arch spirit of sticking to defaults (and retire the emacs-lucid-nativecomp AUR package). Especially if official Arch emacs package switches, then we will definitely switch as well. Not sure yet what to do if default Arch emacs package sticks with no nativecomp though.

Aftermath commented on 2024-12-19 07:54 (UTC) (edited on 2024-12-19 07:56 (UTC) by Aftermath)

Hey fellow companions, as you may know, the second pretest of Emacs' next stable release — V31 — is out. It's been a while, actually, and I've been using it with no issues.

One consideration is that native compilation is enabled by default, from now on.

An emacs-pretest package is already available in AUR. It's build with GTK, however.

For Lucid build, you may apply the below reverse patch to the PKGBUILD of emacs-lucid AUR package — the package that this comment belongs to.

30c30
< pkgver=30.0.92
---
> pkgver=29.4
32c32
< pkgrel=1
---
> pkgrel=3
90,91c90
< validpgpkeys=('12BB9B400EE3F77282864D18272B5C54E015416A'  # Andrea Corallo <acorallo@gnu.org>
<               '17E90D521672C04631B1183EE78DAE0F3115E06B'  # Eli Zaretskii <eliz@gnu.org>
---
> validpgpkeys=('17E90D521672C04631B1183EE78DAE0F3115E06B'  # Eli Zaretskii <eliz@gnu.org>
93c92
< _source_url_prefix="ftp://alpha.gnu.org/gnu/emacs/pretest"
---
> _source_url_prefix="ftp://ftp.gnu.org/gnu/emacs"
96,97c95,96
< sha256sums=('d89287bd5a8381bb60e14aab95202377261d43a60d15dc0a61d0d662bc5626be'
<             'SKIP')
---
> b2sums=('825fd2665b6427dbc3cb618b40df2f71fa6b08883bdd07be6d8acf0039df2aeebd294e679e98f4c64a9dd9bdad93589fc7c176cf3860d4fb823fce23f7f2b3cd'
>         'SKIP')

Note, the putted sha256 digest replacing b2 one is what is provided by Emacs' devel mailing list. Please check it out.

Aftermath commented on 2024-08-31 23:36 (UTC)

@snackattack

Thanks for the explanations.

snackattack commented on 2024-08-31 18:46 (UTC) (edited on 2024-09-01 04:23 (UTC) by snackattack)

Thanks for reporting.

You'll need to uninstall emacs-lucid, then do the system upgrade pacman -Syu, and then rebuild and reinstall emacs-lucid.

Following extra/emacs [1], I've updated pkgrel, which should help with automatically triggering the reinstall on some setups.

The problem occurs because tree-sitter's ABI changed backward-incompatibly resulting in the soname change [2,3], requiring downstream packages to be rebuilt. Furthermore we depend on libtree-sitter instead of tree-sitter (following extra/emacs [4]), but this means that makepkg automatically detects the soname needed by the binary and adds it as a dependency [5], which prevents pacman from updating.

Possibly we should switch the library dependencies to package dependencies, which would prevent the problem of pacman being unable to update. A downside would be the user might not know to rebuild this package on soname changes, unless they encounter breakages or use something like rebuild-detector [6].

[1] https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/commit/a7ad42523c3d31451d3a0d1a251d04d8d681a215

[2] https://bbs.archlinux.org/viewtopic.php?id=283631

[3] https://www.reddit.com/r/archlinux/comments/ymv7vp/reminder_to_rebuild_aur_packages_on_soname_updates/

[4] https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/blob/main/PKGBUILD?ref_type=heads

[5] https://wiki.archlinux.org/title/PKGBUILD#depends

[6] https://github.com/maximbaz/rebuild-detector

yashasolutions commented on 2024-08-29 14:24 (UTC)

Seems like some conflict between latest update and this package:

# pacman -Syu
...
installing tree-sitter (0.23.0-1) breaks dependency 'libtree-sitter.so=0-64' required by emacs-lucid

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: https://yhetil.org/emacs-devel/87ilmlluxq.fsf@yahoo.com/

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:

https://aur.archlinux.org/packages/emacs-lucid-nativecomp

1 2 3 4 5 6 Next › Last »