Re: Ability to add logo to HTML export

[Vladimir Alexiev]

Thanks, that works!

On Fri, Mar 24, 2023 at 4:04 PM Ihor Radchenko  wrote:

> Vladimir Alexiev  writes:
>
> > But then C-c C-e h h complains: "org-export--parse-option-keyword: End of
> > file during parsing".
>
> Please update Org mode.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Docstring fixes

[Stephen J. Eglen]

and a commit message.

org.el: Docstring fixes.

* lisp/org.el (org-hide-emphasis-markers)
(org-hide-macro-markers)
(org-pretty-entities-include-sub-superscripts): Follow elisp
convention for docstrings: 'Non-nil means ...'.



On Sat, Mar 25 2023, Stephen J. Eglen wrote:

> Some small docstring fixes to align with convention in Emacs for
> 'Non-nil means ...'
>
> Stephen
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 4d12084d9..08a6f1a50 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -3600,13 +3600,13 @@ following symbols:
>  (const :tag "Entities" entities
>  
>  (defcustom org-hide-emphasis-markers nil
> -  "Non-nil mean font-lock should hide the emphasis marker characters."
> +  "Non-nil means font-lock should hide the emphasis marker characters."
>:group 'org-appearance
>:type 'boolean
>:safe #'booleanp)
>  
>  (defcustom org-hide-macro-markers nil
> -  "Non-nil mean font-lock should hide the brackets marking macro calls."
> +  "Non-nil means font-lock should hide the brackets marking macro calls."
>:group 'org-appearance
>:type 'boolean)
>  
> @@ -3618,7 +3618,7 @@ When nil, the \\name form remains in the buffer."
>:type 'boolean)
>  
>  (defcustom org-pretty-entities-include-sub-superscripts t
> -  "Non-nil means, pretty entity display includes formatting 
> sub/superscripts."
> +  "Non-nil means pretty entity display includes formatting sub/superscripts."
>:group 'org-appearance
>:version "24.1"
>:type 'boolean)

Re: Document org-hide-emphasis-markers

[Stephen J. Eglen]

sure, sorry I missed that.  I have signed papers with FSF for all my
Emacs contribs.

Stephen

doc/org-manual.org: document org-hide-emphasis-markers.

* doc/org-manual.org (Emphasis and Monospace): Document
org-hide-emphasis-markers.






On Sun, Mar 26 2023, Ihor Radchenko wrote:

> "Stephen J. Eglen"  writes:
>
>> Here is a small patch to document org-hide-emphasis-markers
>
> Thanks!
> Could you please also add a commit message, as described in
> https://orgmode.org/worg/org-contribute.html#first-patch ?

[RFC] ox-icalendar: Unscheduled tasks & repeating tasks

[Jack Kamm]

Hello,

The attached 2 patches add support for exporting unscheduled tasks and
repeating tasks to iCalendar, respectively.

For patch 1 (unscheduled tasks):

Currently, ox-icalendar does not allow creating an iCalendar task
without a scheduled start date. If an Org TODO is missing a SCHEDULED
timestamp, then ox-icalendar sets today as the scheduled start date for
the exported task.

Patch 1 changes this by adding a new customization
org-icalendar-todo-force-scheduling. When non-nil, the start date is set
to today (same as the current behavior). When nil, unscheduled Org TODOs
are instead exported without a start date.

I also propose the default value to be nil. Note, this is
backwards-incompatible with the previous behavior!

But I think it should be the default anyways, because IMO it is the more
correct and useful behavior. An iCalendar VTODO without a DTSTART
property is valid, and has the same meaning as an Org TODO without a
SCHEDULED timestamp. Also, all the iCalendar programs I have tried
support unscheduled tasks, including Thunderbird, Evolution, Nextcloud,
and Tasks.org.

For patch 2 (repeating timestamps):

I add recurrence rule (RRULE) export for repeating SCHEDULED and
DEADLINE timestamps in TODOs, similar to how repeating non-TODO events
are currently handled.

The main complication here is that iCalendar's RRULE applies to both
DTSTART and DUE properties; by contrast, Org's SCHEDULED and DEADLINE
timestamps may have different repeaters. I am not sure the best way to
handle the case where SCHEDULED and DEADLINE have different repeaters,
so in that case I issue a warning and skip the repeater.

>From 1bd268ab260d5077d7456c0d64fea36128772f86 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Sun, 26 Mar 2023 07:43:53 -0700
Subject: [PATCH 1/2] ox-icalendar: Allow exporting unscheduled VTODOs

* lisp/ox-icalendar.el (org-icalendar-todo-force-scheduling): New
option to revert to previous export behavior of unscheduled TODOs.
(org-icalendar--vtodo): Don't force unscheduled TODOs to have a
scheduled start time of today, unless
`org-icalendar-todo-force-scheduling' is set.
---
 etc/ORG-NEWS | 15 +++
 lisp/ox-icalendar.el | 32 +---
 2 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ac233a986..fb4f82b29 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -23,6 +23,15 @@ If you still want to use python-mode with ob-python, you might
 consider [[https://gitlab.com/jackkamm/ob-python-mode-mode][ob-python-mode-mode]], where the code to support python-mode
 has been ported to.
 
+*** Icalendar export of TODOs no longer forces a start time
+
+For TODOs without a scheduled start time, ox-icalendar no longer
+forces them to have a scheduled start time of today when exporting.
+This makes it possible to create icalendar TODOs without a start time.
+
+To revert to the old behavior, set the new custom option
+~org-icalendar-todo-force-scheduling~ to non-nil.
+
 ** New and changed options
 *** New ~org-cite-natbib-export-bibliography~ option defining fallback bibliography style
 
@@ -111,6 +120,12 @@ backend used for evaluation of ClojureScript.
 official [[https://clojure.org/guides/deps_and_cli][Clojure CLI tools]].
 The command can be customized with ~ob-clojure-cli-command~.
 
+*** New ~org-icalendar-todo-force-scheduling~ option for old ox-icalendar TODO scheduling behavior
+
+Set ~org-icalendar-todo-force-scheduling~ to non-nil to revert to the
+old ox-icalendar TODO export behavior, that forced all exported TODOs
+to have a scheduled start time.
+
 ** New features
 *** Add support for ~logind~ idle time in ~org-user-idle-seconds~
 
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 81a77a770..63aefcc84 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -231,6 +231,12 @@ (defcustom org-icalendar-include-todo nil
 	  (repeat :tag "Specific TODO keywords"
 		  (string :tag "Keyword"
 
+(defcustom org-icalendar-todo-force-scheduling nil
+  "Non-nil means unscheduled tasks are exported as scheduled.
+The current date is used as the scheduled time for such tasks."
+  :group 'org-export-icalendar
+  :type 'boolean)
+
 (defcustom org-icalendar-include-bbdb-anniversaries nil
   "Non-nil means a combined iCalendar file should include anniversaries.
 The anniversaries are defined in the BBDB database."
@@ -776,21 +782,25 @@ (defun org-icalendar--vtodo
 Return VTODO component as a string."
   (let ((start (or (and (memq 'todo-start org-icalendar-use-scheduled)
 			(org-element-property :scheduled entry))
-		   ;; If we can't use a scheduled time for some
-		   ;; reason, start task now.
-		   (let ((now (decode-time)))
-		 (list 'timestamp
-			   (list :type 'active
- :minute-start (nth 1 now)
- :hour-start (nth 2 now)
- :day-start (nth 3 now)
- :month-start (nth 4 now)
- :year-start (nth 5 now)))
+   (when org-icalendar-todo-force-scheduling
+		 ;; If 

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Bruno Barbier  writes:

>> Why not simply putStrLn ("\"" ++ show it ++ "\"") ?
>>
>
> I'm not sure I understand. I'm using the first
> 'org-babel-comint-with-output' to execute the source block and save the
> last value (the "it" variable). Then, I'm using a second
> 'org-babel-comint-with-output' to make sure the output of this one
> contains only the last value. If I display "it" in the first block, I
> will not be able to differentiate between some output, previous values
> and the last value. And, printing "org-babel-haskell-eoe" updates the
> "it" variable (the last value becoming "()"), so I have to store the
> real "it" somewhere.

I see. I missed that `it' gets updated because of eoe indicator.

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

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Bruno Barbier]

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>> Note that I've changed the tests about errors; I'm now expecting
>> ob-haskell to raise errors. I'm not sure what we should expect to be
>> consistent with other org babel backends.
>
> Errors are usually displayed separately, using
> `org-babel-eval-error-notify'.

I'll see what can be done with GHCi and use this if possible.
Thanks.


>> +;; To increase the chances of failure when running tests, you can use this 
>> command line:
>> +;;
>> +;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 
>> 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty 
>> & done) 2>&1 | grep FAILED
>> +;;
>> +
>> + Status
>> +;;
>> +;; All the tests should succeed (except for random failures); those
>> +;; flagged with ":expected-result :failed" are known
>> +;; limitations/bugs.  Tested with (2023-03-18):
>> +;;
>> +;; | emacs-version |  29.0.60 |
>> +;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
>> +;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
>> +;; | ghci  |9.0.2 |
>
> You can probably remove this.

Definitely. I'll do. Thanks.



>> +(`value (org-babel-comint-with-output
>> +(session org-babel-haskell-eoe nil full-body)
>> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=()::()\n")
>> +  (comint-send-input nil t)
>> +  (insert full-body)
>> +  (comint-send-input nil t)
>> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=it\n")
>> +  (comint-send-input nil t)
>> +  (insert (concat "putStrLn (\"\\\"\" ++ " 
>> org-babel-haskell-eoe " ++ \"\\\"\")\n"))
>
> Why not simply putStrLn ("\"" ++ show it ++ "\"") ?
>

I'm not sure I understand. I'm using the first
'org-babel-comint-with-output' to execute the source block and save the
last value (the "it" variable). Then, I'm using a second
'org-babel-comint-with-output' to make sure the output of this one
contains only the last value. If I display "it" in the first block, I
will not be able to differentiate between some output, previous values
and the last value. And, printing "org-babel-haskell-eoe" updates the
"it" variable (the last value becoming "()"), so I have to store the
real "it" somewhere.

Am I missing something ?

>> +  (when (and session-name (string= session-name "none"))
>> +(setq session-name nil))
>> +  (unless session-name
>> +;; As haskell-mode is using the buffer name "*haskell*", we stay
>> +;; away from it.
>> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))
>
> This will make ob-haskell spawn a separate ghci process buffer every
> single time a user runs non-session src block. And the buffer is not
> closed after getting the result.

Very good point!

I will update this to use the same buffer named "*ob-haskell*" when the
user doesn't set the session name.  I guess it's consistent with other
org-babel backends.



Thank you very much for the review and you help!

Bruno

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

Re: Bugfix release request / agenda* fix

[Ihor Radchenko]

Ihor Radchenko  writes:

> Дмитрий Логвиненко  writes:
>
>> It would be very kind of you if you could make a bugfix release
>> including this patch.
>
> If there are no objections, I will tag a minor bugfix release this
> weekend.

Tagged a new bugfix release.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=release_9.6.2=c1e8e2ffc7e26591d89fb06beaa5309863f4eb96

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

Re: [PATCH] lisp/ob-scheme.el

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

>>> +  "Expand :var header arguments given as VARS."
>>> +  (mapconcat
>>> +   (lambda (var)
>>> + (format "(define %s %S)" (car var) (cdr var)))
>> Is there any reason why you use %s for variable name? Previously it was
>> formatted with escapes (using %S).
>
> That was me thinking: "The name of the variable should just be itself, not 
> wrapped in double quotes, because in Scheme I cannot create a variable as 
> (define "abc" 123)". But maybe I misunderstood %s and %S. I also do not know, 
> how elisp's `print' treats its arguments. Will use 2 times %S then.

The main difference between %S and %s can be demonstrated using the
following:

(insert (format "%s" 'symbol\#w\ spaces))
(insert (format "%S" 'symbol\#w\ spaces))

Basically, if symbol name contains funny chars, reader may need to have
them escaped. %S does the escaping, while %s does not.

Of course, %S escapes according to Elisp reader, not Scheme.
I am not sure if Scheme syntax allows escapes in symbol names.
If not, there should be no real difference.

Also, `print' is the same as %S.

>> Also, previous version quoted the variable value with "'". Why didn't
>> you do it here?
>
> I am not sure I understand what you are referring to in the previous version. 
> Do 
> you mean that `print' quoted variable values with a single quote? Do you mean 
> this part of the previous code:
>
> (print `(,(car var) ',(cdr var)))
>
> ?

Yes, but upon closer look, it should not matter. Your code will work
just fine.

>>> + (concat (org-babel-expand-header-arg-vars:scheme vars) body))
>> `mapconcat' you used in `org-babel-expand-header-arg-vars:scheme' does
>> not add trailing newline, unlike done previously.

> Am I not adding a newline? I think I do?:

I meant after variable definitions.
You have
   (concat (org-babel-scheme-expand-header-arg-vars vars) body)
but string returned by `org-babel-scheme-expand-header-arg-vars' will
not have final newline after the very last define.

> I have a question or suggestion:
>
> When I save the file in Emacs, my Emacs turns all the tabs in there into 
> spaces. 
> Probably my own custom global config's choice about indentation. Could a 
> general 
> mode line thing be added to avoid that and nail down the current formatting 
> style, so that contributors only need to allow Emacs to run those settings 
> and 
> then not need to care about it? Currently the indentation style seems to be a 
> mix of tabs and spaces.

This is something about your setup overriding Org mode project defaults.
If you open org-mode/.dir-locals.el, you will see that we enable
indent-tabs-mode. If you still do not get it enabled, you probably
set indentation defaults aggressively it in your config via hooks or
something similar.

> And one more question:
>
> Does the name of the patch file matter? Git changed the name and I will 
> attach 
> it as it was created by git. Hope that's alright.

Patch file name does not matter.

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

Re: Document org-hide-emphasis-markers

[Ihor Radchenko]

"Stephen J. Eglen"  writes:

> Here is a small patch to document org-hide-emphasis-markers

Thanks!
Could you please also add a commit message, as described in
https://orgmode.org/worg/org-contribute.html#first-patch ?

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

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Bruno Barbier  writes:

> About :results output vs :results value, I decided to use the "it"
> variable, i.e. to ask GHCi what was the last value (see [1]).
>
> About sessions, I decided to rename the buffer as you suggested. That's
> a partial workaround that should work well enough, until haskell-mode
> provides a way to choose the buffer name.
>
> I've updated the tests and the expected results.

Thanks!
I will provide comments inline.

> Note that I've changed the tests about errors; I'm now expecting
> ob-haskell to raise errors. I'm not sure what we should expect to be
> consistent with other org babel backends.

Errors are usually displayed separately, using
`org-babel-eval-error-notify'.

> +;; To increase the chances of failure when running tests, you can use this 
> command line:
> +;;
> +;;(for I in 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 
> 7 8 9 10; do make 'BTEST_OB_LANGUAGES=haskell' BTEST_RE='haskell' test-dirty 
> & done) 2>&1 | grep FAILED
> +;;
> +
> + Status
> +;;
> +;; All the tests should succeed (except for random failures); those
> +;; flagged with ":expected-result :failed" are known
> +;; limitations/bugs.  Tested with (2023-03-18):
> +;;
> +;; | emacs-version |  29.0.60 |
> +;; | org-version   | main@4cad6c8ea (Mar 16 2023) |
> +;; | haskell-mode  | master@20d4e23 (Mar 4  2023) |
> +;; | ghci  |9.0.2 |

You can probably remove this.

> +(`value (org-babel-comint-with-output
> + (session org-babel-haskell-eoe nil full-body)
> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=()::()\n")
> +  (comint-send-input nil t)
> +  (insert full-body)
> +  (comint-send-input nil t)
> +  (insert "__LAST_VALUE_IMPROBABLE_NAME__=it\n")
> +  (comint-send-input nil t)
> +  (insert (concat "putStrLn (\"\\\"\" ++ " 
> org-babel-haskell-eoe " ++ \"\\\"\")\n"))

Why not simply putStrLn ("\"" ++ show it ++ "\"") ?

> +  (when (and session-name (string= session-name "none"))
> +(setq session-name nil))
> +  (unless session-name
> +;; As haskell-mode is using the buffer name "*haskell*", we stay
> +;; away from it.
> +(setq session-name (generate-new-buffer-name "*ob-haskell*")))

This will make ob-haskell spawn a separate ghci process buffer every
single time a user runs non-session src block. And the buffer is not
closed after getting the result.

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

Re: orgmode website contributions to translations? -- Was: It's possible, to translate the org-mode website into Spanish?

[Ihor Radchenko]

Ruijie Yu  writes:

> While reading the files, there is one immediate issue I have found: on
> current orgweb master (feed1160), line 153 of /index.org has a broken
> link on how to contribute to worg.  Similarly, /ja/index.org has the
> same broken link, whereas /fr/index.org has a different paragraph in its
> place so no broken links there.

Thanks for letting us know!
I fixed the links:
https://git.sr.ht/~bzg/orgweb/commit/af32f764ec777ec44d5a876e0ad4682d945d5dcf

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

Table not expanded as I expect upon

[Alain . Cochard]

Maybe it is normal, but if I put the cursor anywhere in the 1st line
(say) of this table

||---+---|
|| x | x |

and press , it becomes

|   | ---+--- |   |
|   | x   | x |

which is not what I would expect.


By contrast, if  on this one

|---|+---|
| x || x |

it becomes 

|---+---+---|
| x |   | x |

Further, by doing M- on the 2nd column, it becomes

|---+---+---|
|   | x | x |

and using  then does not change the table, which is the result I
would have expected to start with.


Org mode version 9.7-pre release_9.6.1-321-g44e1cb

GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.30, cairo version 1.17.4) of 2021-08-07

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [bug] org-columns-edit-value will capitalize property

[Sławomir Grochowski]

My apologies, I've made a mistake. There is not such a bug. Everythings
works correctly.

On Wed, 22 Mar 2023 at 13:18, Sławomir Grochowski <
slawomir.grochow...@gmail.com> wrote:

> Ok. I will try to send my first patch.
> Desired behavior is: by using command 'org-columns-edit-value' do not
> change 'property' name, just its value.
>
> On Wed, 22 Mar 2023 at 12:52, Ihor Radchenko  wrote:
>
>> Sławomir Grochowski  writes:
>>
>> > After updating the value of property using command
>> 'org-columns-edit-value'
>> > it will capitalize the property name.
>> >
>> > As I understand, "Org is standardized on lower case"
>> > https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/.
>> >
>> > Is this a bug?
>>
>> This is for historical reasons.
>> Org supports (and will support) both, and we are slowly converting to
>> lower case.
>>
>> Patches welcome to change org-columns-edit-value.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>