Re: [PATCH] Clarify that REST is not supported on the start TIME in a time-range timestamp.

[Tom Alexander]

Potentially related, org-mode is accepting this malformed timestamp from[1]:
```
<2016-02-14 Sun ++y>
```

The org-mode documentation[2] only includes REST with TIME, defining TIME as 
"H:MMREST". The above does not have any TIME but it accepts the timestamp 
anyway:
```
(timestamp
  :type active
  :range-type nil
  :raw-value "<2016-02-14 Sun ++y>"
  :year-start 2016
  :month-start 2
  :day-start 14
  :hour-start nil
  :minute-start nil
  :year-end 2016
  :month-end 2
  :day-end 14
  :hour-end nil
  :minute-end nil
)
```

Perhaps that grammar is wrong and REST needs to be separated from TIME?

[1] 
https://github.com/howardabrams/pdx-emacs-hackers/blob/bfb7bd640fdf0ce3def21f9fc591ed35d776b26d/workshops/org-mode-gtd-feature-demo.org#L183
[2] https://orgmode.org/worg/org-syntax.html#Timestamps

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc

[PATCH] Clarify that REST is not supported on the start TIME in a time-range timestamp.

[Tom Alexander]

If REST is included in the first TIME on a time-range timestamp then the entire 
timestamp becomes a single range-less timestamp. To test I used the following 
test document:
```
[1970-01-01 Thu 8:15-13:15foo]
[1970-01-01 Thu 8:15foo-13:15]
```

The first line parses as a timerange from 8:15-13:15.
The second line parses as a single timestamp at 8:15.

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
From b1114e983d961d48e1d837b8d2ad209a976a5417 Mon Sep 17 00:00:00 2001
From: Tom Alexander 
Date: Mon, 2 Oct 2023 17:35:28 -0400
Subject: [PATCH] * org-syntax.org (Timestamps): Clarify that REST is not
 supported on the start TIME in a time-range timestamp.

If REST is included in the first TIME on a time-range timestamp then the entire timestamp becomes a single range-less timestamp. To test I used the following test document:
```
[1970-01-01 Thu 8:15-13:15foo]
[1970-01-01 Thu 8:15foo-13:15]
```

The first line parses as a timerange from 8:15-13:15.
The second line parses as a single timestamp at 8:15.
---
 org-syntax.org | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/org-syntax.org b/org-syntax.org
index c2061431..0c326ba8 100644
--- a/org-syntax.org
+++ b/org-syntax.org
@@ -1686,9 +1686,10 @@ -MM-DD DAYNAME
   - DAYNAME (optional) :: A string consisting of non-whitespace
 characters except =+=, =-=, =]=, =>=, a digit, or =\n=.
 + TIME (optional) :: An instance of the pattern =H:MMREST= where =H=
-  represents a one to two digit number (and can start with =0=), and =M=
-  represents a single digit.  =REST= can contain anything but =\n= or
-  closing bracket.
+  represents a one to two digit number (and can start with =0=), and
+  =M= represents a single digit.  =REST= can contain anything but =\n=
+  or closing bracket. =REST= cannot exist on the start TIME in a
+  time-range timestamp (the patterns with =TIME-TIME=).
 + REPEATER-OR-DELAY (optional) :: An instance of the following pattern:
   #+begin_example
 MARK VALUE UNIT
-- 
2.42.0

[BUG] org-agenda column view error: wrong type markerp, nil [9.6.9 ( @ /path/to/org-9.6.9/)]

[John Borwick]

Hello! After updating org-mode, when I do the below:

  1. Run a custom org-agenda =C-c a w= that has a column view format. (This 
works correctly)
  2. Open a different buffer
  3. Re-run org-agenda

I get the error =Wrong type argument: markerp, nil=.

Using the debugger, I found the error occurred in =org-colview.el=. I no longer 
have the error when using the below workaround.

#+begin_src patch
--- #
+++ #
@@ -525,6 +525,8 @@
   (setq header-line-format org-previous-header-line-format)
   (kill-local-variable 'org-previous-header-line-format)
   (remove-hook 'post-command-hook #'org-columns-hscroll-title 'local))
+(setq org-columns-begin-marker (make-marker))
 (set-marker org-columns-begin-marker nil)
 (when (markerp org-columns-top-level-marker)
   (set-marker org-columns-top-level-marker nil))
#+end_src

Emacs  : GNU Emacs 28.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 
Version 10.14.6 (Build 18G95))
 of 2023-02-22
Package: Org mode version 9.6.9 ( @ /path/to/org-9.6.9/)
-- 
John Borwick

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

[Leo Butler]

On Fri, Sep 22 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> What is the purpose of this `unwind-protect'?
>>> In its current form, it does nothing because no UNWINDFORMS are
>>> provided.
>>
>> I copied the forms from tests I had written for ob-octave, without
>> thinking about why those tests were wrapped in an `unwind-protect'
>> form. The attached patch removes them, otherwise it is identical to the
>> previous patch.
>
> Thanks! Now, may you also add etc/ORG-NEWS entry and update the WORG docs?

Attached is:

- my previous patch, rebased against the latest HEAD and only modified
  to include a patch to etc/ORG-NEWS
- a patch to the worg docs that corrects the urls
- a patch to the worg docs that documents the new header arguments and
  provides examples of usage (two new graphics files are included as
  part of that patch).

Best regards,
Leo

From 7288eb547aff1ad50c3782d9db22b1e2792d6634 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 19 Sep 2023 13:36:06 -0500
Subject: [PATCH] * lisp/ob-maxima.el: enable use of `batch' loader and `draw'

* (org-babel-header-args:maxima): Document the two new header
arguments (batch and graphics-pkg) that are specific to ob-maxima.
* (org-babel-maxima--command-arguments-default): A new variable
storing the default command-line argument(s).  This value was
hard-coded in `org-babel-maxima:execute'.
* (org-babel-maxima--graphic-package-options): A new variable that
stores an alist of Maxima graphics packages and the Maxima code to set
up that package.
* (org-babel-maxima--default-epilogue): A new variable that stores an
alist of the clean-up code that is run at end of a `graphical-output'
or `non-graphical-output' source block.
* (org-babel-maxima--output-filter-regexps): A new variable that
stores a list of regexps to identify "bad" output lines to be removed
from Maxima's output.  Source-code comments document each regexp's
purpose.  Two additional regexps have been added: one filters
un-wanted output from `batch' and the other removes empty input lines
that `batch'-ed output may spuriously produce (actual empty input
lines are syntax errors, see the new tests below).
* (org-babel-maxima--output-filter): A new function that takes a
single line of Maxima output.  It returns nil if the line has zero
length or matches a regexp in
`org-babel-maxima--output-filter-regexps'; otherwise, it returns the
line.  This function and regexp replace the hard-coded filter in
`org-babel-execute:maxima'.
* (org-babel-maxima-expand): Prepare the source block for execution,
depending on whether it is producing graphical output or not.  In case
of graphical output, use the `graphics-pkg' header to set the graphics
package and use `org-babel-maxima--graphic-package-options' to set-up
the package.  Grovel the graphics terminal from the output filename.
* (org-babel-execute:maxima): Use the :batch header argument and
`org-babel-maxima--command-arguments-default' to execute the source
block.  Replace the existing, in-line output filter and its regexps
with `org-babel-maxima--output-filter' and
`org-babel-maxima--output-filter-regexps'.

* testing/examples/ob-maxima-test.org: Add test examples.

Include examples of the batch-related tests from
testing/lisp/test-ob-maxima.el.  Provide an example of the
`:graphics-pkg' header argument with the `draw' package.

* testing/lisp/test-ob-maxima.el: Introduce six new, batch-related
test functions.  Each test exercises the :batch header argument.  The
response to unusual inputs is tested (empty strings, strings with just
whitespace, input with the `:lisp' reader, and two syntax-related
errors).

link: https://list.orgmode.org/87cyz1ivzw@t14.reltub.ca/
---
 etc/ORG-NEWS|  12 +++
 lisp/ob-maxima.el   | 115 +---
 testing/examples/ob-maxima-test.org |  54 +
 testing/lisp/test-ob-maxima.el  | 101 
 4 files changed, 254 insertions(+), 28 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..16f8a1c30 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,18 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluation, and then plotted afterwards.
 
+*** =ob-maxima.el=: Support for ~batch~ and ~draw~
+
+=ob-maxima= has two new header arguments: ~:batch~ and
+~:graphics-pkg~.
+
+The ~:batch~ header argument can be set to one of Maxima's file
+loaders (~batch~, ~load~ or ~batchload~); the default remains
+~batchload~. The ~:graphics-pkg~ header argument can be set to one of
+Maxima's graphics packages (~draw~ or ~plot~); the default remains
+~plot~.  The graphics terminal is now determined from the file-ending
+of the file-name set in the ~:file~ header argument.
+
 ** New functions and changes in function arguments
 *** =TYPES= argument in ~org-element-lineage~ can now be a symbol
 
diff --git a/lisp/ob-maxima.el 

Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?

[Juan Manuel Macías]

Ihor Radchenko writes:

>> ┌
>> │ #+caption: Main caption
>> │ #+begin_figure
>> │ #+CAPTION: subcaption 1
>> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width 
>> \textwidth
>> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>> ...
>> I think this is a case where certain elements of Org have evolved
>> (consciously or unconsciously) ahead of the names, and these names have
>> become somewhat outdated. There is not only the case of :placement. Even
>> :float seems imprecise, since can be used to create a minipage, and the
>> minipage environment is not a float environment. Would it be worth
>> making those names obsolete (with backward compatibility, of course) and
>> replacing them with slightly more precise ones? I think that new names
>> would give the user an idea of more variety of uses, like the examples I
>> have put here.
>
> I am not sure about obsolete - I see not reason to obsolete the intended
> use case. Your example is rather an abuse.

Why abuse? First, it works like a charm. Second, if :float can support
any string as an environment name, why not minipage or subfigure? As for
:placement, the term would seem more precise to me if it were really
"placement" (as :align in tables is actually "align"), not LaTeX code
passed directly after the \begin{...}. That a user can put things like
this (I do it often, and I think I'm not the only one):

:placement [htbp]\SomeExtraLaTeXCode...

it is a consequence of the above. It is not an "orthodox" use (I mean,
it's not described in the manual), but it works without problems. Again,
I don't want to seem too picky about the names, but a user who doesn't
understand the source code might think that :placement only supports
things like [htbp]. My idea here is: instead of implementing new
features, recycle and take advantage of those that arise unexpectedly
:-). Although :placement was created thinking about putting code related
to placement figures, as it is implemented I would have called it
:latex-code or something similar.


> What we might do it to introduce something like a new :wrap attribute:
>
> #+attr_latex: :wrap subfigure,{\textwidht}

That would be nice if with a single latex_attr line you could export a
single figure environment for several images, since every subfigure
environment must be inside a figure environment. And putting a single
subfigure inside a figure environment doesn't make much sense. Other
than that, the idea of :wrap is good. I find it very useful, especially
on tables.

> I think we have discussed something similar in the past, but more
> generic - allow wrapping arbitrary Org elements (headings, drawers,
> paragraphs, etc) on export.

I remember that thread. In fact, I think I created a TODO to study that,
but due to lack of time I haven't been able to take a look at it.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: Extra paragraphs incorrectly spawning when ":end:" appears.

[Tom Alexander]

Hmm thanks, that makes sense. I guess a post-processing step to merge adjacent 
paragraphs wouldn't work either since that wouldn't stitch together objects 
like the bold in this test document without re-parsing the entire paragraph:
```
foo *bar
:end:
baz*
```

oh well 路

--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc

Re: [BUG] org-refile doesn't work when target is immediately above

[Ihor Radchenko]

Rens Oliemans  writes:

> Ihor Radchenko  writes:
>
>> I cannot reproduce on the latest main.
>
> Me neither, it seems that commit 0d5951a9b02d9ce71af154612d0fa3a3381856ec 
> fixed the issue.

Thanks for confirming!
Canceled.

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

Re: [BUG] org-refile doesn't work when target is immediately above

[Rens Oliemans]

Ihor Radchenko  writes:

> I cannot reproduce on the latest main.

Me neither, it seems that commit 0d5951a9b02d9ce71af154612d0fa3a3381856ec fixed 
the issue.

--
Rens

Re: [PATCH] org-id: implement arbitrary cross-file references

[Ihor Radchenko]

Ihor Radchenko  writes:

> Sergei Kosyrev  writes:
>
>> Yes, I saw your comments, thank you for them.
>>
>> Since they imply a non-trivial reformulation, it would require another deep 
>> dive, which I cannot commit to right now.
>
> Thanks for the update!

It has been a couple of months since the last activity in this thread.
May I know if you are still interested to work on this feature?

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

[FR] Re: language-specific org-babel-noweb-wrap-start?

[Ihor Radchenko]

Edgar Lux  writes:

> I wish you a nice day, week, month...
> I would like to know if there is a way to set =org-babel-noweb-wrap-start= 
> for a specific language. If I set that variable to a value, it will apply to 
> all of them. Thank you.
> ...
> What I would like is something like
>
> #+begin_src lang1 :noweb yes
> //;name_of_anoter_block;//
> #+end_src
>
> # Local Variables:
> # org-babel-noweb-wrap-start_lang1: "//;"
> # org-babel-noweb-wrap-end_lang1: ";//"
> # End:

This is currently not possible, but sounds like a reasonable addition.
Patches welcome. See https://orgmode.org/worg/org-contribute.html

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

Re: [BUG] short TeX & in-text code highlighting [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Edgar Lux  writes:

> I'm almost sure that this is known, but I don't want to assume.
>
> I get the text between ~ ~ with colouring as if it was in-text code
> snippet. I found it interesting
>
> \(a ~b\) and \(\int_{\Omega}fv~\mathrm{d}\)

Confirmed.
It is one of the known edge cases with Org fontification, which is
currently approximate.
See https://orgmode.org/list/87ee7c9quk.fsf@localhost

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

Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?

[Ihor Radchenko]

Juan Manuel Macías  writes:

> An example of more "unexpected" (but very practical) uses is this one
> with three subfigures and the subcaption package:
>
> ┌
> │ #+caption: Main caption
> │ #+begin_figure
> │ #+CAPTION: subcaption 1
> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width 
> \textwidth
> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
> ...
> I think this is a case where certain elements of Org have evolved
> (consciously or unconsciously) ahead of the names, and these names have
> become somewhat outdated. There is not only the case of :placement. Even
> :float seems imprecise, since can be used to create a minipage, and the
> minipage environment is not a float environment. Would it be worth
> making those names obsolete (with backward compatibility, of course) and
> replacing them with slightly more precise ones? I think that new names
> would give the user an idea of more variety of uses, like the examples I
> have put here.

I am not sure about obsolete - I see not reason to obsolete the intended
use case. Your example is rather an abuse.

What we might do it to introduce something like a new :wrap attribute:

#+attr_latex: :wrap subfigure,{\textwidht}

I think we have discussed something similar in the past, but more
generic - allow wrapping arbitrary Org elements (headings, drawers,
paragraphs, etc) on export.

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

Re: [BUG] org-refile doesn't work when target is immediately above

[Ihor Radchenko]

Jingcheng Xu  writes:

> with emacs -Q, and the following org file
>
> 
> * heading
> * TODO task
>
> 
>
> When the point is at the second *, running org-refile to "heading"
> doesn't do anything.  If the point is at other places, e.g. end of the
> line, the third line, then org-refile works.

I cannot reproduce on the latest main.

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

[BUG] short TeX & in-text code highlighting [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Edgar Lux]

I'm almost sure that this is known, but I don't want to assume.

I get the text between ~ ~ with colouring as if it was in-text code
snippet. I found it interesting

\(a ~b\) and \(\int_{\Omega}fv~\mathrm{d}\)

Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.17.8)
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/usr/share/emacs/29.1/lisp/org/)
 

-- 
Sent with https://mailfence.com  
Secure and private email

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

[Max Nikulin]

On 27/09/2023 02:12, Juan Manuel Macías wrote:

Max Nikulin writes:


I just have checked that a dirty hack with a few lines of code for
`org-export-filter-final-output-functions' allows to insert arbitrary
text to the beginning of export result. Perhaps a more elegant solution
exists, but I admit it is not a straightforward way. At least it is
possible.


And it is also possible by simply defining a new class (in Org
terminology, not LaTeX). My usual class is an almost empty one, without
documentclass and without packages, because I don't want org to write
the preamble for me. But I think this is not the point.


LATEX_PRE_HEADER you proposed is a document-local setting while 
`org-latex-classes' is shared by all Org documents. In that hack I used 
a buffer-local variable to achieve document-specific fragment.


In the specific cases of \DocumentMetadata and .xmpdata, 
LATEX_PRE_HEADER needs to be passed through `format-spec' with result of 
`org-latex--format-spec' call to get notion of Org metadata. Whether it 
is necessary for \PassOptionsToPackage depends on particular cases. If 
such options do not vary across documents then certainly 
`org-latex-classes' becomes viable.


I do not like "[NO-PACKAGES]" and similar keywords to suppress adding of 
some code snippets. That is why I believe it is better to seek for 
another approach to generate LaTeX preamble. I have not had a look into 
Timothy's code yet, so I can say nothing concerning its flexibility in 
respect to substituting metadata into code before \documentclass.

Re: [BUG] Warning when creating preview

[Edgar Lux]

Nope, there is still something wrong with my config (see attachment). Haven't 
been able to reproduce consistently.

-- 
Sent with https://mailfence.com  
Secure and private email


log.gz
Description: File Attachment: log.gz

language-specific org-babel-noweb-wrap-start?

[Edgar Lux]

Hi!

I wish you a nice day, week, month...
I would like to know if there is a way to set =org-babel-noweb-wrap-start= for 
a specific language. If I set that variable to a value, it will apply to all of 
them. Thank you.

This is fine right now
#+begin_src lang1 :noweb yes
//;name_of_anoter_block;//
#+end_src

# Local Variables:
# org-babel-noweb-wrap-start: "//;"
# org-babel-noweb-wrap-end: ";//"
# End:

What I would like is something like

#+begin_src lang1 :noweb yes
//;name_of_anoter_block;//
#+end_src

# Local Variables:
# org-babel-noweb-wrap-start_lang1: "//;"
# org-babel-noweb-wrap-end_lang1: ";//"
# End:

Thanks!

-- 
Sent with https://mailfence.com  
Secure and private email