Re: Clojure mode

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Mon, 28 Aug 2023 12:35:02 -0400
> Cc: Bozhidar Batsov <bozhidar@batsov.dev>, dmitry@gutov.dev, rms@gnu.org, 
>       danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
> 
> As a practical matter, how
> would people feel about a sort of autoload variation, included in emacs (30) 
> core, that points users
> at relevant packages in [non-]GNU Elpa, which would be overridden by code 
> included in an actual
> package? The idea is to combine a thin pointer with a potential indirection 
> point that allow users (who
> had not already chosen) to choose between alternatives such as clojure-mode 
> and clojure-ts-mode.

You will have to present a more detailed proposal, because up front I
don't see how will this work.  For example, "autoloading"
clojure-ts-mode from ELPA will need:

  . download the Lisp files
  . byte-compile the Lisp files
  . add the directory of Lisp files to load-path
  . download the clojure grammar library
  . build a shared library from the grammar library
  . install the shared library

IOW, you will need to do what package.el does, but in batch and behind
the user's back.  Plus, it will take some non-negligible time.  How is
such "autoloading" useful?

The current idea of including ELPA packages is to include them in the
release tarball, so that for the end-user it looks exactly like a core
package.  What advantages does your proposal have wrt this idea?