Re: oeg-add-note and double backslash ?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>>> We do document the line breaks in
>>> https://orgmode.org/manual/Paragraphs.html
>>
>> The only thing I see with respect to '\\' is:
>>
>>   Paragraphs are separated by at least one empty line.  If you need to
>>   enforce a line break within a paragraph, use ‘\\’ at the end of a line.
>>
>> Which doesn't answer the question of why org-add-note (etc) added it the
>> end of the first line of a Note which lead to my confusion. It's easy to
>> assume, if Org is adding '\\' to the first line of the Note and the Note
>> is a unit, then this is there to prevent folding/wrapping in the Note
>> when Org does "something" (but what?).
>
> Line break is a "forced" break of a line in paragraph. When there is a
> line break, paragraph does not re-flow to the page width.
>
> Re-flow may imply different things, including `fill-region' command in
> Emacs or paragraph layout during export.
>
> The detailed reason why we use this particular markup is that
> otherwise some internal code assumptions inside Org mode may break when
> users run `fill-region' on the notes. This is an internal implementation
> detail which should not be explained in the manual.

Hmm.  Fill-region will also compress the blanks in the generate note
header -- does that run up against the code assumptions?

I'm all for keeping internal implementation details out of the user's
manual, unless...

> What we might explain better is what is a line break, although I am not
> very sure what to explain here - I may be too familiar with the concept
> from my LaTeX-foo.

The manual should set expectations on what an Org file should look like
-- at least the key components.  It already defines Header, Paragraph
and Timestamp. What I think is missing here is the definition of a Note
along with some structure info about it (header line + 2 space indented
paragraphs[s]) to prepare the user.  In this, I probably come from a
more Reference Manual viewpoint (ie. "this is what all the pieces could
look like -- now lets discuss why you want each piece"). You could say
that the '\\' is needed to keep "other things" from combining the header
and paragraph of the note.  You could leave the details of "other
things" to variable or function docstrings as well as internal code.

p.s. would requiring a blank line after the Note header eliminate the
need for '\\' ?

-- 
David Masterson

Re: Consider removing newlines from org-insert-link help message

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Patches welcome.

Please, see the attached patch.

> I see no obvious downsides. May as well.

Done.

> Currently, the minibuffer message is simply "Link: ". "Insert link:"
> is also ok.

Done.

> Maybe "Press" rather than "Type".

I went with "Type" to match other Emacs commands.

> We may, but the default link might sometimes be long. Not sure how it
> will look like.

All right, you be the judge.

Personally, I find this UI less disorienting, as opposed to the unclear
comment about RET in the *Org Links* buffer.  And it makes sense, given
I see the "VERB NOUN [default CANDIDATE]: " constantly, all throughout
in Emacs.

> AFAIK, this is already done. We already use `completing-read'. The UI
> is there historically and in addition to the normal Emacs completion.

Gotcha!

(It is quite confusing when using e.g. Vertico, but if we are optimizing
for the default Emacs completion system, then it makes sense.)

Rudy

>From 7bc8e913af0972f0d6119e45d4ecaf80835f2277 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Sun, 10 Dec 2023 00:51:31 +0100
Subject: [PATCH] org-link: Prettify 'org-insert-link'

* lisp/ol.el (org-insert-link): Update the UI with text that is (1)
shorter, to avoid line breaks, (2) more standard, to match other Emacs
commands, and (3) more readable, with propertized key bindings.  Also,
show the default link in the minibuffer, as seen elsewhere in Emacs.
---
 lisp/ol.el | 44 +---
 1 file changed, 33 insertions(+), 11 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index e684b9504..49499e932 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1866,16 +1866,34 @@ non-interactively, don't allow to edit the default description."
   (org-link--fontify-links-to-this-file)
   (org-switch-to-buffer-other-window "*Org Links*")
   (with-current-buffer "*Org Links*"
-	(erase-buffer)
-	(insert "Insert a link.
-Use TAB to complete link prefixes, then RET for type-specific completion support\n")
-	(when org-stored-links
-	  (insert "\nStored links are available with / or M-p/n \
-\(most recent with RET):\n\n")
-	  (insert (mapconcat #'org-link--prettify
-			 (reverse org-stored-links)
-			 "\n")))
-	(goto-char (point-min)))
+(read-only-mode 1)
+(let ((inhibit-read-only t)
+  ;; FIXME Duplicate: Also in 'ox.el'.
+  (propertize-help-key
+   (lambda (key)
+ ;; Add `face' *and* `font-lock-face' to "work
+ ;; reliably in any buffer", per a comment in
+ ;; `help--key-description-fontified'.
+ (propertize key
+ 'font-lock-face 'help-key-binding
+ 'face 'help-key-binding
+  (erase-buffer)
+  (insert
+   (apply 'format
+  (cons "Type %s to complete link type, then %s to complete destination.\n"
+(mapcar propertize-help-key
+(list "TAB" "RET")
+	  (when org-stored-links
+(insert (apply 'format
+   (cons "\nStored links accessible with %s/%s or %s/%s are:\n\n"
+ (mapcar propertize-help-key
+ (list "" ""
+   "M-p" "M-n"
+   "RET")
+	(insert (mapconcat #'org-link--prettify
+			   (reverse org-stored-links)
+			   "\n"
+(goto-char (point-min)))
   (when (get-buffer-window "*Org Links*" 'visible)
 (let ((cw (selected-window)))
 	  (select-window (get-buffer-window "*Org Links*" 'visible))
@@ -1890,7 +1908,11 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
 			 org-link--insert-history)))
 	(setq link
 		  (org-completing-read
-		   "Link: "
+   (concat "Insert link"
+   (if-let ((default (caar org-stored-links)))
+   (format " [default %s]" default)
+ "")
+   ": ")
 		   (append
 		(mapcar (lambda (x) (concat x ":")) all-prefixes)
 		(mapcar #'car org-stored-links)
-- 
2.39.3 (Apple Git-145)

-- 
"Music is the mathematics of the sense, mathematics is the music of the
reason."  -- James Joseph Sylvester, 1814-1897

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Provide org-insert-subitem

[Bastien Guerry]

Hi Adam,

Ihor Radchenko  writes:

> Adam Porter  writes:
>
>> Well, it's been a few years since I forgot to bump this thread. [0]  :) 
>> I just rediscovered it after wondering why the command 
>> org-insert-subheading still doesn't have a default binding.  May we 
>> revisit this?  I find myself wanting to insert a subheading almost every 
>> day, and I have to "M-x org-insert-subheading RET".
>>
>> Of course I could bind it myself, and in one of my configs I have, but I 
>> still think it deserves a default binding, even if it were to be a 
>> "smart" command that worked like org-table-copy-down when in a table and 
>> does org-insert-subheading otherwise (because I still think that "S-RET" 
>> is an obviously appropriate binding for this command).
>>
>> What do you think?  =)
>
> I think that it still makes sense, even after all these years ;)

+1!  Thanks for reviving this thread.

I would suggest a larger set of enhancements here:

- S-RET on a heading copies down the heading.

  For that we would need a new command `org-clone-subtree' bound to
  S-RET that would immediately copy the heading at point. This command
  would accept a universal argument to allow for a number a clones and
  two universal arguments for adding a time shift.

  `org-clone-subtree-with-time-shift' would continue to be bound to
  `C-c C-x c' but would be really a call to `org-clone-subtree'

- S-RET on a list item calls `org-insert-subitem`, a new command.

- C-M-RET on a heading calls `org-insert-subheading', the existing
  command.

- C-M-RET on a list item calls `org-insert-subitem', a new command.

S-RET already "copy down" a table cells, so I'm really suggesting a
generalization of the current keybinding.

I like C-M-RET better than S-RET because inserting a subheading is
like a "subkey" or inserting a heading.

These improvements seem consistent.  WDYT?

-- 
 Bastien Guerry

Re: [PATCH] Move files when using org-babel-tangle-publish

[Bastien Guerry]

Ihor Radchenko  writes:

>> Yes I have assigned copyright to the FSF already.
>
> Bastien, may you please confirm?

I do - I added Antero to the list of FSF-signed contributors on Worg.

Thanks!

-- 
 Bastien Guerry

Re: [FR] Allow flattened imenu index

[Juri Linkov]

> Normally, `imenu' supports nested menus, when users select the target
> location in steps, like item3  -> item3.1  -> ...
>
> What is proposed is to list all the sub-menus together, as an option, so
> that the users can choose, for example, item.3.1 directly, without going
> through parent item3.

Shouldn't each sub-item keep the parent menu item as a prefix?
So a nested menu like

  menu1
sub-item1
sub-item2

could be flattened to

  menu1 -> sub-item1
  menu1 -> sub-item2

Or this should be optional?

Re: Provide org-insert-subitem

[Ihor Radchenko]

Adam Porter  writes:

> Well, it's been a few years since I forgot to bump this thread. [0]  :) 
> I just rediscovered it after wondering why the command 
> org-insert-subheading still doesn't have a default binding.  May we 
> revisit this?  I find myself wanting to insert a subheading almost every 
> day, and I have to "M-x org-insert-subheading RET".
>
> Of course I could bind it myself, and in one of my configs I have, but I 
> still think it deserves a default binding, even if it were to be a 
> "smart" command that worked like org-table-copy-down when in a table and 
> does org-insert-subheading otherwise (because I still think that "S-RET" 
> is an obviously appropriate binding for this command).
>
> What do you think?  =)

I think that it still makes sense, even after all these years ;)
Would you be interested to submit a patch?

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

[Liu Hui]

Ihor Radchenko  于2023年12月9日周六 18:29写道：
>
> Liu Hui  writes:
>
> >> 2. Check the new variable and attempt to run
> >>`org-babel--associate-session' in org-src-mode definition.
> >
> > I think associating the edit buffer with some session doesn't require
> > starting the session, which is at least feasible for ob-python. When
> > editing python src block, users can use C-c C-p to start the session
> > themselves for evaluating code. So it would be nice to allow a value
> > of 'associate in the customization, which means just running
> > `org-babel--associate-session'.
>
> I think we have a misunderstanding here.
>
> Didn't we just discuss that C-c C-p in python is not equivalent to
> `org-babel-python-initiate-session'?
>
> Also, by "start a new session" I meant "start a new session if there is
> none running already; if a session is already running, unconditionally
> associate Org Src buffer with that running session".

I just want to set 'python-shell-buffer-name' in the edit buffer
according to the :session header and don't need to start the session
even if the session doesn't exist. It may be not a real association by
your definition, so my previous comment is not relevant any more.

Re: Case insensitivity of simple [[links]]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Actually, dang!  I spoke too soon.  While links now work consistently
> before and after exports, their description matches the destination
> heading, not the source link.  But if we case-fold now, it would make a
> lot more sense to match the case of the source link, as it enables one
> to link [[capitalized heading]]s.  Otherwise, we case-fold with no
> significant benefits, as far as I can see.
>
> Without also fixing this part, my problem with Org remains. :(

What you want is very hard to implement in Org mode for all the backends
- the export API, when querying a link target, returns that target as
AST element. Individual backends then decide what to do with that target
in order to extract the actual exported link text. And we have no
control over the third-party export backends.

What you may do instead is to create a custom element in
`org-export-filter-parse-tree-functions' that will force description in
the fuzzy links.

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

Re: [FR] Allow flattened imenu index (was: [PATCH] Add new option 'org-imenu-flatten')

[Ihor Radchenko]

Eli Zaretskii  writes:

>> I am wondering if it makes more sense to add this "flatten" option
>> globally into imenu instead.
>
> I'm not sure I understand what you are asking.  As we don't seem to
> have an active maintainer of imenu on board, more details are needed
> to understand the request.  Of course, patches are even more welcome.

Normally, `imenu' supports nested menus, when users select the target
location in steps, like item3  -> item3.1  -> ...

What is proposed is to list all the sub-menus together, as an option, so
that the users can choose, for example, item.3.1 directly, without going
through parent item3.

> Also, should this be a new bug report? the one mentioned in the CC is
> already closed and archived.

Maybe. I was just not sure how I can create a new bug report, while
still replying to Org mode feature request.

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

Re: Completion of links to man pages

[Ihor Radchenko]

Max Nikulin  writes:

> I am unsure if the code below is appropriate for :complete property of 
> "man" link. It does not rely on any double-dash functions or variables, 
> but it still uses some implementation details since there is no suitable 
> high level functions in man.el and woman.el from Emacs.
>
> (defun org-man-complete ( _arg)
>"Helper for completion of links to man pages."
>(concat
> "man:"
> (let ((completion-ignore-case t)) ; See `man' comments.
>   (funcall
>(if (eq org-man-command 'woman)
>#'org-man--complete-woman
>  #'org-man--complete-man)
>"Manual entry: "
>
> (defun org-man--complete-man (prompt)
>(require 'man)
>(let (Man-completion-cache)
>  (completing-read
>   prompt
>   'Man-completion-table)))
> ...

Considering that the discussion on emacs-devel concluded that woman is
obsolete, that no interest has been shown in introducing a stable
completion API, and that the "man" part of the above code is reasonably
simple, I think that the above two functions would be an OK addition to
ol-man (with woman part of `org-man-complete' removed).

Max, may you convert this into a patch?

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

Re: [FR] Allow flattened imenu index (was: [PATCH] Add new option 'org-imenu-flatten')

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: emacs-orgmode@gnu.org, 58...@debbugs.gnu.org, emacs-de...@gnu.org 
> Date: Sat, 09 Dec 2023 10:57:15 +
> 
> Morgan Smith  writes:
> 
> > Ihor Radchenko  writes:
> >
> >> Have you considered adding a "flatten" option to imenu itself?
> >> That way, you could automatically get the functionality for free
> >> everywhere, not just in Org mode.
> >
> > I have considered that but gave up with minimal investigation because it
> > seemed harder then this solution.  It's possible imenu did actually have
> > this functionality sometime before 1998 (see commit
> > fe2908be7b09f4c765ebdaf16fe07b0a77f78ba8).
> >
> > The doc-view imenu-flatten stuff was added 2022-09-28 (see commit
> > fe002cc8ce38efb256a2a60660ee626c2b2cdf81).  This makes me feel like
> > maybe that person thought adding it to imenu directly would be hard.
> >
> > I might at some point investigate doing that but likely not soon.  Also
> > if that feature was ever added, it would still be compatible with the
> > patch I sent.  For those reasons, I advocate my patch should still be
> > applied even though it is clear that it is a sub-optimal solution.
> 
> I'd prefer to ask Emacs upstream first.
> 
> We are discussing adding a new feature to Org imenu - an option to
> flatten the menu, so that all the nested index entries are displayed at
> top level.
> 
> This feature is also present in doc-view via `doc-view-imenu-flatten',
> and in python.el via `python-imenu-create-flat-index'
> 
> I am wondering if it makes more sense to add this "flatten" option
> globally into imenu instead.

I'm not sure I understand what you are asking.  As we don't seem to
have an active maintainer of imenu on board, more details are needed
to understand the request.  Of course, patches are even more welcome.

Also, should this be a new bug report? the one mentioned in the CC is
already closed and archived.

Thanks.

Re: [FR] Enhancing footnote managment (via indirect buffer)?

[Ihor Radchenko]

Ihor Radchenko  writes:

> It has been two months since the last message here.

Closing due to inactivity.
Canceled.

"Closing" does not mean that this feature will not be accepted. I am
just removing it from the list of tracked tasks that require maintainer
attention.

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

Re: oeg-add-note and double backslash ?

[Ihor Radchenko]

David Masterson  writes:

>> We do document the line breaks in
>> https://orgmode.org/manual/Paragraphs.html
>
> The only thing I see with respect to '\\' is:
>
>   Paragraphs are separated by at least one empty line.  If you need to
>   enforce a line break within a paragraph, use ‘\\’ at the end of a line.
>
> Which doesn't answer the question of why org-add-note (etc) added it the
> end of the first line of a Note which lead to my confusion. It's easy to
> assume, if Org is adding '\\' to the first line of the Note and the Note
> is a unit, then this is there to prevent folding/wrapping in the Note
> when Org does "something" (but what?).

Line break is a "forced" break of a line in paragraph. When there is a
line break, paragraph does not re-flow to the page width.

Re-flow may imply different things, including `fill-region' command in
Emacs or paragraph layout during export.

The detailed reason why we use this particular markup is that
otherwise some internal code assumptions inside Org mode may break when
users run `fill-region' on the notes. This is an internal implementation
detail which should not be explained in the manual.

What we might explain better is what is a line break, although I am not
very sure what to explain here - I may be too familiar with the concept
from my LaTeX-foo.

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

[FR] Allow flattened imenu index (was: [PATCH] Add new option 'org-imenu-flatten')

[Ihor Radchenko]

Morgan Smith  writes:

> Ihor Radchenko  writes:
>
>> Have you considered adding a "flatten" option to imenu itself?
>> That way, you could automatically get the functionality for free
>> everywhere, not just in Org mode.
>
> I have considered that but gave up with minimal investigation because it
> seemed harder then this solution.  It's possible imenu did actually have
> this functionality sometime before 1998 (see commit
> fe2908be7b09f4c765ebdaf16fe07b0a77f78ba8).
>
> The doc-view imenu-flatten stuff was added 2022-09-28 (see commit
> fe002cc8ce38efb256a2a60660ee626c2b2cdf81).  This makes me feel like
> maybe that person thought adding it to imenu directly would be hard.
>
> I might at some point investigate doing that but likely not soon.  Also
> if that feature was ever added, it would still be compatible with the
> patch I sent.  For those reasons, I advocate my patch should still be
> applied even though it is clear that it is a sub-optimal solution.

I'd prefer to ask Emacs upstream first.

We are discussing adding a new feature to Org imenu - an option to
flatten the menu, so that all the nested index entries are displayed at
top level.

This feature is also present in doc-view via `doc-view-imenu-flatten',
and in python.el via `python-imenu-create-flat-index'

I am wondering if it makes more sense to add this "flatten" option
globally into imenu instead.

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

Re: [BUG] ox-odt.el overrides auto-mode-alist defaults [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Peter Prevos  writes:

> ox-odt.el overrides the auto-mode-alist settings and instructs 
> Emacs to open od[fgpst] files in archive-mode instead of 
> doc-view-mode.
>
> This line can be removed because it prevents Emacs from opening 
> LibreOffice files.

Confirmed.
AFAIU, the reason that change is made is a line in
`org-odt--export-wrap' where the exporter
"Open the OpenDocument file in archive-mode for examination."

However, most users probably don't have a chance for "examination" as
the file is opened in the background without notice in the message
buffer or manual. It is also a side effect no other export backend has.

So, I am inclined to remove that code in `org-odt--export-wrap' and then
remove the code altering `auto-mode-alist' (which is definitely
something we must not do). See the attached patch set.

I am not applying the patches yet just in case if some users are relying
on the removed behaviour. If anyone reading this does use this undocumented
feature, please reply, and we will discuss how to retain it.

>From f60b3b4f2d9159ac367c08bfb7e024d0faeb1d3b Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Sat, 9 Dec 2023 11:37:02 +0100
Subject: [PATCH 1/2] lisp/ox-odt.el: Do not open the generated exported file
 in the background

* lisp/ox-odt.el (org-odt--export-wrap): Do not open the exported file
in the background.  Such behavior is not consistent with the other
export backends and is not documented (users don't know about it).
* etc/ORG-NEWS (ODT export no longer opens the exported file in the
background): Document the breaking change.
---
 etc/ORG-NEWS   | 7 +++
 lisp/ox-odt.el | 3 ---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 59c45b2aa..439323f00 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,13 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** ODT export no longer opens the exported file in the background
+
+ODT exporter used to open the exported file in ~archive-mode~ "for
+examination".  This was not documented, was done in the background,
+and is not consistent with all other export backends. Now, this
+feature is removed.
+
 *** ~org-src-associate-babel-session~ and ~org-babel--associate-session~ are now obsolete
 
 This functionality is not documented, rarely used and can be achieved
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 8d3a48394..e51547f48 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -4081,9 +4081,6 @@ (defmacro org-odt--export-wrap (out-file  body)
 	 (message "Created %s" (expand-file-name target))
 	 ;; Cleanup work directory and work files.
 	 (funcall --cleanup-xml-buffers)
-	 ;; Open the OpenDocument file in archive-mode for
-	 ;; examination.
-	 (find-file-noselect target t)
 	 ;; Return exported file.
 	 (cond
 	  ;; Case 1: Conversion desired on exported file.  Run the
-- 
2.42.0

>From 3508ed0df8cf28e8f5d74cc1c9e232f027055356 Mon Sep 17 00:00:00 2001
Message-ID: <3508ed0df8cf28e8f5d74cc1c9e232f027055356.1702118852.git.yanta...@posteo.net>
In-Reply-To: 
References: 
From: Ihor Radchenko 
Date: Sat, 9 Dec 2023 11:38:22 +0100
Subject: [PATCH 2/2] lisp/ox-odt.el: Do not alter `auto-mode-alist'

Reported-by: Peter Prevos 
Link: https://orgmode.org/list/87wmtoosru@prevos.net
---
 lisp/ox-odt.el | 5 -
 1 file changed, 5 deletions(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index e51547f48..c209e01a6 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -4349,11 +4349,6 @@ (defun org-odt-convert ( in-file out-fmt open)
 
 ;;; Library Initializations
 
-(dolist (desc org-odt-file-extensions)
-  ;; Let Emacs open all OpenDocument files in archive mode.
-  (add-to-list 'auto-mode-alist
-	   (cons (concat  "\\." (car desc) "\\'") 'archive-mode)))
-
 (provide 'ox-odt)
 
 ;; Local variables:
-- 
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] Set Python shell in Org edit buffer

[Ihor Radchenko]

Liu Hui  writes:

>> 2. Check the new variable and attempt to run
>>`org-babel--associate-session' in org-src-mode definition.
>
> I think associating the edit buffer with some session doesn't require
> starting the session, which is at least feasible for ob-python. When
> editing python src block, users can use C-c C-p to start the session
> themselves for evaluating code. So it would be nice to allow a value
> of 'associate in the customization, which means just running
> `org-babel--associate-session'.

I think we have a misunderstanding here.

Didn't we just discuss that C-c C-p in python is not equivalent to
`org-babel-python-initiate-session'?

Also, by "start a new session" I meant "start a new session if there is
none running already; if a session is already running, unconditionally
associate Org Src buffer with that running session".

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

Re: [PATCH] Move files when using org-babel-tangle-publish

[Ihor Radchenko]

Antero Mejr  writes:

> Ihor Radchenko  writes:
>
>> Also, may I know if you have an FSF copyright assignment? If not, you
>> also need to add TINYCHANGE to the commit message - see
>> https://orgmode.org/worg/org-contribute.html#first-patch
>
> Yes I have assigned copyright to the FSF already.

Bastien, may you please confirm?

>> I think that it would be nice to add a brief comment why `rename-file'
>> to the code as well.  `copy-file' looks innocent there from a first
>> glance.
>
> Fixed in attached patch.

Thanks!
Applied, onto main, adding a link to this thread in the commit message
and an extra sentence to the comment.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=478576749

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