emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Layers/Modules


From: Ag Ibragimov
Subject: Re: Layers/Modules
Date: Sun, 06 Sep 2020 14:55:31 -0700
User-agent: mu4e 1.4.13; emacs 27.1


On Sun 06 Sep 2020 at 00:32, Andrea Corallo <akrl@sdf.org> wrote:

Ag Ibragimov <agzam.ibragimov@gmail.com> writes:

Spacemacs (community-driven Emacs distribution/config) has a feature
called Layers, Doom-Emacs (another community-driven Emacs config) has
a similar feature (I think they are called Modules).

A Layer is a bundle of [related] Emacs packages that work together and
very often tightly integrate (with one another) to provide a
comprehensive set of features to achieve specific goals. For example,
there are many language-specific Spacemacs layers: Python, Lua,
Haskell, etc.
For example, the Python layer includes basic Python-related packages and sets 
defaults for Flycheck, Company, etc.
There also layers for tools like Docker or layers for version-control, et al.

So my question is: Has anyone ever thought about designing a sort of
standardized module system? It would be great if we could have a
unified model for creating such bundles.
Wouldn't be nice if for example, instead of discovering, installing
and configuring a bunch of related packages, an Emacs user would say:
"install LaTeX module" and then "customize "LaTeX module", etc.

Emacs ecosystem is growing. There are hundreds (maybe more) packages;
standardizing a system that would allow the "plug-n-play" experience
would be very nice. Otherwise, everyone would continue solving same
problems in their own, unique ways, increasing entropy towards the
"Lisp curse."

How is this conceptually different from a package that depends on other
packages?

  Andrea

So take for example Spacemacs Python layer.
It adds dependency to Company, defines package loading order, configures 
Company backends required for coding in Python.
it also adds lsp support, but if the user doesn't use lsp, there's a simple way 
of excluding lsp package, and any logic/configuration pertaining lsp would be 
completely ignored.
Same thing for the completion - you can build a module that supports both - 
Helm and Ivy, and the Module loading mechanism would detect which one is the 
preferred and loads only that one.
What I'm saying is, that there are lots of intricacies of making multiple (related) 
packages to play together well, and currently we don't have a standard or a convention to 
"containerize" them.
You can loosely interpret my point  as if we were taking about Packages as 
libraries, and Modules as applications. I don't know how deep we want this 
rabbit hole to go though. Should Modules be able to import other Modules as 
well?
Right now, both - Doom and Spacemacs have developed their own ways of dealing 
with this problem and you cannot pick a Spacemacs Layer and simply use it in 
Doom (or your own config), and I think it would be nice if you could.
Which kinda brings me to my next question (and I think was asked many times 
before), will we ever get built-in support for use-package in Emacs?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]