Re: File generation from LaTeX src fails due to temporary PDF in wrong directory

[Christian Moe]

chris writes:

>> [ ... snip ... ]
>> Solution:
>>
>> Redefine org-babel-latex-preamble to remove
>> the offending line.
>>
>>   (setq org-babel-latex-preamble
>> '(lambda (_)
>>   "\\documentclass[preview]{standalone}"))
>>
>> With this setup, my example
>>
>>   #+header: :fit yes :headers '("\\usepackage{tikz}")
>>   #+begin_src latex :exports results :results raw file :file 
>> test-tikz-triangle.svg
>> \begin{tikzpicture}
>>   \draw[draw=black, fill=blue!10] (0,4) -- (3,0) -- (-3,0) -- cycle;
>> \end{tikzpicture}
>>   #+end_src
>>
>> exports correctly to an .svg file.
>
> Hmm, your fix works perfectly! And it's a `defcustom` variable so it's not 
> even a hack.

Yes, I only thought about that afterwards.

> I guess that since you haven't selected specific method like:
> `#+header: :imagemagick yes`, the method used is `inkscape`
> (`ob-latex.el` file):
> ```
> (defcustom org-babel-latex-pdf-svg-process
>   "inkscape \
> --pdf-poppler \
> --export-area-drawing \
> --export-text-to-path \
> --export-plain-svg \
> --export-filename=%O \
> %f"
>   "Command to convert a PDF file to an SVG file."
>   :group 'org-babel
>   :type 'string
>   :package-version '(Org . "9.6"))
> ```
>

I would have been, but I've got inkscape installed via Linux Mint apt
repo and it appears to be just a bit too old to have the --pdf-poppler
option. Right now, for testing, I'm just using the first thing I have at
hand that works, which is pdftocairo:

: (setq org-babel-latex-pdf-svg-process "pdftocairo -svg %f %O")

I'll probably switch to inkscape for options like not exporting text to
paths.

I also considered dvisvgm, which I use for snippet preview, but I
*think* that using xetex, I could not use dvisvgm for Babel blocks
because the Babel latex-to-svg process expects a pdf to be produced,
whereas xelatex only outputs dvi (actually an extended dvi format called
xdv) if you use the -no-pdf option. Could be wrong.

> I don't know if you use `org-latex-preview` for `tikz` snippets? Maybe you 
> don't because that doesn't export to `html`.
>
> I use `(setq org-preview-latex-default-process 'dvipng)`, and I guess it 
> would be nice to add an new option in `(defcustom 
> org-preview-latex-process-alist` to add `inkscape`.

I imagine that's possible.

But on raw tikz snippets (not src blocks), this already works well for
me with dvisvgm. To get it working with xetex I have customized the
dvisvgm option in org-preview-latex-process-alist:

   ...
   (dvisvgm :programs
("xelatex" "dvisvgm")
:description "xdv > svg"
:message "you need to install the programs: xetex and dvisvgm."
:image-input-type "xdv" :image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("xelatex -no-pdf -interaction nonstopmode 
-output-directory %o %f")
:image-converter ("dvisvgm %f --no-fonts --exact-bbox
--scale=%S --output=%O")))
   ...


> So with you solution, I guess when we export to `html`, the "normal" `latex` 
> formulas are rendered by `mathjax`, which works very well, and the `tikz` 
> diagrams are automatically exported as a `svg` image, while the code to 
> produce them is not exported.
>
> I suppose you use those `latex` code block for exporting to `html` purpose?

Yes, that's my aim.

Yours,
Christian

Re: Worg: Possible bug about inline-image example using four brackets

[Corwin Brust]

On Fri, Mar 31, 2023 at 7:32 AM  wrote:
>
> it seems there is no bug-tracker for "worg" at
> "https://git.sr.ht/~bzg/worg;.

I believe that we use the org bug tracker including for worg - see
`org-submit-bug-report`.

>
> Please see the line behind this link
> https://git.sr.ht/~bzg/worg/tree/master/item/org-tutorials/images-and-xhtml-export.org#L61
>
> There you find an example of in inline-image in org-mode uing 4 brackets
> on each side.
>
>  lore /img/org-mode-unicorn.png ipsum
>
> My org (Emacs 29) does ignore two of the brackets when exporting to HTL.
> When using two brackets only, inline images also rendered as
> inline-images without problems.

Thanks for reporting, I'll try to take a look at this a little later
today (assuming nobody else fixes it first).

Corwin

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

[Jack Kamm]

Ihor Radchenko  writes:

> Thanks!
> Note that I did not implement my suggestion because I am concerned if
> putting CRLF is safe as every single line ending.
>
> I am looking at
> https://icalendar.org/iCalendar-RFC-5545/3-6-2-to-do-component.html, and
> I note that only BEGIN:VTODO and END:VTODO lines must actually have
> CRLF. For example,
> https://icalendar.org/iCalendar-RFC-5545/3-3-11-text.html has no
> mentions of CRLF, but does talk about escaping staff.

My reading of [1] is that all lines must end with CRLF:

> The iCalendar object is organized into individual lines of text,
> called content lines. Content lines are delimited by a line break,
> which is a CRLF sequence

And in particular, for the component properties after BEGIN:VTODO, [1]
gives the general notation as:

> contentline   = name *(";" param ) ":" value CRLF

For example, the DTSTART notation [2] is:

>  dtstart= "DTSTART" dtstparam ":" dtstval CRLF

And the same is true for all the other properties.

[1] https://icalendar.org/iCalendar-RFC-5545/3-1-content-lines.html
[2] https://icalendar.org/iCalendar-RFC-5545/3-8-2-4-date-time-start.html

Re: [BUG] No font lock in src blocks for shells in org-babel-shell-names (was Re: Font lock for org-babel shell scripts?)

[Ihor Radchenko]

Derek Chen-Becker  writes:

> Would it be fair to use the sh-ancestor-alist as a basis for all of the
> supported shell variants?
>
> https://github.com/emacs-mirror/emacs/blob/master/lisp/progmodes/sh-script.el#L177

How can we use it?

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

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

[Ihor Radchenko]

Jack Kamm  writes:

> However you are right that other parts of the iCalendar export have
> inconsistent line endings. Currently, VEVENT and VTODO components have
> the correct CRLF endings, but the other parts of the VCALENDAR do not
> (such as the preamble).
>
> I like your suggestion in the above thread to just wrap the whole
> export in `org-icalendar-fold-string'.  Though I think it's slightly
> nicer to do it in `org-icalendar--vcalendar' instead of
> `org-icalendar-template'.
>
> So, I've attached a standalone patch to do this. It also fixes an issue
> with `org-icalendar-fold-string' where the last newline was missing
> "\r", and adds a unit test.

Thanks!
Note that I did not implement my suggestion because I am concerned if
putting CRLF is safe as every single line ending.

I am looking at
https://icalendar.org/iCalendar-RFC-5545/3-6-2-to-do-component.html, and
I note that only BEGIN:VTODO and END:VTODO lines must actually have
CRLF. For example,
https://icalendar.org/iCalendar-RFC-5545/3-3-11-text.html has no
mentions of CRLF, but does talk about escaping staff.

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

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

[Ihor Radchenko]

Jack Kamm  writes:

>> I am looking at
>> https://icalendar.org/iCalendar-RFC-5545/3-6-2-to-do-component.html, and
>> I note that only BEGIN:VTODO and END:VTODO lines must actually have
>> CRLF. For example,
>> https://icalendar.org/iCalendar-RFC-5545/3-3-11-text.html has no
>> mentions of CRLF, but does talk about escaping staff.
>
> My reading of [1] is that all lines must end with CRLF:

Good to hear that we do not need to worry about the need to mix CRLF and
\n.

I now only have one minor concern about `org-icalendar-fold-string' when
the original buffer contains DOS line endings. May they mess things up
producing \r\r\n? If not, feel free to install the patch.

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

Re: [BUG] No font lock in src blocks for shells in org-babel-shell-names (was Re: Font lock for org-babel shell scripts?)

[Ihor Radchenko]

Derek Chen-Becker  writes:

> When I asked the question I was just thinking of using it as a reference
> for expanding the current org-src-lang-modes values, but now that you've
> asked the question, perhaps we could dynamically amend org-src-lang-modes
> based on the contents of sh-ancestor-alist. Does that make sense?

Nope, it does not. May you elaborate how exactly can we derive major
mode for an src block using sh-ancestor-alist?
>From my reading of sh-script.el, we may simply use bash-ts-mode for all
the shells.

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

Worg: Possible bug about inline-image example using four brackets

[c . buhtz]

Hello,

it seems there is no bug-tracker for "worg" at 
"https://git.sr.ht/~bzg/worg;.


Please see the line behind this link
https://git.sr.ht/~bzg/worg/tree/master/item/org-tutorials/images-and-xhtml-export.org#L61

There you find an example of in inline-image in org-mode uing 4 brackets 
on each side.


lore /img/org-mode-unicorn.png ipsum

My org (Emacs 29) does ignore two of the brackets when exporting to HTL. 
When using two brackets only, inline images also rendered as 
inline-images without problems.


So do I assume correct that the document is wrong and there should be 
two instead of four brackets?


Kind
Christian

Re: [BUG] No font lock in src blocks for shells in org-babel-shell-names (was Re: Font lock for org-babel shell scripts?)

[Derek Chen-Becker]

When I asked the question I was just thinking of using it as a reference
for expanding the current org-src-lang-modes values, but now that you've
asked the question, perhaps we could dynamically amend org-src-lang-modes
based on the contents of sh-ancestor-alist. Does that make sense?

Thanks,

Derek

On Fri, Mar 31, 2023 at 7:06 AM Ihor Radchenko  wrote:

> Derek Chen-Becker  writes:
>
> > Would it be fair to use the sh-ancestor-alist as a basis for all of the
> > supported shell variants?
> >
> >
> https://github.com/emacs-mirror/emacs/blob/master/lisp/progmodes/sh-script.el#L177
>
> How can we use it?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: Worg: Possible bug about inline-image example using four brackets

[Corwin Brust]

> On Fri, Mar 31, 2023 at 7:32 AM  wrote:
> >
> > There you find an example of in inline-image in org-mode uing 4 brackets
> > on each side.
> >
> >  lore /img/org-mode-unicorn.png ipsum
> >

Now corrected. Thanks again for your feedback on worg :)

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

[Jack Kamm]

Ihor Radchenko  writes:

> I now only have one minor concern about `org-icalendar-fold-string' when
> the original buffer contains DOS line endings. May they mess things up
> producing \r\r\n?

There are 2 issues here: what does `org-icalendar-fold-string' do when
string already contains \r, and what does `org-export-to-file' do when
`org-export-coding-system' or `buffer-file-coding-system' is dos-like.

In both cases, the patch doesn't change the existing behavior -- which
is to produce \r\r\n.

For issue 1, what `org-icalendar-fold-string' does when string already
contains \r\n, you can see that it produces \r\r\n as follows:

emacs -Q -l ox-icalendar
M-:
(org-icalendar-fold-string (org-icalendar-fold-string "Line1\nLine2"))

This is why the patch removes the calls to `org-icalendar-fold-string'
in `org-icalendar--vevent' and `org-icalendar--vtodo' -- otherwise we
would add \r multiple times to the same string.

To change this behavior of `org-icalendar-fold-string', we could
modify the patch to do:

 (defun org-icalendar-fold-string (s)
   "Fold string S according to RFC 5545."
   (replace-regexp-in-string
-   "\n" "\r\n"
+   "\r*\n" "\r\n"

which would strip out any extra \r at end of line. Another alternative
would be to use "\r?\n" instead of "\r*\n".

For the second issue -- when `org-export-coding-system' is dos (or
similar), the file created by `org-export-to-file' will contain
\r\r\n. This was already the pre-existing behavior, but note the patch
does cause a minor change here: before the patch just the main body
will have \r\r\n, but after the patch, the preamble will also have it.

Re: Worg: Possible bug about inline-image example using four brackets

[Corwin Brust]

On Fri, Mar 31, 2023 at 2:49 PM Ihor Radchenko  wrote:
>
> Corwin Brust  writes:
>
> > Now corrected. Thanks again for your feedback on worg :)
>
> Thanks, but you cannot put language as example block argument.
>

When I remove the language argument ("org"), org resumes thinking it
is a link: it becomes a button and hides the markup we are giving an
example of.

> Org mode version 9.6.1 (release_9.6.1-40-g3d817c @ 
> d:/emacs-build/install/emacs-29.0.60/share/emacs/29.0.60/lisp/org/)

Re: Worg: Possible bug about inline-image example using four brackets

[Ihor Radchenko]

Corwin Brust  writes:

> Now corrected. Thanks again for your feedback on worg :)

Thanks, but you cannot put language as example block argument.

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