Max Nikulin writes:
>> Yes, but unfortunately it does not handle early Org loading correctly.
>>
>> Try the following init.el:
>>
>> (require 'org)
>> (add-to-list 'load-path (expand-file-name "/path/to/newest/org-mode/lisp"))
>>
>> Then run emacs -Q -l /path/to/init.el
>>
>> M-x org-version
On 24/10/2021 15:34, Ihor Radchenko wrote:
Max Nikulin writes:
`org-version' with FULL argument checks whether org and org-loaddedfs
are loaded from the same directory and adds "mixed installation!" to the
version string. `org-submit-bug-report' puts full version to the message
subject but it
Tim,
> The key point to remember is that a mized installation is not about
> loading org sources from two different org versions. The problem is
> about compilation of org where some of the source definitions are
> already loaded (from existing installation) and result in output which
> is a
Max Nikulin writes:
> `org-version' with FULL argument checks whether org and org-loaddedfs
> are loaded from the same directory and adds "mixed installation!" to the
> version string. `org-submit-bug-report' puts full version to the message
> subject but it is easily to miss this warning
On 23/10/2021 17:26, Greg Minshall wrote:
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
`org-version' with FULL argument checks whether org and org-loaddedfs
are loaded from the same
Greg Minshall writes:
> Tim,
>
> i wonder if the emacs variable `load-history` might be of (approximate)
> help? i submit a starter routine below. as the comments say: caveat,
> caveat, caveat.
>
> i don't think something as uncertain as this would be a candidate for
> normal run-time
Ihor Radchenko writes:
> Tim Cross writes:
>
>> 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
Tim Cross writes:
> 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
Tim,
i wonder if the emacs variable `load-history` might be of (approximate)
help? i submit a starter routine below. as the comments say: caveat,
caveat, caveat.
i don't think something as uncertain as this would be a candidate for
normal run-time checking (and, i'm not even sure when one
Tim Cross writes:
Greg Minshall writes:
(and, after fifteen years of vi, and now 25 of emacs, i guess
i'll skip
the spacemacs experience. :)
Similar past for me as well. I used vi from early/mid 80x until
mid 90s
and then switched to Emacs and used standard Emacs bindings
until a
Greg Minshall writes:
> (and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip
> the spacemacs experience. :)
>
Similar past for me as well. I used vi from early/mid 80x until mid 90s
and then switched to Emacs and used standard Emacs bindings until a
couple of years ago,
Tim,
thanks. i see that it is more complicated.
(and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip
the spacemacs experience. :)
cheers, Greg
Ok, great -- that fixed it! I thought I had been careful to get rid of
my old org from org elpa before I installed 9.5. However, I hadn't
considered that there was an older org still installed that had been
packaged with my emacs 27.2 installation.
So thanks very much for your quick advice.
Greg Minshall 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
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
William McCoy writes:
> I am modifying my previous message (that has not yet appeared on this list)
> with
> some additional information regarding this issue:
>
>
> I have been having some strange errors when using org-agenda. The errors seem
> to have begun about the time I upgraded to org
16 matches
Mail list logo
