(unknown)

(unknown)

[Ag Ibragimov]

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."

Re: Layers/Modules (was none)

[Andrea Corallo via Emacs development discussions.]

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

Re: Layers/Modules (was none)

[Stefan Monnier]

>> 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).
[...]
>> So my question is: Has anyone ever thought about designing a sort of
>> standardized module system?

I'd very much welcome such a thing.  Presumably, those who designed the
Spacemacs layers and the Doom modules would be good people to get
involved in such a design.


        Stefan

Re: Layers/Modules (was none)

[Yuan Fu]

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

Indeed, and define a minor-mode when enabled, sets up everything. This kind of configuration package would be more controversial than a regular package, though.

Yuan

Re: Layers/Modules (was none)

[Daniel Martín]

>> 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.

I also think that having some sort of package "bundles" that simplify
configuring Emacs for a particular purpose is a good idea. However, I
don't clearly see how this idea fits in Emacs core development; Like
Andrea, I also think of "layers" as "packages of packages". I think a
starting point could be that someone familiar with how Spacemacs/Doom
layers work describe for us in more detail how they work and the pain
points/inconsistencies that people experience when developing them.

--
Daniel Martín

Re: Layers/Modules

[Ag Ibragimov]

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?

Re: Layers/Modules

[Stefan Kangas]

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

> will we ever get built-in support for use-package in Emacs?

Work is on-going here:

    https://github.com/jwiegley/use-package/issues/282

The last update in May reported only 3 missing assignments before it
could go in.