Re: problems with templates and ID in properties

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>>> It might be changed. Currently, we mimic the behavior of
>>> org-yank-subtree, so that we always insert captured entry under the
>>> correct level regardless of the capture target. For example, when you
>>> use OLP, the level will be adjusted.
>> 
>>> May you please explain more why you need to use level 2 heading 
>>> specifically?
>> 
>> Sure. I use this template for extracting from emails sent by my students
>> their names and email addresses to have entries like this
>> --8<---cut here---start->8---
>> * Grupos   :noexport:
>> ...
>> ** !!TODO!! G1 <2023-01-24 12:51> :Annu24: Paul New
>> ...
>> #+TBLNAME: sheets
>> #+BEGIN: columnview :maxlevel 2...
>> ...
>> That however only works if the entries have level **
>> 
>> It my workflow now clearer?

> Yup.
> I recommend changing your capture template to
> (file+olp "~/grupos2024.org" "Grupos")

That gives an error, as gives file+headline
so this part 

(setq org-capture-templates
  '(
("m" "Mail options")
("mk" "Annu Grupos Ejercicios" entry (file+olp 
"~/ALLES/HGs/tex/vorlesungen/HGAnnu/Hojas-Teoria/Soluciones-2024/grupos2024.org")
 "** TODO %^{Grupo} %T %^g %(org-contacts-template-name)
 :ID: %(org-id-new)
 :Link:  %a   
 :Email: %(org-contacts-template-email)
 :Grp: %^{Gr1|Gr2|Gr3|Gr4|Gr6|Gr7|Gr8|Gr9|Gr10|Gr11|Gr12|Gr13}
 :Usuario1: %:fromname
 :Email1: %:fromaddress
 :Usuario2: %(my-extract-cc)
 :Email2:  %(my-extract-cc)
 :Usuario3: %(my-extract-cc)
 :Email3:  %(my-extract-cc)
 :Usuario4: %(my-extract-cc)
 :Email4: %(my-extract-cc)
 :Status:   [ ]
 :Hoja: 
 :Ej:   
 :End:")))

Gives the error 
Deprecated date/weektree capture templates changed to ‘file+olp+datetree’.
org-capture-set-target-location: Wrong type argument: markerp, nil
Updating buffer list...done




>>> What command/variable could org-mode force to have always an UUID in the
>>> ID property?
>> 
>>> `org-id-method' I think.
>> 
>> This variable sets the format, but as far as I can see, is not
>> reasonable for adding an ID.

> Do you mean that you want IDs to be always added any time your create a
> heading? If so, the common method is to add `org-insert-heading-hook'.

That hook is empty, nevertheless and ID with an annoying END is inserted
in the middle of the template
> However, this hook will not work for templates. You may add
> :ID: %(org-id-new)
> to your template to generate an ID.

I will try that.

Thanks 


-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 



smime.p7s
Description: S/MIME cryptographic signature

Re: Async Python src block behavior with :dir header property

[Jack Kamm]

Ihor Radchenko  writes:

>> I agree it's a problem -- if there are multiple blocks with the same
>> session but different ":dir" arguments, then a ":file" result of the
>> second block will be relative to the wrong :dir.
>>
>> This seems like a longstanding problem, and affects both async and
>> non-async session blocks.
>
> Maybe something like the attached?

Nice, that seems like the right way to do it.

I updated the patch for `org-babel-comint-async-filter' to follow the
same approach, setting default-directory based on the session buffer's
value rather than the :dir header arg.

>From 1a1a22e4f4a12ebe83c3fef26fe727066fb14476 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Wed, 31 Jan 2024 20:06:00 -0800
Subject: [PATCH] ob-comint: Make file results from async sessions respect :dir
 header

* lisp/ob-comint.el (org-babel-comint-async-filter): Set
default-directory before calling `org-babel-insert-result'

https://list.orgmode.org/875xz9o4nj.fsf@localhost/T/#t
---
 lisp/ob-comint.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 7d258ea0e..349524701 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -224,6 +224,8 @@ (defun org-babel-comint-async-filter (string)
 	 (file-callback org-babel-comint-async-file-callback)
 	 (combined-string (concat org-babel-comint-async-dangling string))
 	 (new-dangling combined-string)
+ ;; Assumes comint filter called with session buffer current
+ (session-dir default-directory)
 	 ;; list of UUID's matched by `org-babel-comint-async-indicator'
 	 uuid-list)
 (with-temp-buffer
@@ -248,7 +250,8 @@ (defun org-babel-comint-async-filter (string)
 (let* ((info (org-babel-get-src-block-info))
(params (nth 2 info))
(result-params
-(cdr (assq :result-params params
+(cdr (assq :result-params params)))
+   (default-directory session-dir))
   (org-babel-insert-result
(funcall file-callback
 (nth
@@ -291,7 +294,8 @@ (defun org-babel-comint-async-filter (string)
(let* ((info (org-babel-get-src-block-info))
   (params (nth 2 info))
   (result-params
-   (cdr (assq :result-params params
+   (cdr (assq :result-params params)))
+  (default-directory session-dir))
  (org-babel-insert-result
   res-str result-params info))
    t
-- 
2.43.0

I'm not subscriber, but want to send a code.

[Teika Kazura]

Hi, list moderators.

I'd like to submit a code to this mailing list without subscribing it.

Or, if you can forward the following to the list.

Thanks a lot for keeping this list.

[Wishitem] Show the current node name in the header line (w/ sample 
implementation)
---
Hi. The following code shows the current "node name" (outline header
name) in the emacs header line:

(defun org-mode-show-node-in-header ()
  (setq header-line-format
'(:eval
  (org-compute-node-name-for-header

(defun org-compute-node-name-for-header ()
  (let ((level 0)
cur
(str "")
(nodes (org-get-outline-path t)))
(while nodes
  (unless (eq level 0)
(setq str (concat str " ")))
  (setq cur (car nodes))
  (put-text-property 0 (length cur) 'face (nth level org-level-faces) cur)
  (setq str (concat str cur))
  (setq level (1+ level))
  (setq nodes (cdr nodes)))
str
))

(add-hook 'org-mode-hook #'org-mode-show-node-in-header)

If you like, adopt it for org-mode. Feel free to modify.

Several things have to be considered.

1. It does not seem there's a fixed word for "node name" (outline
headers). I know there's the function "org-get-outline-path". OTOH the
info does never use the word "path" for this purpose. Nor does
outline-mode (of Emacs.)

2. It's better to implement it as a minor mode.

3. In the header line, my code shows the node names concatenated by
" " (a single space), but it can be turned into an option. Some people
may prefer e.g. " > ".

4. I use org-level-faces. I think it's ok. If users don't like it,
they can hack the code.

5. Maybe you want to ask emacs upstream to enable multiple headers /
multiple-line header. (I'm sure then you'll throw yourself into a
tough situation.)

Sorry that I can't help with none of these issues.

I got an inspiration of this post from
https://emacs.stackexchange.com/a/30901 , but I wrote the code on my
own, so there is no copyright problem. Still you may want to check other
answers there to improve this.

Please cc: to me. I'm not subscribing the org mailing list.

I'm so grateful for your work in org-mode.

Best regards,
Teika

Re: [BUG] org-format-latex not respecting org-format-latex-options :matchers

[Ihor Radchenko]

[ CCing Timothy and Karthic ]

Jacob Fong  writes:

> It appears that the math-matching regexes are hard-coded in
> `org-format-latex`, as seen in this line:
>
> ```
> (let* ((math-regexp "\\$\\|[([]\\|^[ \t]*begin{[A-Za-z0-9*]+}")
> ```
>
> As a result of this, :matchers does not work as documented, for
> example with `org-latex-preview`. This is confirmed in some places
> (https://emacs.stackexchange.com/questions/78093/removing-certain-latex-preview-matchers-from-org-mode).
>
> Is there any way this can be fixed to accord with the
> org-format-latex-options documentation?

Confirmed.
But we are soon to commit major changes to latex preview system.
I believe that this issue will be addressed.
See https://list.orgmode.org/orgmode/87lek2up0w@tec.tecosaur.net/

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

Re: problems with templates and ID in properties

[Ihor Radchenko]

Uwe Brauer  writes:

>> It might be changed. Currently, we mimic the behavior of
>> org-yank-subtree, so that we always insert captured entry under the
>> correct level regardless of the capture target. For example, when you
>> use OLP, the level will be adjusted.
>
>> May you please explain more why you need to use level 2 heading specifically?
>
> Sure. I use this template for extracting from emails sent by my students
> their names and email addresses to have entries like this
> --8<---cut here---start->8---
> * Grupos   :noexport:
> ...
> ** !!TODO!! G1 <2023-01-24 12:51> :Annu24: Paul New
> ...
> #+TBLNAME: sheets
> #+BEGIN: columnview :maxlevel 2...
> ...
> That however only works if the entries have level **
>
> It my workflow now clearer?

Yup.
I recommend changing your capture template to
(file+olp "~/grupos2024.org" "Grupos")

>>> What command/variable could org-mode force to have always an UUID in the
>>> ID property?
>
>> `org-id-method' I think.
>
> This variable sets the format, but as far as I can see, is not
> reasonable for adding an ID.

Do you mean that you want IDs to be always added any time your create a
heading? If so, the common method is to add `org-insert-heading-hook'.

However, this hook will not work for templates. You may add
:ID: %(org-id-new)
to your template to generate an ID.

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

[BUG] org-format-latex not respecting org-format-latex-options :matchers

[Jacob Fong]

Hey everyone,

It appears that the math-matching regexes are hard-coded in
`org-format-latex`, as seen in this line:

```
(let* ((math-regexp "\\$\\|[([]\\|^[ \t]*begin{[A-Za-z0-9*]+}")
```

As a result of this, :matchers does not work as documented, for
example with `org-latex-preview`. This is confirmed in some places
(https://emacs.stackexchange.com/questions/78093/removing-certain-latex-preview-matchers-from-org-mode).

Is there any way this can be fixed to accord with the
org-format-latex-options documentation?

Thank you,
Jacob

-- 
jacobcf...@gmail.com

Re: problems with templates and ID in properties

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer via "General discussions about Org-mode."
>  writes:

>>> Uwe Brauer  writes:
>> 
>> Thanks for you answer
>>> This is expected. As per `org-capture-templates' docstring, "entry"
>>> capture type inserts top-level entries into files:
>> 
>>> entry   an Org node, with a headline.  Will be filed
>>> as the child of the target entry or as a
>>> top-level entry.  Its default template is:
>>> "* %?
>> 
>> So that cannot be changed, do I understand correctly.

> It might be changed. Currently, we mimic the behavior of
> org-yank-subtree, so that we always insert captured entry under the
> correct level regardless of the capture target. For example, when you
> use OLP, the level will be adjusted.

> May you please explain more why you need to use level 2 heading specifically?


Sure. I use this template for extracting from emails sent by my students
their names and email addresses to have entries like this
--8<---cut here---start->8---
* Grupos   :noexport:
 :PROPERTIES:
 :EXPORT_OPTIONS: num:t
 :COLUMNS:  %10GRP(Grupos) %10HOJA(Hoja Nr) %10EJ(Ejericio Nr) 
%17DATE(Date) %7STATUS(Status){X/}
 :ID:   Grupos
 :END:

** !!TODO!! G1 <2023-01-24 12:51> :Annu24: Paul New
   :PROPERTIES:
   :ID:   0da9c464-74a1-4153-b957-72e6b562bb0a
   :Link: 
[[gnus:nnimap+UCMgmail:INBOX#CAMZEOZ24BUfHRj3_XaF6kxyPBZ4vY4G=qvb2iujz4zenapo...@mail.gmail.com][Email
 from User1: [Annu23] formar Grupo]]
   :Email:us...@gmail.com
   :Grp:  Gr1
   :Usuario1: User1
   :Email1:   us...@gmail.com
   :Usuario2: User2
   :Email2:   us...@gmail.com
   :H2:   1 (Función implícita)
   :P2:   25
   :STHAB2:   [ ]
   :StEnv2:   [ ]
   :H4:   2 (Convergencia adaptativo)
   :P4:   50
   :STHAB4:   [X]
   :StEnv4:   [X]
   :End:
** !!TODO!! G2 <2023-01-29 19:11> :Annu24: John Doe
   :PROPERTIES:
   :ID:   57aed14b-6790-43de-9440-af082d555800
   :Link: 
[[gnus:nnimap+UCMgmail:INBOX#CANpraWwp91vH=-N2y3A5pm7hwuRt-Qzq_Gy7ZyYp7jc5uZ=4...@mail.gmail.com][Email
 from User2: [Annu23] formar Grupo]]
   :Email:us...@gmail.com
   :Grp:  Gr2
   :Usuario1: User3
   :Email1:   us...@gmail.com
   :Usuario2: User4
   :Email2:   u...@gmail.com
   :H1:   4 (Método \theta)
   :P1:   10
   :STHAB1:   [X]
   :StEnv1:   [X]
   :SUMMARY:  ok
   :H2:   1
   :P2:   10
   :STHAB2:   [X]
   :StEnv2:   [X]
   :H5:   6 (Func Ampli RK)
   :P5:   5
   :STHAB5:   [X]
   :StEnv5:   [X]
   :End:
--8<---cut here---end--->8---

** Sheet 
so I can use now columnview to generate a table
--8<---cut here---start->8---


#+TBLNAME: sheets
#+BEGIN: columnview :maxlevel 2  :skip-empty-rows t  :indent nil :hlines 2  
:format "%10Grp(Grupo) %7H1(Hoja1-Ej) %10P1(\%) %7H2(Hoja2-Ej) %10P2(\%) 
%7H3(Hoja3-Ej) %10P3(\%)  %7H4(Hoja4-Ej)  %10P4(\%) %7H5(Hoja5-Ej) %10P5(\%) 
%7H6(Hoja6-Ej) %10P6(\%)"
| <10>  | <7>  | <10> | <7>   | <10> | <7>  | <10> 
| <7> | <10> | <7>   | <10> | <7>  | 
<10> |
| Grupo | Hoja1-Ej | %| Hoja2-Ej  |% | Hoja3-Ej | %
| Hoja4-Ej| %| Hoja5-Ej  | %| Hoja6-Ej | %  
  |
|---+--+--+---+--+--+--+-+--+---+--+--+--|
| Gr1   |  |  | 1 (Función implícita) |   25 |  |  
| 2 (Convergencia adaptativo) | 50   |   |  |  |
  |
|---+--+--+---+--+--+--+-+--+---+--+--+--|
| Gr2   | 4 (Método \theta) | 10   | 1 |   10 |  |  
| |  | 6 (Func Ampli RK) | 5|  
|  |
#+END:

--8<---cut here---end--->8---

That however only works if the entries have level **

It my workflow now clearer?

>> What command/variable could org-mode force to have always an UUID in the
>> ID property?

> `org-id-method' I think.

This variable sets the format, but as far as I can see, is not
reasonable for adding an ID.

regards

-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 

Re: [BUG] No result exporting combined org-agenda files to icalendar [9.6.15 (release_9.6.15 @ z:/emacs-i686/share/emacs/29.2/lisp/org/)]. It was: org-icalendar export problems

[Jack Kamm]

Ypo  writes:

> I can't share my private org files. And I find myself unable to isolate 
> the causes of the possible errors.

One strategy that might help is to "bisect" the Org file by repeatedly
splitting it into 2 files, and exporting each, to find where the
problematic entries are. By splitting in half every time, you might be
able to isolate the problem relatively quickly, and produce a minimal
example from that.

Re: Another low-hanging fruit

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> This is another low hanging fruit. I was a bit annoyed to have to leave an
> empty label for inlined footnotes (à la LaTeX)... I don't know if this
> qualifies as a TINYCHANGE...

Don't you have FSF copyright assignment?

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

Re: Async Python src block behavior with :dir header property

[Ihor Radchenko]

Jack Kamm  writes:

> Ihor Radchenko  writes:
>
>> The patch generally looks reasonable, although I am slightly concerned
>> about interaction between :dir and session we describe in the manual:
>>
>> When ‘dir’ is used with ‘session’, Org sets the starting directory
>> for a new session.  But Org does not alter the directory of an already
>> existing session.
>
> I agree it's a problem -- if there are multiple blocks with the same
> session but different ":dir" arguments, then a ":file" result of the
> second block will be relative to the wrong :dir.
>
> This seems like a longstanding problem, and affects both async and
> non-async session blocks.

Maybe something like the attached?


> Ideally, ":dir" should be set at session level rather than block
> level. This could be done via PROPERTY if there is only one session in
> the file or subtree, but there isn't a mechanism for this more
> generally.

Or we can ask babel backends to respect :dir and issue the necessary
"cd" command in the session for the duration of the code block evaluation.

> Perhaps the simplest solution is to add a check to org-lint, requiring
> all blocks with the same session to have the same :dir.

Or this.

>From 1e87de13d44a1bb31985622bfc9c9a6df6b7548c Mon Sep 17 00:00:00 2001
Message-ID: <1e87de13d44a1bb31985622bfc9c9a6df6b7548c.1706975370.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 3 Feb 2024 16:47:57 +0100
Subject: [PATCH] org-babel-execute-src-block: Force :dir according to live
 session

* lisp/ob-core.el (org-babel-execute-src-block): Force eval directory
to follow live session buffer, if any.  This is consistent with what
we promise in the manual.

Link: https://orgmode.org/list/87mssi8ht2@gmail.com
---
 lisp/ob-core.el | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 1de3af6ad..2cd542012 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -840,14 +840,17 @@ (defun org-babel-execute-src-block ( arg info params executor-type)
 		 (dir (cdr (assq :dir params)))
 		 (mkdirp (cdr (assq :mkdirp params)))
 		 (default-directory
-		   (cond
-		((not dir) default-directory)
-		((member mkdirp '("no" "nil" nil))
-		 (file-name-as-directory (expand-file-name dir)))
-		(t
-		 (let ((d (file-name-as-directory (expand-file-name dir
-		   (make-directory d 'parents)
-		   d
+		  (cond
+		   ((not dir) default-directory)
+   ((when-let ((session (assq :session params)))
+  (when (org-babel-comint-buffer-livep session)
+(buffer-local-value 'default-directory (get-buffer session)
+		   ((member mkdirp '("no" "nil" nil))
+		(file-name-as-directory (expand-file-name dir)))
+		   (t
+		(let ((d (file-name-as-directory (expand-file-name dir
+		  (make-directory d 'parents)
+		  d
 		 (cmd (intern (concat "org-babel-execute:" lang)))
 		 result exec-start-time)
 	(unless (fboundp cmd)
-- 
2.43.0



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

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Ihor Radchenko]

Samuel Wales  writes:

>> May you please elaborate what you want to add to the manual and where?
>
> had been merely thinking mentioning non-brittleness for newcomers.
> in handling links.

Isn't it already mentioned?

 ...  In addition or alternatively, depending on the value of
 ‘org-id-link-to-org-use-id’, create and/or use a globally unique
 ‘ID’ property for the link(1).  So using this command in Org
 buffers potentially creates two links: a human-readable link from
 the custom ID, and one that is globally unique and works even if
 the entry is moved from file to file.  The ‘ID’ property can be
 either a UUID (default) or a timestamp, depending on
 ‘org-id-method’.  Later, when inserting the link, you need to
 decide which one to use.

> but MAYBE also org-id could be slightly more integrated in org, such
> as not having to load the library.

The default value of `org-modules' is indeed a subject of discussion.
AFAIK, the current problem is that adding extra link types into
`org-modules' significantly slows down loading Org.

> ...  (info "(org) Include Files") does not
> mention whether org-id works.  could eliminate the need to specify
> file.

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: [BUG] No result exporting combined org-agenda files to icalendar [9.6.15 (release_9.6.15 @ z:/emacs-i686/share/emacs/29.2/lisp/org/)]. It was: org-icalendar export problems

[Ypo]

Thanks, Ihor

I can't share my private org files. And I find myself unable to isolate 
the causes of the possible errors.


I think I will keep waiting till somebody shares an easy and robust way 
to get an .ics calendar from org files.


Best!

On 02/02/2024 22:25, Ihor Radchenko wrote:

Ypo  writes:


I am sharing a bug report from emacs -q. I don't know how to use a
different org-version that the built-in (or if I should).

Sorry for not being clear. Let me elaborate what I expect.

1. Create example Org file or a set of Org files, open them with
emacs -Q, and try to trigger the problem where you expect to see ics
file, but it does not appear

2. If you can do it, share the example Org files and each step you
performed after emacs -Q until you encountered the problem.

The idea is providing me with enough info to re-create the problem on my
computer, so that I can investigate in depth.

Re: [BUG] No result exporting combined org-agenda files to icalendar [9.6.15 (release_9.6.15 @ z:/emacs-i686/share/emacs/29.2/lisp/org/)]. It was: org-icalendar export problems

[Fraga, Eric]

On Saturday,  3 Feb 2024 at 13:13, Ypo wrote:
> I think I will keep waiting till somebody shares an easy and robust
> way to get an .ics calendar from org files.

Not sure what you are expecting but I can show you my (elided) shell
script that generates a single ics file from multiple org files:

--8<---cut here---start->8---
DIARY=${HOME}/s/notes/diary
OUTLOOK=${HOME}/s/notes/outlook
emacs -Q --batch --debug-init \
--load=esf-org.el \
--visit=${DIARY}.org --eval='(org-icalendar-export-to-ics)' \
--visit=${OUTLOOK}.org --eval='(org-icalendar-export-to-ics)'
cat ${DIARY}.ics \
${OUTLOOK}.ics \
> /tmp/combined.ics
--8<---cut here---end--->8---

where esf-org.el has some org customizations and the resulting combined
ics file is in /tmp/combined.ics.

HTH,
eric

-- 
Eric S Fraga, https://profiles.ucl.ac.uk/5958-eric-fraga

Re: Bug: org-html-example-block can produce multiple class attributes [9.4 (9.4-dist @/usr/share/emacs/site-lisp/elpa/org-9.4/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Joshua Honeycutt  writes:
>
>> I added a class attribute to an example block as in:
>>
>>#+ATTR_HTML :class cmdout
>>#+BEGIN_EXAMPLE
>>text text text
>>#+END_EXAMPLE
>>
>> I expected this to produce a html tag like:
>>
>>
>>
>> but the output was instead:
>>
>>

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5cb52f379

-- 
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-heading changed behavior with Emacs 29.2 [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/29.2/lisp/org/)]

[gusbrs]

Hi,

On Sat, 3 Feb 2024 at 10:27, gusbrs  wrote:
> On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko  wrote:

> > Would it make sense to add a new `org-blank-after-new-entry'
> > customization that will provide explicit user control over what Org does
> > when inserting a new heading?
>
> Looking from the perspective of C-RET alone, I'd be inclined to
> restate my suggestion of treating the issue that motivated that commit
> as a "visibility / folding" problem. However, including M-RET into the
> mix, I think you have a good point, and something like
> `org-blank-after-new-entry' would possibly help improve blank line
> consistency in general.

A couple of further comments about this. First, I think exposing a
`org-blank-after-new-entry' is a good idea also on the grounds that it
becomes a commitment to a desired/desirable behavior. And would offer
more control.

Also, something like `(setq org-blank-after-new-entry '((heading .
auto)))' would arguably have to keep the number of lines existing at
the end of the current entry. In other words, implement (by other
means) the behavior which used to prevail before the commit in
discussion.

Best,
gusbrs

Re: [BUG] org-insert-heading changed behavior with Emacs 29.2 [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/29.2/lisp/org/)]

[gusbrs]

Hi Ihor,

Thanks for looking into this.

On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko  wrote:

> The number of blank lines after newly inserted is not defined by Org
> mode, unlike the number of blank lines before heading that is controlled
> by `org-blank-before-new-entry'.

Well, "not defined" is strong, I'd say. There is no exposed option.
But the behavior used to be regular, and "do the right thing" (OK, you
may wish to debate that). And now the behavior has changed.

The commit basically only changes from:

(org-end-of-subtree)

to:

 (org-end-of-subtree invisible-ok 'to-heading)

Which essentially changes the point position before the task of
actually inserting the heading is carried out.

It goes from here:

#+begin_src org
,* Sec1

,** SubSec1

text

,** SubSec2

text

#+end_src

To here:

#+begin_src org
,* Sec1

,** SubSec1

text

,** SubSec2

text

#+end_src

In practice, the previous behavior would "honor" whatever blank lines
existed in the current heading. That's why
`org-blank-before-new-entry' was needed, but something like
`org-blank-after-new-entry' not so much. Consistency was naturally
kept, because of this regularity.

> If you use M- rather then C- and set
> (setq org-blank-before-new-entry '((heading) (plain-list-item)))
> , you will get no newlines after the new heading inserted before current:
>
> * Sec1
>
> ** SubSec1
>
> M- will yield
>
> * Sec1
> ** 
> ** SubSec1

Not the same thing, C-RET calls `org-insert-heading-respect-content'
and `org-meta-return' calls `org-insert-heading'. Besides, what we get
seems to align with what you asked in `org-blank-before-new-entry'. I
tend to use mostly C-RET, because it is more regular, and I use lists
a lot, so that's the issue I'm raising.

> Would it make sense to add a new `org-blank-after-new-entry'
> customization that will provide explicit user control over what Org does
> when inserting a new heading?

Looking from the perspective of C-RET alone, I'd be inclined to
restate my suggestion of treating the issue that motivated that commit
as a "visibility / folding" problem. However, including M-RET into the
mix, I think you have a good point, and something like
`org-blank-after-new-entry' would possibly help improve blank line
consistency in general.

Best regards,
gusbrs

Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines

[Ihor Radchenko]

"Rick Lupton"  writes:

> I see.  Updated to get the search string first, before the possible 
> properties draw appears.
>
> To make this work I changed `org-link-precise-link-target': instead of
> accepting the RELATIVE-TO argument and rejecting unsuitable targets
> internally, it now sets a marker `org-link-precise-target-marker'
> showing where the target that was found is, so the caller can decide
> if the found target is suitable. I copied the approach from
> `org-entry-property-inherited-from', hope that doesn't cause any other
> issues.

I'd prefer to avoid using global variables here.
`org-entry-property-inherited-from' dates to pre-lexical binding times
and is a potential source of subtle bugs if several `org-entry-get'
calls happen unexpectedly to the code, changing
`org-entry-property-inherited-from' multiple times.

Instead, I suggest changing the return value of
`org-link-precise-link-target' to a list that includes marker in
addition to search string and description.

>> The fact that links stored via `org-store-link' cannot be open with
>> default settings is not good.
>> Also, your patch disregards this setting - it should not match
>> non-headline search strings with the default value of
>> `org-link-search-must-match-exact-headline'.
>
> `org-link-search-must-match-exact-headline' affects `org-link-search', which 
> is called by `org-id-open' -- so I think the behaviour for these org-id links 
> should be the same as for other file links? Am I missing something?

No, you don't.
In my testing, I used #+name: as link target.
However, what I missed is that #+name targets are matched even when
`org-link-search-must-match-exact-headline' is set to 'query-to-create.
The docstring is not accurate there and must be updated.

> Or, maybe you mean links that rely on 
> `org-link-search-must-match-exact-headline' should not be stored.  That would 
> seem reasonable, but also doesn't need to be part of these changes here?

Yes, I also meant this. Indeed, it is out of scope of your patch. It was
a comment for future reference.

>> Probably, changing the default value of
>> `org-link-search-must-match-exact-headline' to nil is due.
>
> It seems like the behaviour below would be desirable, but doesn't currently 
> exist with any setting of `org-link-search-must-match-exact-headline'?
>
> (org-link-search "plain text")  -->  fuzzy search for all text
> (org-link-search "*heading")-->  search only headings, optionally 
> creating if missing

That would also make sense. I like this idea.

>>> -  (org-insert-heading nil t t)
>>> +  ;; Find appropriate level for new heading
>>> +  (let ((level (save-excursion
>>> + (goto-char (point-min))
>>> + (+ 1 (or (org-current-level) 0)
>>
>> This is fragile. You assume that `point-min' always contains a heading.
>> That may or may not be the case - `org-link-search' may be called by
>> third-party code that does not care about setting narrowing in certain
>> ways.
>
> I don't think it's a problem. (org-current-level) returns something suitable 
> whether or not point-min contains a heading. Both the situations below seem 
> reasonable choices for the level of the newly created heading at the end:

That's right.

> ---start of narrowing---
> Text
> * H1
> ** H2
> * A new level 1 heading is created at the end
> ---end of narrowing---
>
> ---start of narrowing---
> * H1
> ** H2
> ** A new level 2 heading is created at the end
> ---end of narrowing---

However, the second scenario is unexpected - consider that your
narrowing is not a narrowing but the whole contents of an Org file.

Before your patch, in both cases, a new level 1 heading is created.
With your patch, the second case will create a new level 2 heading even
for [[*Foo]] links.

It looks like we cannot simply rely on narrowing to determine the
created heading level.

-- 
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-heading changed behavior with Emacs 29.2 [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/29.2/lisp/org/)]

[Ihor Radchenko]

gusbrs  writes:

> I recently upgraded to Emacs 29.2 (from 29.1) and observed that
> `org-insert-heading-respect-content' has changed behavior with regard
> to how it handles blank lines at the end of the entry at which the
> command was called.
>
> Consider the following document (with "|" representing point):
>
> ** |SubSec1
>
> text
>
> ** SubSec2

> Calling `org-insert-heading-respect-content' ("C-RET") with Org
> version 9.6.6 (built-in Emacs 29.1) would result in:
> ...
> ** |
>
> ** SubSec2
>
> Now, with Org version 9.6.15 (built-in Emacs 29.2), it results in:
> ...
> ,** |
> ,** SubSec2
>
> That is an unfortunate change of behavior since those who like to keep
> some breathing space at the end of entries now have to deal with it
> manually after the heading is inserted.  So the handy "C-RET" becomes
> something like "C-RET RET C-b SPC".  Plus the cost of having to think
> about it, and that of occasionally forgetting it, consistency is just
> harder to maintain.

The number of blank lines after newly inserted is not defined by Org
mode, unlike the number of blank lines before heading that is controlled
by `org-blank-before-new-entry'.

If you use M- rather then C- and set
(setq org-blank-before-new-entry '((heading) (plain-list-item)))
, you will get no newlines after the new heading inserted before current:

* Sec1

** SubSec1

M- will yield

* Sec1
** 
** SubSec1

Would it make sense to add a new `org-blank-after-new-entry'
customization that will provide explicit user control over what Org does
when inserting a new heading?

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