emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Greg Minshall <minshall@umich.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: Fwd: errors when using org-agenda
Date: Sat, 23 Oct 2021 22:34:02 +1100	[thread overview]
Message-ID: <m2a6j0ot8s.fsf@blind-drunk.fritz.box> (raw)
In-Reply-To: <1366768.1634984772@apollo2.minshall.org>


Greg Minshall <minshall@umich.edu> writes:

> Tim, et al.,
>
>> These types of errors are frequently caused by a 'mixed' installation
>> of org versions. This will happen if you upgrade org when org is
>> already loaded in the instance of emacs used to perform the upgrade.
>
> a question: is there any way that we can, as org starts up, detect
> either the actuality, or possibility, of a mixed installation?
> maybe something like
> ----
> (assert (eq 1
>             (length
>              (seq-filter
>               (lambda (d) (file-exists-p (concat d "/" "org.el")))
>               load-path))))
> ----
> or some such?  (well, maybe fail in a more user-friendly way... :)
>
I'm not sure auto detecting is possible. It isn't so much about what
files exist, but what functions are already defined and/or what
libraries are already loaded when the upgrade process tries to compile
the new version. The 'mixed' refers to the resulting *.elc files, which
havbe been compiled with definitions from two different org versions.
With package.el for example, once the upgrade has been completed, the
old ELPA version doesn't exist anymore, so it isn't as simple as just
checking for multiple references to org source files in the load path
and at different locations.

What would really be needed is some way to check when org is going to be
compiled that no existing org functionality is loaded. Doubt this can be
easily done within org itself because of a chicken and egg problem - you
would have to load org to run the code to check if org is loaded.

It could be possible to add something to the package installer, but that
would mean doing something with all the package installers e.g.
package.el, straight.el, etc.

Some distributions, like spacemacs, manage this by separating marking of
packages to be upgraded and doing the upgrade into separate sessions.
You check for updates, write the list of packages to be updated, move
the existing packages to a recovery area and then you have to restart
Emacs. On restart, the list of packages to be upgraded (it is really an
install because the previous versions have been moved out into a
separate 'recovery' area) and if org is in the list, move it to the
front of the list so that it is installed before any other packages (to
protect against other packages loading org as part of their
installation).

All this means, with spacemacs, you can be pretty confident an upgrade
will work without the mixed install issue. Even better, if the upgraded
package has problems and you want to downgrade back to the previous
version, that is supported as well.

The bad aspect of spacemacs is that after you have used it for a while,
your pretty much ruined when it comes to running vanilla Emacs. You get
very use to the VI style modal editing and find it hard to use emacs
without evil mode installed.





  reply	other threads:[~2021-10-23 11:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22 20:35 errors when using org-agenda William McCoy
2021-10-23  0:46 ` Fwd: " William McCoy
2021-10-23  1:57   ` Tim Cross
2021-10-23 10:26     ` Greg Minshall
2021-10-23 11:34       ` Tim Cross [this message]
2021-10-23 18:07         ` Greg Minshall
2021-10-23 18:21           ` Tim Cross
2021-10-24  0:45             ` Thomas S. Dye
2021-10-24  5:05         ` Greg Minshall
2021-10-24  6:44           ` Tim Cross
2021-10-24 10:55             ` Greg Minshall
2021-10-24  5:12         ` [PATCH] " Ihor Radchenko
2021-10-24  6:59           ` Tim Cross
2021-10-24  8:16       ` Max Nikulin
2021-10-24  8:34         ` Ihor Radchenko
2021-10-27 16:46           ` Max Nikulin
2022-09-11  9:22             ` Ihor Radchenko
2021-10-23 14:49     ` William McCoy

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

  List information: https://www.orgmode.org/

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

  git send-email \
    --in-reply-to=m2a6j0ot8s.fsf@blind-drunk.fritz.box \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=minshall@umich.edu \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).