Re: ICalendar export

[Jack Kamm]

Ihor Radchenko  writes:

> Henrik Frisk  writes:
>
>> Recently (not sure when) the ics output came out malformed and a newline is
>> omitted between the end of one event and the beginning of another:
>>
>> END:VEVENT
>> BEGIN:VEVENT
>>
>> is now
>>
>> END:VEVENTBEGIN:VEVENT
>>
>> I can't figure out wha the pattern is, for some events the output is
>> correct.
>>
>> This is on Org mode version 9.7-pre release_9.6.8-719-gf299fb and emacs 29.1
>
> We recently did some major changes to comply better to the icalendar
> specs and introduced new feature. As it usually goes, major changes can
> easily introduce new bugs.
>
> Does the attached patch fix the problem for you?

I can reproduce the bug by calling `org-icalendar-export-current-agenda'
in my agenda buffer. It seems to mainly happen when subsequent agenda
entries originate from different files.

Ihor's patch fixes the problem on my end.

Bisecting, the bug was introduced in f4446ce79.

[PATCH] testing: Delete useless ert tests

[Ilya Chernyshov]

Hi!

I applied my ert test deduplicator on org tests and found some useless tests
which you can see in the patch.

>From 32d83fc5b2ad076dcd8681434a46b4117ac23858 Mon Sep 17 00:00:00 2001
From: Ilya Chernyshov 
Date: Sun, 17 Sep 2023 02:33:51 +0700
Subject: [PATCH] testing: Delete useless ert tests

* testing/lisp/test-ob-C.el: Delete useless test.

* testing/lisp/test-ob-fortran.el: Delete useless test.

* testing/lisp/test-ob-lilypond.el: Delete useless test.

* testing/lisp/test-ob-maxima.el: Delete useless test.
---
 testing/lisp/test-ob-C.el| 3 ---
 testing/lisp/test-ob-fortran.el  | 3 ---
 testing/lisp/test-ob-lilypond.el | 3 ---
 testing/lisp/test-ob-maxima.el   | 3 ---
 4 files changed, 12 deletions(-)

diff --git a/testing/lisp/test-ob-C.el b/testing/lisp/test-ob-C.el
index 8546a48dd..c70534a51 100644
--- a/testing/lisp/test-ob-C.el
+++ b/testing/lisp/test-ob-C.el
@@ -22,9 +22,6 @@
 (unless (featurep 'ob-C)
   (signal 'missing-test-dependency "Support for C code blocks"))
 
-(ert-deftest ob-C/assert ()
-  (should t))
-
 (ert-deftest ob-C/simple-program ()
   "Hello world program."
   (if (executable-find org-babel-C++-compiler)
diff --git a/testing/lisp/test-ob-fortran.el b/testing/lisp/test-ob-fortran.el
index 3bff7b9c4..4947d142b 100644
--- a/testing/lisp/test-ob-fortran.el
+++ b/testing/lisp/test-ob-fortran.el
@@ -23,9 +23,6 @@
 (unless (featurep 'ob-fortran)
   (signal 'missing-test-dependency "Support for Fortran code blocks"))
 
-(ert-deftest ob-fortran/assert ()
-  (should t))
-
 (ert-deftest ob-fortran/simple-program ()
   "Test of hello world program."
   (org-test-at-id "459384e8-1797-4f11-867e-dde0473ea7cc"
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond.el
index 5f439793b..49a61fcab 100644
--- a/testing/lisp/test-ob-lilypond.el
+++ b/testing/lisp/test-ob-lilypond.el
@@ -26,9 +26,6 @@
 (file-name-directory
  (or load-file-name (buffer-file-name)
 
-(ert-deftest ob-lilypond/assert ()
-  (should t))
-
 (ert-deftest ob-lilypond/feature-provision ()
   (should (featurep 'ob-lilypond)))
 
diff --git a/testing/lisp/test-ob-maxima.el b/testing/lisp/test-ob-maxima.el
index e2433d232..ae9fdc775 100644
--- a/testing/lisp/test-ob-maxima.el
+++ b/testing/lisp/test-ob-maxima.el
@@ -22,9 +22,6 @@
 (unless (featurep 'ob-maxima)
   (signal 'missing-test-dependency "Support for Maxima code blocks"))
 
-(ert-deftest ob-maxima/assert ()
-  (should t))
-
 (ert-deftest ob-maxima/integer-input ()
   "Test of integer input"
   (org-test-at-id "b5842ed4-8e8b-4b18-a1c9-cef006b6a6c8"
-- 
2.41.0

Fixed width areas not allowing tab after leading colon.

[Tom Alexander]

The documentation for fixed width areas states: A “fixed-width line” starts 
with a colon character (:) and either a whitespace character or the immediate 
end of the line. 

Using the test document:
```
:foo
```

parses as a paragraph instead of a fixed-width area:
```
(org-data
(:standard-properties
  [1 1 1 7 7 0 nil org-data nil nil nil 3 7 nil # nil nil nil]
  :path nil :CATEGORY nil)
(section
  (:standard-properties
   [1 1 1 7 7 0 nil first-section nil nil nil 1 7 nil # nil 
nil #0])
  (paragraph
   (:standard-properties
[1 1 1 7 7 0 nil top-comment nil nil nil nil nil nil # 
nil nil #1])
   #(": foo\n" 0 6
 (:parent #2)
```

This happens in a document in worg: 
https://git.sr.ht/~bzg/worg/tree/74e80b0f7600801b1d1594542602394c085cc2f9/item/org-contrib/org-bom.org#L499

Emacs version: GNU Emacs 29.1 (build 1, x86_64-pc-linux-musl)
Org-mode version: c703541ffcc14965e3567f928de1683a1c1e33f6 (latest in git)

Fixed-width area documentation: 
https://orgmode.org/worg/org-syntax.html#Fixed_Width_Areas
--
Tom Alexander

[patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword

[Juan Manuel Macías]

Rationale for this patch: in certain cases, in a LaTeX document, it is
necessary to add code before the class declaration (\documentclass...).
For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
etc.; or certain packages that should be loaded first using
\RequirePackage{}; and other miscellaneous cases[1]. I think that by
defining a new keyword `latex_pre_header', which behaves the same as
latex_header but concatenated before the class, these situations can be
resolved from Org.

[1] A longer example to export to a pdf that has pdf-x compliance, with
the pdfx package:

\providecommand{\pdfxopts}{x-1a}
\begin{filecontents*}{\jobname.xmpdata}
  \Title{Some Title}
  \Author{Author}
  \Language{es-ES}
  \Keywords{keywords}
  \Publisher{publisher}
\end{filecontents*}
\documentclass{...


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com
>From ac6b743a4489f7bc8ab1cdae7ffd3b36e5f3c1d2 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sat, 16 Sep 2023 19:22:39 +0200
Subject: [PATCH] lisp/ox-latex.el (latex): Add `LATEX_PRE_HEADER' keyword

* (org-latex-make-preamble): In some cases it is necessary to add code
before the `\documentclass' line. `LATEX_PRE_HEADER' behaves the same as
`LATEX_HEADER', except that it is concatenated before the class.
---
 lisp/ox-latex.el | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 14105c7cc..5e97b8b3d 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -124,6 +124,7 @@
 (:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
 (:latex-header "LATEX_HEADER" nil nil newline)
 (:latex-header-extra "LATEX_HEADER_EXTRA" nil nil newline)
+(:latex-pre-header "LATEX_PRE_HEADER" nil nil newline)
 (:description "DESCRIPTION" nil nil parse)
 (:keywords "KEYWORDS" nil nil parse)
 (:subtitle "SUBTITLE" nil nil parse)
@@ -1984,13 +1985,18 @@ specified in `org-latex-default-packages-alist' or
 		   (replace-regexp-in-string
 			"^[ \t]*documentclass\\(\\(\\[[^]]*\\]\\)?\\)"
 			class-options header t nil 1
-	  (user-error "Unknown LaTeX class `%s'" class
+	  (user-error "Unknown LaTeX class `%s'" class)))
+ (pre-header (mapconcat
+		  #'org-element-normalize-string
+		  (list (plist-get info :latex-pre-header) ""
 (org-latex-guess-polyglossia-language
  (org-latex-guess-babel-language
   (org-latex-guess-inputenc
(org-element-normalize-string
 	(org-splice-latex-header
-	 class-template
+ (if pre-header
+	 (format "%s\n%s" pre-header class-template)
+	   class-template)
 	 (org-latex--remove-packages org-latex-default-packages-alist info)
 	 (org-latex--remove-packages org-latex-packages-alist info)
 	 snippet?
-- 
2.42.0

Re: [PATCH] Define new face for the contents of #+RESULTS drawers

[Protesilaos Stavrou]

> From: Ihor Radchenko 
> Date: Sat, 16 Sep 2023 12:44:37 +

> [... 79 lines elided]

> I am still not 100% sure what exactly you want to achieve - just
> highlight evaluation results that are _also_ fixed-width or all kinds of
> evaluation results.

The goal is to make all kinds of evaluation results distinct from their
manually written counterparts.  This is for users who read/interact with
a document and are given basic instructions on what to do while still
not knowing everything Org has to offer.

Though I understand now that there are more cases involved than I had
anticipated.  I will need to review everything on offer.  Let's abort
this effort for now.

Thank you for your time!

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: [PATCH] Define new face for the contents of #+RESULTS drawers

[Ihor Radchenko]

Protesilaos Stavrou  writes:

>> I think there is some misunderstanding here.
>> #+RESULTS is not a drawer. A drawer would be
>>
>> :results:
>> ...
>> :end:
>
> Oh, I see.  How do we describe it?  A keyword, perhaps?

Affiliated keyword.

Org allows attaching arbitrary metadata to syntax elements. For example,
we can assign name and header via affiliated keywords:

#+name: src-block-name
#+header: :var x=1
#+begin_src elisp
 (+ 1 x)
#+end_src

#+results is a special affiliated keyword that marks syntax elements
generated by evaluating code blocks:

#+results:
I am generated paragraph

#+results:
:drawer:
I am generated drawer
:end:

#+results:
: I am generated fixed-width

#+results:
#+begin_latex
I am generated latex snippet
#+end_latex

etc.

>> `org-activate-code' only affects fixed-width text
>>
>> : like
>> : this
>> :
>> : one
> ...
> Thank you for the explanation!  The case I had in mind was indeed the
> one where the 'org-code' face now applies.

I am a bit confused. Now, `org-code' applies to all fixed-width
constructs, not just the ones generated by code blocks.

: I can just manually write this, and it will have ~code-block~ face.

#+begin_src ...
...
#+end_src

#+results:
: And this is generated src block result.
: It is also using ~code-block~ face (as all fixed-width blocks do).

> I am interested in making the results display as distinct elements.  The
> reason is that it can sometimes be hard to tell what was there before
> and what was generated by 'org-babel-execute-buffer' and related.
>
> You are right to point out that adding font-lock rules for all the
> possible #+results is not trivial.  Better leave it as-is.

Not very hard. Basically, we can write a custom activate function that
will search for "^#\\+results:" lines and prepend/append an extra custom
face to whatever that #+results is a part of (affiliated keyword is
never standalone - it is attached to whatever is a result of evaluation).

I am still not 100% sure what exactly you want to achieve - just
highlight evaluation results that are _also_ fixed-width or all kinds of
evaluation results.

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

Re: [PATCH] Define new face for the contents of #+RESULTS drawers

[Protesilaos Stavrou]

> From: Ihor Radchenko 
> Date: Sat, 16 Sep 2023 09:49:50 +

> [... 9 lines elided]

>> +(defface org-code-results '((t :inherit org-code))
>> +  "Face for the contents of #+RESULTS drawers."
>> +  :group 'org-faces
>> +  :version "30.1")
>
> I think there is some misunderstanding here.
> #+RESULTS is not a drawer. A drawer would be
>
> :results:
> ...
> :end:

Oh, I see.  How do we describe it?  A keyword, perhaps?

> As for code evaluation results, it can be anything with #+results
> keyword. Like
>
> #+results:
> : fixed width
> : text
>
> or
>
> #+results:
> #+begin_example
> ...
> #+end_example
>
> or
>
> #+results:
> Simple paragraph of text.
>
>>;; Code
>> -  '(org-activate-code (1 'org-code t))
>> +  '(org-activate-code (1 'org-code-results t))
>
> `org-activate-code' only affects fixed-width text
>
> : like
> : this
> :
> : one
>
> It has no relation to code results, except that fixed width is often
> (but not always) used as the default markup for results of evaluation.
>
> If what you are looking for is different formatting for code markup and
> fixed-width markup, `org-fixed-width' would be a better face name.
>
> If you are looking for formatting of results of evaluation, it would
> need to be a completely new, non-trivial, font-lock-keyword.

Thank you for the explanation!  The case I had in mind was indeed the
one where the 'org-code' face now applies.

I am interested in making the results display as distinct elements.  The
reason is that it can sometimes be hard to tell what was there before
and what was generated by 'org-babel-execute-buffer' and related.

You are right to point out that adding font-lock rules for all the
possible #+results is not trivial.  Better leave it as-is.

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: Clarification on blank lines following list items

[Ihor Radchenko]

Ihor Radchenko  writes:

> "Tom Alexander"  writes:
>
>> I am noticing the list items have some very context-sensitive specific 
>> behavior regarding ownership of the trailing blank lines. I was hoping to 
>> get some clarification on this (namely, are my observations correct, am I 
>> stumbling across a bug, or have I not dug deep enough to suss out the real 
>> rules?). The org-mode documentation states:
>>
>>> With the exception of list items and footnote definitions blank lines 
>>> belong to the preceding element with the narrowest possible scope
>>
>> but it does not state who ends up owning those blank lines.
>
> I can see how this explanation steered you into wrong line of thoughts.
> It should better be explained from the widest scope to the narrowest
> scope, not the opposite.

I tried to clarify things in
https://git.sr.ht/~bzg/worg/commit/ac9de71c1e73ef3a1d63e58e364fc55e83f0214e

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

Re: [PATCH] Define new face for the contents of #+RESULTS drawers

[Ihor Radchenko]

Protesilaos Stavrou  writes:

> I propose the attached patch.  It gives users/themes the opportunity to
> style the contents of #+RESULTS drawers differently than the face
> applied to ~code~ elements.

Thanks for the patch!

> +(defface org-code-results '((t :inherit org-code))
> +  "Face for the contents of #+RESULTS drawers."
> +  :group 'org-faces
> +  :version "30.1")

I think there is some misunderstanding here.
#+RESULTS is not a drawer. A drawer would be

:results:
...
:end:

As for code evaluation results, it can be anything with #+results
keyword. Like

#+results:
: fixed width
: text

or

#+results:
#+begin_example
...
#+end_example

or

#+results:
Simple paragraph of text.

> ;; Code
> -   '(org-activate-code (1 'org-code t))
> +   '(org-activate-code (1 'org-code-results t))

`org-activate-code' only affects fixed-width text

: like
: this
:
: one

It has no relation to code results, except that fixed width is often
(but not always) used as the default markup for results of evaluation.

If what you are looking for is different formatting for code markup and
fixed-width markup, `org-fixed-width' would be a better face name.

If you are looking for formatting of results of evaluation, it would
need to be a completely new, non-trivial, font-lock-keyword.

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

[PATCH] Define new face for the contents of #+RESULTS drawers

[Protesilaos Stavrou]

Hello folks!

I propose the attached patch.  It gives users/themes the opportunity to
style the contents of #+RESULTS drawers differently than the face
applied to ~code~ elements.

To preserve the current style, I made the new face inherit 'org-code'.

What do you think?

All the best,
Protesilaos (or simply "Prot")

-- 
Protesilaos Stavrou
https://protesilaos.com
>From 1ecd64bfe88d06684a9ad97c1ee6df0bdd2c1eb2 Mon Sep 17 00:00:00 2001
Message-ID: <1ecd64bfe88d06684a9ad97c1ee6df0bdd2c1eb2.1694856985.git.i...@protesilaos.com>
From: Protesilaos Stavrou 
Date: Sat, 16 Sep 2023 12:36:18 +0300
Subject: [PATCH] Define new face for the contents of #+RESULTS drawers

* lisp/org-faces.el (org-code-results): Define new face.
* lisp/org.el (org-set-font-lock-defaults): Use it instead of the
generic 'org-code' face.
---
 lisp/org-faces.el | 5 +
 lisp/org.el   | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 436552cb2..3d233eaff 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -409,6 +409,11 @@ (defface org-code '((t :inherit shadow))
   :group 'org-faces
   :version "22.1")
 
+(defface org-code-results '((t :inherit org-code))
+  "Face for the contents of #+RESULTS drawers."
+  :group 'org-faces
+  :version "30.1")
+
 (defface org-meta-line '((t :inherit font-lock-comment-face))
   "Face for meta lines starting with \"#+\"."
   :group 'org-faces
diff --git a/lisp/org.el b/lisp/org.el
index 84ac87438..6fb099618 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5905,7 +5905,7 @@ (defun org-set-font-lock-defaults ()
 	  '(org-fontify-entities)
 	  '(org-raise-scripts)
 	  ;; Code
-	  '(org-activate-code (1 'org-code t))
+	  '(org-activate-code (1 'org-code-results t))
 	  ;; COMMENT
 	  (list (format
 		 "^\\*+\\(?: +%s\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:%s\\)\\(?: \\|$\\)"
-- 
2.42.0

Re: bbb:OrgMeetup for Asia-Pacific time zones (was: #2 [[bbb:OrgMeetup]] on Wed, Sep 13, 19:00 UTC+3)

[Ihor Radchenko]

Tshiung Han See  writes:

> 8am’s not going to work, sorry. But I really appreciate the offer, Corwin.
>
> I would be happy to host something that is more amenable for people in my 
> corner of the world. But I must warn you that I’m *really* new to org-mode.
>
> That is, though I’ve been using it for a while, I use it to organize my 
> lessons (I teach English) and other projects.
>
> I hope that’s OK.

I do not think that there is any requirement about being "veteran" in
Org mode. The job of host is mostly making sure that the conversation is
not stuck - asking people to introduce themselves (or their Org mode
usage), encouraging people to ask questions or sharing something
interesting, looking after questions in chat, etc.

Tshiung, what time and weekday would work best for your schedule?

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

Re: [PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom)

[Ihor Radchenko]

Leo Butler  writes:

>> Also, non-standard arguments should be defined in 
>> `org-babel-header-args:maxima'.
>>
>
> Ok. I see that some packages (e.g. ob-gnuplot.el) use a `defvar' form,
> while others (e.g. ob-R.el) use a `defconst' form. Is there a preference?

defconst I think. The value is not supposed to be changed.

>>> I have also moved two defaults, that were embedded in the code, to
>>> `defvar' forms.
>>
>> This is fine, although I would prefer to keep these variables private for
>> now.
>
> My understanding is that a special variable defined via `defvar' is one
> that is intended to be "private", i.e. users should not change it unless
> they really know what they are doing. Is that accurate?

Users are indeed not supposed to change defvar unless they know what
they are doing. But it is not considered private - there is a guarantee
that the meaning or type of the variable is not going to change.

> Do you mean the names should be something like
>
> org-babel-maxima--command-arguments
>
> ?

Yes. Having "--" means - if you use this variable, do it at your own
risk; we can re-purpose it or change or rename or do whatever at any
time.

>>> -  (format "batchload(%S)$" in-file))
>>> +  (format "(linenum:0, %s(%S))$" batch/load 
>>> in-file))
>>
>> May you clarify the purpose of "linenum"?
>
> Maxima keeps track of input/output line numbers via the variable
> `linenum'. I set the linenum to 0 so that the line numbering of the
> input in `in-file' starts at 1 not 2.
>
> This idiom has been used in other Maxima front-ends, such as
> `imaxima.el', too (although imaxima now uses the lisp reader, instead).
>
> See 
> https://sourceforge.net/p/maxima/code/ci/76105d9ee231679eccac888a04c98e6ef66df087/

Do I understand correctly that the above will simply affect debug output
when maxima references where a problematic line is located in the source?

>>>(unless (or (string-match "batch" line)
>>>(string-match "^rat: replaced 
>>> .*$" line)
>>>(string-match "^;;; Loading #P" 
>>> line)
>>> +  (string-match "^read and 
>>> interpret" line)
>>> +  (string-match 
>>> "^(%\\([io]-?[0-9]+\\))[ ]+$" line)
>>
>> May you explain why you added these two conditions?
>
> When `batch' starts, it emits the line starting with 'read and
> interpret' and including the name of the file being read. This is
> extraneous output, and should be filtered out.
>
> The second addition filters out empty input/output lines. Without that
> filter, the block
>
> #+name: ob-maxima/batch+verbatim+quiet
> #+begin_src maxima :exports both :results verbatim :batch batch :cmdline 
> --quiet
> (assume(z>0),
> integrate(exp(-t)*t^z, t, 0, inf));
> #+end_src
>
> produces an output with a pair of empty lines:
>
> #+RESULTS: ob-maxima/batch+verbatim+quiet
> : (%i1) (assume(z > 0),integrate(exp(-t)*t^z,t,0,inf))
> : (%o1)gamma(z + 1)
> : (%i2) 
> : (%i4) 
>
>
> I don't understand why those extra lines appear. It looks to me like a
> bug in Maxima, but, because of that, they need to be filtered out.

May empty lines be intentional in some maxima code?

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

Re: [PATCH] org-manual: Fix a preposition and capitalization

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> * doc/org-manual.org (Capturing column view): Replace "in the
> ... line" with "on the ... line" and capitalize the containing
> sentence as well.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2c7018f72

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