all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Mark H Weaver <mhw@netris.org>, 47458@debbugs.gnu.org
Subject: bug#47458: Terrible UX upgrading Emacs in Guix
Date: Mon, 29 Mar 2021 10:07:51 +0200	[thread overview]
Message-ID: <a7f2bc110511dead9070bd805dd38788f3d5973f.camel@student.tugraz.at> (raw)
In-Reply-To: <87o8f23eew.fsf@netris.org>

Am Sonntag, den 28.03.2021, 22:02 -0400 schrieb Mark H Weaver:
> I just updated my Guix system, which included the Emacs update from
> 27.1
> to 27.2.  After "guix package -m mhw-manifest.scm" finished running
> (which takes a long time for me, since I don't use substitutes), and
> before I even noticed that it had finished, my existing Emacs session
> started misbehaving badly.
> 
> It failed to even open a plain text file in fundamental mode (a .drv
> file) with an inscrutible error about 'arrayp'.  I tried to enable
> the
> debugger with M-x toggle-debug-on-error, but then I started getting
> errors about 'debug' not found.  (I neglected to record the exact
> messages).
As you are probably aware by now, this is a result of parts of your
EMACSLOADPATH being deleted.  I don't think there's a good solution to
this, but you could (as part of your early init file) resolve the
symlinks in it, so that it behaves deterministically until it is
garbage collected?

> [...]
> 
> 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.
Remember the snippet, that tells you you might want to recompute your
environment variables at the end of `guix package'?  Well, this is just
that.  I've already made it a habit to close Emacs at that point (and
you probably have as well), but as you said, you didn't even notice the
update succeed, so that's what lead to the confusion.

In a similar manner, if I see an Emacs version upgrade at the start of
the transaction, I already know to prepare for a little environment
variable dance to get it to start correctly.  I think there has been an
idea to update environment variables in GNOME Shell directly, for
instance, but
a. we're lacking the technology to do so at the moment (e.g. guile-
dbus)
b. it's not clear, that Guix itself should do such a thing rather than
relying on the user to e.g. code up a oneshot shepherd service 

Regards,
Leo





  reply	other threads:[~2021-03-29  8:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29  2:02 bug#47458: Terrible UX upgrading Emacs in Guix Mark H Weaver
2021-03-29  8:07 ` Leo Prikler [this message]
2021-03-29  8:24   ` Maxime Devos
2021-03-29  8:43     ` Leo Prikler
2021-03-29 15:55 ` [bug#45359] " Ludovic Courtès
2021-03-29 15:55 ` Ludovic Courtès
2021-03-29 18:25   ` bug#45359: " Maxim Cournoyer
2020-12-22  3:28     ` [bug#45359] [PATCH]: Re-introduce Emacs packages specific installation prefix Maxim Cournoyer
2020-12-22  8:51       ` bug#45316: " Leo Prikler
2020-12-22 18:09         ` Maxim Cournoyer
2020-12-22 19:10           ` Leo Prikler
2020-12-26  5:01             ` Maxim Cournoyer
2020-12-26 10:56               ` Leo Prikler
2020-12-27  4:44                 ` Maxim Cournoyer
2020-12-27  8:46                   ` Leo Prikler
     [not found]       ` <handler.45359.D45359.161704236132600.notifdone@debbugs.gnu.org>
2021-03-29 18:45         ` [bug#45359] closed (Re: bug#47458: Terrible UX upgrading Emacs in Guix) Maxim Cournoyer
2021-03-29 18:48         ` bug#45359: [PATCH]: Re-introduce Emacs packages specific installation prefix Maxim Cournoyer
2021-03-30  8:04     ` [bug#45359] bug#47458: Terrible UX upgrading Emacs in Guix Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2020-09-26  6:11 [bug#43627] [PATCH core-updates]: Add a 'append-separator?' field to the <search-path-specification> record Maxim Cournoyer
2020-09-26  6:14 ` [bug#43627] [PATCH core-updates 1/3] guix: Add an append-separator? " Maxim Cournoyer
2020-09-26  6:14   ` [bug#43627] [PATCH core-updates 2/3] gnu: emacs: Use the new append-separator? option to define its search path Maxim Cournoyer
2020-09-26  6:14   ` [bug#43627] [PATCH core-updates 3/3] Revert "emacs-build-system: Ensure the core libraries appear last in the load path." Maxim Cournoyer
2020-09-27 19:01 ` [bug#43627] [PATCH core-updates]: Add a 'append-separator?' field to the <search-path-specification> record Ludovic Courtès
2020-10-03 21:22   ` Maxim Cournoyer
2020-11-02 13:59     ` Ludovic Courtès
2020-11-08  5:49       ` Maxim Cournoyer
2021-03-30 15:51 ` [bug#43627] [PATCH core-updates v2 1/2] guix: Add an append-separator? " Maxim Cournoyer
2021-03-30 15:51   ` [bug#43627] [PATCH core-updates v2 2/2] gnu: emacs: Use the new append-separator? option to define its search path Maxim Cournoyer
2021-04-10 20:42   ` [bug#43627] [PATCH core-updates v2 1/2] guix: Add an append-separator? field to the <search-path-specification> record Ludovic Courtès
2021-05-20 14:24     ` bug#43627: " Maxim Cournoyer
2021-03-30 18:41 ` [bug#43627] [PATCH] gnu: emacs: Wrap EMACSLOADPATH Leo Prikler
2021-04-04  4:35   ` bug#47458: Terrible UX upgrading Emacs in Guix Maxim Cournoyer
2021-04-04  7:49     ` Leo Prikler
2021-04-06 12:09       ` Maxim Cournoyer
2021-04-06 15:49         ` Leo Prikler
2021-04-07 19:46           ` Maxim Cournoyer
2021-05-20 13:24             ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7f2bc110511dead9070bd805dd38788f3d5973f.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=47458@debbugs.gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.