Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> That's formally true, but doing this over the objections of the
>> original authors would be IMO rude, and I would not agree to that
>> lightly.
>
> I agree that'd be rude. I also think that'd be quite confusing for the
> end users and will make some of the operations (e.g. submission of
> bugs) a total mess. Neither the Clojure, nor the Emacs communities are
> big enough to engage lightly in time-wasting activities.
>
> And, I'll say it once more - in case this was missed in the
> conversations. Personal misgivings about the mechanics of Emacs's
> development aside, I think it's not prudent to keep growing its core,
> which is already huge. Obviously it's up to the Emacs developers to
> decide what to do, but I'd be moving more things into packages and
> bundling less things with Emacs. You might have seen this trend in
> some programming languages - e.g. Ruby has slimmed down its core a lot
> and this helped channel the efforts of the core team.
>
> I think by now pretty much every user of an editor or a programming
> language is used to installing packages to augment the core
> functionality, so I'm not buying the argument that we need to have
> more things OOTB. IMO the core of Emacs should consist of fewer, but
> truly essential packages.
>
> Someone mentioned it'd be nice if Emacs suggested packages to install
> for certain (unsupported OOTB) file types and I think that'd be a nice
> way to help with package discovery. Perhaps packages can just mention
> this in their metadata?

Most of the time this would be duplicating information, since most
packages already have a

  ;;;###autoload
  (add-to-list 'auto-mode-alist '("\\.foo\\'" . foo-mode))

in their body somewhere, that can be scraped.  I proposed doing this in
the context of updating the archive-contents file format to address a
few issues that people have been raising for a couple of years now.

Of course this doesn't work when users work in environments without any
internet access or their access to {GNU,NonGNU} ELPA is restricted by a
firewall.  I don't know if it is points like these that motivate adding
functionality directly to the core?