Bug#1039105: Fails to start with Emacs 28

[Dirk Eddelbuettel]

Package: vm
Version: 8.2.0b-8
Severity: normal

Ian,

After updating my main machine (and the only one running vm along and
exim4, dovecot, spamassassin and whatnot) to Ubuntu 23.04 with its Emacs 28.2
(in an upgrade from 22.10 with Emacs 27.*), I found that vm (which I have
been using all those years, still with some hooks and key-binding you emailed
to in the mid-1990s (!!)) would no longer start.

The error was indicative of elc compilation woes. I found a post by the magit
author suggesting removal and reinstallation (of his package). That worked,
so I was relieved, but it worked only once.

Looking around, I stumbled across the Fedora page for vm. It contains a
reference to a change in this commit

https://src.fedoraproject.org/rpms/emacs-vm/c/909b0bc357976252c51502bf17ed1efc6aeb7b97?branch=rawhide

which boils down to

;; Startup settings for VM
+ ;;
+ ;; For some reason, native compilation breaks VM. As a workaround until the
+ ;; problem is understood and fixed, disable native compilation of all VM
+ ;; lisp files.
+ (eval-after-load "comp"
+ '(if (boundp 'native-comp-deferred-compilation-deny-list)
+ (add-to-list 'native-comp-deferred-compilation-deny-list "/vm.*\.el")))

I added this in a local -9 build to the top of debian/vm.emacsen-startup
which now has

;-*-emacs-lisp-*-
; arch-tag: 045640fd-0ff2-45b7-a29f-68e4b8378fbf

;; Borrowed with thanks from Fedora at
;; https://src.fedoraproject.org/rpms/emacs-vm/c/909b0bc357976252c51502bf17ed1efc6aeb7b97?branch=rawhide
;;
;; For some reason, native compilation breaks VM. As a workaround until the
;; problem is understood and fixed, disable native compilation of all VM
;; lisp files.
(eval-after-load "comp"
'(if (boundp 'native-comp-deferred-compilation-deny-list)
(add-to-list 'native-comp-deferred-compilation-deny-list "/vm.*\.el")))

It would be nice if this could be applied to the package as a hot-fix as
failing to start is a little off-putting. We could probably also skip the
installation on start but there is enough going on in that installer script
that I left things were they were.

Happy to locally refinements or variants if you have any as I obviously have
a test bed for the bug.

Cheers, Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

[Dirk Eddelbuettel]

Hi Thomas,

On 27 June 2023 at 22:05, Thomas Lange wrote:
| Hi Dirk,
|
| I'm a vm user for reading my mail.

So there's two of us! :-)

| Thanks a lot for this bug report and fix. It also works for me.
| Patching /etc/emacs/site-start.d/50vm-init.el still compiles vm-vars
| and vm-version, but I can start the VM mode and read my mails with
| emacs 28 using bookworm.

I never quite grok'ed what the deal is with the identical 50vm.el and
50vm-init.el. Other packages don't do that. (But I think I no longer maintain
anything that ships .el code so I no longer look at the these much.)

| After this first test, I can upgrade my computer to bookworm. Yeah!

I am actually enjoying Emacs 28 quite a bit since the update. Feels snappier.

Very minor issues: The "theme" / "face" is a little off for me (I tend to run
both under x11/wayland and inside byobu/tmux and the latter is little
difference). And when running in daemon mode `emacsclient -c` no longer
starts an initial frame so I am back to old school server-start.

| I vote for adding this fix into a new vm version for bookworm proposed
| updates.

Yes. Have not heard yet from the maintainer but it would be good to add this,
and of course figure out why it balks with elisp compilation.

[Ian Jackson]

Dirk Eddelbuettel writes ("Bug#1039105: Fails to start with Emacs 28"):

> After updating my main machine (and the only one running vm along and
> exim4, dovecot, spamassassin and whatnot) to Ubuntu 23.04 with its Emacs 28.2
> (in an upgrade from 22.10 with Emacs 27.*), I found that vm (which I have
> been using all those years, still with some hooks and key-binding you emailed
> to in the mid-1990s (!!)) would no longer start.

Thanks for the report. And thanks to the others for the further
information.

I can reproduce the problem and the suppression of byte compilation
does indeed fix it.

It's a bit funky to reproduce, because emacs likes to byte-compile
things when it's idle with the effect that naive "emacs --batch" runes
don't show the problem.

I'll do a stable update. But first I am going to upload to sid,
as per the stable release policy. And I'm adding a test, since I did
manage to get a reliable repro.

I confess I don't understand the upstream package very well.

Ian.

--
Ian Jackson <ijac...@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

[Ian Jackson]

Control: severity -1 serious

This bug makes the package very hard to use. It fails to work, by
default.