Re: [SUMMARY] [[bbb:OrgMeetup]] on Wed, Aug 9, 19:00 UTC+3

[Esteban Ordóñez]

Thank you for the great summary, Ihor Radchenko!

Re: Htmlize support, maintenance, and Org mode (was: [MAINTENANCE] Org orphanage?)

[Samuel Wales]

[fyi that is probably not related: i use htmlize.el for functions it
has that allow you to copy a region omitting invisible parts.  e.g.
partly folded magit.  i haven't found other code that workd for that
and myb rain could not construct any.]


On 8/13/23, Ihor Radchenko  wrote:
> Jonas Bernoulli  writes:
>
>> `htmlize' is currently maintained at
>> https://github.com/hniksic/emacs-htmlize
>> but its maintainer hasn't been responding to any issues and pull-requests
>> for quite some time now and seems to be inactive on Github altogether.
>
> Hmm... Org has built-in htmlize support and I did not know that it is
> not maintained actively.
>
> Note that Timothy wrote https://github.com/tecosaur/engrave-faces that
> provides similar functionality but not just for HTML.
>
> We might consider extending engrave-faces to cover all the htmlize
> features.
>
>> Regardless of where this package will eventually end up being
>> maintained, it would be a good idea to keep it on Github at least until
>> most of the issues and pull-requests that have already been opened there
>> have been resolved.
>
> Or we can simply hand-pick that 13 open Github issues and transfer them
> manually. (Does not mean that we have to do it, but I see not why having
> a few issues on Github should be a blocker to anything)
>
>> It seems to me it would be a good idea if Hrvoje gave one or more Org
>> maintainer commit access to this repository.  Alternatively we could
>> maintain it at https://github.com/emacsorphanage/htmlize, and I could
>> take care of giving commit access, but in that case Hrvoje would also
>> have to get involved briefly at least, to transfer the repository to
>> that organization.
>
> Also an option.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

unable to do much of a search atm.  but i recall 3-4 org vars that
used to say so in their docstrings but didn't seem to need to be to me
at the time.  perhaps they have been fixed or i was mistaken.

regexp components docstring in bugfix still say reload or restart.
biut mayube that is obsolete.

i found possible examples in appt and ediff bot those are not org.  so
perhaps this is a case where the problem no longer exists?  8if so,
then never mind that comment about guideline for not requiring setting
before org where possible.

perhaps these are unavoidable.

bugfix .el
g set *.el|g before|g load
org-fold-core.el:Important: This variable must be set before loading Org."
org-keys.el:Needs to be set before Org is loaded.
org-list.el:This variable needs to be set before org.el is loaded.  If you
org-list.el:This variable needs to be set before org.el is loaded.  If you
org-persist.el:This variable must be set before loading org-persist library.")
org.el:This variable needs to be set before org.el is loaded.  If you
org.el:This variable needs to be set before org.el is loaded, and you need to


On 8/13/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> 3.
>>
>> istr loading org-id is or was what enables org-ids?  i'd rather have
>> org-id work by default.  OR maybe require activating.
>
> org-id is mostly fine, except that it (1) adds a new link type. (2) adds
> a hook that saves ids before exiting Emacs.
> In general, it is not too different in its design to other link type
> providers. The only difference is better support in other Org core
> libraries, but it only plays when a user customized org-id to take
> preference over other built-in link types - not a problem for users who
> do not use org-id.
>
>> 4.
>>
>> idk if related, but some settings in org must be done before loading.
>> i'd want a guideline in which, where possible, settings can be done
>> after loading.  this is because the user might need to go through
>> contortions in .emacs.  a user can do with-eval-after-load, but
>> with-eval-before-load sounds radically grotesque.
>
> Please, list the settings you have in mind. Some things, like
> configuring Org syntax, must be loaded before Org because we have no
> other way around.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

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

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Samuel Wales]

i currently want to copy a link location and then paste that link
loadtion.  i don't recall theis breaking before.  it does now.

On 8/13/23, Ihor Radchenko  wrote:
> Bastien Guerry  writes:
>
>> Here is another suggestion:
>>
>> 1) Remove the option and make adding the dup link on top the default.
>>
>> 2) Also remove the current C-u C-u C-u arg and make it the default
>>when a region is active.
>>
>> (1) is because removing this option would be a breaking change, and
>> inflincting a new option to every user to deal with a hypothetical
>> use-case does not seem right.
>>
>> (2) should be done anyway.
>>
>> WDYT?
>
> +1
> I did not do (1) originally to maximize backwards-compatibility.
> I do not feel strongly about keeping the old behaviour as an option
> otherwise.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

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

Re: Passing table to Ruby session

[Mike Gauland]

On 11/08/23 19:47, Ihor Radchenko wrote:
On Org side, the best we might do is splitting the long command into 
multiline (if ruby REPL supports line continuation like \ this or 
similar). Of course, it will be a workaround.


I've redefined org-babel-ruby-var-to-ruby in my init.el to add a newline 
after each element in an array, which I think will work for anything 
less than a 4k-long string. Ideally, the hard-coded \n would follow the 
EOL convention of the buffer, but I haven't gotten that far yet.



(defun org-babel-ruby-var-to-ruby (var)
  "Convert VAR into a ruby variable.
Convert an elisp value into a string of ruby source code
specifying a variable of the same value."
  (if (listp var)
  (concat "[" (mapconcat #'org-babel-ruby-var-to-ruby var ", \n") "]")
    (if (eq var 'hline)
    org-babel-ruby-hline-to
  (format "%S" var

Re: org-bibtex-yank failing with error Wrong type argument: stringp, nil

[Ihor Radchenko]

Jeremias Gonzalez  writes:

> On Sun, Aug 13, 2023 at 8:44 AM Ihor Radchenko  wrote:
>
>> Does the attached patch fix the problem?
>>
>
> The patch works for me, thank you very much!

Thanks for testing!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=99cc9619c
Fixed.

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

Re: org-bibtex-yank failing with error Wrong type argument: stringp, nil

[Jeremias Gonzalez]

On Sun, Aug 13, 2023 at 8:44 AM Ihor Radchenko  wrote:

> Does the attached patch fix the problem?
>

The patch works for me, thank you very much!

Re: org-bibtex-yank failing with error Wrong type argument: stringp, nil

[Ihor Radchenko]

Jeremias Gonzalez  writes:

>> Do I understand correctly that you attempted to run org-bibtex-read from
>> a non-bibtex buffer?
>>
>
> At a top level, I was using org-bibtex-yank with an org buffer (and in my
> ideal case with no bibtex buffers whatsoever) as the documentation for that
> function only requires bibtex to be in the kill ring. However, yes,
> org-bibtex-yank calls org-bibtex-read, and I was doing so (in the ideal
> case) with a non-bibtex buffer.

Does the attached patch fix the problem?

>From 67c15a645f98f25af4db37830d632e9daf875e5e Mon Sep 17 00:00:00 2001
Message-ID: <67c15a645f98f25af4db37830d632e9daf875e5e.1691941444.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sun, 13 Aug 2023 18:41:59 +0300
Subject: [PATCH] org-bibtex-yank: Fix bibtex parser not initialized in temp
 buffer

* lisp/ol-bibtex.el (org-bibtex-yank): Make sure that we parse bibtex
entry from the kill ring in a `bibtex-mode' buffer.  Otherwise,
calling `org-bibtex-read' (that calls `bibtex-parse-entry') may err
because some Bibtex parser variables are not initialized.

Reported-by: J. G. 
Link: https://orgmode.org/list/1939460027.3272000.1691771671...@mail.yahoo.com
---
 lisp/ol-bibtex.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ol-bibtex.el b/lisp/ol-bibtex.el
index 4308424a3..17fbb9fbd 100644
--- a/lisp/ol-bibtex.el
+++ b/lisp/ol-bibtex.el
@@ -765,7 +765,10 @@ (defun org-bibtex-yank ()
   "If kill ring holds a bibtex entry yank it as an Org headline."
   (interactive)
   (let (entry)
-(with-temp-buffer (yank 1) (setf entry (org-bibtex-read)))
+(with-temp-buffer
+  (yank 1)
+  (bibtex-mode)
+  (setf entry (org-bibtex-read)))
 (if entry
 	(org-bibtex-write)
   (error "Yanked text does not appear to contain a BibTeX entry"
-- 
2.41.0


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

Htmlize support, maintenance, and Org mode (was: [MAINTENANCE] Org orphanage?)

[Ihor Radchenko]

Jonas Bernoulli  writes:

> `htmlize' is currently maintained at https://github.com/hniksic/emacs-htmlize
> but its maintainer hasn't been responding to any issues and pull-requests
> for quite some time now and seems to be inactive on Github altogether.

Hmm... Org has built-in htmlize support and I did not know that it is
not maintained actively.

Note that Timothy wrote https://github.com/tecosaur/engrave-faces that
provides similar functionality but not just for HTML.

We might consider extending engrave-faces to cover all the htmlize
features.

> Regardless of where this package will eventually end up being
> maintained, it would be a good idea to keep it on Github at least until
> most of the issues and pull-requests that have already been opened there
> have been resolved.

Or we can simply hand-pick that 13 open Github issues and transfer them
manually. (Does not mean that we have to do it, but I see not why having
a few issues on Github should be a blocker to anything)

> It seems to me it would be a good idea if Hrvoje gave one or more Org
> maintainer commit access to this repository.  Alternatively we could
> maintain it at https://github.com/emacsorphanage/htmlize, and I could
> take care of giving commit access, but in that case Hrvoje would also
> have to get involved briefly at least, to transfer the repository to
> that organization.

Also an option.

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

Re: org-bibtex-yank failing with error Wrong type argument: stringp, nil

[Jeremias Gonzalez]

On Sun, Aug 13, 2023 at 12:57 AM Ihor Radchenko  wrote:

> "J. G."  writes:
>
> > Adding the following two lines to my init fixes the error in my case:
> > (require 'bibtex)(bibtex-set-dialect 'biblatex nil)
>
> Do I understand correctly that you attempted to run org-bibtex-read from
> a non-bibtex buffer?
>

At a top level, I was using org-bibtex-yank with an org buffer (and in my
ideal case with no bibtex buffers whatsoever) as the documentation for that
function only requires bibtex to be in the kill ring. However, yes,
org-bibtex-yank calls org-bibtex-read, and I was doing so (in the ideal
case) with a non-bibtex buffer.

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[Ihor Radchenko]

"Valentin G. J. Herrmann" via "General discussions about Org-mode."
 writes:

> In the attachments is a better version with tests that also addresses 
> your latest critique.

Thanks!

> +  (setq time
> +(save-match-data
> +  (org-time-string-to-time ts)))
> +  (unless (equal what "h")
> +(setq time
> +  (time-add time
> +(seconds-to-time (* 3600 
> org-extend-today-until)))

Another corner case:

(setq org-extend-today-until 4)
* TODO Heading
<2023-08-12 Sat 17:00 ++1d> Timestamp a bit (< 4 hours) earlier than current 
wall time

C-c C-t d
* TODO Heading
<2023-08-13 Sun 17:00 ++1d>

Expected:
* TODO Heading
<2023-08-14 Mon 17:00 ++1d>

I generally feel that the approach with `time-add' will have a number of
weird corner cases.

-- 
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: Respect org-extend-today-until in timestamps with ++

[Valentin G. J. Herrmann]

In the attachments is a better version with tests that also addresses 
your latest critique.


On 13/08/2023 14.44, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
>
>>>   (while (or (= nshift 0)
>>> -   (not (time-less-p nil time)))
>>> +   (not (time-less-p nil (time-add 
time-to-extend time

>>
>> And this compares "now" with year 1970. Will always return nil.
>
> Hmm. I somehow missed `time-add'.
> However, this is still fishy.
> What if we have something like <2023-08-13 2:00 ++8h>?
> `org-extend-today-until' should probably be ignored then.From 317ab3f132825af9e5caaf0dc1812df545f0ad5f Mon Sep 17 00:00:00 2001
From: Valentin Herrmann 
Date: Sun, 13 Aug 2023 09:48:42 +0200
Subject: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that
switching a repeating todo with a timestamp of the form <… ++…> respects
`org-extend-today-until'.
---
 lisp/org.el  | 10 +++---
 testing/lisp/test-org.el | 33 +
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index c037b3ee0..9c98d7538 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10111,9 +10111,13 @@ enough to shift date past today.  Continue? "
 			  (org-timestamp-change n (cdr (assoc what whata)))
 			  (org-in-regexp org-ts-regexp3)
 			  (setq ts (match-string 1))
-			  (setq time
-(save-match-data
-  (org-time-string-to-time ts)
+  (setq time
+(save-match-data
+  (org-time-string-to-time ts)))
+  (unless (equal what "h")
+(setq time
+  (time-add time
+(seconds-to-time (* 3600 org-extend-today-until)))
 		  (org-timestamp-change (- n) (cdr (assoc what whata)))
 		  ;; Rematch, so that we have everything in place
 		  ;; for the real shift.
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 1b00f6c45..0cf765af4 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -8390,6 +8390,39 @@ Paragraph"
   (org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+8h>"
 	(org-todo "DONE")
 	(buffer-string)
+  ;; Handle `org-extend-today-until'.
+  (should
+   (string-match-p
+"2014-03-04 .* 18:00"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-02 18:00 ++1d>"
+	  (org-todo "DONE")
+	  (buffer-string))
+  (should
+   (string-match-p
+"2014-03-04 .* 10:00"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 ++8h>"
+	  (org-todo "DONE")
+	  (buffer-string))
+  (should
+   (string-match-p
+"2014-03-04 .* 18:00"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+1d>"
+	  (org-todo "DONE")
+	  (buffer-string))
+  (should
+   (string-match-p
+"2014-03-04 .* 10:35"
+(let ((org-extend-today-until 4))
+  (org-test-at-time "<2014-03-04 02:35>"
+(org-test-with-temp-text "* TODO H\n<2014-03-03 18:00 .+8h>"
+	  (org-todo "DONE")
+	  (buffer-string))
   ;; Do not repeat inactive time stamps with a repeater.
   (should-not
(string-match-p
-- 
2.40.1

Re: [patch] Fix inner smart quotes in French

[Ihor Radchenko]

Bastien Guerry  writes:

>> Are you referring to `org-export-smart-quotes-alist'? It is a defconst.
>
> Ah, indeed.  I'd say using a defcustom here would be useful.

Is changing defconst to defcustom ok for bugfix?

-- 
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: Respect org-extend-today-until in timestamps with ++

[Ihor Radchenko]

Ihor Radchenko  writes:

>>  (while (or (= nshift 0)
>> -   (not (time-less-p nil time)))
>> +   (not (time-less-p nil (time-add 
>> time-to-extend time
>
> And this compares "now" with year 1970. Will always return nil.

Hmm. I somehow missed `time-add'.
However, this is still fishy.
What if we have something like <2023-08-13 2:00 ++8h>?
`org-extend-today-until' should probably be ignored then.

-- 
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: Respect org-extend-today-until in timestamps with ++

[Ihor Radchenko]

Valentin Herrmann via "General discussions about Org-mode."
 writes:

> * org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that
> switching a repeating todo with a timestamp of the form <… ++…> respects
> `org-extend-today-until'.

Thanks, this would make sense. However, I have comments on your patch.

> - (nshift 0))
> + (nshift 0)
> +(time-to-extend (seconds-to-time (* 3600 
> org-extend-today-until

This will return time since epoch:

(format-time-string "%x %X" (seconds-to-time (* 3600 org-extend-today-until)))
;; => "01/01/1970 06:00:00 AM"

>   (while (or (= nshift 0)
> -(not (time-less-p nil time)))
> +   (not (time-less-p nil (time-add 
> time-to-extend time

And this compares "now" with year 1970. Will always return nil.

It would make things easier if you added a test for this fix into
`test-org/auto-repeat-maybe' in testing/lisp/test-org.el

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

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Ihor Radchenko]

Bastien Guerry  writes:

> Here is another suggestion:
>
> 1) Remove the option and make adding the dup link on top the default.
>
> 2) Also remove the current C-u C-u C-u arg and make it the default
>when a region is active.
>
> (1) is because removing this option would be a breaking change, and
> inflincting a new option to every user to deal with a hypothetical
> use-case does not seem right.
>
> (2) should be done anyway.
>
> WDYT?

+1
I did not do (1) originally to maximize backwards-compatibility.
I do not feel strongly about keeping the old behaviour as an option
otherwise.

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

Re: [DISCUSSION] The future of org-mouse.el and org-inlinetask.el

[Ihor Radchenko]

Bastien Guerry  writes:

>> *> TODO inlinetask
>> Inlinetask contents
>> *> END
>
> -1 on this one -- I'd rather get rid of the
>
> * TODO ...
> * END
>
> construct altogether.

I also don't like it, but have no better idea about a good markup to
identify inlinetask body.

Might be

*> TODO inlinetask
...
*<

but it feels against how other Org markup works.

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

Re: [patch] Fix inner smart quotes in French

[Bastien Guerry]

Ihor Radchenko  writes:

>> It's difficult to say what's more common but since we cannot expect
>> the « « inner » » style to be correctly implemented in, say, HTML, and
>> since, even in LaTeX, babel-french defaults to the « “inner” » style,
>> I suggest we stick to the « “inner” » style (this is a defcustom and
>> users can change it.)
>
> Are you referring to `org-export-smart-quotes-alist'? It is a defconst.

Ah, indeed.  I'd say using a defcustom here would be useful.

-- 
 Bastien Guerry

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Bastien Guerry]

Hi Ihor,

Thanks for bearing with me while I discuss something is done, required
time and work, and isn't probably a priority.

Ihor Radchenko  writes:

> Bastien Guerry  writes:
>
>> (1) by always store the latest link on top and remove old dups.
>>
>> (2) always store latest link at the top and remove old dups and allow
>> to keep dups with 3 universal prefix args.
>> ...
>> I'm in favor of option (2) as it deals with the above use-case, and
>> storing a link for each lines in the active region should be the
>> default behavior anyway, with no need for a prefix arg.
>>
>> WDYT?
>
> I am not sure if C-u C-u C-u override is the best design.
> If the user wants to store duplicates, she will be forced to use C-u C-u
> C-u every single time. And a single slip forgetting to use the prefix
> arg will clear the already stored duplicates.

I am not convinced there are many users who want duplicate links by
default.  My guess is that for most users and in most cases, duplicate
links are unwanted -- in +10 years, nobody complained about the fact
that dups were not stored.

> Also, it is not clear how to use a single C-u or double C-u C-u yet
> keeping duplicates.

Indeed, that's an issue.

Here is another suggestion:

1) Remove the option and make adding the dup link on top the default.

2) Also remove the current C-u C-u C-u arg and make it the default
   when a region is active.

(1) is because removing this option would be a breaking change, and
inflincting a new option to every user to deal with a hypothetical
use-case does not seem right.

(2) should be done anyway.

WDYT?

-- 
 Bastien Guerry

Re: [DISCUSSION] The future of org-mouse.el and org-inlinetask.el

[Bastien Guerry]

Ihor Radchenko  writes:

> I'd say that we should not remove org-mouse.el, but instead load it by
> default. Maybe even fully integrating org-mouse.el into other libraries
> like org-keys.el and org.el.

+1 on that.

> For example, we can define inlinetasks as
>
> *> TODO inlinetask
> ***> TODO inlinetask
> ...

+1 on this one.

> *> TODO inlinetask
> Inlinetask contents
> *> END

-1 on this one -- I'd rather get rid of the

* TODO ...
* END

construct altogether.

-- 
 Bastien Guerry

Re: [patch] Fix inner smart quotes in French

[Ihor Radchenko]

Bastien Guerry  writes:

>> What I
>> don't know is why babel-french defaults to the « “inner” » style. Is it
>> the most used currently in France? If the « « inner » » style is more
>> canonical, I don't mind having my patch 'fix' reverted.
>
> It's difficult to say what's more common but since we cannot expect
> the « « inner » » style to be correctly implemented in, say, HTML, and
> since, even in LaTeX, babel-french defaults to the « “inner” » style,
> I suggest we stick to the « “inner” » style (this is a defcustom and
> users can change it.)

Are you referring to `org-export-smart-quotes-alist'? It is a defconst.

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

Re: [patch] Fix inner smart quotes in French

[Bastien Guerry]

Hi Juan,

Juan Manuel Macías  writes:

> In any case (apart from LaTeX), it is clear that I was wrong when I said
> that the inner quotes that my patch 'corrects' were 'incorrect'. 

Indeed, and thanks for the discussion, interesting.

> What I
> don't know is why babel-french defaults to the « “inner” » style. Is it
> the most used currently in France? If the « « inner » » style is more
> canonical, I don't mind having my patch 'fix' reverted.

It's difficult to say what's more common but since we cannot expect
the « « inner » » style to be correctly implemented in, say, HTML, and
since, even in LaTeX, babel-french defaults to the « “inner” » style,
I suggest we stick to the « “inner” » style (this is a defcustom and
users can change it.)

Thanks!

-- 
 Bastien Guerry

[PATCH] org.el: Respect org-extend-today-until in timestamps with ++

[General discussions about Org-mode.]

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that
switching a repeating todo with a timestamp of the form <… ++…> respects
`org-extend-today-until'.
---
 lisp/org.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index c037b3ee0..d9cc9bee6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10099,9 +10099,10 @@ This function is run automatically after each state 
change to a DONE state."
 (- (org-today) (time-to-days time)) 'day)))
 ((equal "+" repeater-type)
  (let ((nshiftmax 10)
-   (nshift 0))
+   (nshift 0)
+(time-to-extend (seconds-to-time (* 3600 
org-extend-today-until
(while (or (= nshift 0)
-  (not (time-less-p nil time)))
+   (not (time-less-p nil (time-add 
time-to-extend time
  (when (= nshiftmax (cl-incf nshift))
(or (y-or-n-p
 (format "%d repeater intervals were not \
-- 
2.40.1

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> 3.
>
> istr loading org-id is or was what enables org-ids?  i'd rather have
> org-id work by default.  OR maybe require activating.

org-id is mostly fine, except that it (1) adds a new link type. (2) adds
a hook that saves ids before exiting Emacs.
In general, it is not too different in its design to other link type
providers. The only difference is better support in other Org core
libraries, but it only plays when a user customized org-id to take
preference over other built-in link types - not a problem for users who
do not use org-id.

> 4.
>
> idk if related, but some settings in org must be done before loading.
> i'd want a guideline in which, where possible, settings can be done
> after loading.  this is because the user might need to go through
> contortions in .emacs.  a user can do with-eval-after-load, but
> with-eval-before-load sounds radically grotesque.

Please, list the settings you have in mind. Some things, like
configuring Org syntax, must be loaded before Org because we have no
other way around.

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

[DISCUSSION] The future of org-mouse.el and org-inlinetask.el (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

[Ihor Radchenko]

Bastien Guerry  writes:

> Also, I'm not sure org-mouse.el has its place in Org's core nowadays.

org-mouse implements mouse bindings + context menus.
Context menu support is something that major modes generally expect to
provide:

24.2.1 Major Mode Conventions
   • Consider adding mode-specific context menus for the mode, to be
 used if and when users activate the ‘context-menu-mode’ (*note
 (emacs)Menu Mouse Clicks::).  To this end, define a mode-specific
 function which builds one or more menus depending on the location
 of the ‘mouse-3’ click in the buffer, and then add that function to
 the buffer-local value of ‘context-menu-functions’.

And better mouse support is getting more important in a view of recent
native Android port of Emacs, where "mouse" is the main mode of
interaction.

I'd say that we should not remove org-mouse.el, but instead load it by
default. Maybe even fully integrating org-mouse.el into other libraries
like org-keys.el and org.el.

>> It changes the very notion of that is a headline - the syntax definition
>> is altered. Very deeply nested headlines may become inlinetasks upon
>> loading org-inlinetask, touching all aspects of Org, not just editing.
>
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.

org-inlinetask, if removed, is bound to break unless we maintain
inlinetask support in the core. And it will be a feature regression for
a number of users (for me, at least - I am a big user of inlinetasks
myself).

However, the current way inlinetasks are implemented is definitely not
great. The clash between headings and inlinetask syntax is getting too
much on the way.

May we re-consider inlinetask syntax and come up with an alternative
syntax that does not clash with headings? This will make things a lot
easier to maintain and allow us to gradually deprecate the existing
 syntax.

For example, we can define inlinetasks as

*> TODO inlinetask
***> TODO inlinetask
...

*> TODO inlinetask
Inlinetask contents
*> END

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

Re: [PATCH] Testing: Ensure 'org-id-locations-file' is set before updating

[Ihor Radchenko]

Max Nikulin  writes:

>> In the absence of clear understanding what went wrong, I cannot accept
>> this patch, unfortunately.
>
> mkdir ~/hide
> mv -i ~/.emacs* ~/hide
> make test-dirty BTEST_RE=test-org-link
>
> Finding ID locations (26/26 files): 
> /home/ubuntu/src/org-mode/testing/examples/agenda-file.org
> Opening output file: No such file or directory, 
> /home/ubuntu/.emacs.d/.org-id-locations
> make: *** [mk/targets.mk:100: test-dirty] Error 255
>
> I have not looked closely into the proposed patch, but I find it 
> reasonable expectation that tests should not write to ~/.emacs.d/

Thanks for the reproducer!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0830f94e

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

Re: how can I get the output of a =#+begin_src org= in the current buffer?

[Ihor Radchenko]

Edgar Lux  writes:

> Regarding the typo, it does not show here. But in the info buffer, the =(see 
> *note...= becomes (see see ...).
>
> See (:P) attachment

This is some info rendering bug in Emacs 28. Nothing to do with Org.
Also, it no longer occurs in Emacs 29.

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

Re: [BUG] make cursor visible in calendar [9.6.7 ( @ /Users/eugenekim/.emacs.d/elpa/org-9.6.7/)]

[Ihor Radchenko]

eugene kim  writes:

> I'd like to see the cursor when using keyboard to select a date from the
> calendar when I use
> org's schedule or deadline.
>
> It can be done with keyboard, but the cursor is not visible.

May you please provide steps to reproduce the problem?
For me, the selected date is highlighted in date selection prompt.

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

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Ihor Radchenko]

Juan Manuel Macías  writes:

>>> +   (concat "\\("
>>> +   (regexp-quote org-latex-line-break-safe)
>>> +   "\n\\)"
>>> +   "\\(^[ \t]*"
>>> +   (regexp-quote org-latex-line-break-safe)
>>> +   "\n"
>>> +   "\\)+")
>>> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) 
>>> "$"))
>>
>> May also use rx for better readability.
>
> I remember that I tried rx a while ago and found it very useful and
> comfortable, but then I haven't done anything with it. The fact is that
> over time I have ended up getting used to suffering from the classic
> regexp and it is hard for me to get out of there :-). Of course, with rx
> it would be clearer but I would have to refresh my memory.

You can refer to [[info:elisp#Rx Constructs][elisp#Rx Constructs]]
I think your regexp in rx should look like

(rx-to-string `(seq (group ,org-latex-line-break-safe "\n")
(1+ (group line-start (0+ space) ,org-latex-line-break 
"\n"

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

Re: [BUG] Warning (org-element-cache)

[Ihor Radchenko]

Carmen Shea  writes:

> The following Warning message appeared while I was entering text into an 
> Org-Roam file.
>
>   [BUG] Warning (org-element-cache): org-elemt--cache: Org parser error 
> in 2023073121272-student_reports_august_2023.org::7669. Resetting. The 
> error was: (wrong-type-argument integer-or-marker-p nil) Backtrace: nil 
> [9.6.7 (N/A @ 
> /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]
> ...
>
> Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.37, cairo version 1.16.0)
> Package: Org mode version 9.6.7 (N/A @ 
> /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)

Thanks for reporting!
May you set debug-on-error to t and report the backtrace next time you
encounter the error?

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

Re: org-bibtex-yank failing with error Wrong type argument: stringp, nil

[Ihor Radchenko]

"J. G."  writes:

> Adding the following two lines to my init fixes the error in my case:
> (require 'bibtex)(bibtex-set-dialect 'biblatex nil)

Do I understand correctly that you attempted to run org-bibtex-read from
a non-bibtex buffer?

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

Re: [BUG][SECURITY] ob-sqlite header args allows execution of arbitrary shell commands

[Ihor Radchenko]

Max Nikulin  writes:

>  8< 
> #+begin_src elisp :results none
>(require 'ob-sqlite)
> #+end_src
>
> #+begin_src sqlite :db /tmp/ob.sqlite$(date >/tmp/ob-sqlite-vuln.log)
>select 1
> #+end_src
>  >8 
>
> Executing of the sqlite code block causes creation of the 
> /tmp/ob-sqlite-vuln.log file.
>
> The cause is usage of `org-fill-template' without `shell-quote-argument'.

Confirmed.

This is clearly very common.
What do you think about creating a new API to built shell commands and
then using it across all the babel backends?

See the attached tentative diff.

diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 7510e5158..27e495fce 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -77,26 +77,20 @@ (defun org-babel-execute:sqlite (body params)
 (with-temp-buffer
   (insert
(org-babel-eval
-	(org-fill-template
-	 "%cmd %header %separator %nullvalue %others %csv %db "
-	 (list
-	  (cons "cmd" org-babel-sqlite3-command)
-	  (cons "header" (if headers-p "-header" "-noheader"))
-	  (cons "separator"
-		(if separator (format "-separator %s" separator) ""))
-	  (cons "nullvalue"
-		(if nullvalue (format "-nullvalue %s" nullvalue) ""))
-	  (cons "others"
-		(mapconcat
-		 (lambda (arg) (format "-%s" (substring (symbol-name arg) 1)))
-		 others " "))
-	  ;; for easy table parsing, default header type should be -csv
-	  (cons "csv" (if (or (member :csv others) (member :column others)
-			  (member :line others) (member :list others)
-			  (member :html others) separator)
-			  ""
-			"-csv"))
-  (cons "db" (or db ""
+(org-make-shell-command
+ org-babel-sqlite3-command
+ (if headers-p "-header" "-noheader")
+ (when separator (format "-separator %s" separator))
+ (when nullvalue (format "-nullvalue %s" nullvalue))
+ (mapcar
+	  (lambda (arg) (format "-%s" (substring (symbol-name arg) 1)))
+	  others)
+ ;; for easy table parsing, default header type should be -csv
+ (unless (or (member :csv others) (member :column others)
+		 (member :line others) (member :list others)
+		 (member :html others) separator)
+	   "-csv")
+ db)
 	;; body of the code block
 	(org-babel-expand-body:sqlite body params)))
   (org-babel-result-cond result-params
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 442c607d7..3c92c9405 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1592,6 +1592,33 @@ (defun org-sxhash-safe (obj  counter)
 	  (puthash hash obj org-sxhash-objects)
 	  (puthash obj hash org-sxhash-hashes)
 
+(defun org-make-shell-command (command  args)
+  "Build safe shell command string to run COMMAND with ARGS.
+
+The resulting shell command is safe against malicious shell expansion.
+
+ARGS can be nil, strings, (literal STRING), or a list of such elements.
+Strings will be quoted with `shell-quote-argument' while
+(literal STRING) will be used without quoting.
+nil values will be ignored."
+  (concat
+   command (when command " ")
+   (mapconcat
+#'identity
+(delq
+ nil
+ (mapcar
+  (lambda (str-def)
+(pcase str-def
+  (`(or nil "") nil)
+  ((pred stringp) (shell-quote-argument str-def))
+  (`(literal ,(and (pred stringp) str))
+   str)
+  ((pred listp) (apply #'org-make-shell-command nil str-def))
+  (_ (error "Unknown ARG specification: %S" str-def
+  args))
+" ")))
+
 (defun org-compile-file (source process ext  err-msg log-buf spec)
   "Compile a SOURCE file using PROCESS.
 

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