Re: [BUG] org-element-at-point: Throw an error when not in org-mode [9.7-pre (release_9.6.15-1033-gd8586f @ /home/marie/.emacs.d/straight/build/org/)]

[Marie-Helene Burle]

I see. That makes sense.

Thank you very much for getting back to me with info. This is much appreciated!

Marie


Ihor Radchenko  writes:

> Marie-Helene Burle  writes:
>
>> Prior to org 9.7, I used to use `org-meta-return` everywhere to nicely add 
>> elements to a list. Whether in mu4e, markdown, or anywhere, typing:
>>
>> - item1 
>>
>> Would nicely give me:
>>
>> - item1
>> -
>> ...
>> So, indeed, not a bug and probably nothing you want to worry about. I'll 
>> just have to learn to live without those nice little org behaviours in 
>> non-org buffers.
>>
>> Note that the Reddit thread I linked in my prior email suggests that
>> I am not the only one who took advantage of this. I don't know what
>> org function that other user was using in non-org buffer, but it
>> used to work and stopped in 9.7.
>
> You can still use org-meta-return at your own risk if you upgrade to the
> latest Org mode. Just hide the warning message that is now displayed in
> place of the error.
>
> The reason org-meta-return and some other functions worked in the past
> is their internal implementation based on regular expressions. In the
> newer Org mode, we are switching to internal implementation based on Org
> parser - it is more accurate and fixes various bugs, but can fail
> unpredictably when not in Org mode buffer.
>
> In future, there is a chance that Org parser will be able to run without
> errors (although not necessarily accurately) in non-Org buffers, but it
> is not something I am specifically looking to fix - rather a side effect
> of some planned changes.

Re: [BUG] org-element-at-point: Throw an error when not in org-mode [9.7-pre (release_9.6.15-1033-gd8586f @ /home/marie/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Marie-Helene Burle  writes:

> Prior to org 9.7, I used to use `org-meta-return` everywhere to nicely add 
> elements to a list. Whether in mu4e, markdown, or anywhere, typing:
>
> - item1 
>
> Would nicely give me:
>
> - item1
> -
> ...
> So, indeed, not a bug and probably nothing you want to worry about. I'll just 
> have to learn to live without those nice little org behaviours in non-org 
> buffers.
>
> Note that the Reddit thread I linked in my prior email suggests that I am not 
> the only one who took advantage of this. I don't know what org function that 
> other user was using in non-org buffer, but it used to work and stopped in 
> 9.7.

You can still use org-meta-return at your own risk if you upgrade to the
latest Org mode. Just hide the warning message that is now displayed in
place of the error.

The reason org-meta-return and some other functions worked in the past
is their internal implementation based on regular expressions. In the
newer Org mode, we are switching to internal implementation based on Org
parser - it is more accurate and fixes various bugs, but can fail
unpredictably when not in Org mode buffer.

In future, there is a chance that Org parser will be able to run without
errors (although not necessarily accurately) in non-Org buffers, but it
is not something I am specifically looking to fix - rather a side effect
of some planned changes.

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

Re: [BUG] org-element-at-point: Throw an error when not in org-mode [9.7-pre (release_9.6.15-1033-gd8586f @ /home/marie/.emacs.d/straight/build/org/)]

[Marie-Helene Burle]

Note: actually, reading that Reddit thread again, it appears that multiple 
persons were doing this and they regret loosing the use of org functions in 
non-org buffers so much that they decided to pin org to 9.6...

Marie

Marie-Helene Burle  writes:

> Hi Ihor,
>
> Thank you for your reply and your explanations: very useful to learn how the 
> system works 
>
> Prior to org 9.7, I used to use `org-meta-return` everywhere to nicely add 
> elements to a list. Whether in mu4e, markdown, or anywhere, typing:
>
> - item1 
>
> Would nicely give me:
>
> - item1
> -
>
> Not a big deal you will say. But I liked the behaviour.
>
> I know that org functions (with the exception of
> `org-open-at-point-global` and maybe a few others intended to work
> everywhere) are only supposed to work in org buffers. But many
> functions actually used to work outside of org, even if that was never
> intended. I took advantage of that 
>
> So, indeed, not a bug and probably nothing you want to worry about. I'll just 
> have to learn to live without those nice little org behaviours in non-org 
> buffers.
>
> Note that the Reddit thread I linked in my prior email suggests that I
> am not the only one who took advantage of this. I don't know what org
> function that other user was using in non-org buffer, but it used to
> work and stopped in 9.7.
>
> Deep thanks for all the work,
>
> Best,
>
> Marie

Re: [BUG] org-element-at-point: Throw an error when not in org-mode [9.7-pre (release_9.6.15-1033-gd8586f @ /home/marie/.emacs.d/straight/build/org/)]

[Marie-Helene Burle]

Hi Ihor,

Thank you for your reply and your explanations: very useful to learn how the 
system works 

Prior to org 9.7, I used to use `org-meta-return` everywhere to nicely add 
elements to a list. Whether in mu4e, markdown, or anywhere, typing:

- item1 

Would nicely give me:

- item1
-

Not a big deal you will say. But I liked the behaviour.

I know that org functions (with the exception of `org-open-at-point-global` and 
maybe a few others intended to work everywhere) are only supposed to work in 
org buffers. But many functions actually used to work outside of org, even if 
that was never intended. I took advantage of that 

So, indeed, not a bug and probably nothing you want to worry about. I'll just 
have to learn to live without those nice little org behaviours in non-org 
buffers.

Note that the Reddit thread I linked in my prior email suggests that I am not 
the only one who took advantage of this. I don't know what org function that 
other user was using in non-org buffer, but it used to work and stopped in 9.7.

Deep thanks for all the work,

Best,

Marie

--
Marie-Helene Burle
Research Solutions Specialist
Research Computing | Simon Fraser University
Digital Research Alliance of Canada
https://www.sfu.ca/~msb2/


Ihor Radchenko  writes:

> Marie-Helene Burle  writes:
>
>> I suspect that this has already been reported as I saw it here: 
>> https://www.mail-archive.com/emacs-elpa-diffs@gnu.org/msg102743.html.
>
> This is just a reference to the commit that introduced the explicit
> error. Do note that the error got downgraded to a warning in a more
> recent development version of Org mode. But the warning still indicates
> inappropriate usage of Org functions that are designed to work in Org
> mode and expect Org mode buffer.
>
>> Just wanted to make sure it got to the right channel. Apologies for a
>> useless message if it already did.
>>
>> Noticed this problem with org 9.7. Used to be no problem with prior version.
>>
>> Also mentioned in 
>> https://www.reddit.com/r/emacs/comments/18gkx0i/orgelementatpoint_cannot_be_used_in_nonorg_buffer/.
>
>> In my case, I get the error when using `org-meta-return` in non-org buffers.
>
>> I then get either of these error messages:
>>
>> Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org 
>> buffer
>> Warning (org-element): org-element--cache: Org parser error in . 
>> Resetting.
>
> `org-meta-return' cannot be used in non-Org buffers. Just as the error
> states. May you please explain why you are trying to use Org mode
> command outside Org mode?
>
> Not a bug, although we can still discuss your use case.
> Canceled. (as a bug)

[BUG] with scheduled event containing inactive timestamps

[rameiko87]

Create an org file named filename.org containing the following text:

* TODO Org-agenda Bug Report Timestamp: [2024-01-04 Thu 15:15]
SCHEDULED: <2024-01-05 Fri>



Expected result:

Friday  5 January 2024
  filename: Scheduled:  TODO Org-agenda Bug Report Timestamp: 
[2024-01-04 Thu 15:15]




Obtained result:

Friday  5 January 2024
 14:00.. 
  filename:15:15.. Scheduled:  TODO Org-agenda Bug Report Timestamp: 
[2024-01-04 Thu 15:15]

 16:00.. 
 16:20.. now - - - - - - - - - - - - - - - - - - - - 
- - - - -

Re: [PATCH] Set Python shell in Org edit buffer

[Ihor Radchenko]

Jack Kamm  writes:

>> python.el is convenient as it allows setting the session buffer name in
>> advance via buffer-local variable. Then, all the normal python-mode
>> commands, including `run-python' or `python-shell-send-region' will work
>> as expected. However, other babel backends like ob-R do not have such a
>> luxury (see the dance with renaming R process buffer in
>> `org-babel-R-initiate-session').
>
> For R specifically, using `ess-gen-proc-buffer-name-function' might
> simplify things. Though of course this doesn't solve the problem more
> generally for other languages.

For now, I changed ob-R and ob-julia to use
`ess-gen-proc-buffer-name-function'. This is indeed cleaner.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b6643884c

With this, I am wondering what would be more appropriate place to set
`ess-gen-proc-buffer-name-function' - `org-babel-edit-prep:R' or
`org-babel-R-associate-session'. Same for python and other backends.

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

Re: [PATCH] Set Python shell in Org edit buffer

[Ihor Radchenko]

Jack Kamm  writes:

>> Because I am still thinking about the idea with global customization and
>> `org-babel--associate-session'.
>
> It's great that you're thinking about this -- it would be nice to have
> better consistency between ob-R, ob-python, etc, and to have better
> configurability on this. In particular, ob-R's behavior to automatically
> start a session is annoying for me, especially when editing on my HPC's
> login node which forbids starting R, python, etc outside of slurm.
>
> However, the most recent version of Liu's patch is very small, and the
> changes should be easy to modify in future, whatever your conclusion on
> `org-babel--associate-session'. So I would suggest not to let it
> be blocked by this for too long.

I just do not want to do double work.

I now reverted the obsoletion of org-babel--associate-session.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=99c9cae25
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b4687fcd6

I also fixed the problem where org-babel--associate-session was
never actually executed due to `org-src--babel-info' being set after
`org-src-mode-hook'.

Now, the question is what to do with the existing implementation of
`org-src-associate-babel-session'. It only runs
org-babel--associate-session when

(and session (not (string= session "none"))
 (org-babel-comint-buffer-livep session)
 (let ((f (intern (format "org-babel-%s-associate-session"
  (nth 0 info)
   (and (fboundp f) (funcall f session

The questionable check here is (org-babel-comint-buffer-livep session) -
it only triggers when session is already initiated, while ob-python and
some other backends do not necessarily need to start a new session to
"associate" it with Org Src buffer.

I am tentatively inclined to change this check to

(or (org-babel-comint-buffer-livep session)
(eq org-src-auto-initiate-session t)
(alist-get (nth 0 info) org-src-auto-initiate-session)
(alist-get 'default org-src-auto-initiate-session))

With `org-src-auto-initiate-session' being a customization that controls
whether to associate session for a given babel backend.

We may set the default value to something like

((default . t) ("R" . nil))

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

Re: Comments on Summary section of Org manual (was: [PATCH] doc/org-manual.org (Summary): Clarify the Org markup is human-readable)

[Ihor Radchenko]

Matt  writes:

>   On Wed, 03 Jan 2024 14:41:29 +0100  Ihor Radchenko  wrote --- 
>
>  > I do not see much benefit changing "todo list" to "to-do list". Both are
>  > clear and both are grammatically correct.
>
> I said "TODO" to "to-do".  I was reacting to it being all caps.  I'm sorry I 
> didn't say that.
>
> When it's all caps, TODO is a keyword.   Otherwise, it's prose.   The 
> following are different (AFAIK):
>
> * TODO Finish this headline
> * todo Finish this headline
> * to-do Finish this headline
>
> Agreed, it's a minor detail.

Yeah. TODO may be a bit funny. Although, we consistently use "TODO list"
across the manual and often say something like "list of all TODO items",
which is resonant with the concept of TODO keywords in Org mode.

So, TODO in caps actually make some sense within the context of Org
manual. You can call it a style.

Unless I hear from people being seriously confused by "TODO" in caps, I
am inclined to keep the existing style convention.

> ...
> "Markup language" is fine.  It's correct.  Org syntax is a markup language.
>
> I'm happy to leave it rather than risk bike-shedding it more than I have.  If 
> we learn that it caused friction for a newcomer, we can change it easily 
> enough.

+1

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

[PATCH v2] doc/org-manual.org (Summary): Clarify the Org markup is human-readable

[Ihor Radchenko]

Ihor Radchenko  writes:

> This is the first section of the manual. Most of the new users will see
> it. So, I'd like to hear any objections before installing the patch.

Thanks for the comments!
I am attaching the next iteration of the patch.

"Thomas S. Dye"  writes:

> How about this, assuming lightweight is equivalent to readable and 
> easy to understand?
>
> It relies on a readable and easy to understand plain-text markup 
> language saved to files with the =.org= extension. Authoring Org 
> files is best supported by Emacs, but you can view and change them 
> with any text editor. As an authoring tool ...

I used a shorter and modified version of your wording with more emphasis
that one can *understand* Org markup.

Matt  writes:

> +Org Mode is an authoring tool and a to-do lists manager for GNU Emacs.
> +It uses a legible plain-text notation to show formatting, structure,
> +relationships.  Anyone able to edit text can write using Org.  Anyone
> +able to read text can view it.

As a non-native speaker, I have some difficulties understanding
"legible" meaning in this context. Also, "anyone able to read text can
view it" would be a bit of a bold claim, I think. So, I went with more
moderate wording.

(I will limit this patch to the specific additions I had in mind.
Changes to the existing text you proposed can be discussed separately,
which is why I created a new branch in this thread.)

>From 9754dea7cca1bc525d0b39cc31e7b0596c5a2bf8 Mon Sep 17 00:00:00 2001
Message-ID: <9754dea7cca1bc525d0b39cc31e7b0596c5a2bf8.1704459551.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sun, 31 Dec 2023 16:20:24 +0100
Subject: [PATCH v2] doc/org-manual.org (Summary): Clarify the Org markup is
 human-readable

Readability of raw Org text is one of the core principles we maintain
when designing Org markup language.  Let's state it explicitly in the
manual.
---
 doc/org-manual.org | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 65aa5dd30..c6c37441f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -22,6 +22,9 @@ ** Summary
 It relies on a lightweight plain-text markup language used in files
 with the =.org= extension.
 
+Authoring Org files is best supported by Emacs, but you can view,
+understand, and change them with any text editor.
+
 As an authoring tool, Org helps you write structured documents and
 provides exporting facilities. Org files can also be used for literate
 programming and reproducible research.  As a TODO lists manager, Org
-- 
2.42.0



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

Re: [PATCH] ob-C.el compile-only header argument, was Re: How to use mpirun with C or C++ Org-babel?

[Ihor Radchenko]

Leo Butler  writes:

>> #+begin_src C :compile-only t :file foo :includes "stdio.h"
>> printf("This is test");
>> #+end_src
>
> It should be "yes" not "t".

I tested with :compile-only yes, but it did not change the observed
issue.

>> , executing should yield file link, even though it is not explicitly
>> specified.
>
> Ok. But, isn't it a responsibility of org-babel to ensure that if :file
> is set and :results is not, then the parameter list that is passed to
> org-babel-*-execute includes a correctly set :result-params field
> (i.e. it includes "file")? I mean, the docs say [1]:
>
> ‘file’  
>  Interpret as a filename.  Save the results of execution of the code
>  block to that file, then insert a link to it.  
>
> I would prefer not to fiddle in ob-*.el to implement a policy that
> should be implemented at a higher level.
>
> [1] (info "(org) Results of Evaluation"):

No, it is not the responsibility of ob-core. Simply because :file "name"
may imply multiple things that only the backend can determine.

:results value :file foo.txt means "execute src block, take its return
value, and save it to file foo.txt"

:results file link :file foo.txt means a completely different thing -
"execute src block for side effect, and insert link to file specified in
:file argument; assume that the file is created by the side effect"

So, when :results is not specified, ob-core leaves it up to the backend
to decide what kind of output to produce.

>> Basically, Org babel promises DWIM behavior when :results type is not
>> explicitly stated.
>
> I am happy to modify the patch to make ob-C.el conform to the stated (or
> implied) Org policies. But, "dwim" hurts my head.

May you please elaborate why "dwim" is a problem?

>> And when you have compilation error,
>>
>> #+begin_src C :compile-only t :file foo :includes "stdio.h"
>> printf("This is test")
>> #+end_src
>>
>> the result may be empty - buffer displayed by `org-babel-eval' is
>> probably enough.
>
> Can you tell me what behaviour you expect? No #+RESULTS: ?

No. The purpose of this example was to illustrate that the same set of
header arguments should _not_ yield [[file:foo]] link in the results, in
contrast to when no compilation error is produced.

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

Re: [BUG] Styles file and locale environment [9.6.13]

[Ihor Radchenko]

Hakan Dağdelen  writes:

> This is too much work unfortunately, since I come around the problem by 
> calling terminal commands instead of built-in emacs functions.
>
> But I can say the problem is still reproducible on my system under Org 
> 9.6.15.

The purpose of my query was to find out whether the problem is with Org
mode or with your config. If it is the problem with Org mode, I'd need
instructions to replicate the problem on my side. Otherwise, it is hard
for me to fix anything.

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

Re: [BUG] simple documentation update [9.7-pre (release_9.6.11-923-g6f960f @ /Users/stephen/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

"Stephen J. Eglen"  writes:

> Line 32 and 33 of org-id.el state:
>
> ;; Identifiers consist of a prefix (default "Org" given by the variable
> ;; `org-id-prefix') ...
>
> I think that should now read:
>
> ;; Identifiers may consist of a prefix (given by the variable
> ;; `org-id-prefix') ...
>
> as the default for org-id-prefix is now nil for no prefix.

Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=aeebac

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

Re: [BUG] org-element-at-point: Throw an error when not in org-mode [9.7-pre (release_9.6.15-1033-gd8586f @ /home/marie/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Marie-Helene Burle  writes:

> I suspect that this has already been reported as I saw it here: 
> https://www.mail-archive.com/emacs-elpa-diffs@gnu.org/msg102743.html.

This is just a reference to the commit that introduced the explicit
error. Do note that the error got downgraded to a warning in a more
recent development version of Org mode. But the warning still indicates
inappropriate usage of Org functions that are designed to work in Org
mode and expect Org mode buffer.

> Just wanted to make sure it got to the right channel. Apologies for a
> useless message if it already did.
>
> Noticed this problem with org 9.7. Used to be no problem with prior version.
>
> Also mentioned in 
> https://www.reddit.com/r/emacs/comments/18gkx0i/orgelementatpoint_cannot_be_used_in_nonorg_buffer/.

> In my case, I get the error when using `org-meta-return` in non-org buffers.

> I then get either of these error messages:
>
> Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer
> Warning (org-element): org-element--cache: Org parser error in . 
> Resetting.

`org-meta-return' cannot be used in non-Org buffers. Just as the error
states. May you please explain why you are trying to use Org mode
command outside Org mode?

Not a bug, although we can still discuss your use case.
Canceled. (as a bug)

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

Re: Stripping captured journal entries

[Michael Welle]

Hi,

"Loris Bennett"  writes:

> Hi,
>
> I capture journal entries such as
>
>   * 2024-01 January
>
>   ** 2024-01-03 Wednesday
>
>   *** Did this
> Added: [2024-01-03 Wed 10:35]
> - foo
>
>   *** Did that
> Added: [2024-01-03 Wed 12:13]
> - bar
>
>   ** 2024-01-04 Thursday
>
>   *** Did something else
> Added: [2024-01-04 Thu 09:53]
> - foobar
>
> I would like be able to extract a simple list of the headlines below the
> dates across multiple dates, i.e.
>
>   *** Did this
>   *** Did that
>   *** Did something else
>
> However, I only want some of the entries within the month, specifically,
> just those within a given week.

maybe you can use (org-map-entries 'org-get-heading "LEVEL=3") as a
starting point.

Regards
hmw