[bug#43627] [PATCH core-updates]: Add a 'append-separator?' field to the <search-path-specification> record.

[Maxim Cournoyer]

Hello Ludovic!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> These three commits extend our search-path-specification record with a
>> new field, that can be used to produce a trailing separator, which can
>> be useful at least with Emacs (I can think of at least another place
>> where it could be used: the INFOPATH variable).
>>
>> It was motivated to allow defining the Emacs search path in a more
>> robust way.
>
> I’m skeptical since we have only one (or two?) use cases.  I think we
> should weigh the added complexity, both in terms of implementation and
> of semantic clarity, compared to reduced complexity elsewhere.  It seems
> to me that the costs outweigh the benefits here.

I too was skeptical at first (which explains why this commit was not
submitted for inclusion for 3 years :-)), but recent events surrounding
emacs-next and the bump to Emacs 27 have put its value back into light.

> Also, the empty search path entry has a special meaning.  For
> EMACSLOADPATH, that entry doesn’t have to be last, one can choose to put
> it in the middle of the search path (info "(emacs) General Variables").
> The trailing separator is just a special case.

Yes, I'm aware of this; it doesn't makes sense for our use to put it
anywhere else than at the end though, because we want to allow user
installed libraries to override builtin ones (e.g., a more recent Org
from emacs-org package overriding the builtin Org version), not the
contrary.

Another reason to consider this change is combining profiles.

Currently:

$ guix install -p /tmp/p1 emacs-no-x emacs-sr-speedbar
$ guix install -p /tmp/p2 emacs-no-x emacs-org
$ guix package -p /tmp/p1 -p /tmp/p2 --search-paths | grep EMACS
export
EMACSLOADPATH="/tmp/profile1/share/emacs/site-lisp:/tmp/profile1/share/emacs/27.1/lisp:/tmp/profile2/share/emacs/site-lisp:/tmp/profile2/share/emacs/27.1/lisp"

Which is clearly wrong, as the Emacs' own libraries will appear before
the user-installed libraries of the second profile, causing the Org
version used to be that of Emacs rather than the one the user installed.

There's no way to work around this except by adding ad-hoc klugdes
around the code where different profiles need to be merged.

On the other hand, if the information is recorded in the search-path
object itself, we can combined search-path in the way they were meant to
be.  In the occurrence, the resulting combined search path would have
the append-separator? set, causing the end result to have a single ':'
appended, with the correct behavior:

(with this proposed change)

$ ./pre-inst-env guix install -p /tmp/p1v2 emacs-no-x emacs-sr-speedbar
$ ./pre-inst-env guix install -p /tmp/p2v2 emacs-no-x emacs-org
$ ./pre-inst-env guix package -p /tmp/p1v2 -p /tmp/p2v2 --search-paths | grep 
EMACS
export
EMACSLOADPATH="/tmp/p1v2/share/emacs/site-lisp:/tmp/p2v2/share/emacs/site-lisp:"

I hope this helps understanding the rationale behind this change.

Thanks,

Maxim