Re: [PATCH] ox-html: Add webp as an inline image format

[Kyle Meyer]

Jay Kamat writes:

> Subject: [PATCH] ox-html: Add webp as an inline image format

Thanks for the patch.  Pushed (a9f38b1c2) with a few additions (updated
the :package-version keyword, added a NEWS entry, and added a period
after the changelog entry.)

Re: [PATCH] Fix ob-smiles using old org API.

[Kyle Meyer]

Lein Matsumaru writes:

> As subject says, it does not get updated, so I did.
[...]
> Subject: [PATCH] ob-smiles.el: Update org babel API

Thanks.  Pushed (1738b455b), along with a follow-up commit that fixes
the free variable reference in molecule-jump.

Note that the plan is to move contrib/ to a separate repo [1], with the
eventual goal of each file being maintained elsewhere, in case you or
others are interested.

  [1] https://orgmode.org/list/87wnzfy60h@bzg.fr

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Timothy]

Tim Cross  writes:

> My view is 'go for it'. Just create a new feature branch and implment
> the functionality in that branch. We can then try using it and see where
> it works and where it doesn't. Once this is done, a call can be made as
> to whether it should be implemented in the main code base

I'm all for this approach, it will just be quite a while till I have the
time free to do this. In addition to the 2-3 currently unresolved
patches from me on the mailing list I already have another 11 patches
lined up (see https://tecosaur.com/public/todo.html#patches-from-my)
among other things .

--
Timothy

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Tim Cross]

Timothy  writes:

> Tim Cross  writes:
>
>> In principal, it wold be great to be able to support multi-row columns.
>> However, I'm not sure how easily this can actually be implemented in a
>> consistent and maintainable manner.
>
> Mmmm, this of feels like something where you'll quickly learn how hard
> it is/isn't when you try to implement it.
>
>> From watching these discussions in the past, I think the big stumbling
>> block is how easily multi-row columns can be added and maintained in the
>> various export formats. Some are easy, like HTML, but others are less
>> so. In particular, I know from my many years working with Latex,
>> multi-row columns are not straight-forward. There are lots of edge cases
>> to deal with and it is hard to get a consistent result programatically.
>>
>> Proposals like this one can seem simple and straight-forward on the
>> surface. However, implementation is another matter. All of the exporters
>> will need to be updated to handle this new syntax and it will probably
>> take a fair bit of work to handle it correctly in just plain org files
>> (formatting, highlighting etc).
>
> Currently if you were to try this content with the proposed syntax,
> content is just put in the top left cell of the group. This seems like a
> reasonable fallback to me. Then for HTML we have colspan/rowspan, and
> for LaTeX there's \multicolumn and with the multirow package \multirow.
>
> FWIW just formatting would need to be updated for Org files.
> Highlighting is fine as is.
>
>> If this was something people were prepared to put the time into
>> implementing, I think it must be done in a completely separate feature
>> branch and would need to be fully tested (including all back end
>> exporters) before it can be merged into the mainline branch. It would
>> also be important to profile and ensure it does not have significant
>> impact on performance.
>>
>> I am a little concerned about the expansion and addition of features in
>> org mode when there seems to already be a challenge with respect to
>> maintenance and bug fixing. Personally, I would prefer an org mode which
>> is consistent and reliable over one with large numbers of features that
>> is less stable and slower.
>
> I appreciate this concern, but I do think that the ability to have
> multi-col/row cells is invaluable in many large tables, and so would be
> a very good addition to Org.

We can debate how easy or hard this is to implement indefinitely. What
is needed is for someone to implement a working version which is
consistent, reliable and provides expected results across all export
environments.

The devil is in the details and I suspect that once you start trying to
implement the feature is when many of those challenges become clear.

My view is 'go for it'. Just create a new feature branch and implment
the functionality in that branch. We can then try using it and see where
it works and where it doesn't. Once this is done, a call can be made as
to whether it should be implemented in the main code base
-- 
Tim Cross

bug#44824: [PATCH] org.el: Avoid xdg-open silent failure

[Kyle Meyer]

Maxim Nikulin writes:

> org.el: Avoid xdg-open silent failure
> 
> * lisp/org.el (org-open-file): Use 'pipe :connection-type instead of
> 'pty to prevent killing of background process on handler exit.
> 
> Problem happens only in some desktop environments where configured
> through `org-file-apps' or mailcap handlers launches actual viewer
> (as defined in .desktop files and obtained from mimeapps.list)
> in background.  E.g. xdg-open invokes "gio open" or kde-open5 for Gnome
> or KDE accordingly and these handlers launches e.g. eog or okular in
> background.  As soon as main process exits, temporary terminal session
> created by `start-process-shell-command' is terminated.  As a result
> background processes receive SIGHUP.
> 
> Previously command were executed with no buffer, so the change
> does not affect "needsterminal" and "copiousoutput" mailcap features,
> they are not supported as earlier.
> 
> If handler main process fails then show a message with exit reason.
> Output (including error messages) is ignored as before.
> Gtk application tends to report significant amount of failed asserts
> hardly informative for majority of users.

Thanks for the detailed commit message.

A few comments in addition to Eli's advice to drop the
(eq system-type 'gnu/linux) condition...

> diff --git a/lisp/org.el b/lisp/org.el
> index 7d8733448..a199a65c9 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -8645,6 +8645,15 @@ opened in Emacs."
> (when add-auto-mode
>   (mapcar (lambda (x) (cons (car x) 'emacs)) auto-mode-alist
>  
> +(defun org--error-process-sentinel (proc event)
> +  "Show a message if process failed (exited with non-zero code
> +or killed by a signal.  Pass the function as :SENTINEL argument

Please rework the first sentence so that it fits on the first line,
though I'd be in favor dropping the function and using a lambda in the
make-process call.

> +of `make-process'."
> +  (unless (string-match "finished" event)

There's no need for substring matching, right?  So it could be

  (equal event "finished\n")

Or perhaps

  (when (and (memq (process-status proc) '(exit signal))
 (/= (process-exit-status proc) 0))
...)

> +(message "Command %s: %s."
> + (mapconcat 'identity (process-command proc) " ")

s/'identity/#'identity/

> + (substring event 0 -1
> +
>  ;;;###autoload
>  (defun org-open-file (path  in-emacs line search)
>"Open the file at PATH.
> @@ -8766,7 +8775,17 @@ If the file does not exist, throw an error."
>  
>(save-window-excursion
>   (message "Running %s...done" cmd)
> - (start-process-shell-command cmd nil cmd)
> + (if (eq system-type 'gnu/linux)
> +   ;; Handlers as "gio open" and kde-open5 start viewer in background

s/as/such as/ ?

> +   ;; and exit immediately. Avoid start-process since it assumes

  ^ missing space

> +   ;; :connection-type 'pty and kills children processes with SIGHUP
> +   ;; when temporary terminal session is finished.
> +   (make-process
> + :name "org-open-file" :connection-type 'pipe :noquery 't

s/'t/t/

> + :buffer nil ; use "*Messages*" for debugging
> + :sentinel 'org--error-process-sentinel
> + :command (list shell-file-name shell-command-switch cmd))
> +   (start-process-shell-command cmd nil cmd))
>   (and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait
>   ((or (stringp cmd)
> (eq cmd 'emacs))

Thanks.

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Timothy]

Tim Cross  writes:

> In principal, it wold be great to be able to support multi-row columns.
> However, I'm not sure how easily this can actually be implemented in a
> consistent and maintainable manner.

Mmmm, this of feels like something where you'll quickly learn how hard
it is/isn't when you try to implement it.

> From watching these discussions in the past, I think the big stumbling
> block is how easily multi-row columns can be added and maintained in the
> various export formats. Some are easy, like HTML, but others are less
> so. In particular, I know from my many years working with Latex,
> multi-row columns are not straight-forward. There are lots of edge cases
> to deal with and it is hard to get a consistent result programatically.
>
> Proposals like this one can seem simple and straight-forward on the
> surface. However, implementation is another matter. All of the exporters
> will need to be updated to handle this new syntax and it will probably
> take a fair bit of work to handle it correctly in just plain org files
> (formatting, highlighting etc).

Currently if you were to try this content with the proposed syntax,
content is just put in the top left cell of the group. This seems like a
reasonable fallback to me. Then for HTML we have colspan/rowspan, and
for LaTeX there's \multicolumn and with the multirow package \multirow.

FWIW just formatting would need to be updated for Org files.
Highlighting is fine as is.

> If this was something people were prepared to put the time into
> implementing, I think it must be done in a completely separate feature
> branch and would need to be fully tested (including all back end
> exporters) before it can be merged into the mainline branch. It would
> also be important to profile and ensure it does not have significant
> impact on performance.
>
> I am a little concerned about the expansion and addition of features in
> org mode when there seems to already be a challenge with respect to
> maintenance and bug fixing. Personally, I would prefer an org mode which
> is consistent and reliable over one with large numbers of features that
> is less stable and slower.

I appreciate this concern, but I do think that the ability to have
multi-col/row cells is invaluable in many large tables, and so would be
a very good addition to Org.

--
Timothy

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

Tim Cross  writes:

> From watching these discussions in the past, I think the big stumbling
> block is how easily multi-row columns can be added and maintained in the
> various export formats. Some are easy, like HTML, but others are less
> so. In particular, I know from my many years working with Latex,
> multi-row columns are not straight-forward. There are lots of edge cases
> to deal with and it is hard to get a consistent result programatically. 
>
> Proposals like this one can seem simple and straight-forward on the
> surface. However, implementation is another matter. All of the exporters
> will need to be updated to handle this new syntax and it will probably
> take a fair bit of work to handle it correctly in just plain org files
> (formatting, highlighting etc).

I don't know if anyone has come up with this other possibility: if the
problem is (usually) the inconvenience of editing cells with a lot of
text within an Org document (since when exporting to LaTeX for example,
it makes no difference whether the cell content is on a single line, if
the tabularx package is used properly), then the possibility of editing
a cell in a dedicated buffer would be very practical here. A kind of
`org-edit-special' for cells... That could be combined with
`org-table-toggle-column-width'.

Best regards,

Juan Manuel 

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Tim Cross]

Atlas Cove  writes:

> On 18/03/2021 14:26, Timothy wrote:
>>Interesting suggestion you have here.
>>On a related note, I wonder if you might have seen this thread I raised
>>a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
>>The discussion has died down (unfortunately), but the idea is still on
>>my mind.
>>
>>--
>>Timothy
>
> I'd like to propose to fold my discussion into yours.

In principal, it wold be great to be able to support multi-row columns.
However, I'm not sure how easily this can actually be implemented in a
consistent and maintainable manner.

>From watching these discussions in the past, I think the big stumbling
block is how easily multi-row columns can be added and maintained in the
various export formats. Some are easy, like HTML, but others are less
so. In particular, I know from my many years working with Latex,
multi-row columns are not straight-forward. There are lots of edge cases
to deal with and it is hard to get a consistent result programatically. 

Proposals like this one can seem simple and straight-forward on the
surface. However, implementation is another matter. All of the exporters
will need to be updated to handle this new syntax and it will probably
take a fair bit of work to handle it correctly in just plain org files
(formatting, highlighting etc).

If this was something people were prepared to put the time into
implementing, I think it must be done in a completely separate feature
branch and would need to be fully tested (including all back end
exporters) before it can be merged into the mainline branch. It would
also be important to profile and ensure it does not have significant
impact on performance.

I am a little concerned about the expansion and addition of features in
org mode when there seems to already be a challenge with respect to
maintenance and bug fixing. Personally, I would prefer an org mode which
is consistent and reliable over one with large numbers of features that
is less stable and slower.

-- 
Tim Cross

RE: Sharing variables between source blocks without session

[Cook, Malcolm]

Eric S Fraga  writes:
>
>> On Tuesday, 16 Mar 2021 at 09:56, Loris Bennett wrote:
>>> How can I avoid having to declare the variable 'user' for both blocks?
>>
>> I imagine you could use a property, as in
>>
>> #+property: header-args :var user=loris
>>
>> or even make it specific for the particular language.
>>
>> (untested)
>
>Thanks for point out using 'header-args;' as property. However, if I do
>the following, the variable is unset in the shell script:
>
>#+properties: header-args :var user=loris
>
>#+begin_src sh
>echo user: ${user}
>#+end_src
>
>#+RESULTS:
>: user:
>
>Is that supposed to work, or am I doing something wrong?

I am unfamiliar with using the plural form of property, as you are trying, at 
buffer-level nor do I see  documented possible here:
https://orgmode.org/manual/Property-Syntax.html#Property-Syntax

try this:

#+property: header-args:sh :var user="loris"
#+begin_src sh
echo user: ${user}
#+end_src

Important: After adding or modifying the #+property line, you will need to 
instruct org to "refresh your local setup" which I typically accomplish by 
positioning the point on that line and typing C-c C-c

>
>Cheers,
>
>Loris
>
>-- 
>This signature is currently under construction.
>

Re: odt export and embedded latex

[Eric S Fraga]

On Thursday, 18 Mar 2021 at 12:03, Esteban Venialgo wrote:
> I'd like to export a .org file as ODT and I have an embedded latex
> gantt chart in a separated tex file. The problem is that the gantt
> chart does not get exported. It seems that it's completely ignored by
> the odt exporting tool.

This is expected.  LaTeX code, included the way you have, is only
processed for LaTeX export (including PDF).  The alternative is to have
a LaTeX src block which results in a (say) .png file which will then be
exported to ODT.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: Sharing variables between source blocks without session

[Eric S Fraga]

On Thursday, 18 Mar 2021 at 14:21, Loris Bennett wrote:
> Thanks for point out using 'header-args;' as property.  However, if I do
> the following, the variable is unset in the shell script:

Works for me.

Make sure you reload properties by hitting C-c C-c on the property line
(or some other #+ meta line in the file).  Also, you will need to put
the value of the user variable in "quotes", i.e. user="loris", for some
reason.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: export org table to html, exclude certain rows

[Uwe Brauer]

>>> "MN" == Maxim Nikulin  writes:

> On 18/03/2021 20:34, Uwe Brauer wrote:
>> Does there exist a similar feature for rows?

> Have you tried "/"?
> https://orgmode.org/manual/Advanced-features.html

You are right of course, sorry




smime.p7s
Description: S/MIME cryptographic signature

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

Atlas Cove  writes:

> In effect, yes. I'm proposing it as a syntax addition to make it easier to 
> read, export, and manage, larger tables.
> I'm unsure if this would fit within the scope of org, but 
> [[https://github.com/RedBug312/markdown-it-multimd-table][other projects]],
> like 
> [[https://fletcher.github.io/MultiMarkdown-6/MMD_Users_Guide.html#tables][MultiMarkdown]]
>  have exactly what I want in terms of table use.
> Since I've already proposed a single, solitary addition to org, we won't 
> discuss all of those nice features /just/ yet!

Thanks for your clarification. I strongly support your proposal.

Best regards,

Juan Manuel 

Re: How to get shell source blocks to read my profile?

[Maxim Nikulin]

On 16/03/2021 20:21, George Mauer wrote:


I do still wonder what would be the disadvantage of just configuring it 
to do --login by default and doing all configuration in profile scripts.


At the first glance it at least should not cause great trouble. Most 
shell stuff is written in fool-proof way to avoid loading interactive 
features in non-interactive shell or reinitialize login settings in 
nested shells. Local scripts could be written with less care.


I do not think you need completion functions or changing window title 
during execution of code snippets from emacs.


Self-contained org files have some value, you are trying to put some 
important settings outside. It might be reasonable for personal 
preferences as account names but hardly should be general practice.


On the other hand, I think, it is an equally valid question:
What is the profit?

For some reason your are avoiding over means to set environment 
variables. If you wish just exported environment variables, you could 
always create your own wrapper (untested)


#!/bin/bash

source ~/.config/wundershrc
exec "$0" "$@"

On 17/03/2021 03:32, Tim Cross wrote:

It can sometimes help to remember what early Unix
environments were like and what the resource constraints were to
understand some of the design decisions. A time when memory and disk
storage was extremely expensive and in short supply, where CPUs were
slower and less capable than those commonly found in a modern washing
machine.


Quite recent story is rewriting init scripts to be able to run them with 
dash instead of bash as /bin/sh. On the other hand unavailable features 
require more extensive usage of subprocesses like sed, awk, etc.

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Atlas Cove]

On 18/03/2021 14:26, Timothy wrote:

Interesting suggestion you have here.
On a related note, I wonder if you might have seen this thread I raised
a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
The discussion has died down (unfortunately), but the idea is still on
my mind.

--
Timothy


I'd like to propose to fold my discussion into yours.

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Timothy]

Hi!

Interesting suggestion you have here.
On a related note, I wonder if you might have seen this thread I raised
a while ago: https://orgmode.org/list/87k0v361x9@gmail.com/
The discussion has died down (unfortunately), but the idea is still on
my mind.

--
Timothy

Re: export org table to html, exclude certain rows

[Maxim Nikulin]

On 18/03/2021 20:34, Uwe Brauer wrote:


Does there exist a similar feature for rows?


Have you tried "/"?
https://orgmode.org/manual/Advanced-features.html

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Maxim Nikulin]

On 18/03/2021 03:29, Atlas Cove wrote:


I'd like to propose an addition to the table syntax that would allow for 
text wrapping in tables, I personally have myself managing
very large org tables, and having to scroll through them is often 
cumbersome. As a result, I often yearn for greater control over how I 
format my tables.


https://orgmode.org/worg/org-faq.html#table-multiline-fields
Org-mode Frequently Asked Questions


Will there ever be support for multiple lines in a table field?

No.

You can embed tables created with the table.el package in org-mode
buffers, with mixed success when it comes to export and publishing.

Notice however

mid:87czz4ielc@gnu.org
https://orgmode.org/list/87czz4ielc@gnu.org/
On 21/12/2020 00:15, Bastien wrote:

Would it be so bad if org-mode decides to stop supporting table.el tables?

I don't see the benefit of supporting both Org tables and tables.el tables,
and it calls for confusion.


There is org-table-wrap-region function that could help to type text
occupying several cell, but the result will not become single cell 
during export.


I have seen several threads related to multiline cells, e.g.

https://orgmode.org/list/f2e9aaacd51ee95dcc696ed9485741dde1067340.ca...@sindominio.net/T/#u
org-cell in org-table with a list or a new paragraph

or proposal of another extension:

https://orgmode.org/list/87k0v361x9@gmail.com
Tables: missing multi-col/row syntax

As to MultiMarkdown, the link that you posted says


Cell content must be on one line only


Personally I do not mind to have paragraph-like cells, but I am afraid 
that it requires a lot of work to support export, feeding src blocks, 
alignment.

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Daniele Nicolodi]

On 18/03/2021 14:38, Atlas Cove wrote:
>> technically the second table is more space efficient than the first
> 
> I was referring to screen space.

Assuming that you are looking at this with a monospaced font (and I
don't see how you could use a variable width font to look at an Org
table effectively), screen space is proportional to the number of
characters.

Cheers,
Dan

Exam LaTeX class

[陈贤文]

Does someone have experiences with the exam LaTeX class: 
http://www-math.mit.edu/~psh/exam/examdoc.pdf?


I made a simple hack to make it work, by adding the following lines to 
the .emacs file:


(add-to-list 'org-latex-classes
'("exam"
"\\documentclass{exam}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))

The next step I'm trying to do, but don't know how, is to ask LaTeX 
exporter to create two exports to PDF.


One export is the usual export.

The other export is to have [answers] in \documentclass, which in LaTeX 
will be:


\documentclass[answers]{exam}

When answers is specified, the resulted PDF will include the solutions 
that are preset in the solution environments.


The switch of printing or hiding solution environments can also be 
achieved by one of the following preamble codes: \printanswers or 
\noprintanswers.


I guess one way is to modify the org-latex-export-to-pdf function, so 
that when the document class is exam, the exporter first export without 
solutions, and then export to an other PDF file (such as 
foo-with_solutions.pdf).


But maybe someone else has hacked on the exam document class as well and 
would like to share their experiences?


Xianwen

copy org-org-output? Based on copy-tex-output

[Uwe Brauer]

Hi 

The following function, courtesy by Al Haji-Ali, allows me to copy latex
output (basically pdf) to a directory of my choice.

(defun copy-tex-output ()
   (interactive)
   (let* ((default (expand-file-name (TeX-active-master nil)))
  (default-dir (file-name-directory default))
  (default-file (concat (file-name-nondirectory default) "." 
(TeX-output-extension)))
  (outputfile (expand-file-name (TeX-active-master 
(TeX-output-extension
  (filename (read-file-name "Save as:" default-dir
 default-file nil default-file)))
 (copy-file outputfile filename t)))

In order to use that for org-export, I need to know whether there is
something like TeX-output-extension for orgmode

Any idea?

regards

Uwe Brauer 

export org table to html, exclude certain rows

[Uwe Brauer]

Hi 

I know how to exclude certain columns in org table for being exported to
HTML o Latex.

Does there exist a similar feature for rows?

Regards

Uwe Brauer 

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Atlas Cove]

technically the second table is more space efficient than the first


I was referring to screen space.


Should Org understand all the 'concatenated text' as a single row (and not as 
multiple rows)?


In effect, yes. I'm proposing it as a syntax addition to make it easier to 
read, export, and manage, larger tables.
I'm unsure if this would fit within the scope of org, but 
[[https://github.com/RedBug312/markdown-it-multimd-table][other projects]],
like 
[[https://fletcher.github.io/MultiMarkdown-6/MMD_Users_Guide.html#tables][MultiMarkdown]]
 have exactly what I want in terms of table use.
Since I've already proposed a single, solitary addition to org, we won't 
discuss all of those nice features /just/ yet!

Re: Sharing variables between source blocks without session

[Loris Bennett]

Eric S Fraga  writes:

> On Tuesday, 16 Mar 2021 at 09:56, Loris Bennett wrote:
>> How can I avoid having to declare the variable 'user' for both blocks?
>
> I imagine you could use a property, as in
>
> #+property: header-args :var user=loris
>
> or even make it specific for the particular language.
>
> (untested)

Thanks for point out using 'header-args;' as property.  However, if I do
the following, the variable is unset in the shell script:

#+properties: header-args :var user=loris

#+begin_src sh
  echo user: ${user}
#+end_src

#+RESULTS:
: user:

Is that supposed to work, or am I doing something wrong?

Cheers,

Loris

-- 
This signature is currently under construction.

[PATCH] Fix ob-smiles using old org API.

[Lein Matsumaru]

As subject says, it does not get updated, so I did.

>From 24fe077429a83c4c4a48d873b03627782de0b883 Mon Sep 17 00:00:00 2001
From: Lein Matsumaru 
Date: Tue, 16 Mar 2021 10:52:18 +
Subject: [PATCH] ob-smiles.el: Update org babel API

* contrib/lisp/ob-smiles.el (org-link): Fix from org-add-link-type to
org-link-set-parameters

TINYCHANGE
---
 contrib/lisp/ob-smiles.el | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/contrib/lisp/ob-smiles.el b/contrib/lisp/ob-smiles.el
index 9f4f14080..77d7e11c4 100644
--- a/contrib/lisp/ob-smiles.el
+++ b/contrib/lisp/ob-smiles.el
@@ -14,7 +14,10 @@
 ;; Maintainer: stardiviner [numbch...@gmail.com]
 
 ;;; Code:
-
+
+(require 'ob)
+(require 'org-element)
+
 ;; Org-mode Babel
 (defun org-babel-execute:smiles (body params)
   "Execute SMILES babel `BODY' with `PARAMS'."
@@ -36,10 +39,10 @@
  ((eq 'html backend)
   (format "%s" name name)
 
-(org-add-link-type
+(org-link-set-parameters
  "molecule"
- 'molecule-jump
- 'molecule-export)
+ :follow 'molecule-jump
+ :export 'molecule-export)
 
 ;; org-mode element
 (org-element-map (org-element-parse-buffer)
-- 
2.30.1

odt export and embedded latex

[Esteban Venialgo]

hi org experts,

I'd like to export a .org file as ODT and I have an embedded latex gantt 
chart in a separated tex file. The problem is that the gantt chart does 
not get exported. It seems that it's completely ignored by the odt 
exporting tool.

This is the latex section within my .org file:


* Planning

  Gantt chart with the project planning:
  #+LaTeX_HEADER: \input{./project_planning/gantt_preamble.tex}
  #+INCLUDE: "./project_planning/gantt.tex" export latex


If I export the .org with org-latex-export-to-pdf, it works with no 
errors. So, it's not an issue related to the latex source itself.

May you have any suggestions to try ?

    Thanks for your help, Esteban

Re: org-capture-template: table lines including newline of sorts

[Uwe Brauer]

   > On 3/16/21 3:34 AM, Uwe Brauer wrote:
   > I'm running org 9.4.4 and emacs 28.0.50, (both from source) on Debian
   > testing. According to my notes in my init file I created the template
   > in early July 2011, modified it slightly two years later. I do not
   > recall any problems with it.

   > Just to  make sure that there is no problem with the timeslips
   > template, at least on my system, I commented out all of the capture
   > templates before and after the timeslips template and reloaded my init
   > file. I ran org-capture (bound to C-cm). The timeslips came up in the
   > dispatcher and it ran OK.

   > I notice that I was off by a key and typed periods and not semicolons
   > in the two lines "some capture templates," and, "some more capture
   > templates."




I commented out all my templates

So the only entry is 

("s" "timeslip" table-line
 (file "/home/oub/timeslips.org")
   ;;   (file "d:/ActiveFiles/timeslips.org")
  "\| %(org-read-date)\| %^{FileName} %i\|
  %^{Narrative} %i\| %^{Time} %i\| %^{Expense} %i"

Timeslips.org is empty.

I mark a line in my org-init file and fire up org-capture using your
template, I insert as file name org-init, 
narrative I insert blabla 
time I insert 10:00
Expense I insert 10

And I obtain 

| Bad template 

What do I miss here?

Thanks 

Uwe 


smime.p7s
Description: S/MIME cryptographic signature