Re: Org-agenda: List project with deadlines

[Christian Moe]

Hi, Sébastien,

A general take: Org does not tell you how to organize your notes, it
provides tools for doing it any way you like, and this freedom bewilders
everyone. People work out their own systems, with advantages and
disadvantages. You may find it liberating to consider that there is no
single right way to do it. Though of course it's always good to arrive
at some consistent scheme you can re-use.

To add to the bewildering choice: One option you did not mention is
capturing column views [[info:org#Capturing column view]]. This gives
you updateable table of tasks and the properties you select for column
view. While you cannot perform actions on the tasks in those tables as
you can when using column view directly, they are helpful for getting an
overview (I find them easier to take in at a glance than the column-view
overlay). Using different column definitions for subtrees, you could
have a top-level table for projects and project-level tables for tasks.

As the info page mentions, in addition to the built-in system there is
also a contributed package, org-collector, that offers an alternative
approach to tabulating tasks and properties. I have found it powerful
and flexible. Since it does not rely on column-view definitions, though,
it means a tiny bit of duplicated effort if you're going to use column
view as well.

Yours,
Christian

Sébastien Gendre writes:

> Hello,
>
> I have some problems to manage my tasks for school with Org-mode. I had
> read manual, blog posts and tried different way. With no success.
>
>
> * What I need.
>
> For the school, I have a list of projects to do. Each with a deadline
> and different level of importance. And each project have their how
> tasks. Some with schedule, some with deadline and some with neither.
>
> Some times, I need to see only the list of projects, with their status,
> deadline, percentage done, importance and class name. How many days left
> would be nice. But not their inner tasks.
>
> When I work on a project, I need to see its tasks with their
> deadline/schedule, importance/optionality and status.
>
>
>
> * The problem I got
>
> I search a good way to manage it with Org-mode, but I have difficulty to
> do it easily. I always end with a complex system.
>
>
> ** Record the information
>
> Each class have its own file. In each class file, I have a section named
> "Projects and Tasks". As the name say, this section regroup the class
> projects and tasks.
>
> For each project and their tasks, I was thinking of creating a heading
> for the project and sub-heading for its tasks. Adding a [%] in the
> project title, a level A to C for its importance, a DEADLINE for its
> deadline and a tag for the class name.
>
> To record a new projects, I use a capture template to not forget
> anything. The new project go into an Inbox.org file and I use Org-refile
> to move it to its file.
>
> But how do I differentiate a project from a task for Org-mode ? Tags
> have inheritance. Do I use a property ?
>
> Is it a good idea to organize every thing by classes ? Or is it better
> to have one Org file named "Assignments" to regroup every projects ? In
> these files, I have other information recorded, like the taken notes,
> the list of distributed documents and their notes and also the list of
> class sessions to see them in my agenda.
>
>
> ** List the projects
>
> To list only the projects, I wanted to use Org-agenda todo list view and
> editing the column shown. But the manual say it may cause issues.
>
> What can I do ? Do I use it correctly or do I need to it in a completely
> different way ? Is it better to use a column view for it ? If yes, is it
> possible to build a column view from multiple files ?
>
>
> ** List of tasks from a project
>
> What is the best way to do it ? A custom Org-agenda view for each
> project ? A column view under the project top heading ?
>
>
> * Conclusion
>
> I have the felling that wanting to have everything well organized and
> using Org-agenda push me to think of too much complex ways to do thing.
>
> Maybe I need to do like with a bullet journal, with an Org-mode file
> instead of a page and don't try to use too much features.
>
> Do you have any suggestion ? Do I forget something ? For what I have
> suggested, am I completely wrong ?
>
>
>
> Best regards

Re: Footnotes on line and not raised

[Christian Moe]

Hi,

The footnote definitions are easy to fix with CSS since they are wrapped
in divs with the .footdef class.

#+begin_src css
  .footdef sup { vertical-align: baseline; font-size: 100%; }
#+end_src

But as you point out, the footnote references, are not as
straigthforward given the  structure -- at least
if you need other superscripts.

If you're not very concerned about cross-browser support, you can use
the :has() selector. Works fine in an up-to-date Firefox, but that's all
I'll promise.

#+begin_src css
  sup:has(.footref) { vertical-align: baseline; font-size: 100%; }
#+end_src

Otherwise, I think you'll need an export filter. Here's one that simply
sets the .footref class on the SUP element as well:

#+begin_src elisp
  (defun my-html-filter-footnotes (footnote backend info)
"Export footnote references with a class definition on the SUP
  element to make them more amenable to CSS."
(when (org-export-derived-backend-p backend 'html)
  (replace-regexp-in-string
   "" "" footnote)))

  (add-to-list 'org-export-filter-footnote-reference-functions
   'my-html-filter-footnotes)
#+end_src

Now it's easy to style the footnote reference with

#+begin_src css
  sup.footref { vertical-align: baseline; font-size: 100%; }
#+end_src

One could perhaps make the case that Org ought to do this by default.

Yours,
Christian

Colin Baxter writes:

> I use footnotes as [fn:1], etc. in an org-mode file which I then export
> to html. In the output, I see the footnotes raised slightly above the
> line. I do not want this. Instead, I would like the footnotes to be on
> the line. Is this possible?
>
> I have read the doc strings associated with the variables
> `org-footnote-define-inline' and `org-footnote-auto-adjust', but,
> frankly, I am none the wiser.
>
> Best Wishes,
>
> Colin Baxter.

Re: Developing Moodle resources/sites with Org Mode

[Christian Moe]

Hi, Edward

Edward Doolittle writes:

> 2) Development of Moodle glossaries. Glossaries can be uploaded to a
> Moodle site using an appropriate XML file.  Glossaries could be
> developed in Org mode, including JSXgraph diagrams and graphs, PNG
> images, and so on, and then Org mode converted to XML and the XML
> transformed to Moodle Glossary XML using XSLT.  (I don't really know
> those tools at all, so I don't know if that would be a good way to go
> about the process; exporting directly to Moodle Glossary was my first
> thought, but it is not a general export that is necessary or
> appropriate, rather an export of a specifically designed Org file.
> XSLT seems old fashioned but there are tools around, and there is a
> project for exporting Org mode to XML.)

I'm a Moodle noob and rusty on the tools, but this is interesting to
think about.

You may not need any additional library for the XML export bit. The
builtin Org HTML exporter does XHTML export by default, and XHTML is an
XML, so one could just apply XSLT to that. There may be advantages to
using a library like om-to-xml (cleaner, more semantic XML; access to
more properties than what gets exported). But it looks like Moodle only
uses XML to wrap the glossary entries and their properties; any markup
inside the glossary definitions appears to be in HTML (with the html
tags entity-escaped), not defined by the Moodle glossary XML format. So
if you're going to have some markup in the definitions, you may be
better off leaving the (X)HTML part to Org instead of reimplementing it
in XSLT.

Another option might be to dispense with XSLT entirely and just write
elisp code to map the entries of an Org glossary and generate Moodle XML
from that.

How would you format the glossary on the Org side? Would you use Org
entries (** term) or Org description lists (- term :: definition)?

On the Moodle side, do you want keywords and attachments?

Yours,
Christian

Re: kaobook tex template integration to a org file to make self-contained, portable?

[Christian Moe]

Hi,

For starters, have you added the kaobook document class to the variable
org-latex-classes? (If yes, ignore the rest of this message, if not, do
so and see what happens.)

This is needed to tell Org how to set the document class and what commands
are used for sections. See the manual 13.10.2 and 13.10.3,
[[info:org#LaTeX specific export settings]] and [[info:org#LaTeX header
and sectioning]], and look up the docstring for org-latex-classes if you
need help.

E.g., in .emacs I have this for Tufte-Latex:

(add-to-list 'org-latex-classes
 '("tufte-handout" "\\documentclass[11pt,a4paper]{tufte-handout}"
   ("\\section{%s}" . "\\section*{%s}")
   ("\\subsection{%s}" . "\\subsection*{%s}")))

(add-to-list 'org-latex-classes
 '("tufte-book" "\\documentclass[11pt,a5paper,nols]{tufte-book}"
   ("\\part{%s}" . "\\part*{%s}")
   ("\\section{%s}" . "\\section*{%s}")
   ("\\subsection{%s}" . "\\subsection*{%s}")
   ("\\paragraph{%s}" . "\\paragraph*{%s}")))

Yours,
Christian


Zenny writes:

> Hi,
>
> References of interest:
> 1. https://github.com/fmarotta/kaobook
> 2. https://github.com/asilata/emacsconf2021
>
> Can anyone guide me how to get a self-contained and portable template that
> executes kaobook tex templates (see 1) to create an org-file that resembles
> with the instance in 2 above?
>
> I tried the best I can by adding the kaobook.cls and kaobook.sty files
> inside `~/texmf/tex/latex/kaobook/` folder and specified 'kaobook' in the
> `#+latex_class: kaobook` but it failed to produce the desired look of pdf
> similar to
> https://github.com/fmarotta/kaobook/blob/master/example_and_documentation.pdf
> withing the same examples directory!
>
> Any input appreciated!
>
> Cheers and have a nice week,
> /z

Re: [FR] Please add support for screenplay formatting

[Christian Moe]

Ihor Radchenko writes:

> Fionn Stephens  writes:
>
>> I think support for screenplay formatting would be a useful feature to add. 
>> Like to how comments or quotes are done, it could be in between the tags: 
>> #+BEGIN_SCREENPLAY and #+END_SCREENPLAY. I think using the markdown used by 
>> Fountain would make the most sense.
>>
>> For example, a section could look like:
>>
>> #+BEGIN_SCREENPLAY
>> INT./EXT. BLOOM HOUSE - (PRESENT) DAY
>> ...
>
> May you please elaborate? What is screenplay? Is it a markup format?
> What do you mean by support? Export? Font-lock? Something else?

Fountain is a Markdown-inspired plain text format for screenplays
(https://fountain.io/).

There exists a fountain-mode major mode for Emacs.

To my mind, Org should not support every kind of markup/markdown format
there is, but to the extent Fountain is the best format for screenplays,
and Org is good for organizing bits of screenplays, I think maybe using
Org-babel src blocks is the way to go?

Even without a dedicated ob-fountain package to support it, it can be
used today for tangling screenplays from blocks of Fountain format with
noweb syntax, editing blocks in fountain-mode, some limited syntax
highlighting etc.

Yours,
Christian

Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG

[Christian Moe]

Ihor Radchenko writes:

> Christian Moe  writes:
>
>> I think there's a better approach. Tl;dr:
>>
>> - A better way to have active CSS in SVG images is to link to the
>>   external SVG file with the  rather than  tag, as we used
>>   to.
>
> Reading the linked threads, it seems that  has its own
> downsides. Why is it strictly better then?

I'm not sure it's strictly better.

The problem in the linked threads was with scaling, and I don't think it
applies anymore. As I just tested in Firefox, at least, I can control
the size of Gerard's SVG illustration perfectly well by setting CSS
height and width attributes on an .

Apart from that, my reasoning amounted only to this:

-  works as well as embedding for CSS

- For Org to extract and embed the SVG means more things that can break
  (though I admit that it can be made a lot less fragile than the
  #+INCLUDE hack) and when they do break, it's an Org problem. With
   Org just needs to properly format the tags; if it does, the
  rest is the browser's responsibility.

- If the external SVG file is modified, with embedding all files
  referencing it need to be exported again for the change to take
  effect. With  linking to the external file, all that is
  needed is refreshing the browser.

- Readable, uncluttered HTML is nice; huge, unreadable stretches of SVG
  aren't.

Some arguments for embedding I didn't consider:

- fewer http calls

- It makes accessing the SVG internals with Javascript a bit easier than
  with  (the difference is just one line of JS) -- and a lot
  easier if you trigger Firefox's same-origin restrictions by keeping
  the files on a file system rather than a server.

>> - Without patching Org, you can embed an external SVG file as an SVG
>>   island in Org HTML export simply by using #+INCLUDE.
>
> To be clear, I am in favor of adding "embedding" switch for ox-html in
> general. It is a feature several people requested elsewhere - for all images.
> #+INCLUDE is cumbersome, does not work with captions, and will generally
> break Org customization relying on Org knowing what kind of object is
> being exported.

Fair points.

Yours,
Christian

Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG

[Christian Moe]

gerard.vermeu...@posteo.net writes:

> On 06.06.2023 11:57, Christian Moe wrote:
[...]
>> 1) Embedded SVG is not the only way to have active CSS etc. in SVG
>> images. Linking to an external SVG file with an OBJECT element instead
>> of IMG should work fine (tested in Firefox). You can test this by
>> exporting Gerard's mwe.org example and editing the mwe.html to replace
>> : img src="./doc8.svg"
>> with
>> : object type="image/svg+xml" data="./doc8.svg"
>
> Indeed, the flower works after the replacement but the caption
> disappears.
> I do not understand why, because the caption is still present in the
> HTML.

Oops, sorry, my example was incomplete. Closing the  tag with
 should help.

[...]
>> 2) You can actually embed an SVG island in Org HTML export simply by
>> using #+INCLUDE. To try this, add the following line to Gerard's
>> mwe.org:
>> : #+INCLUDE: "./doc8.svg" export html
>> The exported HTML should now show the black flower from Gerard's
>> minimal
>> non-working example plus a working flower.
>
> Indeed, the flower works, but the caption disappears because Org does
> not
> recognize the "#+INCLUDE ..." as a link, the caption does not show up
> in the
> HTML. Is there an easy solution for this issue.

Fair point! No, I don't think there is an easy, non-messy solution that
will make for generating proper figure captions using the Org #+CAPTION
keyword with this approach. The same goes for embedding the SVG in the
Org file itself in a =#+begin_export html= block.

That's obviously a major drawback. So for embedding an external SVG file
as an SVG island in HTML output with proper figure captioning, your
approach is superior to my #+INCLUDE hack.

That said, I still think the better solution to the issue you raised is
for Orgmode to go back to exporting SVG links as  not , not
to extract SVG file contents and embed them as SVG islands.

(Though I may be a breaking change for some users. In particular,
because OBJECT does not have an ALT attribute, but uses several other
ways to provide alternative text for accessibility, users would need to
change their =#+attr_html :alt= to using :aria-label or :title
attributes, unless the Org implementation for SVG links were to handle
this smartly.)

Yours,
Christian

Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG

[Christian Moe]

Hi,

I think there's a better approach. Tl;dr:

- A better way to have active CSS in SVG images is to link to the
  external SVG file with the  rather than  tag, as we used
  to.

- Without patching Org, you can embed an external SVG file as an SVG
  island in Org HTML export simply by using #+INCLUDE.

Details:

1) Embedded SVG is not the only way to have active CSS etc. in SVG
images. Linking to an external SVG file with an OBJECT element instead
of IMG should work fine (tested in Firefox). You can test this by
exporting Gerard's mwe.org example and editing the mwe.html to replace

: img src="./doc8.svg"

with

: object type="image/svg+xml" data="./doc8.svg"

Org used to use OBJECT for SVG years ago, but switched to IMG at some
point. I'm not quite sure when or why that happened (forgive me for not
doing an exhaustive search of the archive or delving into the git
record). But I think perhaps the reason was this thread,

  https://lists.gnu.org/archive/html/emacs-orgmode/2016-07/msg00380.html

where the issue was easy scaling, and that Jarmo Hurri's patch switching
to IMG came to be applied at some point, even though Jarmo and I agreed
that adding a common CLASS="svgfig" attribute to OBJECT would solve his
issue, see this thread:

  https://lists.gnu.org/archive/html/emacs-orgmode/2016-07/msg00410.html

I continue to think that OBJECT with an .svgfig class as default (or a
setting to give the user a choice between IMG and OBJECT) is the best
solution.

2) You can actually embed an SVG island in Org HTML export simply by
using #+INCLUDE. To try this, add the following line to Gerard's mwe.org:

: #+INCLUDE: "./doc8.svg" export html

The exported HTML should now show the black flower from Gerard's minimal
non-working example plus a working flower.

(Some SVG files may start with an XML declaration; if the XML
declaration is on a separate first line, you can just skip it by adding
=:lines "2-"= to the #+INCLUDE instruction.)

Yours,
Christian

Ihor Radchenko writes:

> gerard.vermeu...@posteo.net writes:
>
>> I have been trying to export SVG images having links to CSS from Org to
>> HTML
>> and I have found that the this CSS is not active in Firefox (only
>> browser I tried).
>>
>> I have found that the CCS is only active under two conditions:
>> 1. The HTML page should manage the CSS that the SVG image links to.
>> 2. The SVG image should be embedded in the HTML page.
>
> CCing Timothy, the maintainer.
>
> Also, does the above mean that Firefox does not support custom CSS user
> stylesheets? What am I missing?
>
>> I wrote an ox-html derived export backend to embed SVG images:
>> https://forge.chapril.org/gav451/emacs.d/src/branch/main/site-lisp/ox-my-html/ox-my-html.el
>> and merged the SVG embedding functionality into ox-html.el leading to
>> the
>> attached patch.
>
> Thanks! I will provide high-level comments from general ox.el
> perspective.
>
>> +(:html-embed-svg-excludes "HTML_EMBED_SVG_EXCLUDES" nil
>> +  org-html-embed-svg-excludes split)
>> +(:html-embed-svg-includes "HTML_EMBED_SVG_INCLUDES" nil
>> +  org-html-embed-svg-includes split)
>
> This is awkward. To do per-image export adjustments, we usually use
> export attributes (#+ATTR_HTML: ...). And why "split"?
>
>> +(:with-html-svg-embedding nil "html-embed-svg" org-html-embed-svg)
>
> We have :html-inline-images. Maybe better :html-embed-svg ?
>
>> +(defcustom org-html-embed-svg nil
>> ...
>> +  :version "30.0"
>
> We do not use :version tag. Please use :package-version.
> See Elisp manual section "15.1 Common Item Keywords".
>
> Also, maybe instead of t/nil boolean values here, we may allow the value
> to be a list of regular expressions or a string representing regular
> expression. This will allow what you are trying to do with
> HTML_EMBED_SVG_INCLUDES. The list elements might also be (not "..."),
> replicating HTML_EMBED_SVG_EXLCUDES.
>
> Even more generally, we may turn this into HTML_EMBED_IMAGES and embed
> all the images (possibly filtered by regexp). This will be slightly
> beyond the scope of this patch though.
>
>> +(defun org-html--embed-svg-p (link path info)
>> +  "Check whether LINK and INFO specify to embed the SVG file named PATH.
>> +LINK must have no contents and link to an SVG file.  INFO may contain
>> +lists of SVG files to include in and/or to exclude from embedding."
>> +  (and (not (org-element-contents link))
>
> Please use `org-export-inline-image-p'.
>
>> +(defun org-html-svg-contents (path)
>> +  "Return the SVG contents of the file named PATH."
>> +  (with-temp-buffer
>> +(insert-file-contents path)
>> +;; Delete text preceding something starting as an SVG root element.
>> +;; The intent is to remove XML declarations (and XML comments).
>> +;; This breaks in case of a preceding XML comment with > +;; or a preceding XML element with an SVG element inside.
>> +;; See https://emacs.stackexchange.com/a/57433 for the 

Re: Org-mode publish: Some questions when use it for a blog

[Christian Moe]

>> But, generate a RSS feed with ox-rss [1] give me some problems. The
>> README is not really clear on what the Org-mode file should look. And it
>> seems to be done to generate RSS when all blog posts are a headline in
>> the same document. But on my blog, each blog post is on a different
>> document.
>
> Well. You can define a derived dackend for ox-rss. It will require some
> Elisp though. Check out `org-export-define-derived-backend' call in
> ox-rss.el.
>
> Alternatively, I am pretty sure that a number of rss generators already
> exist for static blogs. They are more likely to work using multiple
> individual html pages as input.

I've seen several people solving this by adapting the sitemap
functionality in org-publish, since the sitemap already pulls together
information about different pages. You can configure org-publish to use
a bespoke sitemap-function that formats the sitemap as an Org file
suitable for RSS export with ox-rss. This looks like a clear explainer:

  https://writepermission.com/org-blogging-rss-feed.html

Yours,
Christian

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: File generation from LaTeX src fails due to temporary PDF in wrong directory

[Christian Moe]

chris writes:

> On Wednesday, 29 March 2023 23:15:03 CEST Christian Moe wrote:
>>
>> Hi,
>>
>> Pardon the noise: It turned out to be a pretty obvious problem with my
>> setup that has now been resolved.
>>
>> I had modified org-latex-pdf-process to use xelatex, and for some reason
>> my setup lacked the =-output-directory %o= switch. I should probably
>> have thought of that first, but the omission has had no ill effects on
>> ordinary PDF export, so I didn't run into any problem before trying to
>> use Babel with LaTeX.
>>
>> Ihor and Pedro, thanks for checking.
>>
>> Chris, I don't know why your attempts fail, but I'll be trying similar
>> things over the next days, so maybe I'll come back to you.
>>
>
> For one thing I don't understand 90% of the options, that can explain a lot.
> Another point, the gibberish output I was speaking about are "similar" those
> of
> [[https://emacs.stackexchange.com/questions/68823/minimal-working-example-of-tikz-to-svg-in-orgmode]]
> Actually the svg image they get is an image containing the `tikz` instructions
> transformed as image. What I get is the svg instructions that should generate
> the image: an image showing a `svg` listing.

I am seeing the same problem, and think I have a solution below, but
it's confusing and I'm wondering if other people have this working out
of the box somehow.

The difference between what you are seeing, and what they are seeing in
the stackexchange thread, comes down to whether =:headers
'("\\usepackage{tikz}")= is specified. Without it, all they get is an
SVG of the glyphs in the arguments to the tikz commands. With it, we get
an SVG of the glyphs in the SVG for the image. So when the extension is
.svg, the intermediate PDF that is converted into SVG does not contain
the image, but a listing of the SVG, which has *already* been generated!

The reason, I think, is that org-babel-latex-preamble includes this
definition:

: \def\pgfsysdriver{pgfsys-tex4ht.def}

So what happens, I think, is that tex4ht already generates SVG from the
TikZ code. When Org then uses org-babel-latex-pdf-svg-process to call an
external utility, by default inkscape, to convert the PDF to SVG, we are
converting not an image but a code listing already in SVG.

It is not at all clear to me why tex4ht is invoked in the default
preamble. I wonder if it still serves a purpose. If it makes better SVG
from LaTeX than the other utilities, it would be nice to use it directly
somehow. But perhaps it is just a leftover from a stage in development
when htlatex was used to produce the SVG, before the two-part-process
->PDF->SVG with org-babel-latex-pdf-svg-process was defined. If so it
should probably be changed. Here's the relevant thread, I think, for
people wanting to look into that:

  https://list.orgmode.org/873608ajfn@bzg.fr/t/


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.

Yours,
Christian

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

[Christian Moe]

Hi,

Pardon the noise: It turned out to be a pretty obvious problem with my
setup that has now been resolved.

I had modified org-latex-pdf-process to use xelatex, and for some reason
my setup lacked the =-output-directory %o= switch. I should probably
have thought of that first, but the omission has had no ill effects on
ordinary PDF export, so I didn't run into any problem before trying to
use Babel with LaTeX.

Ihor and Pedro, thanks for checking.

Chris, I don't know why your attempts fail, but I'll be trying similar
things over the next days, so maybe I'll come back to you.

Yours,
Christian


chris writes:

> On Wednesday, 29 March 2023 10:00:35 CEST Pedro Andres Aranda Gutierrez wrote:
>> On Tue, 28 Mar 2023 10:04:24 +0200, Christian Moe  
>> wrote
>> Hi,
>>
>> > I'm trying and failing to export images from TikZ code, apparently
>> > because the temporary PDF is misplaced. Here is a minimal example just
>> > exporting the PDF:
>>
>> > #+LATEX_HEADER: \usepackage{tikz}
>> >
>> > #+header: :fit yes
>> > #+begin_src latex :exports results :file ./test-tikz-triangle.png
>> > \begin{tikzpicture} %
>> > \draw[draw=black, fill=blue!10] (0,4) -- (3,0) -- (-3,0) -- cycle;
>> > \end{tikzpicture}
>> > #+end_src
>>
>> > Execution fails with an error message like this:
>> >
>> > org-compile-file: File "/tmp/babel-Tay2kl/latex-IJVI84.pdf" wasn’t
>> > produced.  See "*Org PDF LaTeX Output*" for details
>>
>> Hi Christian,
>> trying to reproduce this on a master (emacs30.0.50) on Ubuntu. To make it 
>> really
>> lightweight, I'm starting with
>> emacs -Q
>> but unfortunately, I'm not able to reproduce it here :(
>
> Hi, I've been trying to have a similar example working for hours, 
> specifically I was trying to follow 
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html[1]
>
> Could you provide more context because if I run emacs -Q here, with the 
> example provided by OP, and type C-c C-c, I just get "no org-babel execute 
> function for latex!".
> So I guess it might have required a little more work than what I've just 
> described.
>
> Here is the setting I've used:
>
> This in my dot-emacs.org file:
> #+begin_src emacs-lisp
>   (with-eval-after-load 'org
>   (add-to-list 'org-latex-packages-alist '("" "stmaryrd" t))
>   (add-to-list 'org-latex-packages-alist '("" "tikz-cd" t))
>   (add-to-list 'org-latex-packages-alist '("" "amscd" t))
>   (add-to-list 'org-latex-packages-alist '("" "mathtools" t))
>   (add-to-list 'org-latex-packages-alist '("" "unicode-math" t))
>   ;; (add-to-list 'org-latex-packages-alist '("" "breqn" t))
>   (add-to-list 'org-latex-packages-alist '("" "thisisastupidtestfile" t))
>   (setq org-latex-create-formula-image-program 'dvisvgm) ;; probably only 
> this line is relevant with the matter at hand
>   (setq org-format-latex-options
> (plist-put org-format-latex-options :scale 0.80)))
> #+end_src
>
> With this, when I put the following in some org file and type C-c C-x C-l I 
> immediately get a org-latex-preview of the tikz snippet:
> \begin{tikzpicture} %
>   \draw[->] (-3,0) -- (-2,0) arc[radius=0.5cm,start angle=-180,end angle=0]
>   (-1,0) -- (1,0) arc[radius=0.5cm,start angle=180,end angle=0] (2,0) -- 
> (3,0);
>   \filldraw (-1.5,0) circle[radius=1mm];
>   \filldraw (1.5,0) circle[radius=1mm];
> \end{tikzpicture}
>
> Now If I use the following and type C-c C-c, I never get anything in multiple 
> ways:
> Note that I've also tried with imagemagick...
> #+name: test_plot_png
> #+header: :exports results :file test.svg
> #+header: :dvisvgm yes
> #+header: :fit yes :noweb yes :headers '("\\usepackage{tikz}")
> #+begin_src latex :file test.svg
>   \begin{tikzpicture} %
> \draw[->] (-3,0) -- (-2,0) arc[radius=0.5cm,start angle=-180,end angle=0]
> (-1,0) -- (1,0) arc[radius=0.5cm,start angle=180,end angle=0] (2,0) -- 
> (3,0);
> \filldraw (-1.5,0) circle[radius=1mm];
> \filldraw (1.5,0) circle[radius=1mm];
>   \end{tikzpicture}
> #+end_src
>
> Many times a pdf is generated in the /tmp/ directory but that pdf is 
> gibberish. When I go from the latex file to the pdf using pdflatex, only 
> gibberish pdf is generated, no relation with the image that should be 
> generated.
> If instead I use lualatex, the pdf is correctly generated.
> Anyway, I've been experiment

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

[Christian Moe]

Hi,

I'm trying and failing to export images from TikZ code, apparently
because the temporary PDF is misplaced. Here is a minimal example just
exporting the PDF:

  #+LATEX_HEADER: \usepackage{tikz}

  #+header: :fit yes
  #+begin_src latex :exports results :file ./test-tikz-triangle.png
\begin{tikzpicture} %
  \draw[draw=black, fill=blue!10] (0,4) -- (3,0) -- (-3,0) -- cycle;
\end{tikzpicture}
  #+end_src

Execution fails with an error message like this:

  org-compile-file: File "/tmp/babel-Tay2kl/latex-IJVI84.pdf" wasn’t
  produced.  See "*Org PDF LaTeX Output*" for details

It turns out, however, that the missing temporary file, here
latex-IJVI84.pdf, is in fact correctly produced. The problem is that it
is produced in the same directory as the source org file, not in the
temp directory.

I've had a quick look at org-compile-file, but don't understand what is
going wrong.

I'm running Org 9.6.2 on GNU Emacs 27.2 under Linux Mint, all very
vanilla.

Any suggestions?

Yours,
Christian

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Christian Moe]

Hi, Kevin,

A couple of considerations:

1. I think "ALT" should be "ALLE" as in "alle filene" (the documentation
says "ALL" refers to "All files when clock table includes multiple
files").

2. I like "Tid stempla", but "Tidsoversyn" or "Tidssamandrag" would stick
closer to the original and be clearer, I think.

3. I think "ved" should be omitted. It's not used before dates ("den
3.2.2023" but preferably just "3.2.2023"), days ("på fredag") or times
("klokka 14:00", "kl. 14:00", "14:00"). It's generally safe to omit it:
"Tidsoversyn [2023-02-03 Fri 14:00]" would be clear. If a preposition is
wanted, the entire date could be read "fredag 3.2.2023 kl. 14:00", so
the "på" before weekday would work, I guess.

Yours,
Christian


Kevin Brubeck Unhammer writes:

>> (defcustom org-clock-clocktable-language-setup
>> Contributions for other languages are also welcome.
>
> Here's Norwegian Nynorsk:
>
>   (setq org-clock-clocktable-language-setup
> '(
>
>   ("nn" "Fil"  "N"  "Tidspunkt" "Overskrift" "Tid" "ALT" "Total 
> tid" "Filtid" "Tid stempla ved")
>
>   ))
>
> Looking forward when I can delete that line from my init.el :)

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Christian Moe]

Hi,

I have only partly been able to follow the discussion, but this seems
like a very thoughtful proposal.

I'm just not super happy with the ISO format running clock time and
offset together, which I thinks makes clock times less readable when
you're just quickly glancing through notes.

>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC

The '12:00+02' offset is not the 'dd:dd' shape I expect a clocktime
in. Also, since I don't think in UTC offsets, my brain goes '12:00 plus
2 hours' before 'the 12:00 that's 2 hours ahead of Greenwich'. The
extra cognitive load is admittedly small, and I'd probably probably get
used to it quickly if it were only the '+dd'. But I might still get
tripped up by an offset like '14:00-0230', which is unambiguous to a
computer, but synonymous with '14:00-02:30' to my brain.

>From this perspective I'd be happier with the less concise, but super
explicit

  2022-11-12 14:00 UTC+2
  2022-11-12 14:00 UTC-2:30

but I realize there are many considerations to balance here.

Yours,
Christian


>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, ":" is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org timestamps:
>[2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am.
>
>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 8:00-9:00+08]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]
>
>The format is also forward-compatible with extending Org timestamps
>for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
>remain valid if we decide to adopt such format.
>
> 2. Timestamp with time zone specifier
>
>-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>
>
>For now, time zone name will only be processed when it follows TZ
>POSIX format. If necessary, the proposed syntax will still allow
>extensions to TZ POSIX.
>
>Examples:
>2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>2022-11-12 10:00 @Europe/Berlin
>2022-11-12 10:00 @!Europe/Berlin # "!" does nothing here, see below
>2022-11-12 10:00 @EST+5 # TZ syntax
>2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec 
> allowed in TZ
>
>The "@" symbol is selected to disambiguate time zone specifier from
>other auxiliary information in the timestamp. Like calendar name,
>which might be added in future. Note that we cannot use [...] from
>the standard draft. I selected "@" because it is read as "at" -
>location specifier.
>
>The "!" symbol is adapted from
>https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
>I use space before "@" to improve readability. We deviate from the
>standard here so may as well. In contrast, no space before [+-]offset
>is closer to the standard yet not cluttering the timestamp too much
>(IMHO).
>
> 3. (1) and (2) can be combined
>
>2022-11-12 12:00+08 @Asia/Singapore
>
>Org will unconditionally use +08 offset and ignore the time zone
>name. We prefer absolute offset because it is non-ambiguous wrt
>out-of-date tzdb on the computer. One may also not update the TZ
>variable upon travelling - the system clock will again be more likely
>accurate.
>
>This redundant time offset info can serve as human-readable
>indication of absolute time, while the time zone name will indicate
>the location.
>
>2022-11-12 12:00+07 @!Asia/Singapore
>
>Org will calculate the internal time for both +07 offset and
>Asia/Singapore time zone. If they do not match, Org will issue a
>warning. The offset will still be preferred if we have to proceed.
>
>This can be useful when planning future meetings and sending Org file
>with a timestamp to someone else, potentially with obsolete tzdb.
>
> |---|
> |  |
> |---|
>
> Apart from the ideas mentioned above,
> https://www.loc.gov/standards/datetime/ contains a number of other
> interesting ideas that may or may not be adapted by Org in future.
> I will outline the ideas I find noteworthy to keep them in mind when
> considering changing (including current changes) in the timestamp
> syntax:
>
> 1. Reduced timestamp precision:
>1985-04-12 (day precision, time omitted; available in Org)
>1985-04 (month precision, day and time omitted, not available in Org)
>1985 (year precision)
>
>Current timestamp syntax proposal should not interfere.
>
> 2. Using "T" as date/time delimiter
>1985-04-12T23:20:30 (not supported by Org)
>
> 3. Using "/" for time intervals
>

Re: Org-cite (oc-csl) tip: Filtering bibliography for language

[Christian Moe]

Denis Maier writes:

> Am 19.12.2022 um 23:20 schrieb András Simonyi:
>> ... I've forgotten to add that another (probably more user friendly)
>> option would be to design and implement some kind of  filtering DSL.
>> András
>> On Mon, 19 Dec 2022 at 23:05, András Simonyi
>>  wrote:
>>>
>>> Dear All,
>>>
>>> On Mon, 19 Dec 2022 at 15:49, Christian Moe  wrote:
>>>
>>>> Refinements welcome. I'm especially wondering what would be an elegant
>>>> way to generalize this for more languages without defining a predicate
>>>> for each language (given that we cannot pass the language as an
>>>> additional argument in the print_bibliography line).
>>>
>>> Thanks for describing this usage! As for the problem of generalizing
>>> to more languages, one relatively simple solution would be to allow
>>> arbitrary sexps as filters. Then one could write something like
>>>
>>> #+print_bibliography: :filter (lambda (item) (bibitem-has-language item 
>>> "en")))
>>>
>>> Would this type of extension be helpful? One (not necessarily
>>> important)  consequence would be that filters of this type would be
>>> obviously unusable with the biblatex exporter.
>>>
>>> best wishes,
>>> András
>
> I'd say both options are certainly useful. A filtering DSL is surely
> the more user friendly option, but allowing lambda expressions would
> probably be quicker to implement, and it would also allow for
> predicates not anticipated by DSL designers.
>
> Best,
> Denis

Arbitrary sexps would give us more flexibility. Alternately, one could
achieve more or less the same by letting :filter collect any additional
arguments and pass them as  to the user's predicate function,
something like:

  #+PRINT_BIBLIOGRAPHY: :filter bibitem-lang-p nb nn no :type article

(This perhaps makes for cleaner solutions. And it is perhaps slightly
better from a security viewpoint: I hope for a bright future of
collaborative authoring in Org, so I'm wary of proliferating ways to
execute arbitrary elisp that a user might not notice. But we do have
such ways already, and it's possible to abuse the above solution as
well, so I don't know.)

Alternatively, I think there is a case for adding a user-friendly
:language property to the print_bibliography keyword. On my bookshelf it
vies with primary/secondary sources as the most common criterion for
separate bibliographies.

I was going to say that this is the only extension I can think of that
is needed beside :(not)(csl)type and :(not)keyword, but of course people
are sooner or later going to want easy-to-use properties to filter by
author, publication date ranges, and probably other criteria I cannot
think of right now, so it's a strategic decision for the maintainer(s)
if you want to go that way. :-)

Yours,
Christian

Org-cite (oc-csl) tip: Filtering bibliography for language

[Christian Moe]

Hi,

A tip some of you might find useful:

I wanted to separate sub-bibliographies by language, which is not one of
the out-of-the-box available properties of the PRINT_BIBLIOGRAPHY
keyword.[fn:1] Specifically, I wanted to filter out Norwegian items into
one subbibliography and non-Norwegian ones into another in the same
document.[fn:2]

I found out how to do it with the `PRINT_BIBLIOGRAPHY: :filter
' property, which turns out to be used in the function
citeproc-sb--match-p, where it is applied to a var-value list.

I defined a predicate for Norwegian, bibitem-norwegian-p, that matches a
regexp for various labels for Norwegian[fn:3] against the language
value.

#+begin_src elisp
  (defun bibitem-norwegian-p (vv)
"Returns non-nil (0) if a bibliography item is in
  Norwegian. For use in an org-cite PRINT_BIBLIOGRAPHY filter."
(let ((itemlang (alist-get 'language vv)))
  (and itemlang (string-match "n[obn][r-bo]?" itemlang
#+end_src

Then I could successfully use it as follows:

#+PRINT_BIBLIOGRAPHY: :filter bibitem-norwegian-p

For the list of non-Norwegian items I just needed to define a complementary
function:

#+begin_src elisp
  (defun bibitem-not-norwegian-p (vv)
(not (bibitem-norwegian-p vv)))
#+begin_src elisp

#+PRINT_BIBLIOGRAPHY: :filter bibitem-not-norwegian-p

Adapt as needed for other languages and use cases.

Refinements welcome. I'm especially wondering what would be an elegant
way to generalize this for more languages without defining a predicate
for each language (given that we cannot pass the language as an
additional argument in the print_bibliography line).

* Footnotes

[fn:1] [[info:org#Bibliography options in the ``biblatex'' and ``csl''
export processors]]

[fn:2] For this to work at all, of course, your CSL JSON or BibTeX has
to contain language information on the items; it should, or English
formatting such as title-casing might be applied inappropriately to
non-English items by some styles.

[fn:3] The regexp is complicated because Norwegian is complicated, my
labeling is inconsistent and I want to match at least no, nb, nn, no-NO,
nb-NO, nn-NO, nor, nob, nno, norsk and Norwegian ...



Yours,
Christian

Re: Macro: exporting roman numerals formatted as small-caps

[Christian Moe]

Max Nikulin writes:

> On 08/12/2022 19:38, Carlos Martínez wrote:
>> #+MACRO: sc (eval (if (org-export-derived-backend-p
>> org-export-current-backend 'latex) (concat "@@latex:\\textsc{@@" $1
>> "@@latex:}@@") (concat "@@odt:> text:style-name=\"T1\">@@"$1"@@odt:@@")))
>
>^  ^
> Your missed spaces around $1, but it is unlikely a problem.
>
> Disclaimer: I know almost nothing about odt. Have you customized ODT
> styles? I do not see "T1" in etc/styles/OrgOdtStyles.xml
>
> info "(org) Advanced topics in ODT export"
> https://orgmode.org/manual/Advanced-topics-in-ODT-export.html

Indeed. Carlos, I'm guessing that you formatted a Roman numeral in ODT
as you wanted it to look, saved the document, opened content.xml and
used the resulting XML.

However, what happens then is that the formatting gets saved as an
automatically numbered text style "T1", which isn't going to mean the
same thing the next time you export a document.

See if this works:

- In the document you are using as your ODT_STYLES_FILE, type a Roman
  numeral and format it the way you like.

- Then make it a named character style. In LibreOffice, open the "Styles
  and formatting" sidebar and select the "Character styles" tab. Select
  the formatted Roman numeral in the text. From the "Styles actions"
  dropdown (top right in "Styles and formatting"), choose "New style
  from selection". Give it a name, e.g. "Roman numeral".

- Save the styles file.

- In your macro: replace "T1" with "Roman numeral".

- In all your Org documents where you want this to work: make sure that
  (1) the macro is defined and (2) that ODT_STYLES_FILE points to the
  file you have saved with the style definition for "Roman numeral".

There isn't any simpler way to do it, due to the way LibreOffice stores
all local formatting as generated styles.

Yours,
Christian

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Christian Moe]

Esteban Ordóñez writes:

>>> Hope it clarifies things.
>
> It does.  Thank you very much, Christian.

Just to note: The helpful clarification was Ihor's.

I added a note about strings like this being tricky to localize and
keeping that in mind when doing them in English.

Yours,
Christian

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Christian Moe]

Ihor Radchenko writes:

> Esteban Ordóñez  writes:
>
>> El 2022-12-04 06:17, Ihor Radchenko escribió:
>>
>>> #+BEGIN: clocktable :scope file :maxlevel 2
>>> #+CAPTION: Clock summary at [2022-12-04 Sun 14:16]
>>> |   Headline   |   Time|
>>> |--+---|
>>> | *Total time* | *0h 0min* |
>>> #+END:
>>
>> It is still not clear what "Clock summary at" refers to.  Perhaps
>> someone fairly proficient in the English language could use it in a
>> sentence.  That sentence needs to specifically convey the sense of what
>> "Clock summary at" means in org-mode.  Then I could translate it to
>> Spanish correctly.  Nevertheless, the translation is probably fair
>> enough.
>
> In other words, the caption is trying to say that the table below lists
> summary of clocked time as of [...] date; how much time is spent doing
> various tasks before [...] date.
>
> Hope it clarifies things.

And the timestamp includes hours/minutes, therefore the preposition "at"
is used ("at sixteen minutes past two") rather than "on" ("on the fourth
of December").

I mention this because it's the kind of formulation that can trip people
up during localization, especially if they don't know how "[date]" is
going to be formatted. Going forward, it's worth thinking about making
strings easy to localize. There was just a presentation about this at
Emacsconf the other day (https://emacsconf.org/2022/talks/localizing/).

In the case of "Clock summary at [date time]", the string "Clock
summary, [date time]" would be just as clear and leave less scope for
error, and one could even drop the comma. This might in any case be the
best solution for translations if people are confused what to do with
"at" in their language. (In some, it would simply be the right
translation -- e.g. for Norwegian, for which I'll send a patch shortly).

Yours,
Christian

Re: LIterate programming with calc (help)

[Christian Moe]

Fraga, Eric writes:

> On Monday, 24 Oct 2022 at 09:20, Ihor Radchenko wrote:
>> I vaguely recall that storing variables in calc is something like
>> variable := assignment (which is actually rewrite rule, but that's how
>> 13.1 Storing Variables section of the calc manual explains variable
>> assignments).
>
> That is true for embedded calc (which I use all the time) but I cannot
> seem to get this to work for src blocks:


Same: it requires using the `s s' (calc-store) command, though (which
can also be done without the := assignment operator), and I've searched
the manual without spotting a way to do that with algebraic entry and
hence in a src block, as there doesn't seem to be any corresponding
command. I hope there is a way, though!

As an unsatisfying workaround, one could use :var header arguments; they
work up to a point, but not with units, as Ypo wants to use (and which
are are a really cool thing about Calc).

Once one's using variables, it will probably be necessary to wrap the
final calculation in evalv() to get a numeric value as output instead of
a formula with the variable names in it.

Another obstacle to what Ypo is trying to do is the attempt to use the $
sign for the currency unit. Calc does not have pre-defined currency
units, and $ is taken - it refers to the last value on stack. I tend to
use 'USD'.

So a partial, if pointless, way to do this would be to first store the
variables with the calculator:

  ' 300 m
s s a   # store a = 300 m
  ' 300 m
s s b   # store b = 300 m
  ' 1 USD/m^2
s s cost# store cost = (1) usd/m^2
  ' a*b
s s Area# store Area = a*b (*not* 9 m^2)

Then the last step could be done in a src block:

  #+begin_src calc
evalv(Area * cost)
  #+end_src

  #+RESULTS:
  : 9 USD

(Another cool bit: If you change the value of a or b and rerun the src
block, the result will change, since what was stored in Area was the
product of the variables, not the product of their values.)

Yours,
Christian

Re: How do you manage complex project with Org-mode

[Christian Moe]

I nominate this as the ultimate advice on how to get things done with
Org-mode :-)

Jean Louis writes:

> * Sébastien Gendre  [2022-03-01 05:35]:
>> And I don't know how to manage this kind of projects with Org-mode.
>
> Just use pen and paper notebook. Carry it with you.

Re: Create in Org a bilingual book with facing pages

[Christian Moe]

Hi, Juan Manuel,

I keep saving your messages with process documentation for future
reference should I ever attempt anything similar. Much appreciated!

Yours,
Christian

Juan Manuel Macías writes:

> Hi all,
>
> TL; DR:
>
> The bilingual critical edition (ancient Greek/Spanish) of the letters of
> Demosthenes and Aeschines has recently been published in Spain, a book
> whose production and typesetting I have taken charge of, using Org and
> Org-publish. Although I already have a long experience typesetting
> bilingual editions of a certain complexity, especially for philological
> use, I had never done it until now by centralizing the entire process in
> Org-Mode. I have to say that it has been a very interesting experience,
> so I leave here below a brief description of the process and some tips,
> in case they can be useful to someone who wants to prepare from Org
> bilingual texts with facing pages and certain complexity.
>
> BTW, Here’s a sample of two pages from the book:
>
> 
>
> Long version:
>
> First of all, for this kind of work you have to take into account an
> inherent limitation of TeX: the compilation process in TeX is a
> single-threaded process. That is, in TeX you cannot compile different
> parts of a document, with different configurations (= different
> preambles), at the same time. For example, you cannot have one
> configuration for odd pages and another for even pages (original and
> translation) and compile them in parallel and asynchronously. In Adobe
> InDesign-style DTP programs you can load multiple page threads in
> parallel, but these programs don’t have the typographic refinement of
> TeX. And besides, I never use proprietary software ;-).
>
> Therefore, to create a bilingual edition with facing pages, and for this
> particular type of book where the odd pages (the text in Greek) is a
> critical edition with a strong critical apparatus
> (https://en.wikipedia.org/wiki/Critical_apparatus), it is necessary to
> compile two separate documents and then synchronize them. The good news:
> I have found that, thanks to Org, the process is much more streamlined
> and controlled.
>
> On the other hand, since in this book the content of the odd and even
> pages is variable, the synchronization has been done per page, so that
> the reader always obtains the same content on the odd and even page when
> facing the open book. For the Greek document I used the reledmac LaTeX
> package, which is the most mature LaTeX package for philological
> critical editions, but I used it through my org-critical-edition package
> ().
>
> Once both PDFs are obtained and synchronized, they are loaded into the
> master Org document using the pdfpages LaTeX package. Since it was
> necessary to introduce in certain pages some commands specific to each
> page, such as page styles, index entries or labels for references, and
> to avoid having to load the pages one by one with pdfpages commands, I
> wrote a function that obtains the number of pages of the synchronized
> PDF (via mutool) and it does all that work. The function has three
> arguments: the path to the synced PDF, the general page command, and a
> list of page numbers with particular commands (these last two arguments
> are optional). An example of use would be:
>
> ┌
> │ (inserta-pdfpages-bi "resultado.pdf" "\\thispagestyle{plain}" '((2 
> "\\label{some-label}")))
> └
>
> The function is evaluated in the master document within a source block:
>
> 
>
> To compile the two PDFs separately and get the PDF in sync, I also do it
> from Org using a shell source block. So I have all PDFs always
> synchronized up to date. The synchronized PDF is obtained with pdftk:
>
> 
>
> The rest of the book, introduction, indices, etc. it is normally done
> via Org publish. And the final compilation (the master document that
> includes all sub-documents) is done asynchronously using latexmk.
>
> And that’s it. The next challenge for this fall is going to be a
> trilingual edition of the New Testament (Greek, Latin, Spanish). My idea
> is to try to adapt to Org the use of the LaTeX package flowfram (an
> attempt to create dynamic indesign-style text boxes in LaTeX, but
> ---because of TeX's limitations--- they would not be asynchronous
> boxes). Then, each text in a language would go inside an org block.
> We'll see how it turns out :-)
>
> Best regards,
>
> Juan Manuel
>
> --

Re: Simple but repetitive http links

[Christian Moe]

Hi,

Org scans the file for link definitions when you visit it, so when you
type in the link definition in the buffer, Org is not automatically
aware that it exists. To refresh setup without reloading the file, you
can `C-c C-c' with point on the line with the definition. That should do
it.

Also, if you don't particularly need or like the behavior of querying
for creating a new headline when none is found, you can turn it off by
customizing org-link-search-must-match-exact-headline to nil (the default is
'query-to-create).

Yours,
Christian

Perry Smith writes:

> I'm new to Org mode.  I found this page
> https://orgmode.org/manual/Link-Abbreviations.html about Link
> Abbreviations but I wanted to report my confusion.
>
> I added:
>
> #+LINK: rails  https://rubyonrails.org
>
> to my org file and then I wrote [[rails][Rails]] and when I clicked
> the text, it asked me if I wanted to create a section.  I had to kill
> the buffer and reload it to get it to work.  That's fine but I'm
> wondering if there is a way to make it active without killing the
> buffer.  And I also wanted to suggest adding something about that in
> the manual.
>
> Perhaps this is a common fact with many of Org modes features that I
> missed somewhere?
>
> Thank you for your time,
> Perry

Re: Maintaining oc-csl

[Christian Moe]

András Simonyi writes:

> Dear All,
>
> I'd like to volunteer to maintain oc-csl.el, which currently doesn't
> have an official maintainer as far as I can tell. As the author and
> maintainer of citeproc-el and the author of oc-csl's precursor,
> citeproc-org, I think I'm reasonably well positioned to handle issues
> and make improvements.


Apart from being excellent news, this is one of the best understatements
I've read. :-)

Yours,
Christian

[ODT][BUG] Format error on export with table in list structure

[Christian Moe]

Hi,

Consider the following minimal example, a nested list with a table in a
sub-item (regardless of list types and empty lines):

#+BEGIN_EXAMPLE
1. List item
   - Sub-item
 | Table |
#+END_EXAMPLE

This causes a format error on ODT export (I'm running Org version
9.5.4). In the content.xml file, just before the final closing
 tag, there appears a  tag without a
corresponding opening tag, invalidating the XML.

It may be related to this problem that, just after the table section,
for some reason there appears another numbered list item containing an
empty bulleted list, as if the list were trying to continue.

However, surrounding the table with further list items does not
help. This example causes the same error:

#+BEGIN_EXAMPLE
1. List item
   - Sub-item
 | Table |
   - Second sub-item
2. Second top-level item
#+END_EXAMPLE

If this can be reproduced, I think it's a bug.

(It might be argued that this mix of lists and tables is an abomination
and should not be allowed anyway, but it works in the other exporters.)

What *does* help, strangely, is mixing yet another table into the list
structure. The following example exports without error.

#+BEGIN_EXAMPLE
1. List item
   | Table |
   - Sub-item
 | Table |
#+END_EXAMPLE

Perhaps this can somehow help pin down the problem.

Yours,
Christian

Re: how obtain automatic row numbers in a table starting after the second hline?

[Christian Moe]

Hi, Uwe,

I also get an error when exporting my suggestions to ODT with the
official ODT exporter, but it's not because of the solutions. They
should all be fine, but anyway, it's enough that one of them works for
you.

Rather, the exporter seems to be confused by the way I mixed tables into
a list structure, which leads it to add a  tag
without a preceding opening tag, invalidating the XML. If I can pin down
a minimal example, I'll see about reporting it as a bug in the ODT
exporter (possibly the structure I used is not meant to be allowed, but
it seems to work OK in HTML and LaTeX export).

Yours,
Christian

Uwe Brauer writes:

>>>> "CM" == Christian Moe  writes:
>
>> Hi, Uwe,
>> Three ideas:
>
> Wow, thanks a lot of all these solutions
>
> I am using the new ods exporter found in
>
> g...@github.com:kjambunathan/org-mode-ox-odt.git
>
> And the first and the last solution work in the sense that LO can open the 
> exported ods file while the second (string) and third (conditional) result in 
> ods file that cannot be opened.
>
> Given my use case, I think I will take the first solution, thanks
>
> Again
>
> Uwe

Re: how obtain automatic row numbers in a table starting after the second hline?

[Christian Moe]

Hi, Uwe,

Three ideas:

1. Since your solution depends on the row number (@#) in any case, your
   use case does not actually depend on hline-relative references, does
   it?  Then you can also assign to absolute row numbers, either by

   - assigning to the range rather than to the colum, which is not
 possible with hline relative references (the obvious
 @II$1..@>$1=@#-1+572 is not allowed), but with an absolute start
 reference it works:

 |  Nr |
 |-|
 | |
 |-|
 | 574 |
 | 575 |
 | 576 |
 | 577 |
 #+TBLFM: @3$1..@>$1=@#-1+572

   - or assigning to the row first, then assigning the content between
 the hlines to that cell (perhaps a fragile solution).

 |  Nr |
 |-|
 | |
 |-|
 | 574 |
 | 575 |
 | 576 |
 | 577 |
 #+TBLFM: $1=@#-1+572::@2$1=string("")

2. Use a conditional to avoid changing the cell between the hlines, e.g.:

   |  Nr |
   |-|
   | foo |
   |-|
   | 574 |
   | 575 |
   | 576 |
   | 577 |
   #+TBLFM: $1=if(@# < 3, @0$1, @#+571)

   Here, I use @0$1 to replace that cell with itself. If the cell is empty,
   this evaluates as 0, so if you want an empty string, use string("")
   instead of @0$1.

3. Add a first column with special marking characters (see Org manual:
   Spreadsheet: Advanced features), leaving empty the cell between the
   hlines so it won't get recalculated.

   |   |  Nr |
   |---+-|
   |   | |
   |---+-|
   | * | 574 |
   | * | 575 |
   | * | 576 |
   | * | 577 |
   #+TBLFM: $2=@#-1+572

Yours,
Christian

Uwe Brauer writes:

> Hi
>
> I would like to obtain
> #+begin_src
>
> |  Nr |
> |-|
> | |
> |-|
> | 574 |
> | 575 |
> |  .. |
> | 680 |
> #+end_src
>
> I tried
> #+begin_src
>
> | Nr |
> ||
> |  1 |
> ||
> |  1 |
> |  2 |
> #+TBLFM: $1=vlen(@II$1..0);EN
> #+end_src
>
> or
> #+begin_src
>
> |  Nr |
> |-|
> | 573 |
> |-|
> | 574 |
> | 575 |
> #+TBLFM: $1=@#-1+572
> #+end_src
>
> None worked, any ideas?
>
> thanks
>
> Uwe Brauer

Re: [feature] Allow "," decimal point in table cells (was: org-table with different conventions: decimals)

[Christian Moe]

Ihor Radchenko writes:

> Uwe Brauer  writes:
>
>>> Uwe Brauer  writes:
>>
>>> Org tables use Emacs' calc under the hood by default.
>>> AFAIK, calc is unable to use "," as decimal point because it is reserved
>>> as a vector separator. Which is why you got the vector addition in your
>>> example.
>>
>> Thanks. I was afraid that the issue was with calc not with org-mode.
>
> Note that you can instead use Elisp formulas. See 3.5.3 Emacs Lisp forms
> as formulas. It is more flexible.
>
> Alternatively, we may implement the comma separators as a built-in
> feature. Org table formulas already support notations like
>
> | 3,5 | 4,2 | 7 |
> #+TBLFM: $3=$1+$2;N
>
> or
>
> #+TBLFM: $3=$1+$2;E
> #+TBLFM: $3=$1+$2;L
>
> (see 3.5.2 Formula syntax for Calc)
>
> we may as well implement something like ";Nc" that will interpret cells
> as numbers with "," as decimal point separator.
>
> Is there such a demand?
>
> Best,
> Ihor

That's interesting.

I remember an earlier discussion that settled on the recommendation to
keep the spreadsheet as it is and use export-hooks if one needs to
change the decimal separator upon export. My contribution to the
discussion also gave Carsten the idea of starting a Worg page called
org-madness.org. :-).

Thread started here:
https://lists.gnu.org/archive/html/emacs-orgmode/2011-05/msg00551.html

But I don't think we considered the possibility of a flag to make Org
translate dot-separated decimals into comma-separated ones for
Calc. That could offer more fine-grained control than export processing
when you need some dots to stay dots. And it would certainly be less
challenging for users who just want things to work without digging into
advanced export options!

Export processing (which has since become more fine-grained with the
introduction of filters) remains an option, though, and some backends
offer further possibilities.

Yours,
Christian

Re: Mastodon link type for capturing toots?

[Christian Moe]

Yes, I probably will write my own (and share it here). Just wanted to
check first if the wheel had already been invented, as I'm feeling
lazy. Thanks for confirming it probably hasn't.

Yours,
Christian

Ihor Radchenko writes:

> Christian Moe  writes:
>
>> Has anyone written a link type for Mastodon that would allow you to
>> org-capture the post/status ("toot") at point?
>>
>> I'm referring to mastodon.el
>> (https://codeberg.org/martianh/mastodon.el), which is available via
>> install-packages.
>
> No AFAIK. But it is very easy to define new link types in Org. You can
> do it yourself. See A.3 Adding Hyperlink Types section of the manual.
>
> Best,
> Ihor

Re: About 'inline special blocks'

[Christian Moe]

Juan Manuel Macías writes:

> To add some ideas that have been occurring to me these days...
>

Hi,

This makes sense to me.

Note: For the html output in your example, I expect you don't mean
contents>, but contents. That
would give the desired custom style controle of the output, and would
parallel the behavior of special blocks.

If "inline special blocks" will be able to nest, they will have an
advantage over org macros, which cannot.

Apart from nesting, an org macro could do the same job, but less
elegantly. The suggested inline syntax would not require commas to be
escaped in the contents. And it would be somewhat more concise and far
more legible, as illustrated in the below example (with working macros,
imagined inline special blocks, and a CSS implementation):

#+begin_example
#+macro: fmt @@html:$2latex:\$1{$2}odt:$2@@
#+html_head: .highlight {background-color: yellow;}
#+html_head:.smallcaps {font-variant: small-caps;}

This is some {{{fmt(highlight, highlighted text)}}} and this is some
{{{fmt(smallcaps, text in small caps)}}}.

This is some %[highlight]{highlighted text} and this is some
%[smallcaps]{text in small caps}.
#+end_example

Yours,
Christian

> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would produce
> an overly complicated syntax. Big brothers are independent of the
> paragraph and there it makes sense to add lines with attr_latex, etc.,
> since it is a line-oriented syntax. Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
>
> Another argument against possible fine-tuning within inline special
> blocks, for export purposes, is that (in my opinion) direct formatting
> is a practice that should be avoided as much as possible in a document.
> A document with a lot of direct formatting is an inconsistent document.
> In html, all possible formatting should be controlled by style sheets;
> in LaTeX, by (re)defining macros, commands and environments in the
> preamble or in a .sty file; in odt using character styles.
>
> Perhaps if we detach special blocks from fine-tuning possibilities we
> lose some (export) flexibility, but we gain in a clearer implementation
> of these elements and keep Org aseptic about the output format. And in
> any case, if someone needs a fine-tuning in a certain case, there are
> always the export filters. Or it can be implemented in a similar way to
> inline tasks, with a default format function (for html, latex, etc),
> which can be changed via a defcustom.
>
> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> contents>
>
> in odt:
>
> contents
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
> Best regards,
>
> Juan Manuel

Mastodon link type for capturing toots?

[Christian Moe]

Hi,

Has anyone written a link type for Mastodon that would allow you to
org-capture the post/status ("toot") at point?

I'm referring to mastodon.el
(https://codeberg.org/martianh/mastodon.el), which is available via
install-packages.

Yours,
Christian

Re: export to odt, but #text# should be coloured

[Christian Moe]

I forgot to escape the quotation marks, of course.

>   "@@odt:@@\\1@@odt:@@"

  "@@odt:@@\\1@@odt:@@"

Re: export to odt, but #text# should be coloured

[Christian Moe]

Hi,

Since all formatting is defind as styles and styles are defined in
separate (parts of the) files that make up an ODT file, this requires
you to work with ODT styles. There may be a hack around it, I don't
know.

See the manual for how to use a style sheet with #+ODT_STYLES_FILE. (For
a once-off document, the simplest is to export your document to ODT,
make any style changes to the ODT document, save it, and point
#+ODT_STYLES_FILE to that document for future export.)

In the ODT document you use as styles file, create a new Character
style. For example: In the document, mark some text red. Select the red
text. Open the Styles and Formatting dialog, go to the Character styles
tab (that's the second tab, the first is paragraph styles). Then from
the drop-down "Styles actions" menu (icon on the right), choose "New
style from selection". Name your style, e.g. "Red". It should show up in
the list of character styles.

To apply that style to a span of text, you need to wrap the text in
 tags in the content.xml
component of the ODT file. For your "#" formatting, you could set up an
export hook or filter (manual: "Advanced export configuration") with a
replace-match like

  "@@odt:@@\\1@@odt:@@"

I would probably rather use a macro like

  #+MACRO: red @@odt:@@$1@@odt:@@

  This text is {{{red(alarmingly)}}} red.

Yours,
Christian

Uwe Brauer writes:

> Hi
>
> a short hack of the sort
>
>   (interactive)
>   (while (re-search-forward "#\\([^#]*\\)#" nil t)
> (replace-match "\\1")))
> Allows me to export text like this
> #important#
>
> to HTML where the resulted text is colored in red.
>
> Now, how can I achieve something like this for the odt export?
>
> Reards
> Uwe Brauer

Re: [tip] org-publish to work with (very) large books

[Christian Moe]

Thanks, Juan!

Yours,
Christian

Juan Manuel Macías writes:

> Hi Ihor and Christian,
>
> Ihor Radchenko writes:
>
>> Christian Moe  writes:
>>
>>> Do I understand correctly that the main advantage of this approach (over
>>> #+INCLUDE) is the ability to continuously update preview of the whole
>>> book with latexmk -pvc even if you only re-export one chapter from
>>> Org-mode?
>>
>> I am not sure why Juan did not use include. Include would not require
>> LaTeX to re-compile unchanged files. See
>> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>>
>>> I couldn't find the :body-only publishing option in the docs ...?
>>
>> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>>
>> Best,
>> Ihor
>>
>
> Sorry for not explaining the \input part in more detail. I think the
> essential part here is that all the .tex files (the subdocuments) are
> already created by org-publish before I compile the master document. The
> master document simply stores all the subdocuments: I use
> \input{subdocument.tex} instead of the org #+INCLUDE directive (not the
> LaTeX \include command). The master document calls ready-made TeX files,
> not Org files. And it is independent of the whole org-publish process,
> which is responsible for creating only the parts of the book. This
> procedure, apart from being able to compile parts of the book in real
> time with latexmk -pvc, allows me to have more control over these parts.
> But it makes more sense to use it when dealing with very long books. The
> first time I used it was in a book of more than 1000 pages :-)
>
> The skeleton of the process is that subdocuments are produced with
> org-publish (as uncompiled tex files) and the master document is
> exported to tex from org and then compiled with latexmk inside /tex
> directory.
>
> Best regards,
>
> Juan Manuel 

Re: [tip] org-publish to work with (very) large books

[Christian Moe]

I see, thanks.

Ought this to be documented at [[info:org#Publishing options]], perhaps?

Yours,
Christian

Ihor Radchenko writes:

> Christian Moe  writes:
>
>> Do I understand correctly that the main advantage of this approach (over
>> #+INCLUDE) is the ability to continuously update preview of the whole
>> book with latexmk -pvc even if you only re-export one chapter from
>> Org-mode?
>
> I am not sure why Juan did not use include. Include would not require
> LaTeX to re-compile unchanged files. See
> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>
>> I couldn't find the :body-only publishing option in the docs ...?
>
> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>
> Best,
> Ihor

Re: [tip] org-publish to work with (very) large books

[Christian Moe]

Thanks for this, really interesting.

Do I understand correctly that the main advantage of this approach (over
#+INCLUDE) is the ability to continuously update preview of the whole
book with latexmk -pvc even if you only re-export one chapter from
Org-mode?

I couldn't find the :body-only publishing option in the docs ...?

Yours,
Christian

Juan Manuel Macías writes:

> Hi all,
>
> - tl; dr: I describe here my workflow with org-publish to work with long
> books.
>
> —
>
> I discovered a long time ago that `org-publish' not only works very well
> for managing websites but also for working with long and complex books
> with many parts, with output to LaTeX/PDF. I developed a workflow around
> it that has been quite productive for me, and that I briefly describe
> here in case someone finds it useful and wants to try it or modify/adapt
> it to their needs. I usually use it for my typesetting work, but I think
> it can also be useful for personal projects, such as doctoral theses.
>
> First of all, each folder of my project-books has the same structure:
> two subdirectories named `/org' and `/tex', for the source `org' files
> and for the output `.tex' documents, respectively. And, inside the `org'
> directory I include a `setup' file, an `elisp' file (for export
> filters), and another `/img' directory for image files. Each `org' file
> is a part of the book, and usually begins simply with the directives:
>
> ┌
> │ #+SETUPFILE: xxx.setup
> │ #+INCLUDE: "elisp"
> └
>
> `Org-publish' exports the subdocuments (body only!) as `.tex' documents
> in the `/tex' folder, but they are not compiled.
>
> What gets compiled is a master `.org' file, which is also inside the
> `org' folder. I compile this master file using an asynchronous function
> that calls `latexmk'. I put all the LaTeX configuration, the packages to
> load, the (re)defined commands and macros, the necessary Lua code, etc.
> in a `.sty' file that I load at the very beginning of the master
> document. Subdocuments are loaded into this file by the LaTeX command
> (\input), not by the org #+INCLUDE directive. So the master file usually
> looks like this:
>
> ┌
> │ #+LaTeX_CLASS: my-custom-latex-class
> │ #+LaTeX_Header: \input{my-custom-conf.sty}
> │ #+SETUPFILE: .setup
> │ #+INCLUDE: "elisp"
> │
> │ * Part 1
> │ ** Chapter 1
> │ #+LaTeX: \input{chapter1.tex}
> └
>
> When I eval my function, `latexmk' compiles the entire book with the
> `-pvc' option, which keeps the session open, and if it detects any
> changes to the entire document, it recompiles and refresh the pdf view.
> For example, if I edit one of the subdocuments and run
> `org-publish-current-file', everything is automatically recompiled.
>
> When I have the project folder ready, I add this to
> `org-publish-project-alist' (this is an example from one of the books I
> did recently):
>
> ┌
> │ ("cartas-org"
> │  :base-directory "~/Git/cartas/libro/org/"
> │  :base-extension "org"
> │  ;; Directorio para los ficheros *.tex
> │  :publishing-directory "~/Git/cartas/libro/tex/"
> │  :publishing-function org-latex-publish-to-latex
> │  :body-only t ;; this is important!
> │  :exclude "cartas-master\\.org\\|bibliografia-cartas\\.org"
> │  :recursive t)
> │
> │ ("cartas-img"
> │  :base-directory "~/Git/cartas/libro/org/img/"
> │  :base-extension "jpg\\|png"
> │  :publishing-directory "~/Git/cartas/libro/tex/img/"
> │  :recursive t
> │  :publishing-function org-publish-attachment)
> │
> │ ("cartas" :components ("cartas-tex" "cartas-img"))
> └
>
> And finally, this is the function that compiles everything (each project
> usually has some local variables, like the value of ’jobname’ or the
> status of the printing proofs).
>
> Nota Bene: The reason for using async is that in some projects,
> especially bilingual editions, I need to pre-compile some files first.
> Under normal conditions I don't think it's necessary to use async, since
> org-publish just exports everything to .tex documents (short timeout)
> and then start-process-shell-command run latexmk asynchronously.
>
> Best regards,
>
> Juan Manuel
>
> ┌
> │ (require 'async)
> │ (require 'projectile)
> │
> │ (defun latexmk-compile-project-async ()
> │   (interactive)
> │   (let*
> │   ((project-root (projectile-project-root))
> │(master-file (read-file-name "Compile: "
> │ (concat project-root "libro/org/")))
> │(master-file-tex (file-name-sans-extension
> │  (expand-file-name master-file)))
> │(dir-tex (file-name-directory
> │  (expand-file-name
> │   (replace-regexp-in-string "/org/" "/tex/" master-file)
> │ ;; save the master document
> │ (with-current-buffer
> │ (find-file-noselect master-file)
> │   (save-buffer))
> │ (async-start
> │  (lambda ()
> │(load "~/.emacs")
> │(with-current-buffer
> │(find-file-noselect master-file)
> │  (org-show-all)
> │ 

Re: About 'inline special blocks'

[Christian Moe]

+1

Eric S Fraga writes:

> On Tuesday, 24 May 2022 at 10:51, Timothy wrote:
>> To me, this is another reason for comment and #+attr_X lines not to
>> break paragraphs [...].
>
> And, in fact, if this were true (which I would like), I personally would
> see no reason for having inline special blocks.
>
> Just my 2¢.

Org-cite rocks!

[Christian Moe]

Hi,

This is just to say that I've finally got around to testing org-cite
with citeproc.el and it's awesome. A big thanks to Bruce, András,
Nicolas and everyone else who's been patiently chipping away at this for
years.

Yours,
Christian

[BUG] Agenda view fails with rx error in org-at-timestamp-p

[Christian Moe]

Hi,

After updating to Org mode version 9.5.3-g69c588 via Elpa on Emacs
26.3, my Org Agenda view fails with the following backtrace:

Debugger entered--Lisp error: (error "rx form ‘regexp’ requires args satisfying 
‘stringp’")
  signal(error ("rx form ‘regexp’ requires args satisfying ‘stringp’"))
  error("rx form `%s' requires args satisfying `%s'" regexp stringp)
  rx-check((regexp org-ts-regexp3))
  rx-regexp((regexp org-ts-regexp3))
  rx-form((regexp org-ts-regexp3) |)
  #f(compiled-function (x) #)((regexp org-ts-regexp3))
  mapconcat(#f(compiled-function (x) #) ((regexp 
org-ts-regexp3) (regexp org-element--timestamp-regexp)) "\\|")
  rx-or((or (regexp org-ts-regexp3) (regexp org-element--timestamp-regexp)))
  rx-form((or (regexp org-ts-regexp3) (regexp org-element--timestamp-regexp)))
  rx-to-string((or (regexp org-ts-regexp3) (regexp 
org-element--timestamp-regexp)) t)
  #f(compiled-function ( regexps) #)((or (regexp 
org-ts-regexp3) (regexp org-element--timestamp-regexp)))
  (rx (or (regexp org-ts-regexp3) (regexp org-element--timestamp-regexp)))
  (if (eq extended (quote agenda)) (rx (or (regexp org-ts-regexp3) (regexp 
org-element--timestamp-regexp))) org-ts-regexp3)
  (if extended (if (eq extended (quote agenda)) (rx (or (regexp org-ts-regexp3) 
(regexp org-element--timestamp-regexp))) org-ts-regexp3) org-ts-regexp2)
  (let* ((regexp (if extended (if (eq extended (quote agenda)) (rx (or (regexp 
org-ts-regexp3) (regexp org-element--timestamp-regexp))) org-ts-regexp3) 
org-ts-regexp2)) (pos (point)) (match\? (let ((boundaries (org-in-regexp 
regexp))) (save-match-data (cond ((null boundaries) nil) ((eq extended ...) t) 
(t (or ... ...))) (cond ((not match\?) nil) ((= pos (match-beginning 0)) 
(quote bracket)) ((= pos (1- (match-end 0))) (quote bracket)) ((= pos 
(match-end 0)) (quote after)) ((org-pos-in-match-range pos 2) (quote year)) 
((org-pos-in-match-range pos 3) (quote month)) ((org-pos-in-match-range pos 7) 
(quote hour)) ((org-pos-in-match-range pos 8) (quote minute)) ((or 
(org-pos-in-match-range pos 4) (org-pos-in-match-range pos 5)) (quote day)) 
((and (or (match-end 8) (match-end 5)) (> pos (or (match-end 8) (match-end 5))) 
(< pos (match-end 0))) (- pos (or (match-end 8) (match-end 5 (t (quote 
day
  org-at-timestamp-p(agenda)
  org-agenda-get-timestamps(nil)
  org-agenda-get-day-entries("/home/cm/org/pro.org" (4 18 2022) :deadline 
:scheduled :timestamp :sexp)
  apply(org-agenda-get-day-entries "/home/cm/org/pro.org" (4 18 2022) 
(:deadline :scheduled :timestamp :sexp))
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  org-agenda(nil)
  funcall-interactively(org-agenda nil)
  call-interactively(org-agenda nil nil)
  command-execute(org-agenda)

Yours,
Christian

Re: adding a header and/or footer when exporting to odt

[Christian Moe]

Uwe Brauer writes:

>>>> "CM" == Christian Moe  writes:
>
>> Uwe Brauer writes:
>
>>> Hi
>>> 
>>> Is it possible to have a header and footer in all pages when
>>> exporting to odt? I presume I have to use a odt style I create with
>>> Libreoffice/Openoffice?
>>> 
>>> Thanks
>>> 
>>> Uwe Brauer
>
>> Yes, that's it. Just export your document, add the header you want (and
>> do whatever else you want to do with the style), save it as
>> "my-document-styles.odt" or whatever, and add the header
>
> Shouldn't that be my-documents-styles.ott ???

It could be, if you like, but it works just as well as .odt. Org just
needs to grab a styles.xml from somewhere.

Yours,
Christian

Re: adding a header and/or footer when exporting to odt

[Christian Moe]

Uwe Brauer writes:

> Hi
>
> Is it possible to have a header and footer in all pages when exporting to 
> odt? I presume I have to use a odt style I create with Libreoffice/Openoffice?
>
> Thanks
>
> Uwe Brauer

Yes, that's it. Just export your document, add the header you want (and
do whatever else you want to do with the style), save it as
"my-document-styles.odt" or whatever, and add the header

#+ODT_STYLES_FILE: "my-document-styles.odt"

To reuse a template for several documents with variable header content,
you can use LibreOffice's Insert > Field for Author, Title, Date etc.

With images, etc. it gets a bit more involved.

See the Org manual, Advanced topics in ODT export: Working with
OpenDocument style files.

Yours,
Christian

Re: [PATCH] Accept more :tangle-mode specification forms

[Christian Moe]

Tom Gillespie writes:

> I strongly oppose this patch. It adds far too much complexity to the
> org grammar.  Representation of numbers is an extremely nasty part of
> nearly every language, and I suggest that org steer well clear of
> trying to formalize this.

I'd like to understand these objections better. Aren't you overstating
what is at issue? The patch allows a single keyword option,
:tangle-mode, to accept a few different ways of setting file
permissions. I'm not sure that amounts to formalizing representation of
numbers in Org, or even modifying Org grammar as such. (And I can't
think of other parts of Org where this would be relevant, so I wouldn't
expect demands for further feature creep.)

> With an eye to future portability I suggest
> that no special cases be given to something as important for security
> as tangle mode without very careful consideration.

When you say portability, what are you thinking about? If you're talking
about tangling Org-Babel code with other processors than Emacs Org-mode,
this seems like fairly trivial functionality to reproduce. In fact,
wouldn't this be easier than the current arrangements, which would
require the processor to be able to evaluate an arbitrary Emacs Lisp
expression outside Emacs?

What is the added security problem here, given that file permissions can
already be set by tangle mode?

I suppose that the greater complexity of the patch provides maintainers
with somewhat more opportunities for making code errors. And the greater
choice of representations perhaps gives the user more opportunities for
making user errors (though speaking strictly for myself, I'm more likely
to make those errors calculating octals than using the more intuitive
representations Timothy is helpfully making available). But these
problems seem marginal to me. Are there others?

> Emacs lisp closures have clear semantics in Org and the number syntax
> is clear. If users are concerned about the verbosity of (identity
> #o0600) they could go with the sorter (or #o0600).

But why would anyone want to write a lisp closure a number literal would
suffice? It's not what a user would expect.

Yours,
Christian

Re: Citations merged!

[Christian Moe]

Wow, congratulations!

Yours,
Christian

Nicolas Goaziou writes:

> Hello,
>
> It took years, but citations are now full part of Org syntax.
>
> Thanks to everyone involved over the time!
>
> Now, it needs to be documented, but that will come a bit later.
>
> Regards,

Re: convert subtree or nested list to table

[Christian Moe]

Hi, Matt,

Here's a version of this with a bit more processing.

Define this somewhere in your document

#+NAME: list2table
#+BEGIN_SRC elisp :var order="columns"
  (let (longest)
(setq data (map 'list 'flatten data))
(setq data (map 'list (lambda (x) (seq-difference x '(unordered ordered))) 
data))
;; Pad out lists to equal length
(setq longest (seq-max (map 'list 'length data)))
(setq data
  (map 'list
   (lambda (l)
 (append l (make-list (- longest (length l)) "")))
 data))
;; Order by columns or rows
(if (string= order "columns")
(apply #'mapcar* #'list data) ; transpose
  data))
#+END_SRC

Here is an example list to try it out with:

#+NAME: testlist
- Letters
  1. a
  2. b
  3. c
- Roman numerals
  1. i
  2. ii
  3. iii
- Greek letters
  1. alpha
  2. beta
  3. gamma

Now you can call the src block, passing the name of the list to the
"data" variable.

#+CALL: list2table(data=testlist)

#+RESULTS:
| Letters | Roman numerals | Greek letters |
| a   | i  | alpha |
| b   | ii | beta  |
| c   | iii| gamma |

The default here is that each top item and its sublist forms a column.

To get rows instead, pass order="rows" (or anything other than
order="columns" really):

#+CALL: list2table(data=testlist, order="rows")

#+RESULTS:
| Letters| a | b| c |
| Roman numerals | i | ii   | iii   |
| Greek letters  | alpha | beta | gamma |

You can use numbered or unnumbered lists. Sublists don't strictly have
to be the same length - the code pads them out to equal length with the
empty string before transposing. However, I would strongly recommend
using numbered sublists of the same length (with blank items as needed),
so you can make sure that items line up correctly.

If you want column headers or rownames, you will need to take care of
that manually before exporting. Using ":colnames yes" will lead to
errors when the source is a list. Might be away to hack org-babel to get
around this but I don't know how. (The only automatic solution I can
think of would be by naming the calls in an unexported section and
referencing them with another layer of calls in the exported section,
using a src block that only passes the data on with :colnames yes. But
that's fiddly.)

Will this work for you?

Yours,
Christian


Matt Price writes:

> I think this is exactly what I want (with just a little moreprocessing).
> Thank you so much for the idea!
>
> I'm having a little bit of trouble getting the same output as you though,
> and I'm wondering if there might be a setting that I need to change.
>
> Here is what I tried, and the result. Do you have an idea of what is going
> wrong here?
>
> Thank you!
>
>
> 
> #+NAME:essay-rubric
> - Category
>   - A
>   - B
>   - C
>   - D
>   - F
> - Writing
>   - great
>   - good
>   - ok
>   - lousy
>   - awful
>
> #+begin_src emacs-lisp :var contents=essay-rubric :results table
> contents
> #+end_src
>
> #+RESULTS:
> #+begin_src emacs-lisp
> | (("Category" |
> #+end_src
> -
> On Wed, Jul 7, 2021 at 6:29 AM tbanelwebmin  wrote:
>
>> Hi Matt
>>
>> Le 05/07/2021 à 21:44, Matt Price a écrit :
>> > I have to write a number of text-heavy documents which need to be
>> > delivered as tables with wrapped paragraphs in most cells. Working
>> > directly in table format is pretty arduous and uncomfortable.  Has
>> > anyone ever written a function to accept a list or subtree as input
>> > and process it into a table?
>> >
>> > If anyone has done something similar, I'd love some tips!
>>
>> Maybe you could use builtin Babel
>> Hereafter you have a starting point
>> - Give a name to your input Org list
>> - Process it with Emacs-Lisp (or whatever language you are comfortable
>> with) to output it as a table
>>
>>
>>  self contained Org Mode example _
>>
>> Example of a named list
>> #+NAME: BBB
>> - abc
>>   + 123
>>   + 456
>> - def
>>   + red
>>   + blue
>> - ghi
>>   + big
>>   + small
>>
>> Example of converting the named list into a table with Emacs-Lisp
>> #+begin_src elisp :var bbb=BBB :results table
>> bbb
>> #+end_src
>>
>> #+RESULTS:
>> | abc | (unordered (123) (456))   |
>> | def | (unordered (red) (blue))  |
>> | ghi | (unordered (big) (small)) |
>> ___
>>
>>
>>

Re: publishing: no default publishing function, or symbol is not defined

[Christian Moe]

Hi, Chris,

"Symbol's function definition is void" means there is no such function
defined.

Try org-html-publish-to-html instead.

Yours,
Christian

Christopher W. Ryan via General discussions about Org-mode. writes:

> I'm making my first foray into publishing a project. I'm running GNU
> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>
> I've defined a single project, just to try it out and learn.  Here is
> the relevant portion of my .emacs file
>
>
> ;; Projects and publishing
> ;;
> (setq org-publish-project-alist
>   '(("CaseInvestigationTrainingAndReferenceManual"
>  :base-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/"
>  :publishing-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea")))
>
>
> There is one org file in /Sandbox,  called
> WorkAreaForIndexingTrainingAndReferenceManual-7-June.org
>
> (as the filename suggests, I'm mostly interested in learning how to make
> an index).
>
> If I execute C-c C-e P a  whilie in the org file I am trying to publish,
> I get an error message that there is "No publishing function chosen".  I
> thought org-publish-org-to-html was the default, as described here:
>
> https://www.gnu.org/software/emacs/manual/html_node/org/Publishing-action.html
>
> But if I modify the relevant section of my .emacs file like this,
> specifying a publishing action:
>
> ;; Projects and publishing
> ;;
> (setq org-publish-project-alist
>   '(("CaseInvestigationTrainingAndReferenceManual"
>  :base-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/"
>  :publishing-directory
> "E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea"
>  :publishing-function org-publish-org-to-html)))
>
> and try again, I get an error message that I can't figure out: "Symbol’s
> function definition is void: org-publish-org-to-html"
>
> Grateful for any guidance.
>
> Thanks.
>
> --Chris Ryan

Re: org-critical-edition (a package for philologists and classicists)

[Christian Moe]

Very neat!

Curious about a design choice: If I understand correctly,
org-critical-edition puts the hidden notes in the description and the
visible annotated text in the target of an org link. This is the reverse
of the out-of-the-box link appearance (description visible, target
hidden if description present). Why take the extra trouble to do it this
way?

Yours,
Christian

Juan Manuel Macías writes:

> Hi all,
>
> I have uploaded the (very) initial version of my package
> org-critical-edition:
>
> https://gitlab.com/maciaschain/org-critical-edition
>
> This package lets you prepare a philological critical edition in Org
> Mode. The natural output is LaTeX with the reledmac package
> (https://www.ctan.org/pkg/reledmac).
>
> (For those who are not philologists, this is an example of critical
> edition that I typesetted recently: https://imgur.com/a/drqCib5)
>
> Feedback welcome!
>
> Best regards,
>
> Juan Manuel

Re: Cross referencing in Emacs Org mode

[Christian Moe]

Hi,

The question, then, is not if you can have cross-references (as you say,
they work fine), but if they will work with subtree export.

I believe not (but others may have to correct me). Links/refs to parts
of the document outside the exported subtree *will* be broken. The
exporter does not consider other sections of the document and will not
try to resolve how the refs *should* have looked.

If you use custom IDs or dedicated Org targets like <> for the
label and links like [[label1]] for the refs, you *can* manage how
broken links should be handled. `C-h v org-export-with-broken-links' for
details.

Yours,
Christian

Partha Pratim Ghosh writes:

> Dear All,
>
> Is it possible to have cross reference in LaTeX export for Org
> mode. To be specific: I have a org file segmented into sections, say as
> follows:
>
> *** example of Org file, excluding the headers**
>
> * Section 1
>   contains some text, a label [label:label1] and some citation 
> [cite:cite1]
>
> * Section 2
>   contains some text, a label [label:label2] and a reference to label1
>   as [ref:label1], and a reference to a label in Section 3, [ref:label3]
>
> * Section 3
>   contains some text, and label [label:label3]
>
> \printbibliography
>
> 
>
> I did not include the headers where the bibliography files are properly
> added. When I export the full buffer with C-c C-e l o everything runs
> fine. However, whenever I go to Section 2, say and try to export using
> C-c C-e C-s l o (for subtree export only), the bibliography does not
> appear, and the reference to label1 or label3 does not appear.
>
> Is it possible to have the labels properly referenced as well as the
> bibliography printed when subtrees are only exported to pdf?
>
> With my regards and all the very best wishes,
>
> partha

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

Maxim Nikulin writes:

> On 17/05/2021 02:21, Christian Moe wrote:
>> Maxim Nikulin writes:
>>> On 03/05/2021 04:08, Christian Moe wrote:
>> [snip]
>>> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
>>> #'identity _ ",")))
>>>
>>> {{{allargshack(one, two, three)}}}
>>>
>>> I do not know if Eric can swap order of arguments of his credits
>>> macro. Extracting namely last argument requires a bit more lisp code.
>>
>> Yes, I didn't think that far. This would provide a comprehensive
>> backwards-compatible solution to the comma-escaping problem, though
>> perhaps not the most newbie-friendly one. It would also make macros more
>> flexible and powerful in the bargain (I'm sure people will think of
>> other uses for this than commas).
>
> I agree that it would abuse arguments syntax, but I expect that namely
> newbies would not bother since it would "just work":
>
> #+MACRO definition  - $1 ::$_
>
> {{{definition(one, two, three}}}
>
> It is more experienced users who may be confused why it works.


That's not what I was trying to say. I don't think your suggestion
abuses the argument syntax - it would extend it, in a way that is likely
to prove helpful for multiple purposes.

When I said it was probably not the most newbie-friendly solution for
the comma-escaping problem, I thought that it required including a bit
of lisp in their macros to add the commas back in (the mapconcat
expression in your "allargshack" example above).

But if the "definition" macro above "just works", I suppose that in your
solution, the list of arguments $_ would by default expand to the same
string as the mapconcat expression would, i.e. the commas would be added
back in. That makes sense. The mapconcat expression would not even be
needed, then, unless one wants the macro to do anything else than
preserve commas. Or am I misunderstanding something?

Yours,
Christian

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

Maxim Nikulin writes:

> On 03/05/2021 04:08, Christian Moe wrote:
[snip]
>> Something that would help, without adding new syntax, is
>> making macro expansion smart enough to *ignore* separators when the
>> macro definition contains only *one* argument anyway, as in the cases
>> above.
>
> I think, this is an idea of the best approach. Unsure concerning
> precise form. Maybe e.g. "$_" could expand into all arguments greater
> than maximum referenced number. No promise of forward compatibility of
> the following hack since it relies on undocumented implementation
> details.
>
> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
> #'identity _ ",")))
>
> {{{allargshack(one, two, three)}}}
>
> I do not know if Eric can swap order of arguments of his credits
> macro. Extracting namely last argument requires a bit more lisp code.


Yes, I didn't think that far. This would provide a comprehensive
backwards-compatible solution to the comma-escaping problem, though
perhaps not the most newbie-friendly one. It would also make macros more
flexible and powerful in the bargain (I'm sure people will think of
other uses for this than commas).

Yours,
Christian

Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

I frequently need to escape commas in macros, which is a bit of a pain
and easy to forget. My most frequent use case is a macro that expands in
ODT export to a margin comment (like #+begin_annotation does, but
without causing a line break). It takes one argument which typically
consists of several lines of text with commas in them. If I forget to
escape a comma, the rest of the comment is silently lost to the reader.

So a backwards-compatible remedy would be nice. Juan's/Nicholas's
solution is smart, but I'm not sure if it's exactly what I've been
waiting for. It saves escaping every comma, but I'd still have to
remember to add the separator character every time I *invoke* a macro,
and remembering is the tricky part. I don't know if you've already
considered the option of instead specifying a different separator in the
macro *definition*, say something like

  #+macro: comment @@html:@@ :sep "&"

Another point: Something that would help, without adding new syntax, is
making macro expansion smart enough to *ignore* separators when the
macro definition contains only *one* argument anyway, as in the cases
above. That behavior would also be safely backwards-compatible, I
think. It would not help with macros with more than one arg, like Juan's
example, but it would solve most of my problems, for example.

Yours,
Christian


Juan Manuel Macías writes:

> Hi all,
>
> Thanks for your comments, Bastien and Nicolas.
>
> I think macros can work out of the box as a perfect 'backend' for those
> LaTeX commands that include at least one argument with textual content.
> In my case they are very useful to 'extend' the markup language. Apart
> from the LaTeX example that I put previously
> (\foreignlanguage{lang}{short-text}), there are commands like
> \textsc{text in small caps}, \textcolor{color}{text}, and so on. When
> one of the arguments consists of textual content, even if it is a short
> text, it can be tedious to escape constantly commas[1]. Anyway, I
> understand that my use case may not be that of the rest of the users,
> and what is a 'problem' for me, it may not be seen as a problem by other
> users; therefore, I fully understand Bastien's warnings about making a
> modification to something that already works fine, and has been working
> fine since always.
>
> Nicolas's suggestion seemed the most reasonable, or the least
> destructive, in the hypothetical scenario that there would be a great
> demand among users of an alternative separator. Now I see unlikely,
> however, that such a demand exists ;-) So, if my use case is a minority,
> of course I agree with give up this proposal...
>
> [1] To mitigate 'comma issue' I wrote a function that escapes commas
> when saving document :-D
>
> Best regards,
>
> Juan Manuel
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Bastien  writes:
>>
>>> thank you for the patch.  I understand the general idea, but I think
>>> we should be careful not to overload the macro syntax - escaping the
>>> coma seems okay to me.  I'm closing this suggestion.
>>>
>>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>>> course insist on rejecting it.
>>
>> This is a followup to a previous discussion in this mailing list, in
>> which Juan Manuel explained his use-case for a different argument
>> separator in macros. I noticed then that there was an opening for
>> a backward compatible syntax extension for it. As I was also not certain
>> it would be a good idea overall, I suggested him to start a new, more
>> visible, thread with the proposal, and collect feedback.
>>
>> So, maybe it is a bit early to close it.
>>
>> BTW, I would like to amend the proposed syntax, so as to limit friction
>> with the rest of Org. What would be more reasonable is the following:
>>
>>{{{macroname·(...)}}}
>>
>> where · is either nothing or a _single_ printable non-alphanumeric
>> non-space non-parenthesis character that isn't already meaningful in
>> Org. For example, if for some reason, we limit ourselves to ASCII
>> characters only, the set of allowed separators would be:
>>
>>!   %   &   ,   ;   ?   `
>>
>> So, again, I'm not saying we should do this. TBH, I'm not convinced by
>> the idea of duplicate syntax (comma-escaping and alternate characters)
>> for the same thing. But hard-core macro users may have a word to say
>> about it.
>>
>> WDYT?
>>
>> Regards,

Re: org-refile using the ID of the target

[Christian Moe]

My approach is to tag the equivalent of your "Notes" subtree of the
various projects in my agenda files with an :INBOX: tag.

The following code in .emacs then makes sure they are presented as
refile targets:

;; Refile
(setq org-refile-targets
  '((org-agenda-files . (:tag . "INBOX")) ;; Inbox subtree in each file
(nil . (:level . 1;; and all top headings current 
buffer
(setq org-refile-use-outline-path t)

It may not be quite as fast as what you have in mind, but it is perhaps
more flexible, and saves having to define or remember those keys.

If you already consistently use "Notes" as the heading for this purpose,
you might not even need to tag them; you could try simply replacing
(:tag . "INBOX") above with (:regexp . "Notes").
(This might cast too wide a net, though.) See the documentation for
org-refile targets.

Yours,
Christian

Jack Bauer writes:

> I take a lot of notes using MobileOrg in my phone, and after syncing, they go 
> into in.org (my gtd "in basket"). From there, I do the capturing
> process.
>
> Thing is, sometimes there's a *lot* of notes that I just want to refile to 
> the "Notes" subtree from the corresponding project/context. A quick
> way to do that would be nice.
>
> My idea was to use the org-speed-commands-user to have a single key to press 
> for each category of note. I'd add entries like
>
> ("Q" (my/org-refile-to-id  "TODO")
>
> ("W" (my/org-refile-to-id  "DONE")
>
> ("E" (my/org-refile-to-id  "")
>
> At first, I tried using org-refile, but couldn't find a way to tell it to 
> refile to a specific subtree (eg, using its id).
>
> Then I started hackstumbling around. So far, what I could come up with was:
>
> (defun my/org-refile-to-id (id  todo)
>   "Refile current subtree to subtree with ID."
>   (interactive
>(list (read-string "ID: ")))
>   (when todo (org-todo todo))
>   (org-cut-subtree)
>   (let ((anchor (ignore-errors (org-id-get-create
> (org-id-goto id)
> (org-insert-heading-respect-content)
> (org-demote-subtree)
> (org-yank)
> (exchange-point-and-mark)
> (zap-to-char 1 (string-to-char " "))
> (move-beginning-of-line nil)
> (if anchor
> (org-id-goto anchor)
>  (message "This was the last one."
>
> It feels kinda messy, though.
>
> Any advice would be more than welcome!

Re: How to have a repeating item within some hours?

[Christian Moe]

If it's on the same day, how about this?

** <2021-03-29 Mon 05:15-06:16 +7d> Time block

Yours,
Christian

Marcin Borkowski writes:

> Ping?
>
> On 2021-03-28, at 11:52, Marcin Borkowski  wrote:
>
>> Hi Orgers,
>>
>> I'd like to have a repeating time block on the agenda, say every Monday
>> from 5:15 to 6:15.  I tried this:
>>
>> ** <2021-03-29 Mon 05:15 +7d>--<2021-03-29 Mon 06:15 +7d> Time block
>>
>> but it didn't show on the agenda, and this:
>>
>> ** Time block
>> SCHEDULED: <2021-03-29 Mon 05:15 +7d>--<2021-03-29 Mon 06:15 +7d>
>>
>> but it didn't show the end time.
>>
>> Any hints?

Re: [PATCH] tweaks to ox-html style

[Christian Moe]

Tim Cross writes:

> BTW I think it would be nice if the html export was able to produce/use
> a separate CSS file rather than in-line styles. This would make it
> easier to drop exported HTML files into existing sites with custom
> styles or update the look of exported files without needing to re-export
> or manually edit. The complication is with exporting of HTML snippets,
> where you probably want in-line styles.

Isn't this already covered by existing capabilities? From the manual:

   The HTML export back-end includes a compact default style in each
   exported HTML file.  To override the default style with another
   style, use these keywords in the Org file.  They will replace the
   global defaults the HTML exporter uses.

 #+HTML_HEAD: 
 #+HTML_HEAD_EXTRA: 

   To just turn off the default style, customize
   ‘org-html-head-include-default-style’ variable, or use this option
   line in the Org file.

 #+OPTIONS: html-style:nil

The only thing I don't think it does is export the default style as a
separate .css file rather than inline. Maybe there's a use case where
that would be better than turning it off and specifying a linked style,
but I can't really think of one. I suppose one would need a new option
to specify a path for the exported stylesheet, so it wouldn't save a lot
on option lines.

Yours,
Christian

Re: How to combine two org files that each have footnotes?

[Christian Moe]

Hi,

This is actually easy because Org allows named footnotes (numbers are
really just a special case of names).

Make backup copies of your files for safety's sake, then visit file1.org
and M-% to replace all instances of "fn:" with (for example)
"fn:file1_". The footnotes will now be named fn:file1_1, fn:file1_2,
etc. At this point all your footnotes across the two documents are
already uniquely named (but you can of course also do the corresponding
thing to file2 if you like). Merge away.

Yours,
Christian



aroz...@gmail.com writes:

> Most of my writing is academic and involves lots of footnotes. Sometimes it
> is useful to be able to combine two separate files, each of which have
> footnotes. How do I do so in a way that automatically renumbers the
> footnotes in the file that comes second?
>
> More specifically, I have file1.org and file2.org, and each of them have
> three footnotes ([fn:1], [fn:2], and [fn:3]). I want to create file3.org,
> which simply merges file1.org and file2.org, with the contents of file2.org
> coming after the contents of file1.org. The problem is that the footnote
> calls ([fn:#]) in the file2 section will end up pointing the file1
> footnotes. What I really want is to automatically renumber all the
> footnotes [fn:1]...[fn:6], but I don't know how to do this, given that org
> permits multiple footnote calls to the same footnote.
>
> Thanks,
> Alan

Re: Free up C-c SPC/org-table-blank-field?

[Christian Moe]

Tim Cross writes:

> Eric Abrahamsen  writes:
>
>>> Does it actually need a key binding? I've never used it and just use
>>>  to move to the next field, leaving the field blank.
>>
>> I assume it's meant for blanking a field you've already typed something
>> into. But yes, I can't imagine it's a heavily-used command, and I
>> suspect the C-c  binding is mostly mnemonic: "make this field
>> contain only blanks".
>>
>
> I guess that makes sense, but not convinced the use of a valuable key
> binding is justified given the need. Then again, others probably have
> vastly different use cases to mine.

One can also blank a field by pressing  immediately after tabbing
into it. So C-c  isn't strictly needed.

(Though since you typically discover you want to blank a field only when
you're actually in it, it can help shave a few seconds off your day that
you'd otherwise use to move out of the field you want to blank and tab
back in ... which is how I've done this until now, being unaware of C-c
).

Yours,
Christian

Re: Local variables insecurities - Re: One vs many directories

[Christian Moe]

Located Eric's message and can confirm the same for mu4e (no query about
setting/evaluating anything upon opening the message).

cm

Eric S Fraga writes:

> On Wednesday, 25 Nov 2020 at 15:38, Jean Louis wrote:
>> I have not configured anything. In fact I have opened the email and I
>> was surprised that I am getting those dialogues to execute local
>> variables.
>
> Very strange.  It was my email that instigated this part of the
> thread.  I can view my email and I do not get asked to set any locate
> variables or, in this case, evaluate the elisp expression.  Out of
> curiosity, what mail reader did you use that actually interprets file
> local variables?  Gnus article view does not.

Re: [PATCH] org-table: Add mode flag to enable Calc units simplification mode

[Christian Moe]

Great! Thanks for following through on this, Dan!

Yours,
Christian

Kyle Meyer writes:

> Daniele Nicolodi writes:
>
>> Thank you for the review, Kyle.
>>
>> Another updated patch set is attached.
>
> Thank you for the update.
>
> Applied, tweaking the manual entry to use "a unit" rather than "an
> unit".
>
> 1:  bd7e16ca2 = 1:  bd7e16ca2 org-table: Remove unused org-tbl-calc-modes 
> variable declaration
> 2:  abd994943 = 2:  abd994943 org-table: Simplify mode string parsing
> 3:  cb77e7a46 ! 3:  15469774d org-table: Add mode flag to enable Calc units 
> simplification mode
> @@ doc/org-manual.org: *** Formula syntax for Calc
>  +- =u= ::
>  +
>  +  Units simplification mode of Calc.  Calc is also a symbolic
> -+  calculator and is capable of working with values having an unit,
> -+  represented with numerals followed by an unit string in Org table
> ++  calculator and is capable of working with values having a unit,
> ++  represented with numerals followed by a unit string in Org table
>  +  cells.  This mode instructs Calc to simplify the units in the
>  +  computed expression before returning the result.
>  +

Re: Tables: missing multi-col/row syntax

[Christian Moe]

+1 for enabling table-cell merges in export. I imagine this would be a
tricky job for developers, but it would relieve me as a user of much
repeated fiddling with exported drafts.

+1 for doing it without adding clutter to the table syntax, but
specifying merges on a separate line like formulas, like Tom's

  #+TBLCELLMERGE: @2..3$1

(amended here to use the established '..' rather than hyphen for range)

Though if we do add such a line, we might also think of a more general
solution that could over time be extended with additional formatting
options, e.g. something like

  #+TBLSTYLE: @2..3$1='(:merge t)::@4$1='(:bgcolor yellow :color red)

But obviously that could open a can of worms, aka potentially endless
feature requests requiring different implementations for each backend.

Yours,
Christian



Tom Gillespie writes:

> Any support for something like this would need to retain backward
> compatibility as well to avoid older versions reformatting the tables
> due to e.g. the presence of a double pipe. I also think that extending
> the table syntax in ways that makes it more complex than it already
> is, will be a non-starter. Thus, an alternate but more likely approach
> would be to allow specification of what cells to merge outside the
> table as is done for formulas. It is not elegant, but it would be a
> layer on top of existing syntax, and it would allow the fundamental
> structure of the table to remain the same -- rows of cells. For
> example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts?
> Tom
>
> On Mon, Nov 2, 2020 at 1:37 PM TEC  wrote:
>>
>> Hi all,
>>
>> This is a pretty major 'feature request', but I think also an
>> important
>> one.
>>
>> When developing large tables, it can often be /necessary/ to start
>> using
>> multi-column/row cells for clarity, and sensible exporting
>> results.
>>
>> As far as I am aware, in Org does not currently have any
>> multi-col/row
>> syntax. The only viable method seems to be re-implementing the
>> table
>> using export blocks in every backend you may want to export to (in
>> my
>> case, usually TeX + HTML). This is clumsy, difficult to work with,
>> and
>> could be avoided should org gain support for multi-col/row syntax.
>>
>> I appreciate that this would constitute a major change both the
>> Org's
>> syntax and the codebase, but I believe such a change is warranted
>> by the
>> advantages it would provide.
>>
>> Both how this can be implemented while minimising/eliminating the
>> chance
>> of breaking well-formed current table elements, and what syntax
>> may be
>> both acceptable and seem sensible to use.
>>
>> I would anticipate such a feature working by designating two
>> characters
>> to indicate "add row" and "add column". For example "|" and "-".
>> These
>> characters would take affect when /immediately following/ (no
>> space) a
>> cell separator ("|"), and designate the dimensions of the top
>> right cell.
>>
>> Example:
>> | a | b | c |
>> |---+---+---|
>> | a | - | | |
>> | - | b | . |
>> | . | | | c |
>>
>> Would be interpreted just as any current table is.
>>
>> However,
>>
>> | hello | there | you  |
>> |---+---+--|
>> || two column   | cell |
>>
>> Contains a 2x1 cell.
>>
>> | a little | test |
>> |--+--|
>> |- hello   | hi   |
>> | two row  | you  |
>>
>> Contains a 1x2 cell. In a more complex example:
>>
>> | a | b | c |
>> |---+---+---|
>> ||-- hi | a |
>> | two x | . |
>> | three | b |
>> | c | - | . |
>>
>> Contains a 2x3 cell.
>>
>> This is just the first syntax that comes to mind, but hopefully
>> the
>> general form of this idea seems viable.
>>
>> All the best,
>>
>> Timothy.
>>

Re: org-tables with monetary amounts

[Christian Moe]

Hi, Derek,

Very useful, thanks!

Yours,
Christian

Derek Feichtinger writes:

> Hi,
>
> On Mon, Oct 12 2020, Eric S Fraga  wrote:
>
>> On Monday, 12 Oct 2020 at 10:22, Christian Moe wrote:
>>> I think I was thinking about adding mode flags for unit computations,
>>> like in the imagined example above (`$3=$2+$1;u'), similar to what has
>>> been done for duration computations.
>>
>> This would be very useful, actually.  I use embedded calc all the time
>> with units; being able to use some of the same expressions in a table
>> would be highly welcome.
>
> The functions that one can use in calc formulas can be extended using
> the 'defmath' lisp command. I paste here from my notes (not about
> monetary units, but easily adapted):
>
> +++
> Defining a new calc function for unit conversion with defmath
> #+BEGIN_SRC emacs-lisp
> (defmath uconv (expr target-units  pure)
>   (math-convert-units expr target-units pure))
> #+END_SRC
>
> #+RESULTS:
> : calcFunc-uconv
>
> | km | ft   |
> |+--|
> | 2.5 km | 8202.0997 ft |
> #+TBLFM: $2=uconv($1, ft)
>
> Using the units from the table header (if the 3rd arg is given to
> uconv, the output is stripped of the unit):
>
> |  km |ft |
> |-+---|
> | 2.5 | 8202.0997 |
> #+TBLFM: $2 = uconv($1 * @<$1, @<$2, t)
>
> The standard calc function usimplify also works for this use
> case:
>
> |  km |ft |
> |-+---|
> | 2.5 | 8202.0997 |
> #+TBLFM: $2 = usimplify($1 * @<$1 / @<$2)
>
> A lisp equivalent of the above
> #+begin_src elisp
> (calc-eval "usimplify(2.5 km / ft)")
> #+end_src
>
> #+RESULTS:
> : 8202.09973753
>
> Let's define a function that converts to base units
> #+begin_src elisp
>   (defmath ustd (expr) (math-simplify-units (math-to-standard-units expr 
> nil)))
> #+end_src
>
> #+RESULTS:
> : calcFunc-ustd
>
> | distance | time   | speed   | std unit speed   | speed in ft/s|
> |--++-+--+--|
> | 3 km | 2.5 hr | 1.2 km / hr | 0. m / s | 1.0936133 ft / s |
> #+TBLFM: @2$3=$1/$2::@2$4=ustd($3)::@2$5=uconv($-1, ft/s)
> 

Re: org-tables with monetary amounts

[Christian Moe]

Hi, Daniele,

Good that it's working for you. I'll try to explain the unclear parts.

Daniele Nicolodi writes:

> On 24/09/2020 11:17, Christian Moe wrote:
>
>> Now, with the Calc command to simplify units, you can add dollars to
>> euros and get the result in whichever currency comes first in the
>> algebraic expression
>>
>>   | 3 USD | 4 EUR | 6.58 EUR |
>>   #+tblfm: $3=usimplify($2+$1)
>>
>>   | 3 USD | 4 EUR | 7.6511628 USD |
>>   #+tblfm: $3=usimplify($1+$2)
>
> Having to explicitly use usimplify() is a bit too verbose. It would be
> ideal if this could be somehow be implicit.

Yes, or at least with a less obtrusive syntax, like a mode flag,
something like

  $3=$2+$1;u

(here using "u" for "units" -- unfortunately, capital "U" is already
taken)

>> I don't use this functionality, so I don't have answers to all the
>> questions you'll now have -- including how to get the desired precision
>> without lopping off the currency unit in the last example!
>
> Having the desired fixed precision is quite important for this to be
> useful. In y recent tests I had to drop the units (currencies) to
> achieve this. It would be nice to find a way to avoid it.

[...]

>> Apart from `usimplify', most Calc functions on units appear (?) to be
>> missing corresponding algebraic versions that you can use in Calc
>> expressions in Org tables, which limits the usefulness.

I may be missing something, but it looks like handy Calc commands like
simple unit conversion currently can't be used in an Org spreadsheet,
making Calc units less useful in the spreadsheet. And that this is due
to a lacuna in Calc, not in Org.

When using Calc directly, there are two ways to enter calculations. The
default is reverse Polish notation on the stack (like an old HP
calculator), with various keys bound to all the available commands. The
alternative is algebraic notation.

For example, the command for square root is `calc-sqrt', entered with
the `Q' key. To get the square root of two, you would enter `2 Q' or `2
RET Q'. The corresponding function to use in algebraic notation is
`sqrt'. To use it, you would press apostrophe for algebraic notation,
and enter `sqrt(2) RET'.

But while all Calc commands have keys assigned, it seems not all have
corresponding algebraic notation (?). The Calc manual says that the
command `u s' (`calc-simplify-units') has the algebraic expression
`usimplify'. But it does not list such expressions for other handy Calc
commands, like the `u c' (`calc-convert-units') command, the `u r'
(`calc-remove-units') command or the `u x' (`calc-extract-units')
command.

The Org spreadsheet can also use Lisp formulas, so I've tried to use
calc-simplify-units directly, but this leads to #ERROR.


>> Org tables don't seem to have any specific formula syntax for leveraging
>> Calc unit operations apart from what happens to work out of the
>> box. This might be an area for improvement, though I'm not sure what to
>> ask for.

I think I was thinking about adding mode flags for unit computations,
like in the imagined example above (`$3=$2+$1;u'), similar to what has
been done for duration computations. See the manual, 3.5.2 Formula
syntax for Calc. Might be useful, but I'm not sure how to specify a
request.

> I don't understand what you mean in the two paragraphs above. Can you
> please clarify, maybe with examples?

Hope this helps.

Yours,
Christian

Re: Help: how to extend org-mode markup?

[Christian Moe]

Please disregard my response. I misunderstood both your intention and
the use of font-lock keywords. Sorry for the noise. :-(

Yours,
Christian

Pierre-Henry F. writes:

> Thank you very much for your replies.
>
> Here is the use case:
>
> |---+|
> | something | :next: |
> |---+|
>
> I would like :next: to show up using an arbitrary face.
>
>
> As suggested by Ihor, I tried:
>
> (font-lock-add-keywords 'org-mode
>   '(("\\W\\(:next:\\)\\W" 1 font-lock-warning-face prepend)))
>
> in my init.el
>
> It does not work either.
>
>
> @Christian yes, it's the same syntax as tags, I would like to extend it 
> eventually.
>
>
> Thanks,
> PHF
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, September 25, 2020 9:26 AM, Ihor Radchenko  
> wrote:
>
>> > (add-to-list 'org-font-lock-extra-keywords
>>
>> It is internal variable. You should not use it.
>>
>> Simply use font-lock-add-keywords instead.
>>
>> Best,
>> Ihor
>>
>> "Pierre-Henry F." cont...@phfrohring.com writes:
>>
>> > Hello,
>> > I would like to extend the org-mode markup.
>> > For example, I would like to change the face of a keyword, say: :next: .
>> > Whenever :next: is displayed from an org-mode buffer, it should show up in 
>> > using an arbitrary face.
>> > I tried this:
>> > (defun org-add-my-extra-markup ()
>> > (add-to-list 'org-font-lock-extra-keywords
>> > '("[^\\w]\\(:next:\\)[^\\w]"
>> > (1 font-lock-warning-face t
>> > (add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-markup)
>> > But it does not work.
>> > So: how to extend org-mode markup?
>> > Many thanks,
>> > PHF

Re: Help: how to extend org-mode markup?

[Christian Moe]

Hello,

In your example, `:next:' is a tag. Tags and keywords are different
entities.
https://orgmode.org/worg/dev/org-syntax.html

You should be able to do what you want by customizing `org-tag-faces'.

Yours,
Christian 

Pierre-Henry F. writes:

> Hello,
>
> I would like to extend the org-mode markup.
>
> For example, I would like to change the face of a keyword, say: :next: .
>
> Whenever :next: is displayed from an org-mode buffer, it should show up in 
> using an arbitrary face.
>
> I tried this:
>
> (defun org-add-my-extra-markup ()
> (add-to-list 'org-font-lock-extra-keywords
> '("[^\\w]\\(:next:\\)[^\\w]"
> (1 font-lock-warning-face t
>
> (add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-markup)
>
> But it does not work.
>
> So: how to extend org-mode markup?
>
> Many thanks,
> PHF

Re: org-tables with monetary amounts

[Christian Moe]

Hi,

Parsing numbers followed by currencies is sort of supported already
through Calc's operations on units. (Calc is the built-in emacs
calculator that powers the spreadsheet function of Org tables). I
haven't used this or explored it much, but my impression is that it
could be made more useful than it currently is. Here are a couple of
things you can do fairly easily.

If you're only working with one currency and just want it to show up
automatically, the following calculation will give you 59.97 USD in the
third column right out of the box, without even requiring you to define
it as a unit first.

  | 50 USD | 8.97 USD | 59.97 USD   |
  #+TBLFM: $3=$1+$2

Adding undefined currencies together will result in an expression like
"3 USD + 4 EUR". However, if you define the currencies as units based on
exchange rates, you can get conversion as part of arithmetic operations.

E.g. in Calc,
- put `1' on top of the stack
- then do `u d EUR' to define the euro as your unit currency (for
example)
- then define e.g. US dollars: Today's rate is 1 USD = 0.86 EUR.
- hit apostrophe to enter algebraic mode and enter `0.86 EUR'
  (today's rate: 1 USD = 0.86 EUR)
- now do `u d USD' to define the rate

Now, with the Calc command to simplify units, you can add dollars to
euros and get the result in whichever currency comes first in the
algebraic expression

  | 3 USD | 4 EUR | 6.58 EUR |
  #+tblfm: $3=usimplify($2+$1)

  | 3 USD | 4 EUR | 7.6511628 USD |
  #+tblfm: $3=usimplify($1+$2)

I don't use this functionality, so I don't have answers to all the
questions you'll now have -- including how to get the desired precision
without lopping off the currency unit in the last example!

There are ways to enter user-defined units permanently. But exchange
rates change, so to use this functionality on a daily basis, you'll want
to have some kind of function to pull exchange rates and update the
currency unit definitions in the Calc init file.

Apart from `usimplify', most Calc functions on units appear (?) to be
missing corresponding algebraic versions that you can use in Calc
expressions in Org tables, which limits the usefulness.

Org tables don't seem to have any specific formula syntax for leveraging
Calc unit operations apart from what happens to work out of the
box. This might be an area for improvement, though I'm not sure what to
ask for.

Yours,
Christian

Daniele Nicolodi writes:

> Hello,
>
> I often use org-tables to work with monetary amounts. It would be very
> nice to have a couple of functionalities common in this domain:
>
> - fixed precision arithmetic, namely derive the precision of the results
> from the precision of the arguments (I think that calc can do this),
>
> - support for parsing numbers followed by currencies,
>
> - correct alignment for monetary values.
>
> I had a quick look around, but I haven't found anything that implements
> those things. Has anyone some secret code that they would like to share?
>
> Thank you!
>
> Cheers,
> Dan

Re: I'm slowly coming back

[Christian Moe]

Important work! Stay safe.

Christian

Bastien writes:

> Dear all,
>
> my day job is to work for the open data public agency in France.
>
> I have been drown under a massive workload in the last four weeks,
> due to the COVID-19 crisis.
>
> I am slowly freeing more time and I'll be back at reading the list
> on a regular basis at the end of week 16.
>
> Thanks,

Re: org2blog: get horizontal scrollbar on code examples?

[Christian Moe]

Try adding

 .org-src-container .src { overflow: auto; white-space: nowrap }

to the CSS, e.g.:

  #+html_head_extra: .org-src-container .src { overflow: auto; 
white-space: nowrap }

Cheers,
Christian

Steinar Bang writes:

> Does anyone know of a way to get horizontal scrollbars on code examples,
> instead of line breaks?
>
> I try to make code examples as horizontally compact, but sometimes
> that's not enough, see e.g. some maven  elements here, and
> the maven command line examples:
>  
> https://steinar.bang.priv.no/2020/03/30/how-to-get-test-coverage-back-in-sonarcloud-maven-builds/

Re: Need Guidance in developing and generating code using org-mode

[Christian Moe]

Hi, Kokou,

Adding to what Leslie Watter writes:

>>- Under Register, and Login heading, How do i generate html forms
>>which will post entries to specific destinations? and also generate code
>>for capturing the data?
>>
>> To use forms, you'll probably will use raw HTML:
>
> https://orgmode.org/manual/Quoting-HTML-tags.html#Quoting-HTML-tags
>

And for capturing the data, you will of course need to provide scripts
on a server as targets for the html forms.

Org is great for quick writing and exporting to HTML. It can also be
used to publish whole static websites and blogs. Some people use a
combination of Org and other static blogging tools, like Jekyll, which
adds some helpful functionality.

However, if you want to dynamically serve pages only to logged-in users,
Org-mode may not be the tool you are looking for. You may want to look
at blogging platforms or content management systems. (If you like
writing in Org, you can still use it for drafting.)

Yours,
Christian

Re: Exporting comments to comments?

[Christian Moe]

I use a rather complex comment macro to make ODT annotations without
introducing unwanted paragraph breaks.

I'm not sure what the Markdown comment syntax is. But e.g. for HTML, the
macro could be defined as simply as:

#+MACRO: comment @@html:@@

Then you can write things like

  This is a sentence with a comment.{{{comment(This is the comment.)}}}
  This is another sentence.

and get comments in the exported HTML. It's ugly, and any commas within
the comment text must be backslash-escaped, but it works, and could be
adapted for Markdown.

HTH,
Christian

Allen S. Rout writes:

> I'd like to write an org-mode document, export it to markdown, and have
> comments exist in the markdown.
>
>
> I feel like I'm thinking about the process incorrectly, and it's hard to
> search around because the discussions around 'org-mode comments' focus
> on org data for which authors would like to _prevent_ export.
>
> I saw some old conversations about making links to the hacked-in
> comment: URI scheme, but that seemed quite hackish indeed.
>
> I thought about making a block of a 'comment' type, but of course all
> the workflow for that is, again, focused on either preventing its export
> in the first place, or making sure that it's exported in a visible
> manner in the output.  ("I want to print the comments in my LaTeX..").
>
>
> So... am I missing something obvious?  Anyone else trying something similar?
>
>
> - Allen S. Rout

Re: [Idea] Org Collections

[Christian Moe]

+1, that is: This is an interesting idea, there have been times when I
might have found something like this handy, and I might well use if it's
developed, though I'm not sure if it will ease my cognitive load or add
to it. :-) 

Yours,
Christian Moe

Gustav Wikström writes:

[...]
 
>
>  ORG MODE: COLLECTIONS/PROJECTS
>
> Gustav Wikström
> 
>
[...]

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Nicolas, Lennart, cc: Charles Celerier,

Below, Lennart points out another issue with ODT_STYLES_FILE, a silent
change in syntax not reflected in the manual: quotation marks are no
longer needed around simple file paths.

I think this change was introduced by the below commit, which stopped
reading the string as a Lisp expression, and therefore at the same time
broke the option of providing a list for #+ODT_STYLES_FILE. My patch
last week fixed the list problem, but left the other change
intact. (Sorry for not doing the research.)

We could either update the manual and announce the syntax change, or
revert ox-odt-template to before the below patch to bring the code back
in conformity with the manual. I don't have a strong opinion one way or
the other. I like the change (never liked those quotation marks), but
it's backwards-incompatible, and the old code looks cleaner than my fix.

Yours,
Christian


commit 30498ef932bc35c26e3e58278f4987a67480b446
Author: Charles Celerier 
Date:   Sat Jul 28 17:09:16 2018 -0400

ox-odt: Fix `org-odt-template' styles file retrieval

* lisp/ox-odt.el (org-odt-template): Fix `org-odt-template' styles
  file retrieval.

TINYCHANGE

Signed-off-by: Charles Celerier 

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index a1145a9..74d811d 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -1359,11 +1359,10 @@ original parsed data.  INFO is a plist holding export 
options."
   ;; Write styles file.
   (let* ((styles-file (plist-get info :odt-styles-file))
 (styles-file (and (org-string-nw-p styles-file)
-  (read (org-trim styles-file
+  (org-trim styles-file)))
 ;; Non-availability of styles.xml is not a critical
 ;; error. For now, throw an error.
 (styles-file (or styles-file
- (plist-get info :odt-styles-file)
  (expand-file-name "OrgOdtStyles.xml"
org-odt-styles-dir)
  (error "org-odt: Missing styles file?"




L.C. Karssen writes:

> On 06-11-18 16:35, Christian Moe wrote:
>>
>> I believe the need to use quotation marks around the style file name was
>> removed at some point
>
> I didn't know that. I had a quick look at the changes to ox-odt.el for
> the last few months, but it doesn't seem to be mentioned in any of the
> commit messages. Or was this a more global change?
>
> Does this also count for the regular #+INCLUDE: statement? I just tested
> it and for #+INCLUDE: it seems to work both with and without quotes
> (although the manual uses quotes).
>
>
> Best,
>
> Lennart.
>
>> , and the manual is out of date. Instead of
>>
>>  #+ODT_STYLES_FILE: "template.ott"
>>
>> the manual ought now to read:
>>
>>  #+ODT_STYLES_FILE: template.ott
>>
>> Yours,
>> Christian
>>
>> L.C. Karssen writes:
>>
>>> Hi list,
>>>
>>> Not sure if this is related (or fixed with the aforementioned patch)
>>> because I'm not using a list for the ODT style file.
>>>
>>> Today, after upgrading from Org 9.1.13 (actually installed from melpa on
>>> 20180625) to melpa version 20181105 exporting to ODT stopped working. In
>>> my org file the style file name was enclosed in double quotes (as
>>> specified in the manual [1]):
>>>
>>> #+ODT_STYLES_FILE: "template.ott"
>>>
>>> The error message is:
>>>
>>> OpenDocument export failed: Invalid specification of styles.xml file:
>>> "\"template.ott\""
>>>
>>> Removing the quotes fixes the export to ODT.
>>>
>>>
>>> Best regards,
>>>
>>> Lennart.
>>>
>>> [1] https://orgmode.org/org.html#Applying-custom-styles
>>>
>>>
>>> On 05-11-18 09:49, Christian Moe wrote:
>>>>
>>>> Thanks, Nicolas!
>>>>
>>>> I'll test on my end when it shows up in ELPA.
>>>>
>>>> Yours,
>>>> Christian
>>>>
>>>> Nicolas Goaziou writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> Christian Moe  writes:
>>>>>
>>>>>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>>>>>> option as a list, as in this example from the manual
>>>>>> ([[info:org#Applying custom styles]]):
>>>>>>
>>>>>>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>>>>>
>>>>>> This is needed

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

I believe the need to use quotation marks around the style file name was
removed at some point, and the manual is out of date. Instead of

 #+ODT_STYLES_FILE: "template.ott"

the manual ought now to read:

 #+ODT_STYLES_FILE: template.ott

Yours,
Christian

L.C. Karssen writes:

> Hi list,
>
> Not sure if this is related (or fixed with the aforementioned patch)
> because I'm not using a list for the ODT style file.
>
> Today, after upgrading from Org 9.1.13 (actually installed from melpa on
> 20180625) to melpa version 20181105 exporting to ODT stopped working. In
> my org file the style file name was enclosed in double quotes (as
> specified in the manual [1]):
>
> #+ODT_STYLES_FILE: "template.ott"
>
> The error message is:
>
> OpenDocument export failed: Invalid specification of styles.xml file:
> "\"template.ott\""
>
> Removing the quotes fixes the export to ODT.
>
>
> Best regards,
>
> Lennart.
>
> [1] https://orgmode.org/org.html#Applying-custom-styles
>
>
> On 05-11-18 09:49, Christian Moe wrote:
>>
>> Thanks, Nicolas!
>>
>> I'll test on my end when it shows up in ELPA.
>>
>> Yours,
>> Christian
>>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Christian Moe  writes:
>>>
>>>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>>>> option as a list, as in this example from the manual
>>>> ([[info:org#Applying custom styles]]):
>>>>
>>>>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>>>
>>>> This is needed if you want a complex style with e.g. an image in the
>>>> header.
>>>>
>>>> Exporting this causes an "Invalid specification of styles.xml file"
>>>> error on my recent ELPA version. The problem seems to be that the option
>>>> is treated as a string and never tested to see if it contains a list.
>>>>
>>>> To reproduce the problem, place the attached documents
>>>> odt-styles-test.org and odt-test-styles.odt in the same directory, then
>>>> export odt-styles-test.org to ODT. The result should have a unicorn in
>>>> the letterhead.
>>>>
>>>> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
>>>> better approach.
>>>
>>> Thank you. I applied your patch with an additional check: the value should
>>> be enclosed within round brackets.
>>>
>>> Regards,
>>
>>

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Thanks, Nicolas!

I'll test on my end when it shows up in ELPA.

Yours,
Christian

Nicolas Goaziou writes:

> Hello,
>
> Christian Moe  writes:
>
>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>> option as a list, as in this example from the manual
>> ([[info:org#Applying custom styles]]):
>>
>>   #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>
>> This is needed if you want a complex style with e.g. an image in the
>> header.
>>
>> Exporting this causes an "Invalid specification of styles.xml file"
>> error on my recent ELPA version. The problem seems to be that the option
>> is treated as a string and never tested to see if it contains a list.
>>
>> To reproduce the problem, place the attached documents
>> odt-styles-test.org and odt-test-styles.odt in the same directory, then
>> export odt-styles-test.org to ODT. The result should have a unicorn in
>> the letterhead.
>>
>> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
>> better approach.
>
> Thank you. I applied your patch with an additional check: the value should
> be enclosed within round brackets.
>
> Regards,

Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Sorry, forgot to attach the test files.

#+title: ODT styles test
#+ODT_STYLES_FILE: ("odt-test-styles.odt" ("styles.xml" "Pictures/120100A200B0A7D655E3F0A97ECF.png"))



Place this Org file in the same directory as the
accompanying file odt-test-styles.odt and export it to ODT.

Expected result: the exported document has a picture of the Org
unicorn in the header.

The ODT_STYLES_FILE option is set correctly according to
[[info:org#Applying%20custom%20styles][info:org#Applying custom styles]]. It references another ODT document
providing the custom styles to apply to this document, including an
image to be used in the header.


odt-test-styles.odt
Description: application/vnd.oasis.opendocument.text

[O] [BUG][ODT] ODT_STYLES_FILE not read as a list

[Christian Moe]

Hi,

It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
option as a list, as in this example from the manual
([[info:org#Applying custom styles]]):

  #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))

This is needed if you want a complex style with e.g. an image in the
header.

Exporting this causes an "Invalid specification of styles.xml file"
error on my recent ELPA version. The problem seems to be that the option
is treated as a string and never tested to see if it contains a list.

To reproduce the problem, place the attached documents
odt-styles-test.org and odt-test-styles.odt in the same directory, then
export odt-styles-test.org to ODT. The result should have a unicorn in
the letterhead.

The below quick-and-dirty patch seems to fix it, but I'm sure there's a
better approach.

*** /home/cm/.emacs.d/elpa/org-20180924/ox-odt.el   2018-09-27 
13:38:07.644922989 +0200
--- /home/cm/Downloads/ox-odt.el2018-10-30 21:18:44.827975243 +0100
***
*** 1360,1365 
--- 1360,1368 
(let* ((styles-file (plist-get info :odt-styles-file))
 (styles-file (and (org-string-nw-p styles-file)
   (org-trim styles-file)))
+;; Try reading it as a list
+(styles-expr (car (read-from-string styles-file)))
+(styles-file (if (listp styles-expr) styles-expr styles-file)
 ;; Non-availability of styles.xml is not a critical
 ;; error. For now, throw an error.
 (styles-file (or styles-file

Re: [O] letterhead and signature in odt export

[Christian Moe]

You should be able to make a letterhead template by placing the
letterhead in the header, saving it as an ODT styles file and
specifically referencing any images in a list in the ODT_STYLES_FILE
header. See the manual 12.12.5, "Applying custom styles".

When I try it, though, Org fails to parse the odt_styles_file list.

I attach my test files - I'd be obliged if someone else could take a
look, maybe it's just my setup.

Yours,
Christian

#+title: ODT styles test
#+ODT_STYLES_FILE: ("odt-test-styles.odt" ("styles.xml" "Pictures/120100A200B0A7D655E3F0A97ECF.png"))



Place this Org file in the same directory as the
accompanying file odt-test-styles.odt and export it to ODT.

Expected result: the exported document has a picture of the Org
unicorn in the header.

What I see:

  OpenDocument export failed: Invalid specification of styles.xml
  file: "(\"odt-test-styles.odt\" (\"styles.xml\"
  \"Pictures/120100A200B0A7D655E3F0A97ECF.png\"))"

  Use M-x make-directory RET RET to create the directory and its
  parents

The ODT_STYLES_FILE option is set correctly according to
[[info:org#Applying%20custom%20styles][info:org#Applying custom styles]] (info "org#Applying custom styles").
It references another ODT document providing the custom styles to
apply to this document, including an image to be used in the header.

However, it seems the value of ODT_STYLES_FILE is not being parsed
correctly as a list.



odt-test-styles.odt
Description: application/vnd.oasis.opendocument.text



Matt Price writes:

> in North America it's letter-of-reference season for professors, and I am
> writing a lot of them. These are some of the only documents I still compose
> in libreoffice, because I need to use a letterhead that contains both image
> and text, and I need to insert a .png of my signature near the bottom.  I
> would much prefer to compose these letter in org and them export. In order
> to so I would need to preserve the letterhead and the signature somehow.
> Both these sections in my current letters occur within the
> 
> 
>
> section which I guess is always replaced by org on export.  My immediate
> question: Is there a way to preserve some of these contents? More
> generally: do people have template files they are very satisfied with? I
> would be happy to go straight to pdf via latex, if it were easy to
> accomplish the same effect that way I don't use latex at all myself so it
> might not be so easy for me :-/.
>
> For completeness, here is the xml for my letterhead (sorry it's rather
> long):
>
> -
>  text:display-outline-level="2" text:separation-character="."
> text:name="Illustration"/> text:display-outline-level="2" text:separation-character="."
> text:name="Table"/> text:separation-character="." text:name="Text"/> text:display-outline-level="0" text:name="Drawing"/> text:display-outline-level="0" text:name="Figure"/> text:display-outline-level="2" text:separation-character="."
> text:name="Equation"/> text:separation-character="."
> text:name="Listing"/> text:outline-level="1"/> table:style-name="Table1"> table:style-name="Table1.A"/> table:style-name="Table1.B"/> table:style-name="Table1.1"> office:value-type="string"> draw:style-name="fr1" draw:name="Image1" text:anchor-type="as-char"
> svg:width="1.857cm" svg:height="3.025cm" draw:z-index="0"> xlink:href="Pictures/100041D61B2F2FDA8AF7D675B9CA7740.wmf"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"
> loext:mime-type="image/x-wmf"/> xlink:href="Pictures/1201010701CF636AB597708AB63A.png"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"
> loext:mime-type="image/png"/> table:style-name="Table1.A1" office:value-type="string"> text:style-name="P5">University of
> Toronto
>  text:style-name="P5">dept. of
> history
>  text:style-name="T5">Rm-2074 sidney smith, 100 st. george street, TORONTO,
> ONTARIO M5S 3G3 CANADA text:style-name="P4">Telephone 416-978-3363
> Fax 416-978-4810
>  text:style-name="P7" text:outline-level="1"> text:name="org54567cc"/>
> --
>
> and here is my signature:
>
> 
>  text:display-outline-level="2" text:separation-character="."
> text:name="Illustration"/> text:display-outline-level="2" text:separation-character="."
> text:name="Table"/> text:separation-character="." text:name="Text"/> text:display-outline-level="0" text:name="Drawing"/> text:display-outline-level="0" text:name="Figure"/> text:display-outline-level="2" text:separation-character="."
> text:name="Equation"/> text:separation-character="."
> text:name="Listing"/> text:outline-level="1"/> table:style-name="Table1"> table:style-name="Table1.A"/> table:style-name="Table1.B"/> table:style-name="Table1.1"> office:value-type="string"> draw:style-name="fr1" draw:name="Image1" text:anchor-type="as-char"
> svg:width="1.857cm" svg:height="3.025cm" draw:z-index="0"> xlink:href="Pictures/100041D61B2F2FDA8AF7D675B9CA7740.wmf"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"

Re: [O] [patch] Problems producing TikZ PNGs from LaTeX src blocks (was: Problems producing TikZ PNGs from LaTeX src blocks)

[Christian Moe]

Benjamin Motz writes:

> It seems that the function `org-babel-execute:latex' ignores the
> property :headers under certain circumstances. Therefore the line
> "\usepackage{tikz}" will be missing in your resulting latex document.
>
> The property is not ignored if you also append the property
> ":imagemagick t" to the #+header line. So you can use the following
> header as a fix (for another fix, see below):
>
> #+header: :file "tikzpic.png" :fit yes :results raw file :exports results 
> :headers '("\\usepackage{tikz}") :imagemagick t

Thank you. When I try this workaround, I run into another issue, which
may be local to my setup. When I add the :imagemagick header, Org tries
to generate a PDF.  This gives me a message that the file wasn't
produced, but in fact a PDF with the correct image is produced --
however, it has a temporary file name, not the one I assigned to
it. (The same problem occurs if I try to create file output from this or
any other Babel latex block with a .pdf extension instead of .png.) It
looks like Org for some reason fails to take a last step in the
latex-to-PDF export -- changing the file name and cleaning up temporary
files. Probably as a result of this failure, no PNG is created.

I have also tried to apply your patch, without effect. Maybe I did it
wrong, but it increasingly looks like I have some weird problem with my
setup in addition to the issue you uncovered.

Yours,
Christian Moe

[O] Fwd: Re: Problems producing TikZ PNGs from LaTeX src blocks

[Christian Moe]

(Forgot to copy this to the list, sorry)

> Hi, Eric
>
> Thanks for looking into this.
>
>> This works for me, cutting and pasting exactly what you have posted into a 
>> small org file.
>>
>> Output from my *Messages* buffer:
>> ,
>> | Wrote /tmp/x.org
>> | org-babel-exp process latex at position 128...
>> | Evaluate this latex code block on your system? (y or n) y
>> | executing Latex code block...
>> | (Shell command succeeded with no output)
>> | Code block evaluation complete.
>> | Local Ispell dictionary set to british
>> | Saving file /tmp/x.tex...
>> `
>> when I export to LaTeX.  What does your message log say?
>
> org-babel-exp process latex at position 148...
> executing Latex code block...
> Code block evaluation complete.
> Saving file /home/cm/Pro/CiP/latex-babel-test.tex...
> Wrote /home/cm/Pro/CiP/latex-babel-test.tex
> Processing LaTeX file latex-babel-test.tex...
> PDF file produced.
> Running evince /home/cm/Pro/CiP/latex-babel-test.pdf...done
>
> Nothing obvious here that I can see.
>
>> Finally, what version of org are you using?  (maybe should have asked this 
>> first...)
>
> I'm on 9.1.14 (2018-09-24) via ELPA.
>
> Yours,
> Christian

Re: [O] Problems producing TikZ PNGs from LaTeX src blocks

[Christian Moe]

Eric S Fraga writes:

> On Friday, 28 Sep 2018 at 16:37, Christian Moe wrote:
>> Hi, Eric
>>
>> Thanks for looking into this.
>>
>>> | executing Latex code block...
>>> | (Shell command succeeded with no output)
>>> | Code block evaluation complete.
>>
>> executing Latex code block...
>> Code block evaluation complete.
>>
>> Nothing obvious here that I can see.
>
> Well, for some reason my case outputs that extra line about shell command 
> succeeding...

Yes, that may be where the problem lies. I also have a problem
outputting PDFs instead of PNGs with the same setup (just changing .png
extension to .pdf). This gives me a message that the file wasn't
produced, but in fact a PDF with the correct image is produced --
however, it has a temporary file name, not the one I assigned to it.

> Have you tried with emacs -Q to make sure it's not a configuration error?

I should probably try this with a minimal init file (need one loading latex as a
babel language and probably a few other things). Didn't get around to that.

> I do have
>
>   (add-to-list 'org-latex-packages-alist '("" "tikz"))
>
> in my configuration so maybe that's the key even though you are specifying 
> that this package should be included in the babel header spec.

I have tried this without success. Also tried adding the LATEX_HEADERS
keyword to the document. Doesn't solve the problem, but changes the
output from an image of the code to an empty image.

Yours,
Christian

[O] Problems producing TikZ PNGs from LaTeX src blocks

[Christian Moe]

Hi,

I am trying to generate a PNG file with a TikZ picture from a LaTeX src
block, looking at instructions here:
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html

I try this:

#+header: :file "tikzpic.png" :fit yes :results raw file :exports results 
:headers '("\\usepackage{tikz}")
#+begin_src latex
  \begin{tikzpicture}
   \draw [fill=green] (0,4) -- (3,0) -- (-3,0) -- cycle;
  \end{tikzpicture}
#+end_src

Expected result: A tikzpic.png image of a green triangle.

Actual result: A tikzpic.png image (attached) that only shows the line
of TikZ code. It seems that the :headers argument isn't working.

If I add a #+LATEX_HEADER: \usepackage{tikz} line to my document, I can
export latex blocks as well as latex src blocks as drawings within an
exported PDF. But exporting the image as a PNG file continues to fail
(in this case, for some reason, the above src block results in an empty
image, no longer showing either the code or the intended picture).

What might I be missing?

Yours,
Christian

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Christian Moe]

So, user feedback: I'm fine with not enabling by default.

I don't use any of these, but it sounds like the new default expansion
mechanism Nicolas mentioned might suit me if I ever switch from my
homemade insert-block function (which does prompts and regions).

Yours,
Christian

Bastien writes:

> Hi Nicolas,
>
> Nicolas Goaziou  writes:
>
>> You disagreed with me in the first place with commit 71ad7b1. It was my
>> original intent to not load Org Tempo by default.
>
> Sorry if I missed the statement where you explicitely said you thought
> org-tempo should not be enabled by default, I thought it was just an
> oversight and I didn't realize I was in a disagreement with you when I
> pushed this commit -- if I thought so, I'd write to you on the list to
> raise the topic instead of forcing a change through a commit.
>
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.
>
> Thanks,

Re: [O] Should wip-cite branch be merged to master?

[Christian Moe]

I have no opinion on whether it's time for a merge or not, but please
don't wait up for me.

Nicolas Goaziou writes:

> I also remember that Christian Moe suggested an alternate syntax for
> citations. He might want to point out what is missing from @cite syntax
> and if he still prefers his idea.

I did, but my suggestions did not get any traction back when a native
citation syntax was first being discussed on the list. Regrettably, I
have not managed to follow up my proposal properly, then or now -- not
even to the point of updating my own sample code after a Zotero
development broke it last year -- and I probably won't in the
foreseeable near future. So I wouldn't want to hold back a
community-developed solution on account that I had a different idea.

My proposal was for a different approach (parsing a "natural-looking"
citation syntax like (Smith 1990: p.3)), which I thought could be both
more user-friendly and more aesthetically pleasing in plain text.  It
was not for improvements to the @cite syntax, so I don't actually know
what is missing from the latter, if anything. I was very excited about
the citeproc contributon, but I have not found the time to test it out.

Re: [O] Structured links to headings with endless depth

[Christian Moe]

ST writes:

> Adding an extra <> is not an option, as it will make the text
> less readable, and there is no need in this, as the headings tree
> structure is already there:

Adding targets, CUSTOM_IDs or IDs are all options. You may not like them.

> * 1
> ** 1
> ** 2
> *** 1
>
> Why should I turn it into the following
>
> * 1
> ** 1
> ** 2
> *** 1
> <<1>>

With a fixed structure, you wouldn't; you'd use e.g. <<1:2:1>>.

> and then link with [[file:1]]?!... This both:
> a) adds unnecessary information into the text making it less readable

Let's not exaggerate the readability cost. And it does add information.

> b) those who read the org file as simple text without the ability to
> click the link will not know where it goes... while the link
> [[file:1:2:1]] makes it quite clear even without clicking it.

But so does the link [[1:2:1]] to the target <<1:2:1>>.

also, c): Adding a target like <<1:2:1>> to a section preserves
information about the location of that section in the source document if
you later cut that part out and insert it somewhere else. This
information is not contained in your headlines.

> Example use case: scriptures with well known structure, e.g. the Bible.

Fair enough.

But typical Org use will quickly break links like that, since Org shines
as an organizer for drafting and easily restructuring text. I don't
think Org needs a link type that would encourage people to make easily
breakable links.

I acknowledge that a separate target or CUSTOM_ID for every verse in the
Bible seems a bit heavy; if that's what you need, it might be better
solved by a custom link type.

Yours,
Christian

>
> On Mon, 2018-03-12 at 10:29 +, Eric S Fraga wrote:
>> On Monday, 12 Mar 2018 at 12:09, ST wrote:
>> > Hi,
>> >
>> > after reading the manual I didn't find a way to construct structured
>> > links referring to headings with endless depth, like:
>>
>> I'm not entirely sure what your use case is but could you use a target,
>> i.e. something like <>, to indicate where you want to link to?
>> Cf. section 4.2 of org manual on internal links.
>>

Re: [O] [RFC] Moving "manual.org" into core

[Christian Moe]

Bastien Guerry writes:

> Hi Nicolas,
>
>> "manual.org" was updated a month ago, and, so far, nobody complained
>> about it. So, I think it's a good time to discuss about what could be
>> done next.
>
> Having the manual in .org is a great achievement, congrats to anyone
> who worked on this titanic task!

+1 !!

Yours,
Christian

[O] org-adapt-indentation 'content (was Re: [RFC] Moving "manual.org" into core)

[Christian Moe]

Nicolas Goaziou writes:

> Bastien Guerry  writes:
>
>> I've added (org-list-description-max-indent . 5)
>
> OK.
>
>> Me too, for the same argument.  But this points to a strong limitation
>> to `org-adapt-indentation' for which I'd like to propose this change.
>>
>>(setq org-adapt-indentation t) => current behavior
>>  (setq org-adapt-indentation nil) => current behavior
>> (setq org-adapt-indentation 'content) => only adapt content's
>>  indentation, not that of the property drawer.
>
> I proposed this very change some years ago, but it didn't get much
> traction and wasn't implemented in the end.

FWIW, I'd like this.

Yours,
Christian

Re: [O] Org citations, CSL and citeproc-el

[Christian Moe]

This is exciting news, and I look forward to trying it out.

Regarding syntax:

1. A couple of years back, there was an active discussion on this list to
flesh out a native citation syntax for Org. I fell off the discussion,
but I think it resulted in a non-link-based, feature-rich syntax spec,
but not much code to make use of it. Perhaps someone could comment?

2. Not many people liked my proposal: a link-based syntax similar to yours
but also including author and date in the link description. The idea was
to have descriptions that are both (1) human-readable even though the
citekeys are hidden away in the link path and (2) machine-readable to
determine the form of the citation (parenthetical or not, date-only or
not, etc.). I have used one to work with Zotero, and have a simple
parser for it, if you're interested in pursuing something similar.

Yours,
Christian

Simonyi András writes:

> Dear List Members,
>
> a few days ago I've released the first public version of citeproc-el
> (https://github.com/andras-simonyi/citeproc-el), a CSL 1.01 citation
> processor library for Emacs. Since the main motivation of my work was to
> contribute to org-mode's citation rendering I also implemented a "proof
> of concept" add-on to org-ref that uses citeproc-el to render org-ref
> citation links for non-LaTeX (and optionally even LaTeX) export backends
> (see https://github.com/andras-simonyi/citeproc-orgref).
>
> Both packages are in a relatively early stage of their development so
> I'd be grateful to receive any feedback on them. In particular, in
> citeproc-orgref I had to abuse the cite link descriptions to an even
> greater degree than they were by org-ref to accommodate the full CSL
> representation of citations (citations consist of cites and each cite
> can have a prefix, postfix and a locator). The resulting link syntax is
> rather cumbersome so I'd like to ask your opinion about introducing an
> alternative org-mode citation syntax that handles all of these elements.
> One option would be to use something very similar to pandoc's citation
> syntax (which I tried to follow as much as possible in the cite link
> descriptions of citeproc-orgref).
>
> A more general question I'd like to raise how (or whether) you see
> citeproc-el's (and CSL's) potential place in the org-mode ecosystem.
> There are a lot of directions which the further development could take
> (BibLaTeX support, citeproc-YAML bibliographies, CSL editing and CSL
> extensions etc.) and I'd be grateful to receive your input on which ones
> I should focus on.
>
> thanks in advance & best wishes,
>
> András Simonyi

Re: [O] make test is failing? [ob-fortran stuff]

[Christian Moe]

I see. Thanks.

Yours,
Christian

Kaushal Modi writes:

> Turns out the Fortran compiler binary gfortran is part of GCC. Those
> fortran tests fail for GCC 4.4.7 but not when using GCC 6.1.0.
>
> On Tue, Feb 23, 2016 at 3:59 AM Christian Moe <m...@christianmoe.com> wrote:
>
>>
>> I always fail the Fortran tests too, on Mac OS X 10.6.8, though
>> supposedly there's a Fortran interpreter in there somewhere.
>>
>> Yours,
>> Christian
>>
>> Kaushal Modi writes:
>>
>> > Hi all,
>> >
>> > I cloned a fresh copy of org-mode and ran "make test" for the first time.
>> >
>> > The following are failing:
>> >
>> > 3 unexpected results:
>> >FAILED  ob-fortran/list-matrix-from-table1
>> >FAILED  ob-fortran/list-matrix-from-table2
>> >FAILED  ob-fortran/list-var-from-table
>> >
>> > Is it known? Or it's failing just for me?
>> >
>> > I am running Emacs version: GNU Emacs 25.0.91.1
>> (x86_64-unknown-linux-gnu,
>> > GTK+ Version 2.24.23) of 2016-02-21, built using commit
>> > e19c1c301700430ae428f40c2a364671f5d50dcf.
>> >
>> >
>> > --
>> > Kaushal Modi
>>
>> --
>
> Kaushal Modi

Re: [O] Reproducing a table

[Christian Moe]

Jarmo Hurri writes:

> In some earlier version of Org the following
> used to work:
>
>   #+name: my-table
>   | row 1 | 1 | 2 |
>   | row 2 | 3 | 4 |
>   |---+---+---|
>   |   | col 1 | col 2 |
>
>   #+call: my-table() :hlines yes
>
> That is, in the past the table name used to sort of define a function
> which could then be called to reproduce the table. But this produced
> errors in the current version, so I started to figure out ways to
> achieve the same end result.

I see! I had no idea that this was possible, but it does indeed work for
me (I'm still on version 8.3.4).

Yours,
Christian

Re: [O] Reproducing a table

[Christian Moe]

You can simplify it even further to

#+begin_src elisp :var data=my-table :hlines yes
  data  
#+end_src

which is sane enough for me.

To get simpler than that, I think you need #+INCLUDE and a separate
file.

I can't tell from the example why you need to define it in one place and
reproduce it in another, though, instead of just giving it a name right
where you want it to appear. (One situation where it would be helpful,
obviously, is if you want the same table to appear in multiple documents
that you export from the same .org file.)

Yours,
Christian


Jarmo Hurri writes:

> Greetings (again).
>
> What is the smartest way to reproduce a table without defining the table
> as an Org source block (constraint explained below).
>
> I can do the following, but it doesn't seem very sane (need to use elisp
> or some other language just to funnel the table).
>
> # -
> * define table
>   #+name: my-table
>   | row 1 | 1 | 2 |
>   | row 2 | 3 | 4 |
>   |---+---+---|
>   |   | col 1 | col 2 |
> * reproduce entire table
>   I need to be able to reproduce the entire table in my document
>   #+BEGIN_SRC elisp :var data=my-table :hlines yes
>   (print data)
>   #+END_SRC
>
>   #+RESULTS:
>   | row 1 | 1 | 2 |
>   | row 2 | 3 | 4 |
>   |---+---+---|
>   |   | col 1 | col 2 |
> * reproduce only data
>   I also need to be able to pass only the data to functions
>   #+BEGIN_SRC elisp :var data=my-table[0:1,1:2]
>   (print data)
>   #+END_SRC
>
>   #+RESULTS:
>   | 1 | 2 |
>   | 3 | 4 |
> # -
>
> The reason I can _not_ define the table as an Org source block is the
> second example. I need to pass parts of the table as data to functions,
> and constructs like my-table()[0:1,1:2] don't work. (At least I have not
> been able to get them to work.)
>
> Jarmo

Re: [O] [Ann] Tool to hack time

[Christian Moe]

Here I was, hoping it was a tool to *actually* hack time.

You know, M-x tardis-mode.

:-)

Yours,
Christian



Marco Wahl writes:

> Dear Orgers,
>
> https://gitlab.com/marcowahl/hack-time is a little tool to forge the
> `current-time' in Emacs.  This allows to mark todo-items done
> conveniently at another date.
>
> Maybe you want to play with that time forgery.
>
> Comments welcome, as always.
>
>
> Best regards
>
>Marco

Re: [O] Remove Org from Emacs repository?

[Christian Moe]

+1.

(= Keep it in.)

Yours,
Christian

Carsten Dominik writes:

> Dear all,
>
> I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> in, and I believe that the vast majority of Emacs users does not install
> packages.  For a newbie to get to Emacs and to be able to open a .org file
> is a big plus.  So my vote goes toward keeping it in.
>
> Carsten
>
> On Sun, Dec 18, 2016 at 10:22 AM,  wrote:
>
>> 2 cents from me...
>>
>> Besides I continuously see many users praising Emacs just for Org
>> presence (they even may be completely non-technical users), I'm
>> personally think Org may be removed from Emacs distribution because:
>>
>> 1) all Reuben's argument seems sane;
>> 2) there are situations when someone wants particular version of Org,
>>and it may be not tne one bundled with Emacs. In this case someone
>>should perform extra steps to ensure things are going the right way.
>>When Org will be available only from ELPA, it will be SPOT for such
>> cases.
>>
>> Reuben Thomas  writes:
>>
>> > Now that Emacs has had package.el for some years, and Org is installable
>> > directly from GNU ELPA, would it be a good idea to remove Org from
>> Emacs's
>> > source repository?
>> >
>> > The current situation is left over from before Emacs had package.el, and
>> I
>> > see no compelling reason to keep it. Org is too big and distinct to be
>> > swallowed by Emacs; it doesn't make much sense to keep its current
>> half-in,
>> > half-out state; so logically it seems sensible to take it out.
>> >
>> > I am asking this question from an Org point of view; I will ask the Emacs
>> > maintainers separately for their perspective.
>> >
>> > I think it would benefit Emacs too, as there would be less code to
>> maintain
>> > (even though Org is quasi-external at present, it still has to build
>> > successfully as part of an Emacs build), and the Emacs distribution would
>> > be slimmer for non-Org users.
>> >
>> > Of course, Emacs "distributions" would still be able to include Org
>> > out-of-the box if they wished.
>> >
>> > --
>> > http://rrt.sc3d.org
>>

Re: [O] ODT export

[Christian Moe]

Haven't done this in a while, but I just tested, and ODT custom style files
work fine for me under Org 8.3.4. (Note: I haven't pulled the latest Org
changes; waiting for another package to catch up.)

I've never know this to fail as such. I did have a problem for a while
using .odt files as stylesheets on Mac under Snow Leopard, which
apparently didn't get the command Org used to unzip the ODT file and
extract the style document. I never found the fix, so for a while I
worked around it by extracting the style .xml manually and referenced that file
instead. Now everything seems to be working as it should, though.

Yours,
Christian

Eduardo Mercovich writes:

> Hi Philip.
>
>>> First time out, very disappointing and confusing results.
>>> Having created a styled example.odt file as per instructions in the 
>>> manual...
>>> [...]
>>> (info "(org) Applying custom styles")
>> Sanity check: anyone able to confirm they've done this successfully?
>
> I did it, but a looong time ago. I don't remember how to and since those
> times, I had a new machine and reinstalled emacs/org-mode from zero to
> make it clean, sorry I can't help.
>
> The good news is that -at least in some previous past- it worked. :)
>
> Best...

[O] [DOCS] Re: Making DocBook xml books from org mode?

[Christian Moe]

Peter Davis writes:

>  3. The direct route from org to DocBook xml seems to be missing.

It's gone extinct, but there is a fossil record of it in the online
manual:

  http://orgmode.org/guide/DocBook-export.html

It's not linked to from the TOC, but turned up in a DuckDuckGo
search. It should probably be carefully excavated and placed in the
Museum of Paleorgology.

Yours,
Christian

Re: [O] apply attr_html to a whole figure?

[Christian Moe]

I don't think Org syntax provides any way to do this at present, but
ignore the rest of this message if anyone knows better.

Possible workarounds:

1. Wrap your figure in a #+BEGIN_ADDITIONALCLASS...#+END_ADDITIONALCLASS
block, to wrap the div.figure in a div.additionalclass. Not exactly what
you wanted, and a pain in the neck if you have many such figures, but
gives you enough to work with in CSS.

2. Add javascript to move the extra class attribute from the img to
the containing div. 

3. Write an export filter.

Yours,
Christian


Matt Price writes:

> When exporting images with captions, ox-html currently creates a strucuture 
> like this:
>
>
> div class=figure
> pimg src=./images/hlevel.png 
> alt=hlevel.png
> /p
> pspan class=figure-numberFigure 1:/span 
> test/p
> /div
>
> (Ive tried setting org-html-html5-fancy to t, but for whatever 
> reason this doesnt result in the useo f the figure tag. I tried 
> with emacs -q with no luck).
>
> I would like to be able to give an additional class to the enclosing div 
> class=figure. Any idea how i might be able to do that? As far 
> as I can see, org-html--wrap-image does not have access to the org link 
> element and so cant query for attributes. 
>
> I really appreciate any ideas! Thanks,
> Matt
>
>  

Re: [O] Inline HTML?

[Christian Moe]

David A. Gershman writes:


> My org file has:
>
> This is line one.
> This is line two.
>
> but the HTML export makes them different paragraphs...

Does it? If they're not separated by a blank line, the exporter should run them
together into one paragraph. Mine does.

> However, a separate portion of my file has a long line and I
> do /not/ want a new paragraph, just to force a :

Quoting HTML is one solution (as you've already discovered), but more
simply, you could do:

  
  This long line starts here \\
  and continues here.


Yours,
Christian

Re: [O] odt macro export

[Christian Moe]

Ken Mankoff writes:

> This works:
>
> #+BEGIN_ODT
> 
> This paragraph is specially formatted and uses bold text.
> 
> #+END_ODT
>
> But this does not. Should it?
>
> #+MACRO: BEGIN_RC @@odt:@@
> #+MACRO: END_RC @@odt:@@
> {{{BEGIN_RC}}}
> This paragraph is specially formatted and uses bold text.
> {{{END_RC}}}

You can analyze the problem by examining the content.xml part of the ODT
document. (On my system, simply opening the ODT file in Emacs reveals
the unzipped files in dired; your settings may vary.)

In this case, your source is already treated as a block and wrapped in a
 element, so macro expansion results in a  illegally wrapped in a
:

#+begin_example
  
  
  This paragraph is specially formatted and uses bold text.
  
  
#+end_example

This makes it different to style a paragraph block with macros. You
could add closing and opening tags to the macros, but that would result
in empty paragraphs (double spacing) on either side.

However, following the example in the Info, you could create a bold
character style, and use the inline  instead of the block
 in your macro. Actually, my version of LibreOffice has a "Bold"
character style pre-defined, so I can just do this:

#+begin_example
  #+MACRO: BEGIN_RC @@odt:@@
  #+MACRO: END_RC @@odt:@@

  {{{BEGIN_RC}}}This paragraph is specially formatted and uses bold 
text.{{{END_RC}}}
#+end_example

This should solve your use case. It does not provide a convenient method
if you want to affect paragraph-style properties rather than
character-style ones, though.

Yours,
Christian

Re: [O] verse

[Christian Moe]

Uwe Brauer writes:

>>> It seems that the verse environment does what I want, it is however
>>> exported in a ugly font (type writer), how can I change that font.
>
>> See the manual, section 12.9.4 "Applying custom styles".
>
> That section is a very general one, I cannot find anything about the
> verse environment and its setting.

The section is general because it tells you how to style *everything*,
including, but not limited to, verse environments. When exporting to ODT
you don't set fonts for particular environments in Org-mode. Rather, you
use an application like LibreOffice to modify and save a stylesheet, and
tell Org-mode what stylesheet to apply to exported ODT.

Export a document to ODT with the ugly verse environment, then either
locate the 'OrgVerse' style in the LibreOffice 'Stylist' and edit it
there, or simply right-click on a verse and choose 'Edit Paragraph
Style' from the menu. Choose a different font. Change any other styles
(e.g. headings) as you like. Save the modified document in a convenient
place, then use it as an Org ODT styles file as described in the manual.

Yours,
Christian

Re: [O] verse (was: orgmode aquivalent of hfill?)

[Christian Moe]

Uwe Brauer writes:

> It seems that the verse environment does what I want, it is however
> exported in a ugly font (type writer), how can I change that font.

See the manual, section 12.9.4 "Applying custom styles".

Yours,
Christian

Re: [O] Patch: default CSS class for SVG images in HTML export

[Christian Moe]

Jarmo Hurri writes:

> If this patch is ok, then what is missing are the default CSS settings
> for the new class org-svg in constant org-html-style-default. I simply
> did not know what to put there. The manual says that this constant has
> basic settings for _all_ defined CSS entities. Either defaults need to
> be set for the new class, or the text in the manual needs to be
> changed. Or we have to accept that the manual is not logically
> coherent. :-)

Logically, no settings could be the default settings, couldn't they?
:-)

Perhaps a percentage width, maybe 80% or 90% to scale all SVGs to fit
neatly inside their container?

Yours,
Christian

Re: [O] Request: change SVG embedding in exported HTML

[Christian Moe]

Scott Randby writes:

>>   #+attr_html: :width 100px
>>   [[path/to/image.svg]]
>
> It has been awhile since I tried to scale an SVG image using Org markup,
> but I recall trying what you suggest and it didn't work. I will try
> again when I have some time and report the results to this list.

I think I've been there, too, in the past. But it Works for me with Org
8.3.4 in Firefox, and Jarmo Hurri now reports it working in Chrome (see
the thread "Scaling HTML-exported SVG").  It seems I got some details
wrong about *how* it works, though.

Yours,
Christian

Re: [O] Scaling HTML-exported SVG

[Christian Moe]

Jarmo Hurri writes:

> The method you suggested above - setting id - works (all tests done in
> Chrome).

Mine are in Firefox. 

> But setting id-values is cumbersome, because you need to do it
> for every file.
> It is also possible to set a CSS class similarly, that is, modifying
> your example above,
>
> #+html_head_extra: .svgfig {width: 200px; }
>
> #+attr_html: :class svgfig
> [[path/to/image.svg]]
>
> This also works and is better, because then it is possible to set a
> common class for all SVG figures, and handle them with a single CSS
> rule.

Sure, if they should mostly be scaled to the same size. I just didn't
make that assumption.

> Better, but not yet perfect, because I still need to add a
> attr_html to every SVG figure.

> But there seems to be a way around this. With the last approach the
> generated HTML looks something like
>
> 

Indeed. Now I'm confused, because this example seems to mean I got
several things wrong earlier today. First, it seems one *can* scale an
SVG image by setting attributes on the  element, not just by
scaling the container element as I thought. At least in FF and
Chrome. And second, Org passes attributes from #+attr_html to the
 element, not to the container  as I wrote, though I could
have sworn that was what I saw when I tested today. On that note, I
think I'll go to bed... But first:

> Why don't we just set a common class for all SVG-images in an HTML
> export by default? Then we could still use an  to embed it, and
> control its size from CSS.

> It seems to me that this solves the problem, and requires an extremely
> small change.

Me too. At least, I cannot think of any obvious disadvantages, and it
could be helpful if you want all or most of your SVGs to be scaled to
the same size (or otherwise styled the same way). Particularly if you
need to distinguish them from  tags embedding other media, like
videos.

(If you're *not* using  for anything beside SVGs, or at least
not in  environments, you could just style objects,
couldn't you?  e.g.:

  object { width: 200px; }

or slightly safer

  .figure object { width: 200px; }

But I agree that an explicit 'svg' class could be better.)

Yours,
Christian