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

[Jack Kamm]

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.

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.

> ":results graphics file" imply that graphics generated during code
> block execution is saved to file specified in the :file header args.
> This feature is only available for some backends that can derive
> graphics data from the source block.  When :file is not specified,
> using the actual code block output is confusing, and we may want to
> reconsider this behaviour.

I agree.

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).

> 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.

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.

(Note I do _not_ suggest changing ob-R -- even if my interpretation is
correct, I think that common usage and backwards-compatibility
outweighs strict technical correctness in this case).

[1] https://list.orgmode.org/87fu41zcn2@nicolasgoaziou.fr/
[2] https://list.orgmode.org/87eenpfe77@gmail.com/

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

[Jack Kamm]

Ihor Radchenko  writes:

> Liu Hui  writes:
>
>> To reproduce the bug:
>>
>> 1. create test.org:
>> ──✀──
>> #+begin_src python :session "*Python 3*" :async t
>> 1
>> #+end_src
>>
>> # Local Variables:
>> # python-shell-buffer-name: "Python 3"
>> # End:
>> ──✀──
>>
>> 2. emacs -Q -L  --eval "(require 'ob-python)"
>>
>> 3. Open test.org, then start a python shell with M-x run-python, which
>> should create a buffer named "*Python 3*"
>>
>> 4. Press C-c C-c on the src block. Then an error "No inferior Python
>> process running" is shown.
>
> Confirmed.
> CCing Jack Kamm, the maintainer.

And I can confirm now as well. Thanks for reporting, and for the patch.

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?

Thanks,
Jack

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[M. Pger]

Hi,

I understand better, thanks. Would be a good opportunity for me to (try to) 
contribute; this weekend I will check carefully the link you've sent. I'll keep 
you posted, your assistance would be more than welcome :)

Best,

MP




Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, July 11th, 2023 at 10:14 PM, Ihor Radchenko  
wrote:


> "M. Pger" mp...@protonmail.com writes:
> 
> > Sorry for the possibly silly question, but by '+1', can I understand that 
> > you will implement this feature because you think it is worth it?
> 
> 
> No, it just means that I think that this feature makes sense to be
> implemented. Basically, upvote.
> 
> Whether I am going to implement it myself depends on other users.
> 
> I usually do not put agenda features high in my todo list because
> org-agenda.el is a pain to work with due to obsolete code. But, I will
> re-consider if other people also say that they want this feature.
> 
> [ For context, I currently have 500 feature requests and ideas recorded in
> my notes. And there are also bugs and general maintenance tasks... I have
> to prioritize. ]
> 
> Or maybe someone motivated enough can try to implement it and submit a
> patch (see https://orgmode.org/worg/org-contribute.html). I will then
> provide assistance. (Helping new and returning contributors is certainly
> high in my todo list ;])
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 
> Support Org development at https://liberapay.com/org-mode,
> 
> or support my work at https://liberapay.com/yantar92

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[Ihor Radchenko]

"M. Pger"  writes:

> Sorry for the possibly silly question, but by '+1', can I understand that you 
> will implement this feature because you think it is worth it?

No, it just means that I think that this feature makes sense to be
implemented. Basically, upvote.

Whether I am going to implement it myself depends on other users.

I usually do not put agenda features high in my todo list because
org-agenda.el is a pain to work with due to obsolete code. But, I will
re-consider if other people also say that they want this feature.

[ For context, I currently have 500 feature requests and ideas recorded in
my notes. And there are also bugs and general maintenance tasks... I have
to prioritize. ]

Or maybe someone motivated enough can try to implement it and submit a
patch (see https://orgmode.org/worg/org-contribute.html). I will then
provide assistance. (Helping new and returning contributors is certainly
high in my todo list ;])

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

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[M. Pger]

Hi,

Sorry for the possibly silly question, but by '+1', can I understand that you 
will implement this feature because you think it is worth it?

If this is case, thank you very much; if not, thank you anyway for your work 
with Org-mode!

Note that I was suggesting setting an upper bound, but being able to truncate 
breadcrumbs from both sides would be even nicer^^

Best,

MP

--- Original Message ---
On Tuesday, July 11th, 2023 at 11:30 AM, Ihor Radchenko  
wrote:


> "M. Pger" mp...@protonmail.com writes:
> 
> > Feature request: adjust ~org-agenda-format-item~ to let the user choose the 
> > first level included in breadcrumbs
> 
> 
> +1
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 
> Support Org development at https://liberapay.com/org-mode,
> 
> or support my work at https://liberapay.com/yantar92

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]

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.

Best,

-
From: Ihor Radchenko 
Sent: 11.07.2023 15:07
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:

> Please change bug.el to
>
> (add-hook 'org-mode-hook #'org-modern-mode)
> (setq-default org-adapt-indentation t)
>
> Select the region and M-x indent-region  multiple times.

Thanks!

A simpler reproducer:

1. /tmp/bug.org

#+begin_quote
foo
#+end_quote

2. emacs -Q -L /path/to/compat/ -L /path/to/org-modern/ -l compat -l org-modern 
/tmp/bug.org

3. M-x org-modern-mode

4. Move to the beginning of #+begin_quote line

5. M-: (indent-line-to 3) 
6. M-: (indent-line-to 3) 
7. 

8. M-x org-modern-mode
9. Observe overindentation

The reason why this happens is the following:

1. indent-line-to tries hard to create indentation and move the
   beginning of visible text to column 3.
2. indent-line-to notices (at point (5)) that line is not indented at
   all.
3. It computes that it should insert "   " to indent to column 3 and
   inserts these spaces.
4. org-modern-mode notices modification and re-hides spaces
5. indent-line-to is fires one more time at point (6)
6. indent-line-to notices that line is indented, but the leading
   whitespace is invisible.
7. It computes that it should yet insert extra "" to move the text
   to column 3 visually (because the existing spaces are hidden).
8. It inserts the extra spaces
9. org-modern-mode notices modification and re-hides added spaces.

I believe that it is org-modern's fault. Indentation works are it
supposed to and tried hard to align text visually to third column.
org-modern fights against.

Note that indenting visually is Emacs' convention that applies
everywhere.

Canceled.
Not an Org mode bug.

-- 
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/)]

[Ihor Radchenko]

Hammer Hu  writes:

> Please change bug.el to
>
> (add-hook 'org-mode-hook #'org-modern-mode)
> (setq-default org-adapt-indentation t)
>
> Select the region and M-x indent-region  multiple times.

Thanks!

A simpler reproducer:

1. /tmp/bug.org

#+begin_quote
foo
#+end_quote

2. emacs -Q -L /path/to/compat/ -L /path/to/org-modern/ -l compat -l org-modern 
/tmp/bug.org

3. M-x org-modern-mode

4. Move to the beginning of #+begin_quote line

5. M-: (indent-line-to 3) 
6. M-: (indent-line-to 3) 
7. 

8. M-x org-modern-mode
9. Observe overindentation

The reason why this happens is the following:

1. indent-line-to tries hard to create indentation and move the
   beginning of visible text to column 3.
2. indent-line-to notices (at point (5)) that line is not indented at
   all.
3. It computes that it should insert "   " to indent to column 3 and
   inserts these spaces.
4. org-modern-mode notices modification and re-hides spaces
5. indent-line-to is fires one more time at point (6)
6. indent-line-to notices that line is indented, but the leading
   whitespace is invisible.
7. It computes that it should yet insert extra "" to move the text
   to column 3 visually (because the existing spaces are hidden).
8. It inserts the extra spaces
9. org-modern-mode notices modification and re-hides added spaces.

I believe that it is org-modern's fault. Indentation works are it
supposed to and tried hard to align text visually to third column.
org-modern fights against.

Note that indenting visually is Emacs' convention that applies
everywhere.

Canceled.
Not an Org mode bug.

-- 
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]

Please change bug.el to

(add-hook 'org-mode-hook #'org-modern-mode)
(setq-default org-adapt-indentation t)

Select the region and M-x indent-region  multiple times.

Best,

-
From: Ihor Radchenko 
Sent: 11.07.2023 13:22
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/)]

[ Adding Org mailing list back to CC. Please use "reply all" ]

Hammer Hu  writes:

> I tried on the latest version, but the problem persists:
>
> Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.38, cairo version 1.17.8)
>  of 2023-07-11
> Package: Org mode version 9.6.6 (release_9.6.6 @ 
> /usr/share/emacs/30.0.50/lisp/org/)

Sorry, but I am unable to reproduce.

I tried the following:

1. Create /tmp/bug.org

** A level-2 heading
something

something

#+begin_quote
a block
#+end_quote

and something

2. Create bug.el

(add-hook 'org-mode-hook #'org-indent-mode)
(add-hook 'org-mode-hook #'org-modern-mode)


3. emacs -Q -L /path/to/compat/ -L /path/to/org-modern/ -l compat -l org-modern 
-l /tmp/bug.el /tmp/bug.org

4. Select region containing the code block
5. M-x indent-region 
6. Nothing happens

I tried emacs master, emacs 28, and emacs 27.

Please, provide more detailed reproducer.

-- 
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/)]

[Ihor Radchenko]

[ Adding Org mailing list back to CC. Please use "reply all" ]

Hammer Hu  writes:

> I tried on the latest version, but the problem persists:
>
> Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.38, cairo version 1.17.8)
>  of 2023-07-11
> Package: Org mode version 9.6.6 (release_9.6.6 @ 
> /usr/share/emacs/30.0.50/lisp/org/)

Sorry, but I am unable to reproduce.

I tried the following:

1. Create /tmp/bug.org

** A level-2 heading
something

something

#+begin_quote
a block
#+end_quote

and something

2. Create bug.el

(add-hook 'org-mode-hook #'org-indent-mode)
(add-hook 'org-mode-hook #'org-modern-mode)


3. emacs -Q -L /path/to/compat/ -L /path/to/org-modern/ -l compat -l org-modern 
-l /tmp/bug.el /tmp/bug.org

4. Select region containing the code block
5. M-x indent-region 
6. Nothing happens

I tried emacs master, emacs 28, and emacs 27.

Please, provide more detailed reproducer.

-- 
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

[Ilya Chernyshov]

Ihor Radchenko  writes:

> The patch looks good in general, but there is at least one test failing
> when I run make test. May you please check?

Inside `org-timestamp-split-range', there was an attempt to intepret a
timestamp object with :type `active'/`inactive' and :range-type
`daterange'/`timerange' which caused an error. Fixed by setting
:range-type to nil before `(org-element-interpret-data split-ts)'.


> Also, see the attached diff where I suggest some comments to explain the
> code logic.

Looks good to me, I just changed a note about
`org-element-timestamp-parser' setting nil for end part if :type is
`active'/`inactive'. That's not true. The actual behavior is that it
sets end date/time to the same values as start date/time even if it's
`active'/`inactive'. So here is the patch:

>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

* lisp/org-element.el (org-element-timestamp-interpreter): Preserve old
behavior when :range-type is `nil'.  Take into account :range-type
value when interpreting ranges.  When :range-type is `timerange',
return a timerange ().  If :range-type is
`daterange' return a daterange (<...>--<...>).  When :range-type is
nil, return a daterange (as it was before).  When :range-type is
`daterange' or `timerange' and :type is `active'/`inactive', throw an
error.
(org-element-timestamp-parser): Add :range-type property.

* lisp/org.el (org-timestamp-split-range): Make sure that :range-type
is nil for a split timestamp.

* testing/lisp/test-org-element.el
(test-org-element/timestamp-interpreter): Add new tests.
(test-org-element/timestamp-parser): Add tests for :range-type
property.

* etc/ORG-NEWS (Major changes and additions to Org API): Add news about this property.
---
 etc/ORG-NEWS |   7 +
 lisp/org-element.el  | 215 +++-
 lisp/org.el  |   1 +
 testing/lisp/test-org-element.el | 231 ++-
 4 files changed, 355 insertions(+), 99 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 973a97a2f..a4725ae8c 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -200,6 +200,13 @@ a newly created one.
 Previously, one had to use
 
 : (apply #'org-element-create 'section nil (org-element-contents node))
+ New property ~:range-type~ for org-element timestamp object
+
+~org-element-timestamp-parser~ now adds =:range-type= property to each
+timestamp object.  Possible values: ~timerange~, ~daterange~, ~nil~.
+
+~org-element-timestamp-interpreter~ takes into account this property
+and returns an appropriate timestamp string.
 
 *** ~org-priority=show~ command no longer adjusts for scheduled/deadline
 
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 1c9707573..075f64920 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4043,7 +4043,7 @@ Assume point is at the target."
   "Parse time stamp at point, if any.
 
 When at a time stamp, return a new syntax node of `timestamp' type
-containing `:type', `:raw-value', `:year-start', `:month-start',
+containing `:type', `:range-type', `:raw-value', `:year-start', `:month-start',
 `:day-start', `:hour-start', `:minute-start', `:year-end',
 `:month-end', `:day-end', `:hour-end', `:minute-end',
 `:repeater-type', `:repeater-value', `:repeater-unit',
@@ -4077,6 +4077,10 @@ Assume point is at the beginning of the timestamp."
 			 (activep 'active)
 			 ((or date-end time-range) 'inactive-range)
 			 (t 'inactive)))
+ (range-type (cond
+  (date-end 'daterange)
+  (time-range 'timerange)
+  (t nil)))
 	 (repeater-props
 	  (and (not diaryp)
 		   (string-match "\\([.+]?\\+\\)\\([0-9]+\\)\\([hdwmy]\\)"
@@ -4123,6 +4127,7 @@ Assume point is at the beginning of the timestamp."
 	(org-element-create
  'timestamp
 	 (nconc (list :type type
+  :range-type range-type
 		  :raw-value raw-value
 		  :year-start year-start
 		  :month-start month-start
@@ -4142,99 +4147,121 @@ Assume point is at the beginning of the timestamp."
 
 (defun org-element-timestamp-interpreter (timestamp _)
   "Interpret TIMESTAMP object as Org syntax."
-  (let* ((repeat-string
-	  (concat
-	   (pcase (org-element-property :repeater-type timestamp)
-	 (`cumulate "+") (`catch-up "++") (`restart ".+"))
-	   (let ((val (org-element-property :repeater-value timestamp)))
-	 (and val (number-to-string val)))
-	   (pcase (org-element-property :repeater-unit timestamp)
-	 (`hour "h") (`day "d") (`week "w") (`month "m") (`year "y"
-	 (warning-string
-	  (concat
-	   (pcase (org-element-property :warning-type timestamp)
-	 (`first "--") (`all "-"))
-	   (let ((val (org-element-property :warning-value timestamp)))
-	 (and val (number-to-string val)))
-	   

Re: Fwd: [BUG] Sparse tree does not work on properties with dashes

[Ihor Radchenko]

Fabian Kurmann  writes:

> I can reproduce it with the sample in the annex, following the steps
> below:
>
> - Start Emacs with 'emacs -Q'
> - Open a new Org file
> - Add the contents of the Annex
> - Type 'C-c /' and then 'p' for property.
> - Select "TEST-HELLO"
> - Select any of the two values
>
> Expected behaviour: produce a sparse tree.
>
> Actual result: no sparse tree.

Thanks for reporting!
Confirmed.

This is because `org-sparse-tree' will produce the following matcher:

 TEST-HELLO="one"

Which is interpreted as: Has tag "TEST" and does not have property
"HELLO" set to "one".

AFAIK, there is currently no mechanism to escape "-" in matcher string.
`org-make-tags-matcher' assumes that property name can only contain
alphanumeric charters and underscore.

-- 
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/)]

[Ihor Radchenko]

Hammer Hu  writes:

> When `org-modern' is installed and `org-modern-mode' is enable in a
> buffer, the fontification is augmented. See
> [[https://raw.githubusercontent.com/minad/org-modern/screenshots/example.gif]]
> for a demonstration.  But when I have `org-modern-mode' turned on,
> `org-adapt-indentation' to be `t', and indent some region, it becomes:
> ...
> #+begin_quote
> Thanks. I can reproduce the problem. It seems that `org-indent-region'
> or `org-indent-line' has issues computing the indentation if there are
> invisible/diplay properties on the line. This is not something we can
> fix in org-modern, since `org-modern' only augments the fontification
> and does not override indentation functionality. It should be repaired
> in Org directly if even - maybe ask on the Org issue tracker? I suggest
> you either don't use `org-adapt-identation' or set
> `org-modern-block-name' to nil. With `org-modern-block-name=nil' the
> issue also seems to go away.
> #+end_quote
>
> Emacs  : GNU Emacs 28.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.36, cairo version 1.17.6)
>  of 2023-01-07

Thanks for reporting!

Org relies on `current-indentation' to determine indentation.
AFAIU, `current-indentation' was not able to handle invisible and
display properties before Emacs 29.

May you please try to reproduce using Emacs 29 or newer?

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

[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]

--text follows this line--

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.

Hi there,

I found this problem when indenting a region with `org-adapt-indentation=t'
and `org-modern-mode' is turned on. I initially posted this issue on the
issue tracker of `org-modern'
[[https://github.com/minad/org-modern/issues/144]], but as the author
suggested, I need to turn to the `org' side. Below is the problem.

When `org-modern' is installed and `org-modern-mode' is enable in a
buffer, the fontification is augmented. See
[[https://raw.githubusercontent.com/minad/org-modern/screenshots/example.gif]]
for a demonstration.  But when I have `org-modern-mode' turned on,
`org-adapt-indentation' to be `t', and indent some region, it becomes:

#+begin_quote
** A level-2 heading
   something

   something

#+begin_quote
a block
#+end_quote

and something
#+end_quote

While it should become:

#+begin_quote
** A level-2 heading
   something

   something

   #+begin_quote
   a block
   #+end_quote

   and something
#+end_quote

Here is the reply from minad (author of `org-modern'):

#+begin_quote
Thanks. I can reproduce the problem. It seems that `org-indent-region'
or `org-indent-line' has issues computing the indentation if there are
invisible/diplay properties on the line. This is not something we can
fix in org-modern, since `org-modern' only augments the fontification
and does not override indentation functionality. It should be repaired
in Org directly if even - maybe ask on the Org issue tracker? I suggest
you either don't use `org-adapt-identation' or set
`org-modern-block-name' to nil. With `org-modern-block-name=nil' the
issue also seems to go away.
#+end_quote

Best
-

Emacs  : GNU Emacs 28.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.17.6)
 of 2023-01-07
Package: Org mode version 9.6.7 ( @ 
/home/huzf/.cache/emacs_configs/default/elpa.28/org-9.6.7/)

current state:
==
(setq
 org-archive-location "/home/huzf/org/personal/archive.org::* Archive"
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-log-done t
 org-startup-folded 'content
 org-agenda-files '("/home/huzf/org/personal/todo.org"
"/home/huzf/org/personal/inbox.org"
"/home/huzf/org/personal/archive.org")
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-refile-targets '((nil :maxlevel . 5) (org-agenda-files :maxlevel . 5))
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-default-notes-file "/home/huzf/org/personal/inbox.org"
 org-refile-use-outline-path 'file
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append
local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 org-modern-mode)
 org-agenda-clockreport-parameter-plist '(:link t :maxlevel 3)
 org-confirm-shell-link-function 'yes-or-no-p
 org-reveal-start-hook '(org-decrypt-entry)
 org-adapt-indentation t
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-mode-hook '((closure (t) nil
 (add-hook 'window-configuration-change-hook
  'org-agenda-align-tags nil t)
 )
)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-agenda-after-show-hook '(org-show-entry)
 org-edit-timestamp-down-means-later t
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-window-setup 'current-window
 org-tags-exclude-from-inheritance '("crypt")
 org-hide-leading-stars t
 org-todo-keywords '((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
 (sequence "PROJECT(p)" "|" "DONE(d!/!)" "CANCELLED(c@/!)")
 (sequence "WAITING(w@/!)" "DELEGATED(e!)" 

Fwd: [BUG] Sparse tree does not work on properties with dashes

[Fabian Kurmann]

Dear maintainers,

EXPLANATION HERE

I can reproduce it with the sample in the annex, following the steps
below:

- Start Emacs with 'emacs -Q'
- Open a new Org file
- Add the contents of the Annex
- Type 'C-c /' and then 'p' for property.
- Select "TEST-HELLO"
- Select any of the two values

Expected behaviour: produce a sparse tree.

Actual result: no sparse tree.

Best, Fabian


ANNEX

* Test with "one"
:PROPERTIES:
:TEST-HELLO: one
:END:

** Test with "two"
:PROPERTIES:
:TEST-HELLO: two
:END:

* Test with "two"
:PROPERTIES:
:TEST-HELLO: two
:END:

** Test with "one"
:PROPERTIES:
:TEST-HELLO: one
:END:

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.33, cairo version 1.16.0)

 of 2022-05-31
Package: Org mode version 9.6.1 ( @ /home/fabian/.emacs.d/elpa/org-9.6.1/)

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[Ihor Radchenko]

"M. Pger"  writes:

> Feature request: adjust ~org-agenda-format-item~ to let the user choose the 
> first level included in breadcrumbs

+1

-- 
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: Fix async evaluation

[Ihor Radchenko]

Liu Hui  writes:

> To reproduce the bug:
>
> 1. create test.org:
> ──✀──
> #+begin_src python :session "*Python 3*" :async t
> 1
> #+end_src
>
> # Local Variables:
> # python-shell-buffer-name: "Python 3"
> # End:
> ──✀──
>
> 2. emacs -Q -L  --eval "(require 'ob-python)"
>
> 3. Open test.org, then start a python shell with M-x run-python, which
> should create a buffer named "*Python 3*"
>
> 4. Press C-c C-c on the src block. Then an error "No inferior Python
> process running" is shown.

Confirmed.
CCing Jack Kamm, the maintainer.

-- 
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]

Max Nikulin  writes:

> On 11/07/2023 06:11, Evgenii Klimov wrote:
>> I added `org-summary-todo' example function, that are advertized in
>> `org-after-todo-statistics-hook', to my init file (with
>> lexical-binding: t) and got a compilation warning:
>> 
>>Warning (bytecomp): Unused lexical variable `org-log-states'
>
> May it be a typo? There is the `org-todo-log-states' variable added in
>
> : 70b6cc5da 2008-01-31 11:36:18 +0100 Carsten Dominik: Release 5.10a

Indeed.
I fixed it myself on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix=0b6f9f

Handled.

-- 
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:

> Preserved old behavior for `org-element-timestamp-interpreter'
> function for :range-type set to `nil'. The new function
>
> The new function takes into account :range-type value when interpreting
> ranges and throws error when :range-type set for `active'/`inactive'
> types.

Thanks!

The patch looks good in general, but there is at least one test failing
when I run make test. May you please check?

Also, see the attached diff where I suggest some comments to explain the
code logic.
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 203f45a33..baa605548 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4152,6 +4152,8 @@ (defun org-element-timestamp-interpreter (timestamp _)
 (let ((day-start (org-element-property :day-start timestamp))
   (month-start (org-element-property :month-start timestamp))
   (year-start (org-element-property :year-start timestamp)))
+  ;; Return nil when start date is not available.  Could also
+  ;; throw an error, but the current behavior is historical.
   (when (and day-start month-start year-start)
 (let* ((repeat-string
 	(concat
@@ -4184,39 +4186,82 @@ (defun org-element-timestamp-interpreter (timestamp _)
  (and (org-string-nw-p warning-string) (concat " " warning-string))
  (cdr brackets
   (concat
+   ;; Opening backet: [ or <
(car brackets)
+   ;; Starting date/time: -MM-DD DAY[ HH:MM]
(format-time-string
-	(org-time-stamp-format (when (and minute-start hour-start) t) 'no-brackets)
+;; `org-time-stamp-formats'.
+	(org-time-stamp-format
+ ;; Ignore time unless both HH:MM are available.
+ ;; Ignore means (car org-timestamp-formats).
+ (and minute-start hour-start)
+ 'no-brackets)
 	(org-encode-time
 	 0 (or minute-start 0) (or hour-start 0)
 	 day-start month-start year-start))
-   (let((hour-end (org-element-property :hour-end timestamp))
-(minute-end (org-element-property :minute-end timestamp)))
+   ;; Range: -HH:MM or TIMESTAMP-END--[-MM-DD DAY HH:MM]
+   (let ((hour-end (org-element-property :hour-end timestamp))
+ (minute-end (org-element-property :minute-end timestamp)))
  (pcase type
((or `active `inactive)
+;; `org-element-timestamp-parser' use this type
+;; when no time/date range is provided.  So,
+;; should normally return nil in this clause.
 (pcase range-type
   (`nil
+   ;; `org-element-timestamp-parser' will never assign end times here.
+   ;; End time will always imply `active-range' or `inactive-range' TYPE.
+   ;; But manually built timestamps may contain
+   ;; anything, so check for end times anyway.
(when (and hour-start hour-end minute-start minute-end
   (or (/= hour-start hour-end)
   (/= minute-start minute-end)))
+ ;; Could also throw an error.  Return range
+ ;; timestamp nevertheless to preserve
+ ;; historical behavior.
  (format "-%02d:%02d" hour-end minute-end)))
   ((or `timerange `daterange)
(error "`:range-type' must be `nil' for `active'/`inactive' type"
+   ;; Range must be present.
((or `active-range `inactive-range)
 (pcase range-type
+  ;; End time: -HH:MM.
+  ;; Fall back to start time if end time is not defined (arbitrary historical choice).
+  ;; Error will be thrown if both end and begin time is not defined.
   (`timerange (format "-%02d:%02d" (or hour-end hour-start) (or minute-end minute-start)))
-  ((or `nil `daterange)
+  ;; End date: TIMESTAMP-END--[-MM-DD DAY HH:MM
+  ((or `daterange
+   ;; Should never happen in the output of `org-element-timestamp-parser'.
+   ;; Treat as an equivalent of `daterange' arbitrarily.
+   `nil)
(concat
+;; repeater + warning + closing > or ]
+;; This info is duplicated in date ranges.
 timestamp-end
 "--" (car brackets)
 (format-time-string
-	 (org-time-stamp-format (when (and minute-end hour-end) t) 'no-brackets)
+