Allow a list for tangleArg

[terlar]

I'm currently toying with the idea to use one org file, but produce multiple Emacs configurations/packages.

The plan goes like this:

• One init.org file.

• Tangles early-init.el

• Tangles init.el.

• Tangles init-medium.el

• Tangles init-large.el

• Inside the init.el all the use-package for the common smallest subset with basic editing support and essentials.

• Inside the init-medium.el will have some more use-package definitions, most commonly used major-modes, some bells and whistles.

• Inside the init-large.el will have even more use-package definitions, all the major-modes and fancy bells and whistles.

• Produce 3 emacsTwist packages

  1. tangleOrgBabelFile with tangleArg = ["init.el"]
  2. tangleOrgBabelFile with tangleArg = ["init.el" "init-medium.el"]
  3. tangleOrgBabelFile with tangleArg = ["init.el" "init-medium.el" "init-large.el"]

Do you think this makes sense, would be useful?

[terlar]

Or perhaps I should just do it via initFiles and multiple tangles with explicit tangleArg. I guess that is more realistic and true to the tangle implementation, since it doesn't support multiple.

[akirak]

Actually, this library allows the user to define multiple configuration profiles by filtering subtrees with Org tags. It might not be clear from the documentation how you can use it for multiple configurations, but I have been using it in my config from the start (not elegant code, but I made the API as general as possible):

      initFiles =
        [
          (tangleOrgBabelFile "init.el" ./emacs-config.org {
            processLines = org.excludeHeadlines (
              s:
                org.tag "ARCHIVE" s
                || (
                  if extraFeatures == true
                  then false
                  else (org.tag "@extra" s && !lib.any (tag: org.tag tag s) extraFeatures)
                )
            );
          })
        ]

In this example, subtrees with @extra tag are ignored by default but can be included by specifying corresponding tags. extraFeatures is an option in my custom home-manager module, so the extra packages are installed depending on what each host should be capable of. All packages are included when they are locked (with extraFeatures == true), so there is only a single lock directory. Each profile (or variant) is a subset of the master configuration.

Nevertheless, it's possible to enhance tangleArg to match multiple targets. Tags are my preference, but people use Org mode in different ways. It would be even possible to accept a regular expression for tangleArg, which is more general than a list. In your case, what API would be desirable?

[akirak]

I also noticed that people are trying to use both this Nix library and the Emacs-native tangle function to generate init.el. I only use the former, and wrapper.nix loads the Nix-generated init.el into Emacs, but this is not as intuitive as I thought.

[akirak]

Do you think this makes sense, would be useful?

While I seldom need an alternative profile, a small/minimal profile would be useful in certain situations. For example, one does not require a full profile for editing Git commit messages, so you could use the small profile instead in EDITOR/GIT_EDITOR (or the alternate editor if you use Emacs in server mode).

[terlar]

Thank you for your thoughtful feedback. I didn't think about that it will be separate "lock-files". So the solution would not be optimal. I will look into using the tag feature, to see if that can achieve things nicer.

The wrapper.nix that you talk about, is it this one?

Yeah, I haven't really required it before, but I have some more environments recently, some like Google Cloud Workstation, which mainly comes with an editor already and then things like servers. I was thinking there you could have a light-weight Emacs that has all the editing packages and nothing more.

I guess it is not super high on my prio-list currently. Feel free to close this or I might come back to this when I get around to test things.

Currently I only use the org-babel to generate the packages, then I generate the org -> el files in a separate derivation, because I have multiple outputs, init.el and early-init.el as well, as byte compiling the result. Of course it would be nice if all this could be wired up as part of twist.nix, but also I guess it is a bit esoteric.

I also noticed :tangle could take a elisp-function/expression. That could also be interesting to evaluate.