Hi, Ludovic Courtès <l...@gnu.org> writes:
> Hi Mark, > > Mark H Weaver <m...@netris.org> skribis: > >> Eventually, I realized what the problem was: >> >> (1) My existing emacs session started failing because >> ~/.guix-profile/share/emacs/27.1 had disappeared out from under it. >> >> (2) My newly launched emacs sessions were failing because my >> EMACSLOADPATH variable was still set to its old value, pointing at >> /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer >> existed. >> >> I'm not sure why I've never run into this problem before. I'm also not >> sure what can be done to make this better, but if anyone has ideas, that >> would be good. If a 7+ year Guix veteran developer gets bitten badly by >> this, I doubt that less experienced users will be impressed. > > Ouch. “It used to be” (speaking like a veteran :-)) that Emacs in Guix > would not use EMACSLOADPATH. Then we switched to EMACSLOADPATH, which > had some advantages, but necessarily has this drawback. > > IIUC, <https://issues.guix.gnu.org/45359> is about possibly > backtracking. Maxim, what’s the status of this one? It's abandoned, The MUMI tracker lacks the responses from Leo Prickler, but they had good arguments maintaining the status quo rather than going with the extra complexity. It also wouldn't change the issue at hand; it'd merely prevent conflicts of *resources* files of Emacs packages (and somewhat integrate with the Emacs native package manager, while making the autoloading a bit slower). It seems the price to pay is too high for such a small gain. I'm closing it now. On the other hand, this very problem was the motivation for this patch series here: https://issues.guix.gnu.org/43627, which would solve the issue ta hand. You were skeptical of the benefits the last time you took a look at it; perhaps it's time to take a new look at it :-). Thanks, Maxim
