make: Don't use Q, allow the use of site-lisp

[Thaodan]

The rationale is that some Emacs packages might be found in site-lisp,
especially as for other packages such as those that would require
native modules.

[tarsius]

The rationale is that some Emacs packages might be found in site-lisp,

I think you are saying that some of the packages that you have installed using Borg have dependencies that were installed using a different method and that when you compile the packages that were installed using Borg, these packages are missing from the load-path.

Despite that, I think it is very appropriate to not load the configuration files intended for interactive use, in non-interactive use. They might do any kind of thing that is completely inappropriate in non-interactive use.

Note that the arguments are set with ?=, so you can override this easily, thanks to the -include etc/borg/config.mk further up. But you shouldn't, at least not for this use-case.

Borg provides an init file specifically for non-interactive use. If it exists, etc/borg/init.el is loaded by borg-initialize. The main use-case for this file is just this: add externally installed dependencies to the load-path.

I just noticed that etc/borg/{init.el,config.el,config.mk} are not sufficiently documented. I'll do that when I get the time.

[Thaodan]

Jonas Bernoulli ***@***.***> writes:

> The rationale is that some Emacs packages might be found in site-lisp, I think you are saying that some of the packages that you have installed using Borg have dependencies that were installed using a different method and that when you compile the packages that were installed using Borg, these packages are missing from the `load-path`.

Yes they are installed into the Emacs builtin site-lisp. -Q prevents that the builtin site-lisp isn't aviable.

Despite that, I think it is very appropriate to not load the configuration files intended for interactive use, in non-interactive use. They might do any kind of thing that is completely inappropriate in non-interactive use.

Site-lisp isn't about configuration that isn't intended for non-interactive use. It is about packages that are installed into site-lisp, they should be available even in non-interactive. What configuration are you talking about?

[tarsius]

It seems that in the decade since I last read the respective documentation, I forgot about some nuances. (I though -Q was necessary to ignore default.el, for starters.) After reading it again, some things are still a bit unclear to me, and I want to read some code, to catch up on some finer points, before making a decision.

I will likely merge something like this when I am done. (But drop -q, because --batch implies that. I also want to check whether --no-splash and --no-x-resources actually make a difference in batch mode; it seems to me that at least --no-splash should be implied.)

[Thaodan]

Jonas Bernoulli ***@***.***> writes:

I will likely merge something like this when I am done. (But drop `-q`, because `--batch` implies that. I also want to check whether `--no-splash` and `--no-x-resources` actually make a difference in batch mode; it seems to me that at least `--no-splash` should be implied.)

Reading the Emacs manual tells me that all configuration variables in Xressources are for ui so they don't seem relevant. Since no ui is initialized I don't think they even will be loaded.

[tarsius]

I've decided to not merge this for the time being. Init file handling has to be reworked from the ground up. This includes changes to borg's own init files, which will be more work. I think it would be a bad idea to change the default behavior now, and then again in a few months, when I have the time to go all the way.

Thanks for bringing this to my attention though!

[Thaodan]

How does this affect the default behaviour besides including packages from site-lisp? Packages from site-lisp have the least priority, the user packages installed by borg will be preferred.

[tarsius]

It's a change in behavior, which can also be achieved through trivial customization. Since you are the first to have brought this up, everybody else must either not be bothered by the current behavior or they have just added the necessary customization. As I said, I think there is room for better defaults here (going beyond what you are suggesting). Some might prefer the current default behavior, some the future default behavior, so someone will have to add customization. I don't want to force users to adapt their customization twice, so I am leaving things as-is for the time being.