Re: [Bug] org-insert-link removes on one link from 2 added by org-store-link

[Samuel Wales]

link has already been stored is a bug in my case in that i can't just
go to a header, grab it [whether rabbed bfere or not] and then paste
it.  i surprise easily when the wrong link gets pasted.

[also the id links with no desc and the prefix links do not help me
find the link i want to insert if it is opne previously.

in answer to a q by ihor, indeed puttig previously stored id liks as
descriptions in front of all the prefixes woudl be useful to me, but
idk who is doing the sorting, so idk whether it wold make a difference
but if it dos then gret..]

it seems org-insert-=inki is overloaded.  one use case says insert a
previously stored link.  the other says insert a brand new link which
i will now specify.  might it be useful to separate those two
functions?

On 7/12/23, Max Nikulin  wrote:
> On 02/07/2023 14:49, Ihor Radchenko wrote:
>> Max Nikulin  writes:
>>> M-x org-store-link adds 2 entries:
>>> - [[*title][title]]
>>> - [[#a-heading][title]]
>>>
>>> however `org-insert-link' (C-c C-l) removes from the stored link only
>>> one of them. As a result the number of unused stored links increases
>>> during an Emacs session.
>> Confirmed.
>> Not Urgent.
>
> Agree. I forgot to mention that the "This link has already been stored"
> feature works only for one link from this pair.
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

[PATCH] ob-tangle.el: Blocks overwrite each other when grouping before tangling

[Evgenii Klimov]

And here's the patch to fix it.
>From 2695d48f265a4100a9fc25c4dd278ab2b4b89ba5 Mon Sep 17 00:00:00 2001
From: Evgenii Klimov 
Date: Wed, 12 Jul 2023 19:24:48 +0100
Subject: [PATCH] ob-tangle.el: Avoid relative file names when grouping blocks
 to tangle

* lisp/ob-tangle.el (org-babel-effective-tangled-filename): Avoid
using relative file names that could cause one block to overwrite the
others in `org-babel-tangle-collect-blocks' if they have the same
target file but in different formats.
---
 lisp/ob-tangle.el | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 25129616f..4aab453e3 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -427,17 +427,23 @@ that the appropriate major-mode is set.  SPEC has the form:
 		org-babel-tangle-comment-format-end link-data)
 
 (defun org-babel-effective-tangled-filename (buffer-fn src-lang src-tfile)
-  "Return effective tangled filename of a source-code block.
+  "Return effective tangled absolute filename of a source-code block.
 BUFFER-FN is the name of the buffer, SRC-LANG the language of the
 block and SRC-TFILE is the value of the :tangle header argument,
 as computed by `org-babel-tangle-single-block'."
-  (let ((base-name (cond
-((string= "yes" src-tfile)
- ;; Use the buffer name
- (file-name-sans-extension buffer-fn))
-((string= "no" src-tfile) nil)
-((> (length src-tfile) 0) src-tfile)))
-(ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang)))
+  (let* ((fnd (file-name-directory (buffer-file-name
+(get-buffer buffer-fn
+ (base-name (cond
+ ((string= "yes" src-tfile)
+  ;; Use the buffer name
+  (file-name-concat fnd
+(file-name-sans-extension buffer-fn)))
+ ((string= "no" src-tfile) nil)
+ ((> (length src-tfile) 0)
+  (if (file-name-directory src-tfile)
+  src-tfile
+(file-name-concat fnd src-tfile)
+ (ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang)))
 (when base-name
   ;; decide if we want to add ext to base-name
   (if (and ext (string= "yes" src-tfile))
-- 
2.34.1

[BUG] ob-tangle.el: Blocks overwrite each other when grouping before tangling

[Evgenii Klimov]

Hi, I noticed that during grouping of blocks to tangle some of them can
overwrite each other if they have the same target file, but in different
format (relative vs absolute).

Consider this example (part of example.org file in the attachment):

  * 1st explicit :tangle yes
  #+begin_src emacs-lisp :tangle yes
"1st explicit :tangle yes"
  #+end_src
  * 1st implicit default
  #+begin_src emacs-lisp
"1st implicit :tangle no"
  #+end_src

If we call `org-babel-tangle-file' with target-file arg equal to
"/path/to/example.el" (e.g. `org-babel-load-file' does that), then
target file name for the first block will be "example.el" and
"/path/to/example.el" for the second block. It appears to be crucial in
`org-babel-tangle-collect-blocks' [1]:

  ;; `org-babel-map-src-blocks' runs this part on each source block
  (let* ((block (org-babel-tangle-single-block counter))
 (src-tfile (cdr (assq :tangle (nth 4 block
 (file-name (org-babel-effective-tangled-filename
 (nth 1 block) src-lang src-tfile))
 (by-fn (assoc file-name blocks)))
(if by-fn (setcdr by-fn (cons (cons src-lang block) (cdr by-fn)))
  (push (cons file-name (list (cons src-lang block))) blocks)))

Current implementation of `org-babel-effective-tangled-filename' returns
relative file name if :tangle is "yes" or relative FILENAME. But if
:tangle happened to be absolute (as `org-babel-load-file' does), then
blocks with the same file name but one name is relative while the other is
absolute, will be treated as different and won't be group (see last tree
lines of code above).

As a result when blocks are returned to `org-babel-tangle' [2] one group
will overwrite the previous one, since their absolute file names are
equal.

I noticed two scenarious where such things happen (e.g. if running
`org-babel-tangle-file'):
- if target-file arg is equal to one of :tangle FILENAMEs and some
  blocks don't have :tangle argument, while other have :tangle
  FILENAME. As a result one of these groups will be lost.
- if target-file arg is equal to tangled original Org file and some
  blocks don't have :tangle argument, while other have :tangle
  "yes". As a result one of these groups will also be lost.

I attach example Org file and scratch code to reproduce both scenarious.

[1] [[file:lisp/ob-tangle.el::(file-name 
(org-babel-effective-tangled-filename][target file-name]]

[2] [[file:lisp/ob-tangle.el::org-babel-tangle-collect-blocks lang-re 
tangle-file))][blocks return]]

* 1st explicit :tangle yes
#+begin_src emacs-lisp :tangle yes
  "1st explicit :tangle yes"
#+end_src
* 1st explicit :tangle filename.el
#+begin_src emacs-lisp :tangle filename.el
  "1st explicit :tangle filename.el"
#+end_src
* 1st implicit default
#+begin_src emacs-lisp
  "1st implicit :tangle no"
#+end_src
* 2nd explicit :tangle yes
#+begin_src emacs-lisp :tangle yes
  "2nd explicit :tangle yes"
#+end_src
* explicit :tangle no
#+begin_src emacs-lisp :tangle no
  "explicit :tangle no"
#+end_src
* 2nd explicit :tangle filename.el
#+begin_src emacs-lisp :tangle filename.el
  "2nd explicit :tangle filename.el"
#+end_src
* 2nd implicit default
#+begin_src emacs-lisp
  "2nd implicit :tangle no"
#+end_src


scratch.el
Description: scratch code to reproduce the bug

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Ihor

On 12 Jul 2023, Ihor Radchenko wrote:

[...]

I have recently seen 
https://masto.ai/@rfc1149/110674961710491363 that revealed a 
problem with example from 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org29a742f


Instead of lilypond fragments, full pages are inserted when 
exporting to pdf.


Upon further investigation, it looks like something changed in 
how Lilypond defines page layout.


Can you check if adding:

\version "2.24.1"
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'tall-page-formats 'pdf)

to the version-and-paper block fixes the issue.

Also, I believe tagline = "" is now the only variable needed.

--
Jonathan

Re: [PATCH] ob-python: Fix async evaluation

[Jack Kamm]

Liu Hui  writes:

> OK, I have added a test to the patch.

While your test works on its own, it seems to break subsequent tests
(the next test hangs).

My guess is that it has something to do with the fact that most of the
Python session tests share the same session, and ob-python is getting
confused about which session to use on the next test.

One possible fix might be to kill the Python session started by your new
test, after it's finished running.

(It is probably not the best design that the Python session tests all
share the same session...)

Re: [PATCH] org.el: Remove undefined dynamic variable `org-log-states' from example

[Evgenii Klimov]

Ihor Radchenko  writes:

> It looks like 5 working days have passed since your email to FSF. If so,
> please follow up once and wait another 5 working days.

I've got papers from FSF, signed it and sent it back. It was 6 working
days ago. 5 days that you mention is for the first response from them, I
guess?

[PATCH] testing: Delete duplicate tests

[Ilya Chernyshov]

Hello.

In my last patch, I found a duplicate test, so I decided to find all of
the duplicate tests inside testing/lisp/ folder via this function:

(defun count-duplicate-tests ( directory)
  (let (files)
(dolist (file (directory-files (or directory default-directory) t (rx ".el" 
string-end) t))
  (with-current-buffer (find-file-noselect file)
(save-excursion
  (goto-char (point-min))
  (while (search-forward "(ert-deftest" nil t)
(ignore-errors
  (while-let((form (or (read (current-buffer)) t)))
(when (eq (car-safe form) 'should)
  (setf
   (alist-get form (alist-get file files nil nil #'equal) 0 nil 
#'equal)
   (1+ (alist-get form (alist-get file files nil nil #'equal) 0 
nil #'equal))
(seq-remove
 (lambda(file) (null (cdr file)))
 (mapcar
  (lambda(file)
(cons
 (car file)
 (seq-filter
  (lambda(form) (/= (cdr form) 1))
  (cdr file
  files

(setq dups (count-duplicate-tests "~/org-mode/testing/lisp/"))

Then I checked the result manually and deleted some of them.

Here is the patch I wrote:

>From 21ba128bd648c6737ed088abdd2a1824cfe01759 Mon Sep 17 00:00:00 2001
From: Ilya Chernyshov 
Date: Thu, 13 Jul 2023 01:36:33 +0700
Subject: [PATCH] testing: Delete duplicate tests

* testing/lisp/test-ol.el (test-org-link/store-link): Delete a duplicate test.

* testing/lisp/test-org-clock.el (test-org-clock/clocktable/properties): Delete a duplicate test.

* testing/lisp/test-org-element.el (test-org-element/link-parser,
test-org-element/timestamp-parser): Delete duplicate tests.

* testing/lisp/test-org-table.el (test-org-table/get-field): Delete a duplicate test.

* testing/lisp/test-org.el (test-org/auto-fill-function): Delete a duplicate test.
---
 testing/lisp/test-ol.el  |  8 
 testing/lisp/test-org-clock.el   | 15 ---
 testing/lisp/test-org-element.el | 10 --
 testing/lisp/test-org-table.el   |  4 
 testing/lisp/test-org.el |  8 
 5 files changed, 45 deletions(-)

diff --git a/testing/lisp/test-ol.el b/testing/lisp/test-ol.el
index a38d9f979..70be03818 100644
--- a/testing/lisp/test-ol.el
+++ b/testing/lisp/test-ol.el
@@ -301,14 +301,6 @@ See https://github.com/yantar92/org/issues/4.;
(let ((file (buffer-file-name)))
 	 (equal (format "[[file:%s::two]]" file file)
 		(org-store-link nil))
-  (should
-   (let ((org-stored-links nil)
-	 (org-context-in-file-links t))
- (org-test-with-temp-text-in-file "# two"
-   (fundamental-mode)
-   (let ((file (buffer-file-name)))
-	 (equal (format "[[file:%s::two]]" file file)
-		(org-store-link nil))
   (should
(let ((org-stored-links nil)
 	 (org-context-in-file-links t))
diff --git a/testing/lisp/test-org-clock.el b/testing/lisp/test-org-clock.el
index d40939eb6..16cfc63a5 100644
--- a/testing/lisp/test-org-clock.el
+++ b/testing/lisp/test-org-clock.el
@@ -821,21 +821,6 @@ CLOCK: [2016-12-27 Wed 13:09]--[2016-12-28 Wed 15:09] => 26:00
 :PROPERTIES:
 :A: 1
 :END:
-CLOCK: [2016-12-27 Wed 13:09]--[2016-12-28 Wed 15:09] => 26:00"
-  (test-org-clock-clocktable-contents ":properties (\"A\")"
-  ;; Handle missing properties.
-  (should
-   (equal
-"| A | Headline | Time|
-|---+--+-|
-|   | *Total time* | *26:00* |
-|---+--+-|
-| 1 | Foo  | 26:00   |"
-(org-test-with-temp-text
-"* Foo
-:PROPERTIES:
-:A: 1
-:END:
 CLOCK: [2016-12-27 Wed 13:09]--[2016-12-28 Wed 15:09] => 26:00"
   (test-org-clock-clocktable-contents ":properties (\"A\")")
 
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 2e3a249ab..d95195f0d 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2436,11 +2436,6 @@ e^{i\\pi}+1=0
  (let ((file (expand-file-name (buffer-file-name
(insert (format "[[file:%s]]" file))
(equal (org-element-property :path (org-element-context)) file
-  (should
-   (org-test-with-temp-text-in-file ""
- (let ((file (expand-file-name (buffer-file-name
-   (insert (format "[[file:%s]]" file))
-   (equal (org-element-property :path (org-element-context)) file
   ;; ... multi-line link.
   (should
(equal "ls *.org"
@@ -3195,11 +3190,6 @@ Outside list"
 (org-test-with-temp-text "<2023-07-02 Sun 12:00>--<2023-07-02 Sun 13:00>"
   (org-element-property :range-type (org-element-timestamp-parser)))
 'daterange))
-  (should
-   (eq
-(org-test-with-temp-text "<2023-07-02 Sun 12:00>--<2023-07-02 Sun>"
-  (org-element-property :range-type (org-element-timestamp-parser)))
-'daterange))
   (should
(eq
 (org-test-with-temp-text "<2023-07-02 Sun 12:00 +5d>--<2023-07-02 Sun 13:00>"
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 

Re: [BUG] Incorrect indentation when there are invisible/diplay properties on the line [9.6.7 ( @ /home/huzf/.cache/emacs_configs/default/elpa.28/org-9.6.7/)]

[Ihor Radchenko]

Hammer Hu  writes:

> ** heading
>
>text 1
>
> #+begin_quote
> block
> #+end_quote
>
>text 2
> ---
>
> It makes it easy to copy code snippets from org file without emacs.

Check out org-src-preserve-indentation.

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

Re: [BUG] Incorrect indentation when there are invisible/diplay properties on the line [9.6.7 ( @ /home/huzf/.cache/emacs_configs/default/elpa.28/org-9.6.7/)]

[Hammer Hu]

When indent-region, instead of getting:

---
** heading

   text 1

   #+begin_quote
   block
   #+end_quote

   text 2
---

we allow the it to be:

---
** heading

   text 1

#+begin_quote
block
#+end_quote

   text 2
---

It makes it easy to copy code snippets from org file without emacs. I put
together casual numerical codes with other research records in org files and
have them synced to cloud drive. So sometimes when I need to extract codes from
org files and don't have access to a computer with emacs, I either bear with
messy codes or adjust then manually. Even worse, when python codes is in need,
it would be a disaster.

Best,

-
From: Ihor Radchenko 
Sent: 12.07.2023 08:42
To: Hammer Hu 
Subject: Re: [BUG] Incorrect indentation when there are invisible/diplay 
properties on the line [9.6.7 ( @ 
/home/huzf/.cache/emacs_configs/default/elpa.28/org-9.6.7/)]

Hammer Hu  writes:

> Thanks for your accommodations. Is it possible to introduce a feature to align
> all blocks to the begining to the lines when indenting? I thing it helps when
> copying contents from a org file without emacs installed.

May you elaborate? 

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

Re: [PATCH] org.el: Remove undefined dynamic variable `org-log-states' from example

[Ihor Radchenko]

Evgenii Klimov  writes:

> PS: I didn't add TINYCHANGE since I have reached the contribution
> limit but FSF didn't respond yet.

It looks like 5 working days have passed since your email to FSF. If so,
please follow up once and wait another 5 working days.

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

[BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> I typically use it directly, but if the maintenance burden is
> manageable, I could offer maintenance here, too (once I have the papers
> in place).

I have recently seen https://masto.ai/@rfc1149/110674961710491363 that
revealed a problem with example from
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org29a742f

Instead of lilypond fragments, full pages are inserted when exporting to pdf.

Upon further investigation, it looks like something changed in how
Lilypond defines page layout.

Arne, maybe you can point me in the right direction?

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

Re: [Bug] org-insert-link removes on one link from 2 added by org-store-link

[Max Nikulin]

On 02/07/2023 14:49, Ihor Radchenko wrote:

Max Nikulin  writes:

M-x org-store-link adds 2 entries:
- [[*title][title]]
- [[#a-heading][title]]

however `org-insert-link' (C-c C-l) removes from the stored link only
one of them. As a result the number of unused stored links increases
during an Emacs session.

Confirmed.
Not Urgent.


Agree. I forgot to mention that the "This link has already been stored" 
feature works only for one link from this pair.

Re: [PATCH] Keep the link if the command was cancelled

[Max Nikulin]

On 03/07/2023 22:28, Ihor Radchenko wrote:

If necessary, removing stored links without inserting can be made as an
effect of negative prefix argument in `org-insert-link' or in
`org-insert-all-links'.


I do not think it would be a noticeable improvement. It increases code 
complexity, but `org-insert-link' + `undo' requires the same amount of 
keystrokes.


Maybe I just do not like prefix argument. Instead of triple C-u to keep 
the link I would prefer to be able to activate it from the link prompt 
(something similar to to M-s i switches for incremental search).


It might be more reasonable to have some binding to cancel 
`org-store-links' immediately after this command.

Re: [PATCH] ob-python: Fix async evaluation

[Liu Hui]

Jack Kamm  于2023年7月12日周三 12:51写道：

> The patch looks good, but it would be nice to include a unit test as
> well -- could you update the patch to include one, Liu Hui?

OK, I have added a test to the patch.
From 56fd5e05bc7dc82fb825416100e75663a520 Mon Sep 17 00:00:00 2001
From: Liu Hui 
Date: Wed, 12 Jul 2023 18:07:06 +0800
Subject: [PATCH] ob-python: Fix async evaluation

* lisp/ob-python.el (org-babel-python-async-evaluate-session): Bind
`python-shell-buffer-name' inside the temp buffer.
* testing/lisp/test-ob-python.el (test-ob-python/async-local-python-shell):
Add test.
---
 lisp/ob-python.el  | 47 ++
 testing/lisp/test-ob-python.el | 15 +++
 2 files changed, 40 insertions(+), 22 deletions(-)

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 0e0539d7a..c15d45b96 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -400,28 +400,31 @@ (defun org-babel-python-async-evaluate-session
session (current-buffer)
"ob_comint_async_python_\\(.+\\)_\\(.+\\)"
'org-babel-chomp 'org-babel-python-async-value-callback)
-  (let ((python-shell-buffer-name (org-babel-python-without-earmuffs session)))
-(pcase result-type
-  (`output
-   (let ((uuid (org-id-uuid)))
- (with-temp-buffer
-   (insert (format org-babel-python-async-indicator "start" uuid))
-   (insert "\n")
-   (insert body)
-   (insert "\n")
-   (insert (format org-babel-python-async-indicator "end" uuid))
-   (python-shell-send-buffer))
- uuid))
-  (`value
-   (let ((tmp-results-file (org-babel-temp-file "python-"))
- (tmp-src-file (org-babel-temp-file "python-")))
- (with-temp-file tmp-src-file (insert body))
- (with-temp-buffer
-   (insert (org-babel-python-format-session-value tmp-src-file tmp-results-file result-params))
-   (insert "\n")
-   (insert (format org-babel-python-async-indicator "file" tmp-results-file))
-   (python-shell-send-buffer))
- tmp-results-file)
+  (pcase result-type
+(`output
+ (let ((uuid (org-id-uuid)))
+   (with-temp-buffer
+ (insert (format org-babel-python-async-indicator "start" uuid))
+ (insert "\n")
+ (insert body)
+ (insert "\n")
+ (insert (format org-babel-python-async-indicator "end" uuid))
+ (let ((python-shell-buffer-name
+(org-babel-python-without-earmuffs session)))
+   (python-shell-send-buffer)))
+   uuid))
+(`value
+ (let ((tmp-results-file (org-babel-temp-file "python-"))
+   (tmp-src-file (org-babel-temp-file "python-")))
+   (with-temp-file tmp-src-file (insert body))
+   (with-temp-buffer
+ (insert (org-babel-python-format-session-value tmp-src-file tmp-results-file result-params))
+ (insert "\n")
+ (insert (format org-babel-python-async-indicator "file" tmp-results-file))
+ (let ((python-shell-buffer-name
+(org-babel-python-without-earmuffs session)))
+   (python-shell-send-buffer)))
+   tmp-results-file
 
 (provide 'ob-python)
 
diff --git a/testing/lisp/test-ob-python.el b/testing/lisp/test-ob-python.el
index 7aac87116..14dae0ef5 100644
--- a/testing/lisp/test-ob-python.el
+++ b/testing/lisp/test-ob-python.el
@@ -296,6 +296,21 @@ (ert-deftest test-ob-python/async-output-drawer ()
  (string= (concat src-block result)
   (buffer-string)))
 
+(ert-deftest test-ob-python/async-local-python-shell ()
+  ;; Disable the test on older Emacs as built-in python.el sometimes
+  ;; fail to initialize session.
+  (skip-unless (version<= "28" emacs-version))
+  (when-let ((buf (get-buffer "*Python*")))
+(let (kill-buffer-query-functions)
+  (kill-buffer buf)))
+  (org-test-with-temp-text-in-file
+  "# -*- python-shell-buffer-name: \"Python 3\" -*-
+#+begin_src python :session \"*Python 3*\" :async yes
+1
+#+end_src"
+(run-python nil nil 'hide)
+(should (org-babel-execute-src-block
+
 (provide 'test-ob-python)
 
 ;;; test-ob-python.el ends here
-- 
2.25.1

Re: [BUG] Incorrect indentation when there are invisible/diplay properties on the line [9.6.7 ( @ /home/huzf/.cache/emacs_configs/default/elpa.28/org-9.6.7/)]

[Ihor Radchenko]

Hammer Hu  writes:

> Thanks for your accommodations. Is it possible to introduce a feature to align
> all blocks to the begining to the lines when indenting? I thing it helps when
> copying contents from a org file without emacs installed.

May you elaborate? 

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

Re: [PATCH] ob-python: support header argument `:results file graphics'

[Ihor Radchenko]

Jack Kamm  writes:

> Ihor Radchenko  writes:
>
>> ":results file" imply that results of the code block are written to a file
>> (the file is specified using header args).
>>
>> ":results file link" imply that results of the code block are interpreted
>> as file link. The fact that presence of :file header arg overrides this
>> behaviour is something we may want to reconsider - it is confusing.
>
> I think this is a lot clearer and more intuitive than the current
> behavior, and worth doing.
>
> But it is a breaking change, so it would be good to provide a variable
> to re-enable the previous behavior, for back-compatibility of older
> Org documents.

Not necessarily. We may instead arrange org-lint and possibly ob-core to
throw a warning when an src block uses confusing setting combinations.

Without changing the underlying behaviour.

Basically, discourage using confusing staff.

> In particular, the Worg matplotlib example of ":results file" without
> ":file" header arg is fairly old, and I have a few Org docs using
> ":results file" this way as well. So I would appreciate a
> backwards-compatibility variable if we change this.

We should update the docs to avoid such examples.

> On a related note, I think we should revert most of b088389c6 on
> bugfix branch. That documentation causes more harm than good, and is
> based on some confusion in [1] ("graphics" and "link" are _not_
> equivalent in general).

We should generally rewrite that part of the manual, I think.
My previous message was a tentative outline on how the things should be
presented in the manual.

And I do not think that we should do it on bugfix. It is a non-trivial
change, so it should go on main.

>> Sorry, but I do not fully understand.
>> Generated graphics is not what Org sees as "results of evaluation".
>> I think it is well illustrated by
>>
>>   #+begin_src R :file img.png
>>   hist(rnorm(100))
>>   "img.png is going to contain this string."
>>   #+end_src
>>
>>   #+begin_src R :file img.png :results graphics
>>   hist(rnorm(100))
>>   "But now img.png is going to contain graphics."
>>   #+end_src
>>
>> The latter has nothing to do with block output, which is a string.
>
> IMO block _value_ is string, while block _output_ is string AND
> graphics.

>From the point of view of ob-core.el, the output is stdout.
We even display stderr separately (except sessions, where they are
indistinguishable).

But I can see where the confusion is coming from.
"Output" can mean many things, including stdout, stderr, graphical
display (plot window), a file, a sound, or maybe even interactive
terminal ncurses interface.
I do not have a solid idea how to deal with such confusion on design
level.

> So by my interpretation, ob-R is slightly incorrect in how it handles
> ":results output graphics" vs ":results value graphics".  IMO the more
> technically correct approach is in the ob-python patch that I proposed
> a couple years ago [2], and plan to revisit soon. In that patch,
> ob-python ":results graphics output" will plot from pyplot.gcf(),
> while ":results graphics value" will expect a matplotlib.Figure object
> to be returned for plotting.

Sounds reasonable. Let me know if you need any help along the way.

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

Re: [PATCH] org-element-timestamp-interpreter: Return daterange anyway, if DATERANGE is non-nil

[Ihor Radchenko]

Ilya Chernyshov  writes:

> From 823e7f39d33977854605485fcae814af0a3fdefe Mon Sep 17 00:00:00 2001
> From: Ilya Chernyshov 
> Date: Sat, 18 Feb 2023 14:55:39 +0700
> Subject: [PATCH] lisp/org-element.el: Add new timestamp property :range-type

Thanks!
Applied, onto main, with slight amendments.
I re-filled the modified comment, added a link to this thread, and
mentioned why we need the new property.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c74c4ab18

I also applied the patch for WORG.
https://git.sr.ht/~bzg/worg/commit/1f049c5e

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