Re: bug#59882: Multiple versions of Org in load-path problem

[David Masterson]

Eli Zaretskii  writes:

>> Cc: emacs-orgmode@gnu.org, 59...@debbugs.gnu.org
>> From: David Masterson 
>> Date: Thu, 08 Dec 2022 13:56:03 -0800
>> 
>> In my testing, I found a strange case where, in *scratch*, I get:
>> 
>> (message "%s" org-version)
>> ;; Error undefined
>> ;; Do 'C-h v org-version'
>> (message "%s" org-version)
>> 9.3
>> 
>> So, 'describe-variable' on org-version causes Org to be loaded?!?
>
> Why is it so surprising?  Is this the first time you see that a Help
> command loads something to do its job?

Yes, it is surprising.  How did Emacs know to load Org to find
org-version?  I didn't request it to by this action.  Or did it do a
package-activate-all (or similar) to ensure that everything was loaded?
That would be overkill.  Sometimes the best answer is 'nil'.

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[Tim Cross]

David Masterson  writes:

> Tim Cross  writes:
>
>> David Masterson  writes:
>>
>>> "Michel Schinz"  writes:
>>>
 Just for the record, I also ran into problems when installing Org 9.6
 using Emacs' package system on top of an older version that came with
 Emacs. If I tried to install it as usual (M-x list-packages, then
 install the package from there), I had errors during compilation related
 to `org-assert-version`, and then if I restarted Emacs, I would get a
 fatal error in an unrelated package.

 I managed to solve that problem by:
 1. uninstalling Org 9.6 and exiting Emacs,
 2. starting Emacs with -q,
 3. installing Org 9.6 from there (using M-x list-packages as usual),
 4. restarting Emacs.
>>>
>>> Interesting!  I tried this (essentially) and it worked for my case.  In
>>> my case, I had a built-in Org-9.3 and I was trying to use list-packages
>>> to install Org-9.6. I checked that using -q still added Org-9.3 to
>>> the
>>> load-path, but, since Org wasn't loaded, the install via list-packages
>>> worked.
>>>
>>> The question is what's the proper way of doing this without '-q'?
>
> [...]
>
>> I don't think there is any safe way to install an updated version of
>> org-mode other than
>>
>> 1. Use the -q approach outlined above
>
> Thinking about it, this only works if Org is in elpa as melpa (etc.) are
> not added to package-archives.  You'd have to do some handwritten elisp
> out of *scratch* to setup package-archives if Org-9.6 was still coming
> out of melpa. That's why this can only be labeled as a hack and not a
> solution.
>

Well, yes, if your going to use this technique to load a package which
is not in the default package archives you would need to add that
archive first. People who use this technique often just have a
'update.el' file which they load/evaluate when starting Emacs with -q. 


>> 2. Craft your init.el file such that org functionality is only loaded
>> when explicitly requested and always update as the first action after
>> starting emacs.
>
> In this case, something happened in package-install when trying to
> install Org-9.6 with a built-in Org-9.3.  During the compilation check
> (.el -> .elc) many files failed because the new 'org-assert-version'
> macro was not defined.  Sort of like, after package-install started
> working on Org-9.6, org-macs.el (where org-assert-version should be) got
> loaded *before* the new load-path had been set causing it to load the
> old one from 9.3.  Thereafter, everything went awry. 
>

You must have some custom code in your init.el or are using something
like use-package as package.el doesn't try to install or upgrade
packages during init by default.

Where people can come undone is when they are using use-package and set
the :ensure t option. In this case, use-package will not know about the
bundled version and will attempt to install org from ELPA. If use
package runs after org has already been loaded (possibly because some
other package has been loaded which depends on/requires org mode and has
loaded the bundled version) then things will break because you will end
up with a mixed version install. This is why I always ensure org is the very
first use-package in my init.el and it comes before any other code which
loads or initialises anything.  

>> The first approach is actually the easiest. The second is hard to get
>> right and very fragile because packages like use-package and more
>> specifically, other packages with leverage off org functionality, make it
>> impossible to reliably know exactly when org is loaded.
>
> Using ':after" in use-package is supposed to help that, but I'm not sure
> it is reliable.  Packages are often incomplete about what other packages
> it depends on.
>

You cannot rely on :after. The problem is, other packages may require
org functionality and will load org when they are loaded. This can be
very subtle as there are a lot of packages which only make very small
use of org mode, but even that requires that org mode is loaded. 

>> An approach used by many 'canned' distributions is to postpone package
>> updates. You have a function you run to check for updates which
>> generates a list of packages to update and writes that list to a
>> file. Each time emacs is started, it looks for this update list and if
>> it finds it, it installs packages updates at the very beginning of the
>> init process (before any of your other init.el code or custom
>> blocks). The process also looks for org in the list of packages to
>> update and if it is found, updates it first. 
>
> Probably doesn't work in this case as you would need to be able to use
> package.el suggesting that the load-path has been updated for all
> built-ins already.  The thing I note is that the load-path has already
> been updated for built-ins at the beginning of
> '~/.emacs.d/early-init.el', but the libraries haven't been loaded yet
> (unless needed). That's okay if the newer version of a package then

Re: bug#59882: Multiple versions of Org in load-path problem

[Eli Zaretskii]

> Cc: emacs-orgmode@gnu.org, 59...@debbugs.gnu.org
> From: David Masterson 
> Date: Thu, 08 Dec 2022 13:56:03 -0800
> 
> In my testing, I found a strange case where, in *scratch*, I get:
> 
> (message "%s" org-version)
> ;; Error undefined
> ;; Do 'C-h v org-version'
> (message "%s" org-version)
> 9.3
> 
> So, 'describe-variable' on org-version causes Org to be loaded?!?

Why is it so surprising?  Is this the first time you see that a Help
command loads something to do its job?

Re: Multiple versions of Org in load-path problem

[David Masterson]

Tim Cross  writes:

> David Masterson  writes:
>
>> "Michel Schinz"  writes:
>>
>>> Just for the record, I also ran into problems when installing Org 9.6
>>> using Emacs' package system on top of an older version that came with
>>> Emacs. If I tried to install it as usual (M-x list-packages, then
>>> install the package from there), I had errors during compilation related
>>> to `org-assert-version`, and then if I restarted Emacs, I would get a
>>> fatal error in an unrelated package.
>>>
>>> I managed to solve that problem by:
>>> 1. uninstalling Org 9.6 and exiting Emacs,
>>> 2. starting Emacs with -q,
>>> 3. installing Org 9.6 from there (using M-x list-packages as usual),
>>> 4. restarting Emacs.
>>
>> Interesting!  I tried this (essentially) and it worked for my case.  In
>> my case, I had a built-in Org-9.3 and I was trying to use list-packages
>> to install Org-9.6. I checked that using -q still added Org-9.3 to
>> the
>> load-path, but, since Org wasn't loaded, the install via list-packages
>> worked.
>>
>> The question is what's the proper way of doing this without '-q'?

[...]

> I don't think there is any safe way to install an updated version of
> org-mode other than
>
> 1. Use the -q approach outlined above

Thinking about it, this only works if Org is in elpa as melpa (etc.) are
not added to package-archives.  You'd have to do some handwritten elisp
out of *scratch* to setup package-archives if Org-9.6 was still coming
out of melpa. That's why this can only be labeled as a hack and not a
solution.

> 2. Craft your init.el file such that org functionality is only loaded
> when explicitly requested and always update as the first action after
> starting emacs.

In this case, something happened in package-install when trying to
install Org-9.6 with a built-in Org-9.3.  During the compilation check
(.el -> .elc) many files failed because the new 'org-assert-version'
macro was not defined.  Sort of like, after package-install started
working on Org-9.6, org-macs.el (where org-assert-version should be) got
loaded *before* the new load-path had been set causing it to load the
old one from 9.3.  Thereafter, everything went awry. 

> The first approach is actually the easiest. The second is hard to get
> right and very fragile because packages like use-package and more
> specifically, other packages with leverage off org functionality, make it
> impossible to reliably know exactly when org is loaded.

Using ':after" in use-package is supposed to help that, but I'm not sure
it is reliable.  Packages are often incomplete about what other packages
it depends on.

> An approach used by many 'canned' distributions is to postpone package
> updates. You have a function you run to check for updates which
> generates a list of packages to update and writes that list to a
> file. Each time emacs is started, it looks for this update list and if
> it finds it, it installs packages updates at the very beginning of the
> init process (before any of your other init.el code or custom
> blocks). The process also looks for org in the list of packages to
> update and if it is found, updates it first. 

Probably doesn't work in this case as you would need to be able to use
package.el suggesting that the load-path has been updated for all
built-ins already.  The thing I note is that the load-path has already
been updated for built-ins at the beginning of
'~/.emacs.d/early-init.el', but the libraries haven't been loaded yet
(unless needed). That's okay if the newer version of a package then
cleanly replaces all the files in the old version.

> I don't think there is a safe way to load org mode after the init
> process i.e. after booting emacs by M-x package-update.

Where is package-update called in the boot process of emacs?  I don't
see package-update in Emacs v2.7.

> I've had good success using straight.el. I had to be careful regarding
> how I structured my init.el file (ensuring any straight stuff happens
> first and the first use package stanza is for org. The main reason
> straight works well for me is that my work flow is to do a M-x
> straight-pull-all when I want to update my packages. This does a git
> pull for all the sources, but does not do any build/install. This occurs
> when I next start Emacs and because I have all the straight stuff at the
> start and because org mode is the first straight-use-package, the update
> and install happens before any other org functionality is loaded,
> avoiding mixed version issues.

Where do you get straight.el?  I don't see it in [m]elpa.

-- 
David Masterson

[BUG] Setting export scope to subtree not working as expected [9.6 (9.6-gb3da42 @ /Users/apc/.emacs.d/straight/build/org/)]

[Alejandro Pérez Carballo]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


If point is on a heading followed by a subheading without any text in between, 
the export process is using the tree starting with the subheading instead of 
the tree starting from point position. If instead you have some text after the 
first heading and before the subheading, the tree that is exported is the tree 
starting from point position, as expected. I’m assuming this is a bug, but 
maybe I’m missing something.

For example, take a buffer containing just this:

   * The title
   ** A subtitle
   Some text

If I export this to an HTML buffer, with point at the beginning of the first 
line and  after setting the scope to ‘subtree’, I get an HTML buffer whose 
title is “A subtitle”.

If I follow the same steps on a buffer containing just this: 

   * The title
   Some text
   ** A subtitle

I get an HTML buffer whose title is “The title”.

This doesn’t happen with Org 9.5.5. In both cases, I get what I expect, viz. an 
HTML buffer whose title is “The title”.

I can reproduce this with the following minimal configuration:

I can reproduce this behavior with the following minimal config:

   (setq straight-check-for-modifications '(check-on-save find-when-checking))

   (defvar bootstrap-version)
   (let ((bootstrap-file
 (expand-file-name "straight/repos/straight.el/bootstrap.el" 
user-emacs-directory))
 (bootstrap-version 5))
 (unless (file-exists-p bootstrap-file)
   (with-current-buffer
   (url-retrieve-synchronously
   
"https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el;
   'silent 'inhibit-cookies)
 (goto-char (point-max))
 (eval-print-last-sexp)))
 (load bootstrap-file nil 'nomessage))

   (setq-default use-package-enable-imenu-support t)
   (setq straight-use-package-by-default t)
   (straight-use-package 'use-package)
   (setq use-package-verbose nil
 use-package-compute-statistics t
 use-package-expand-minimally t
 use-package-always-defer t)

   (straight-register-package 'org)

   (use-package org
 :ensure t)



Emacs  : GNU Emacs 28.2 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.60 
Version 12.5 (Build 21G72))
of 2022-09-15
Package: Org mode version 9.6 (9.6-gb3da42 @ 
/Users/apc/.emacs.d/straight/build/org/)

Re: Multiple versions of Org in load-path problem

[Tim Cross]

David Masterson  writes:

> Adding this to bug #59882
>
> "Michel Schinz"  writes:
>
>> Just for the record, I also ran into problems when installing Org 9.6
>> using Emacs' package system on top of an older version that came with
>> Emacs. If I tried to install it as usual (M-x list-packages, then
>> install the package from there), I had errors during compilation related
>> to `org-assert-version`, and then if I restarted Emacs, I would get a
>> fatal error in an unrelated package.
>>
>> I managed to solve that problem by:
>> 1. uninstalling Org 9.6 and exiting Emacs,
>> 2. starting Emacs with -q,
>> 3. installing Org 9.6 from there (using M-x list-packages as usual),
>> 4. restarting Emacs.
>
> Interesting!  I tried this (essentially) and it worked for my case.  In
> my case, I had a built-in Org-9.3 and I was trying to use list-packages
> to install Org-9.6. I checked that using -q still added Org-9.3 to the
> load-path, but, since Org wasn't loaded, the install via list-packages
> worked.
>
> The question is what's the proper way of doing this without '-q'?
>
>> I'm not sure this is related to your problem, or whether that helps (but
>> I hope it does)...
>
> I think it does.
>
> Side note:
>
> In my testing, I found a strange case where, in *scratch*, I get:
>
> (message "%s" org-version)
> ;; Error undefined
> ;; Do 'C-h v org-version'
> (message "%s" org-version)
> 9.3
>
> So, 'describe-variable' on org-version causes Org to be loaded?!?  Why
> do I have a feeling this is related to this bug?

I don't think there is any safe way to install an updated version of
org-mode other than

1. Use the -q approach outlined above

2. Craft your init.el file such that org functionality is only loaded
when explicitly requested and always update as the first action after
starting emacs.

The first approach is actually the easiest. The second is hard to get
right and very fragile because packages like use-package and more
specifically, other packages with leverage off org functionality, make it
impossible to reliably know exactly when org is loaded.

An approach used by many 'canned' distributions is to postpone package
updates. You have a function you run to check for updates which
generates a list of packages to update and writes that list to a
file. Each time emacs is started, it looks for this update list and if
it finds it, it installs packages updates at the very beginning of the
init process (before any of your other init.el code or custom
blocks). The process also looks for org in the list of packages to
update and if it is found, updates it first. 

I don't think there is a safe way to load org mode after the init
process i.e. after booting emacs by M-x package-update.

I've had good success using straight.el. I had to be careful regarding
how I structured my init.el file (ensuring any straight stuff happens
first and the first use package stanza is for org. The main reason
straight works well for me is that my work flow is to do a M-x
straight-pull-all when I want to update my packages. This does a git
pull for all the sources, but does not do any build/install. This occurs
when I next start Emacs and because I have all the straight stuff at the
start and because org mode is the first straight-use-package, the update
and install happens before any other org functionality is loaded,
avoiding mixed version issues.

Re: Multiple versions of Org in load-path problem

[David Masterson]

Adding this to bug #59882

"Michel Schinz"  writes:

> Just for the record, I also ran into problems when installing Org 9.6
> using Emacs' package system on top of an older version that came with
> Emacs. If I tried to install it as usual (M-x list-packages, then
> install the package from there), I had errors during compilation related
> to `org-assert-version`, and then if I restarted Emacs, I would get a
> fatal error in an unrelated package.
>
> I managed to solve that problem by:
> 1. uninstalling Org 9.6 and exiting Emacs,
> 2. starting Emacs with -q,
> 3. installing Org 9.6 from there (using M-x list-packages as usual),
> 4. restarting Emacs.

Interesting!  I tried this (essentially) and it worked for my case.  In
my case, I had a built-in Org-9.3 and I was trying to use list-packages
to install Org-9.6. I checked that using -q still added Org-9.3 to the
load-path, but, since Org wasn't loaded, the install via list-packages
worked.

The question is what's the proper way of doing this without '-q'?

> I'm not sure this is related to your problem, or whether that helps (but
> I hope it does)...

I think it does.

Side note:

In my testing, I found a strange case where, in *scratch*, I get:

(message "%s" org-version)
;; Error undefined
;; Do 'C-h v org-version'
(message "%s" org-version)
9.3

So, 'describe-variable' on org-version causes Org to be loaded?!?  Why
do I have a feeling this is related to this bug?

-- 
David Masterson

RE: Multiple versions of Org in load-path problem

[Cook, Malcolm]

>Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> I went so far as to add the following to early-init.el:
>>>
>>> (if (featurep 'org) (unload-feature 'org))
>>> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
>>> (load-library "org")
>>>
>>> The load-library still fails with the org-assert-version error.
>>
>> Indeed. It is to be expected. M-x package-install should not err here
>> though. In theory.
>
>My testing says that, in early-init.el, Org is not yet a feature, so the
>built-in Org-9.3 is not yet loaded and the first 'if' fails. Adding the
>path for Org-9.6 should put it at the front of the load-path and
>(hopefully) override Org-9.3 if it is in the load-path (I think I
>checked that). The error in the load-library is, therefore, a problem
>with Org-9.6 installed by package-install. 
>
>> I suggest you to read `org-assert-version'. It aims to catch the
>> situation above and similar.
>
>This is chicken and egg problem. I can't use 'org-assert-version'
>unless I can get Org to load.
>
>> Note, however, that installation problem is different. Or rather it
>> should be different.
>>
>>> Could it be that, when you package-install Org-9.6, it runs through a
>>> check where (I think) it compiles the package? I get a lot of warnings
>>> and 34(?) failed files. Could it be that some of the files are not
>>> built and, so, when I load-library, I'm picking up some of the wrong
>>> files from the built-in Org-9.3? Do we need to remove all versions of
>>> Org that is not the current version from the load-path at the very
>>> beginning of org.el to ensure no fall-through? Kind of a hack, but...

Hi,

I've been reading along as I've been similarly hounded in years past with org 
version changes.

It really sounds like you compiled org-9.6 with Org-9.3 already loaded.

I'd recommend reinstalling.

Here is one way to do it that is pretty safe:

> emacs -Q -batch -eval "(progn (require 'package) (package-initialize) 
 (package-refresh-contents) (package-install 'org))"

If after doing this, and running emacs, you find M-x org-version does not 
return 9.6, or you find the package assert problem, I'd try the more paranoid:
> emacs -Q -batch -eval "(progn (require 'cl-seq) (delete (car 
(cl-member "lisp/org" load-path :test  #'string-match)) load-path) (require 
'package) (package-initialize)  (package-refresh-contents) (package-install 
'org))"

And possibly consider adding to your init.el at the very top:

(require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test  
#'string-match)) load-path)

YMMV,

~ Malcolm

>>
>> Maybe. It should not. That's why I raised
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>> I'd like to see if Emacs devs have anything to say here.
>
>Good. I'm not used to bug reporting in Emacs, so I raised a question on
>use-package in mailto:emacs-de...@gnu.org, but they pointed me at your bug.
>I'll see if I can add anything there.
>
>-- 
>David Masterson
>

Re: Multiple versions of Org in load-path problem

[Michel Schinz]

Just for the record, I also ran into problems when installing Org 9.6
using Emacs' package system on top of an older version that came with
Emacs. If I tried to install it as usual (M-x list-packages, then
install the package from there), I had errors during compilation related
to `org-assert-version`, and then if I restarted Emacs, I would get a
fatal error in an unrelated package.

I managed to solve that problem by:
1. uninstalling Org 9.6 and exiting Emacs,
2. starting Emacs with -q,
3. installing Org 9.6 from there (using M-x list-packages as usual),
4. restarting Emacs.

I'm not sure this is related to your problem, or whether that helps (but
I hope it does)...

Michel.

On Thu, 8 Dec 2022, at 19:24, David Masterson wrote:
> Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> I went so far as to add the following to early-init.el:
>>>
>>> (if (featurep 'org) (unload-feature 'org))
>>> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
>>> (load-library "org")
>>>
>>> The load-library still fails with the org-assert-version error.
>>
>> Indeed. It is to be expected. M-x package-install should not err here
>> though. In theory.
>
> My testing says that, in early-init.el, Org is not yet a feature, so the
> built-in Org-9.3 is not yet loaded and the first 'if' fails. Adding the
> path for Org-9.6 should put it at the front of the load-path and
> (hopefully) override Org-9.3 if it is in the load-path (I think I
> checked that).  The error in the load-library is, therefore, a problem
> with Org-9.6 installed by package-install. 
>
>> I suggest you to read `org-assert-version'. It aims to catch the
>> situation above and similar.
>
> This is chicken and egg problem.  I can't use 'org-assert-version'
> unless I can get Org to load.
>
>> Note, however, that installation problem is different. Or rather it
>> should be different.
>>
>>> Could it be that, when you package-install Org-9.6, it runs through a
>>> check where (I think) it compiles the package?  I get a lot of warnings
>>> and 34(?) failed files.  Could it be that some of the files are not
>>> built and, so, when I load-library, I'm picking up some of the wrong
>>> files from the built-in Org-9.3?  Do we need to remove all versions of
>>> Org that is not the current version from the load-path at the very
>>> beginning of org.el to ensure no fall-through?  Kind of a hack, but...
>>
>> Maybe. It should not. That's why I raised
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>> I'd like to see if Emacs devs have anything to say here.
>
> Good. I'm not used to bug reporting in Emacs, so I raised a question on
> use-package in emacs-de...@gnu.org, but they pointed me at your bug.
> I'll see if I can add anything there.
>
> -- 
> David Masterson

Re: Multiple versions of Org in load-path problem

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> I went so far as to add the following to early-init.el:
>>
>> (if (featurep 'org) (unload-feature 'org))
>> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
>> (load-library "org")
>>
>> The load-library still fails with the org-assert-version error.
>
> Indeed. It is to be expected. M-x package-install should not err here
> though. In theory.

My testing says that, in early-init.el, Org is not yet a feature, so the
built-in Org-9.3 is not yet loaded and the first 'if' fails. Adding the
path for Org-9.6 should put it at the front of the load-path and
(hopefully) override Org-9.3 if it is in the load-path (I think I
checked that).  The error in the load-library is, therefore, a problem
with Org-9.6 installed by package-install. 

> I suggest you to read `org-assert-version'. It aims to catch the
> situation above and similar.

This is chicken and egg problem.  I can't use 'org-assert-version'
unless I can get Org to load.

> Note, however, that installation problem is different. Or rather it
> should be different.
>
>> Could it be that, when you package-install Org-9.6, it runs through a
>> check where (I think) it compiles the package?  I get a lot of warnings
>> and 34(?) failed files.  Could it be that some of the files are not
>> built and, so, when I load-library, I'm picking up some of the wrong
>> files from the built-in Org-9.3?  Do we need to remove all versions of
>> Org that is not the current version from the load-path at the very
>> beginning of org.el to ensure no fall-through?  Kind of a hack, but...
>
> Maybe. It should not. That's why I raised
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
> I'd like to see if Emacs devs have anything to say here.

Good. I'm not used to bug reporting in Emacs, so I raised a question on
use-package in emacs-de...@gnu.org, but they pointed me at your bug.
I'll see if I can add anything there.

-- 
David Masterson

Re: Pasting an image with org-download in org-capture buffer

[Max Nikulin]

On 08/12/2022 22:12, Alexei Gilev wrote:


However, org-capture buffers are indirect buffers, so the 
|buffer-file-name is nil, so it fails.|


Org sources are full of

(buffer-file-name (buffer-base-buffer))

expressions. Unfortunately there are enough bugs due to direct usage of 
`buffer-file-name' as well.


You might be interested in org-attach as an alternative (I do not have a 
ready to use recipe for your particular task), but recently added 
`org--confirm-resource-safe' is affected by this kind of bugs.

Re: Images generated by R code blocks do not display

[William Denton]

On 8 December 2022, Ihor Radchenko wrote:


I now reported this to Emacs upstream.
I do not see anything wrong on Org side in this case.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59902


Thanks for reporting this there.  I like how you simplified the bug example with 
the two images, so nothing needs to be generated on the fly.


As a reminder for anyone else having this problem, where updated images don't 
appear, this will refresh them:


M-: (clear-image-cache)


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

How to prevent emacs from asking “file is read only on disk make buffer read only, too?”

[Alexei Gilev]

Basically that :) This comes up in helm-ag searches a lot. Very annoying!
Thank you!
A.

Pasting an image with org-download in org-capture buffer

[Alexei Gilev]

Hi,

I'm pretty sure somebody must have come with a solution for this basic task.

I want to paste a screenshot while in org-capture buffer.

However, org-download takes saves the screenshot image in a (already
existing otherwise created) folder with the same name as the buffer the
org-capture will save the text into.

However, org-capture buffers are indirect buffers, so the buffer-file-name
is nil, so it fails.

How is it possible to tell Emacs to get this info from the org-capture
buffer rule itself? How to get this path and save the images while in the
org-capture indirect buffer?

The other solution is just to capture, and then open it and paste the
image, but that defeats the purpose of the org-capture buffer itself.

Thanks so much in advance,

A.

Re: Flyspell causes severe slowdown when manipulating footnotes

[arozbiz]

Thanks Ihor for the response. Unfortunately, setting
org-element--cache-self-verify to nil didn't work. Profile report attached.

On Wed, Dec 7, 2022 at 7:23 AM Ihor Radchenko  wrote:

> aroz...@gmail.com writes:
>
> > I just upgraded to Org 9.6 and I've noticed that having flyspell-mode
> > turned on causes very large slowdowns when adding or deleting footnotes
> in
> > an org file with lots of footnotes (e.g., more than 200, which is common
> > for the academic articles that I use org for). Any ideas for what might
> be
> > causing this?
>
> Most likely cache updates.
> Could you please (1) Set org-element--cache-self-verify to nil and see
> if things get back to normal; (2) If things are still slow after setting
> the variable, please run M-x profiler-start ... M-x profiler-report and
> share the data. See https://orgmode.org/list/87ee2nlslt.fsf@localhost.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

[profiler-profile "28.1" cpu #s(hash-table size 217 test equal rehash-size 1.5 
rehash-threshold 0.8125 data ([nil nil nil nil nil nil nil nil nil nil nil nil 
nil nil nil nil] 37 [if "#" funcall let wc-count 
let* wc-mode-update setq progn if when "#" apply 
timer-event-handler nil nil] 131 ["#" funcall let 
wc-count let* wc-mode-update setq progn if when "#" apply 
timer-event-handler nil nil nil] 3 ["#" nil nil 
nil nil nil nil nil nil nil nil nil nil nil nil nil] 3 [file-truename 
file-truename file-truename file-truename org-roam-descendant-of-p 
org-roam-file-p org-roam-buffer-p if let azr/tab-bar-tab-name-current 
tab-bar-tabs tab-bar--current-tab-index doom-modeline-segment--workspace-name 
eval redisplay_internal\ \(C\ function\) nil] 3 [file-truename file-truename 
org-roam-descendant-of-p org-roam-file-p org-roam-buffer-p if let 
azr/tab-bar-tab-name-current tab-bar-tabs tab-bar--current-tab-find 
tab-bar--current-tab doom-modeline-segment--workspace-name eval 
redisplay_internal\ \(C\ function\) nil nil] 4 [file-relative-name 
org-roam-file-p org-roam-buffer-p if let azr/tab-bar-tab-name-current 
tab-bar-tabs tab-bar--current-tab-index doom-modeline-segment--workspace-name 
eval redisplay_internal\ \(C\ function\) nil nil nil nil nil] 3 
[doom-modeline-format--main eval redisplay_internal\ \(C\ function\) nil nil 
nil nil nil nil nil nil nil nil nil nil nil] 5 [org-roam-descendant-of-p 
org-roam-file-p org-roam-buffer-p if let azr/tab-bar-tab-name-current 
tab-bar--current-tab-make tab-bar--current-tab 
doom-modeline-segment--workspace-name eval redisplay_internal\ \(C\ function\) 
nil nil nil nil nil] 3 [org-roam-file-p org-roam-buffer-p if let 
azr/tab-bar-tab-name-current tab-bar--current-tab-make tab-bar--current-tab 
doom-modeline-segment--workspace-name eval redisplay_internal\ \(C\ function\) 
nil nil nil nil nil nil] 3 [org-roam-descendant-of-p org-roam-file-p 
org-roam-buffer-p if let azr/tab-bar-tab-name-current tab-bar-tabs 
tab-bar--current-tab-index doom-modeline-segment--workspace-name eval 
redisplay_internal\ \(C\ function\) nil nil nil nil nil] 3 
[org-roam-descendant-of-p org-roam-file-p org-roam-buffer-p if let 
azr/tab-bar-tab-name-current tab-bar-tabs tab-bar--current-tab-find 
tab-bar--current-tab doom-modeline-segment--workspace-name eval 
redisplay_internal\ \(C\ function\) nil nil nil nil] 3 ["#" org-element--parse-to org-element-at-point 
org-element-context org-footnote-action funcall-interactively command-execute 
nil nil nil nil nil nil nil nil nil] 4 [org-element-entity-parser 
org-element--object-lex org-element-context org-footnote-all-labels 
org-footnote-new org-footnote-action funcall-interactively command-execute nil 
nil nil nil nil nil nil nil] 4 [org-element-context org-footnote-all-labels 
org-footnote-new org-footnote-action funcall-interactively command-execute nil 
nil nil nil nil nil nil nil nil nil] 54 [org-footnote-new org-footnote-action 
funcall-interactively command-execute nil nil nil nil nil nil nil nil nil nil 
nil nil] 3 [rx--every rx--translate-or rx--translate-form rx--translate 
rx--translate-seq rx--translate-form rx--translate rx-to-string 
org-element--parse-generic-emphasis org-element-italic-parser 
org-element--object-lex org-element-context org-footnote-all-labels 
org-footnote-new org-footnote-action funcall-interactively] 3 
[org-element-at-point org-element-context org-footnote-all-labels 
org-footnote-new org-footnote-action funcall-interactively command-execute nil 
nil nil nil nil nil nil nil nil] 6 [org-element-footnote-reference-parser 
org-element--object-lex org-element-context org-footnote-all-labels 
org-footnote-new org-footnote-action funcall-interactively command-execute nil 
nil nil nil nil nil nil nil] 3 [font-lock-extend-jit-lock-region-after-change 
jit-lock-after-change org-footnote-new org-footnote-action 

Re: Macro: exporting roman numerals formatted as small-caps

[Max Nikulin]

On 08/12/2022 19:38, Carlos Martínez wrote:


#+MACRO: sc (eval (if (org-export-derived-backend-p
org-export-current-backend 'latex) (concat "@@latex:\\textsc{@@" $1
"@@latex:}@@") (concat "@@odt:@@"$1"@@odt:@@")))


   ^  ^
Your missed spaces around $1, but it is unlikely a problem.

Disclaimer: I know almost nothing about odt. Have you customized ODT 
styles? I do not see "T1" in etc/styles/OrgOdtStyles.xml


info "(org) Advanced topics in ODT export"
https://orgmode.org/manual/Advanced-topics-in-ODT-export.html


I want to achieve something like this: "When exporting to LaTeX (o
derived formats), surround the argument with \textsc{}; if any other
format [it will always be odt], do the same with the proper odt code.


I recommend fallback to the argument as plain text for other backends:

(cond
 ((org-export-derived-backend-p org-export-current-backend 'latex)
  (concat ; or format
  ))
 ((org-export-derived-backend-p org-export-current-backend 'odt)
  ; ...
  ))
 (t $1))

If you are absolutely sure that you will never export the file to ascii 
or html then no `eval' is necessary


#+MACRO: sc @@latex:\textsc{$1}odt:text:style-name="T1">$1@@


Here I assume that macro argument contains no markup and can be safely 
put inside export snippets. Otherwise a bit longer version closer to 
`concat' arguments in your original variant would be better.


Another point is the name. Small caps as "sc" means direct formatting. A 
name based on "roman number" might be better. If some other objects 
should be formatted as small caps then creating another macro might help 
to change styles independently later.

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Greg Minshall]

Ihor,

> The time span is years and I do not recall any related bug reports.
> So, nobody seems to care.

:)

Re: [PATCH] lisp/ox-latex.el: put labels inside example blocks

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Please, revert this patch. Default environment for #+begin_example is 
>> verbatim. With this patch the following PDF is generated
>>
>>  \label{org9283054}
>>  code
>>
>> for
>>
>>  #+name: test
>>  #+begin_example
>>code
>>  #+end_example
>>
>> It is the reason why \label must be outside. I do not remember if line 
>> break penalty helps after \label.
>
> Oops. You are indeed right.
> Reverted.

Hugo, you may consider writing an alternative patch that only puts label
inside for the environments where we know that it is safe.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Greg Minshall  writes:

>> Does it make sense from the point of view of R code?
>> AFAIU, the current ob-R implementation converts lists into R tables,
>> which is not accurate? Would it make sense to convert Elisp lists into R
>> lists directly?
>
> my "barely half a cent" would be that backwards compatibility here
> trumps, hmm, "logic".  i suspect a note in the wiki page for ob-R
> stating that lists are converted to single-column tables would be
> sufficient.  (partly because i think people writing code need to refer
> to such pages to understand these sorts of mappings.)
>
> (one could make the case that "no one" passes lists to R code; that
> could push *me* towards your suggestion.)

Once upon a time, ob-core converted lists to actual lists. It is what is
reflected in the manual.

Later, the code was changed and lists were interpreted as lists of
lists.

Now, I reverted to the original behaviour.

The time span is years and I do not recall any related bug reports.
So, nobody seems to care.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/ox-latex.el: put labels inside example blocks

[Ihor Radchenko]

Max Nikulin  writes:

>> Applied onto bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=304f18cb7
>
> Please, revert this patch. Default environment for #+begin_example is 
> verbatim. With this patch the following PDF is generated
>
>  \label{org9283054}
>  code
>
> for
>
>  #+name: test
>  #+begin_example
>code
>  #+end_example
>
> It is the reason why \label must be outside. I do not remember if line 
> break penalty helps after \label.

Oops. You are indeed right.
Reverted.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Greg Minshall]

Ihor,

> Does it make sense from the point of view of R code?
> AFAIU, the current ob-R implementation converts lists into R tables,
> which is not accurate? Would it make sense to convert Elisp lists into R
> lists directly?

my "barely half a cent" would be that backwards compatibility here
trumps, hmm, "logic".  i suspect a note in the wiki page for ob-R
stating that lists are converted to single-column tables would be
sufficient.  (partly because i think people writing code need to refer
to such pages to understand these sorts of mappings.)

(one could make the case that "no one" passes lists to R code; that
could push *me* towards your suggestion.)

cheers, Greg

Macro: exporting roman numerals formatted as small-caps

[Carlos Martínez]

Hello everyone!,
I am working in a paper written in org mode. There are lots of roman
numerals referring to centuries. In Spanish, those are written in
roman numerals and small caps. I want to export my paper both to odt
and to LaTeX.

I found a macro by Juan Manuel Macías which helped me to export the
numerals surrounded by \textsc{} when exporting to pdf, but I struggle
to do the same when exporting to odt. This is the macro:

#+MACRO: sc (eval (if (org-export-derived-backend-p
org-export-current-backend 'latex) (concat "@@latex:\\textsc{@@" $1
"@@latex:}@@") (concat "@@odt:@@"$1"@@odt:@@")))

I want to achieve something like this: "When exporting to LaTeX (o
derived formats), surround the argument with \textsc{}; if any other
format [it will always be odt], do the same with the proper odt code.

Thanks everyone, and my apologies if this is a noob question (but I am
actually a noob).
Best regards
N.B.: I extracted the odt snippet looking at the contents.xml inside
the odt file.

Re: [PATCH] lisp/ox-latex.el: put labels inside example blocks

[Max Nikulin]

On 08/12/2022 18:39, Ihor Radchenko wrote:

h...@heagren.com writes:

The attached patch forces example environments to be printed thus:

,---
|  \begin{example}\label{ex:foo}
| My example here
|  \end{example}
`---


Applied onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=304f18cb7


Please, revert this patch. Default environment for #+begin_example is 
verbatim. With this patch the following PDF is generated


\label{org9283054}
code

for

#+name: test
#+begin_example
  code
#+end_example

It is the reason why \label must be outside. I do not remember if line 
break penalty helps after \label.

Re: [PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats

[Ihor Radchenko]

Tom Gillespie  writes:

> Hi,
>Here is a patch for org-contrib/lisp/org-expiry.el to account for
> recent changes to org-time-stamp-formats. Best,
> Tom
>
> PS is this list still the best place to send org-contrib patches?

Yes, this list is suitable as long as org-expiry is orphaned.

For the patch, note that it is not a good idea to bump the minimal
required Org version of Org 9.6. I'd rather suggest keeping backwards
compatibility by stripping "<" and ">" from org-time-stamp-formats, if
any. That will not affect existing users of older Emacs versions and
built-in Org.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/ox-latex.el: put labels inside example blocks

[Ihor Radchenko]

h...@heagren.com writes:

> The attached patch forces example environments to be printed thus:
>
> ,---
> |  \begin{example}\label{ex:foo}
> | My example here
> |  \end{example}
> `---
>
> This solves the problem.
>
> The logic/conditions for when to print a label, and how it is generated
> remain unchanged.
>
> Hope this is helpful for someone else too!

Thanks!
Applied onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=304f18cb7

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Images generated by R code blocks do not display

[Ihor Radchenko]

William Denton  writes:

>> Could you please confirm?
>
> Confirmed!

I now reported this to Emacs upstream.
I do not see anything wrong on Org side in this case.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59902

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Multiple versions of Org in load-path problem

[Ihor Radchenko]

David Masterson  writes:

> I have to play with the solution I suggested.  I'm beginning to wonder
> if it will cause other problems with (seeming) Org dependent packages.
> In my case, the error I get is from various use-package calls --
> something like "Error: org-assert-version is not known".  This is
> confusing because I've arranged my .emacs as (almost) an alphabetical
> loading of the packages and some of the use-package errors are coming
> from packages loaded before Org.  IOW, org-assert-version from 9.6
> shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
> what's referring to org-assert-version?

If you install Org via package-install (or :ensure t), Org 9.6 should
get loaded once package system is initialized. Emacs should correctly
put ELPA's version of Org in from of the load-path. However, it looks
like Org 9.6 compilation is off and `org-assert-version' macro is
compiled as a function call instead of a macro.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Jeremie Juste  writes:

> Many thanks to you all for your feedback.
> From 1ad16ffb9, I have restored the expected output in R. that is.
>
>
> #+NAME: example-list
> - simple
>   - not
>   - nested
> - list
>
> #+BEGIN_SRC R :var x=example-list
> x
> #+END_SRC
>
> #+RESULTS:
> | simple |
> | list   |

I am not sure if I like the approach you used in the commit.

-(unless (listp (car value)) (setq value (list value)))
+(unless (listp (car value)) (setq value (mapcar 'list value)))

In the above, you are transforming (val1 val2 val3 ...) list into
((val1) (val2) (val3) ...).

Does it make sense from the point of view of R code?
AFAIU, the current ob-R implementation converts lists into R tables,
which is not accurate? Would it make sense to convert Elisp lists into R
lists directly?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at