unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Peter Hull <peterhull90@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: nongnu ELPA and slime
Date: Tue, 06 Feb 2024 08:10:09 +0000	[thread overview]
Message-ID: <87cytaxbby.fsf@posteo.net> (raw)
In-Reply-To: <CAK9Gx1cqD5i2=N2KNObe5p+mhq6DSU5aLEXr21P0d=J0EDBKKg@mail.gmail.com> (Peter Hull's message of "Mon, 5 Feb 2024 20:12:38 +0000")

Peter Hull <peterhull90@gmail.com> writes:

> Hi,
>
> Is this list the correct place to discuss nongnu ELPA?

Sure.

> I've come across a problem with the latest (2.29.1) SLIME package when
> installed from ELPA. Basically the package appears to install without
> problems but none of its functions are registered so it cannot be
> activated. There is more discussion on
> https://github.com/slime/slime/issues/808
>
> What I believe is happening is that the slime-2.29.1.tar on ELPA is
> being constructed without its hand-written slime-autoloads.el file. At
> install time, an autoload file is generated which doesn't work,
> because the relevant functions in SLIME are not marked with autoload
> cookies. The release tarball on github does have the autoloads file,
> as does slime-20240125.1336 from MELPA.

Do you know why they don't mark their functions with autoload cookies?
Writing a manual autoload file is very unusual.

> Unfortunately I've only ever been a user of emacs packages so I don't
> understand how it all works. Is there a way to specify that the
> slime-autoloads.el file needs to be included in the package, or will
> the relevant bits of SLIME need to be annotated so the generated file
> is functional?

It would be imaginable to configure the ELPA build server to not
overwrite the slime-autoloads.el file, but I'd first like to understand
why they take this route in the first place.

FWIW the quick fix for this issue is to add this to your init.el

(autoload 'slime-mode "slime")
(add-hook 'lisp-mode-hook 'slime-mode)

> Thanks for your help,
>
> Peter



  reply	other threads:[~2024-02-06  8:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 20:12 nongnu ELPA and slime Peter Hull
2024-02-06  8:10 ` Philip Kaludercic [this message]
2024-02-06  9:38   ` Colin Baxter
2024-02-06 10:07     ` Philip Kaludercic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cytaxbby.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=emacs-devel@gnu.org \
    --cc=peterhull90@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).