* Footnote definition within a verse block has spurious line breaks when exported to LaTeX
@ 2020-12-01 12:08 6% Juan Manuel Macías
2020-12-05 9:09 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-01 12:08 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]
Hi,
When a verse block includes a footnote reference, the
corresponding footnote definition is
understood in the LaTeX export as if it were part of the verses.
In other words, every
line in a =\footnote{}= macro ends with the string =\\=, and the
spaces between paragraphs are understood as spaces
between stanzas (\vspace*{1em}). If the text of the footnote
definition contains one or more filled
paragraphs, then the export result is catastrophic.
For example, if we have something like this:
#+begin_src org
,#+begin_verse
lorem
ipsum[fn:1]
dolor
,#+end_verse
[fn:1] Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Donec hendrerit tempor
tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt
et, mattis eget,
convallis nec, purus.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus.
Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec,
purus.
#+end_src
in LaTeX we get this:
#+begin_src latex
\begin{verse}
lorem\\
ipsum\footnote{Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec hendrerit tempor\\
tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt
et, mattis eget,\\
convallis nec, purus.\\
\vspace*{1em}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus.\\
Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec,\\
purus.}\\
dolor\\
\end{verse}
#+end_src
Since footnotes are allowed within a LaTeX =verse= environment, I
think
this behavior should be fixed.
I'm wondering if it would make sense to modify the
=org-latex-verse-block= function, in order to "save" the text
formatting
of the footnote definition, something like this (apologies in
advance
for my rudimentary Elisp: what I'm proposing is more of a
concept, or a pedestrian solution, than a actual patch ;-):
#+begin_src emacs-lisp
(defun preserve-footnote-definition-in-verse-block (cont)
(with-temp-buffer
(insert cont)
(save-excursion
(goto-char (point-max))
(while (re-search-backward "}" nil t)
(let ((from (point))
(to (save-excursion
(re-search-backward "\\\\footnote{" nil t)
(point))))
(save-restriction
(narrow-to-region from to)
(goto-char (point-min))
(while (re-search-forward "\n\n+" nil t)
(replace-match "\\\\par\s" t nil))
(goto-char (point-min))
(while (re-search-forward "\n" nil t)
(replace-match "\s" t nil))))))
(buffer-string)))
(defun org-latex-verse-block (verse-block contents info)
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
(org-latex--wrap-label
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a
line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
(format "\\begin{verse}\n%s\\end{verse}"
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}"
(length m)))
(replace-regexp-in-string
"^[ \t]*\\\\\\\\$" "\\vspace*{1em}"
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
(preserve-footnote-definition-in-verse-block
contents) nil t) nil t) nil t))
info))
#+end_src
Best,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Footnote definition within a verse block has spurious line breaks when exported to LaTeX
2020-12-01 12:08 6% Footnote definition within a verse block has spurious line breaks when exported to LaTeX Juan Manuel Macías
@ 2020-12-05 9:09 6% ` Nicolas Goaziou
2020-12-05 13:47 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2020-12-05 9:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> When a verse block includes a footnote reference, the
> corresponding footnote definition is
> understood in the LaTeX export as if it were part of the verses.
> In other words, every
> line in a =\footnote{}= macro ends with the string =\\=, and the
> spaces between paragraphs are understood as spaces
> between stanzas (\vspace*{1em}). If the text of the footnote
> definition contains one or more filled
> paragraphs, then the export result is catastrophic.
>
> For example, if we have something like this:
>
> #+begin_src org
> ,#+begin_verse
> lorem
> ipsum[fn:1]
> dolor
> ,#+end_verse
>
> [fn:1] Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
> Donec hendrerit tempor
> tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt
> et, mattis eget,
> convallis nec, purus.
>
> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
> hendrerit tempor tellus.
> Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
> mattis eget, convallis nec,
> purus.
> #+end_src
This is hopefully fixed in master branch. Let me knows if it works for
you.
Thank you for the report.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: Footnote definition within a verse block has spurious line breaks when exported to LaTeX
2020-12-05 9:09 6% ` Nicolas Goaziou
@ 2020-12-05 13:47 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-05 13:47 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> This is hopefully fixed in master branch. Let me knows if it works for
> you.
Thank you, Nicolas. I've tried it and it works perfectly. I see that
\footnotemark\footnotetext is used now, same as in tables. I
think it's a great solution.
Best,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-09 15:06 10% ` Juan Manuel Macías
[not found] ` <69288122-6dfb-4235-47bf-d38344c730b0@gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-09 15:06 UTC (permalink / raw)
To: Charis Michelakis; +Cc: orgmode
Hello,
Charis Michelakis <ch.p.mxs@gmail.com> writes:
> There is a potential bug regarging how footnotes on headers are
> converted to LaTeX.
>
> Consider the following org file:
> ------start-of-file-----------
>
> #+AUTHOR: Me
> #+LATEX_HEADER: \usepackage{titlesec}
>
> * Header1[fn:1]
>
> * Footnotes
>
> [fn:1]Lorem ipsum
It is a LaTeX problem, as the footnote command is a 'fragile' command and should not
be put in a section. Try this:
* Header1[fn:1]
:PROPERTIES:
:ALT_TITLE: Header1
:END:
* Footnotes
[fn:1]Lorem ipsum
in latex it is exported as
\section[Header1]{Header1\footnote{Lorem ipsum}}
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
[not found] ` <69288122-6dfb-4235-47bf-d38344c730b0@gmail.com>
@ 2020-12-09 15:31 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-09 15:31 UTC (permalink / raw)
To: Charis Michelakis; +Cc: orgmode
You're welcome ;-)
Charis Michelakis <ch.p.mxs@gmail.com> writes:
> Thank you :)
>
> On 12/9/20 5:06 PM, Juan Manuel Macías wrote:
>> Hello,
>>
>> Charis Michelakis <ch.p.mxs@gmail.com> writes:
>>
>>> There is a potential bug regarging how footnotes on headers are
>>> converted to LaTeX.
>>>
>>> Consider the following org file:
>>> ------start-of-file-----------
>>>
>>> #+AUTHOR: Me
>>> #+LATEX_HEADER: \usepackage{titlesec}
>>>
>>> * Header1[fn:1]
>>>
>>> * Footnotes
>>>
>>> [fn:1]Lorem ipsum
>> It is a LaTeX problem, as the footnote command is a 'fragile' command and should not
>> be put in a section. Try this:
>>
>> * Header1[fn:1]
>> :PROPERTIES:
>> :ALT_TITLE: Header1
>> :END:
>>
>> * Footnotes
>> [fn:1]Lorem ipsum
>>
>> in latex it is exported as
>>
>> \section[Header1]{Header1\footnote{Lorem ipsum}}
>>
>> Regards,
>>
>> Juan Manuel
>
^ permalink raw reply [relevance 6%]
* Accessing a DLNA server through an Org link
@ 2020-12-10 22:17 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-10 22:17 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Hi,
I'm storing in an Org document a list of links to all my media files
(videos, music, and the like). This is a little trick that I came up
with to access the multimedia content of my raspberry's dlna server
(minidlna), using an Org link and the Javier López
'simple-dlna-browser' script
(https://github.com/javier-lopez/learn/blob/master/sh/tools/simple-dlna-browser).
You need to install socat:
#+begin_src emacs-lisp
(org-link-set-parameters
"dlna"
:follow (lambda (file)
(let ((command (concat "~/Scripts/./simple-dlna-browser.sh "
"\""
file
"\""
" | xargs vlc")))
(start-process-shell-command command nil command)))
:face '(:foreground "green4" :weight bold :underline t))
#+end_src
Tested on Arch Linux. As an external player I use vlc; `file' can simply be the name of
the file. For example, if we have gattaca.mp4 on our server, the link could be:
#+begin_src org
[[dlna:gattaca]]
#+end_src
Well, it works reasonably well. But I wonder if anyone knows of any
package or library to be able to do this (accessing a dlna server) in
a more emacs/org-centric way ...
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: #+include and org-export-before-processing-hook
@ 2020-12-13 17:26 10% ` Juan Manuel Macías
2020-12-13 20:05 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-13 17:26 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hello,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Hello,
>
> I have a particular function that I want to invoke when exporting an org
> file. This works just fine, adding this function to the
> org-export-before-processing-hook, for simple org files. However, if I
> have an org file which uses #+include: to include other org files, it
> seems like the processing doesn't happen on included files.
I have the same problem with a function that I wrote to not export
certain footnotes, and to date I have not been able to fix it. According
to the `org-export-before-processing-hook' docstring:
" *This is run before include keywords and macros are expanded*
and Babel code blocks executed, on a copy of the original buffer
being exported. Visibility and narrowing are preserved. Point
is at the beginning of the buffer.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: #+include and org-export-before-processing-hook
2020-12-13 17:26 10% ` Juan Manuel Macías
@ 2020-12-13 20:05 6% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2020-12-13 20:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have the same problem with a function that I wrote to not export
> certain footnotes, and to date I have not been able to fix it. According
> to the `org-export-before-processing-hook' docstring:
>
> " *This is run before include keywords and macros are expanded*
> and Babel code blocks executed, on a copy of the original buffer
> being exported. Visibility and narrowing are preserved. Point
> is at the beginning of the buffer.
There is also `org-export-before-parsing-hook'.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* [Small suggestion] on exporting verse blocks to LaTeX and vertical spaces
@ 2020-12-15 17:21 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-15 17:21 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
Hi,
When exporting a verse block to LaTeX, each empty line between
'stanzas' results in the command =\vspace*{1em}=, which is fine.
However, I would dare to suggest that, in order to be more consistent
with the LaTeX `verse' environment (both the one that comes by
default and the one provided by the verse.sty package) the separation
between stanzas should be marked with:
- the last line of the stanza without =\\=
- + one (at least) empty line
which is the correct (or at least the most common) way to separate the
stanzas within this environment, since each stanza is still a
paragraph whose lines are cut off. Thus, we could also redefine
globally the \stanzaskip length provided by the verse.sty package
(i.e. \setlength{\stanzaskip}{1.2em plus .2em minus .5em}, etc.).
For example, with this (the number of white lines does not matter):
#+begin_src org
,#+begin_verse
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
,#+end_verse
#+end_src
we should get:
#+begin_src latex
\begin{verse}
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
\end{verse}
#+end_src
Perhaps replacing these lines in =org-latex-verse-block=
#+begin_src emacs-lisp
(replace-regexp-in-string
"^[ \t]*\\\\\\\\$" "\\vspace*{1em}"
#+end_src
with something like this
#+begin_src emacs-lisp
(replace-regexp-in-string
"\\(\\\\\\\\\n\\)+\\([ \t]*\\\\\\\\\\)+" "\n"
#+end_src
?
(On the other hand, I also think that vertical spaces between groups
of lines in verse blocks should always be exported to any format as
a single fixed space, regardless of how many empty lines there are).
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 8%]
* [patch] A proposal to add LaTeX attributes to verse blocks
@ 2020-12-17 17:11 5% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-17 17:11 UTC (permalink / raw)
To: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 4802 bytes --]
Hi,
I would like to propose this patch to add some LaTeX attributes to verse blocks,
especially to be able to apply certain features from the verse.sty package, which is an
extension (widely used in Humanities) of the standard LaTeX 'verse'
environment (see https://www.ctan.org/pkg/verse).
These attributes would be:
- `:lines' to add verse numbers, according to any numbering sequence
- `:center' to apply the optical centering of the poem, which is a typographic convention
whereby a poem or a group of verses is centered (as a 'block') on the page, taking the width of the
longest verse as a reference. In fact, optical centering is the correct arrangement of
verses in a document.
- `:versewidth' which expects a literal string that is the longest verse of the poem,
required when applying the `:center' attribute.
As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
attribute would be used to add arbitrary code within the verse environment.
Consider this complete example with Shakespeare's first sonnet:
#+begin_src org
,#+ATTR_LaTeX: :center t :options \small :lines 5
,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
,#+begin_verse
From fairest creatures we desire increase,
That thereby beauty’s rose might never die,
But as the riper should by time decrease,
His tender heir mught bear his memeory:
But thou, contracted to thine own bright eyes,
Feed’st thy light’st flame with self-substantial fuel,
Making a famine where abundance lies,
Thyself thy foe, to thy sweet self too cruel.
Thou that art now the world’s fresh ornament
And only herald to the gaudy spring,
Within thine own bud buriest thy content
And, tender churl, makest waste in niggarding.
Pity the world, or else this glutton be,
To eat the world’s due, by the grave and thee.
,#+end_verse
#+end_src
when exporting to LaTeX we get:
#+begin_src latex
\settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
\begin{verse}[\versewidth]
\poemlines{5}
\small
From fairest creatures we desire increase,\\
That thereby beauty’s rose might never die,\\
But as the riper should by time decrease,\\
His tender heir mught bear his memeory:\\
But thou, contracted to thine own bright eyes,\\
Feed’st thy light’st flame with self-substantial fuel,\\
Making a famine where abundance lies,\\
Thyself thy foe, to thy sweet self too cruel.\\
Thou that art now the world’s fresh ornament\\
And only herald to the gaudy spring,\\
Within thine own bud buriest thy content\\
And, tender churl, makest waste in niggarding.\\
Pity the world, or else this glutton be,\\
To eat the world’s due, by the grave and thee.\\
\end{verse}
#+end_src
In an attached image I send a screenshot with the typographic result
And finally, this is the patch I would propose
#+begin_src diff
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a14b25d5..bc6b64e78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,16 @@ channel."
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
+(let*
+ ((lin (org-export-read-attribute :attr_latex verse-block :lines))
+ (opt (org-export-read-attribute :attr_latex verse-block :options))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if opt (format "\n%s" opt) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3513,7 +3523,9 @@ contextual information."
;; character and change each white space at beginning of a line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
- (format "\\begin{verse}\n%s\\end{verse}"
+ (format "%s\\begin{verse}%s\n%s\\end{verse}"
+ vwidth-attr
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
@@ -3524,7 +3536,7 @@ contextual information."
info)
;; Insert footnote definitions, if any, after the environment, so
;; the special formatting above is not applied to them.
- (org-latex--delayed-footnotes-definitions verse-block info)))
+ (org-latex--delayed-footnotes-definitions verse-block info))))
#+end_src
Regards,
Juan Manuel
[-- Attachment #1.2: Type: text/html, Size: 1 bytes --]
[-- Attachment #2: verse-test.png --]
[-- Type: image/png, Size: 286585 bytes --]
^ permalink raw reply related [relevance 5%]
* [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2020-12-17 17:23 5% Juan Manuel Macías
2021-01-03 10:25 6% ` TEC
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-17 17:23 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 4811 bytes --]
(Sorry, due to a mistake, the text of my message did not appear in my previous email)
Hi,
I would like to propose this patch to add some LaTeX attributes to the verse block,
especially to be able to apply certain features from the verse.sty package, which is an
extension (widely used in Humanities) of the standard LaTeX 'verse' environment.
These attributes would be:
- `:lines' to add verse numbers, according to any numbering sequence
- `:center' to apply the optical centering of the poem, which is a typographic convention
whereby a poem or a group of verses is centered on the page, taking the width of the
longest verse as a reference. In fact, optical centering is the correct arrangement of
verses in a document.
- `:versewidth' which expects a text string that is the longest verse of the poem,
required when applying the `:center' attribute.
As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
attribute would be used to add arbitrary code within the verse environment.
Consider this complete example with Shakespeare's first sonnet:
#+begin_src org
,#+ATTR_LaTeX: :center t :options \small :lines 5
,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
,#+begin_verse
From fairest creatures we desire increase,
That thereby beauty’s rose might never die,
But as the riper should by time decrease,
His tender heir mught bear his memeory:
But thou, contracted to thine own bright eyes,
Feed’st thy light’st flame with self-substantial fuel,
Making a famine where abundance lies,
Thyself thy foe, to thy sweet self too cruel.
Thou that art now the world’s fresh ornament
And only herald to the gaudy spring,
Within thine own bud buriest thy content
And, tender churl, makest waste in niggarding.
Pity the world, or else this glutton be,
To eat the world’s due, by the grave and thee.
,#+end_verse
#+end_src
when exporting to LaTeX we get:
#+begin_src latex
\settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
\begin{verse}[\versewidth]
\poemlines{5}
\small
From fairest creatures we desire increase,\\
That thereby beauty’s rose might never die,\\
But as the riper should by time decrease,\\
His tender heir mught bear his memeory:\\
But thou, contracted to thine own bright eyes,\\
Feed’st thy light’st flame with self-substantial fuel,\\
Making a famine where abundance lies,\\
Thyself thy foe, to thy sweet self too cruel.\\
Thou that art now the world’s fresh ornament\\
And only herald to the gaudy spring,\\
Within thine own bud buriest thy content\\
And, tender churl, makest waste in niggarding.\\
Pity the world, or else this glutton be,\\
To eat the world’s due, by the grave and thee.\\
\end{verse}
#+end_src
In an attached image I send a screenshot with the typographic result
And finally, this is the patch I would propose
#+begin_src diff
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a14b25d5..bc6b64e78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,16 @@ channel."
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
+(let*
+ ((lin (org-export-read-attribute :attr_latex verse-block :lines))
+ (opt (org-export-read-attribute :attr_latex verse-block :options))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if opt (format "\n%s" opt) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3513,7 +3523,9 @@ contextual information."
;; character and change each white space at beginning of a line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
- (format "\\begin{verse}\n%s\\end{verse}"
+ (format "%s\\begin{verse}%s\n%s\\end{verse}"
+ vwidth-attr
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
@@ -3524,7 +3536,7 @@ contextual information."
info)
;; Insert footnote definitions, if any, after the environment, so
;; the special formatting above is not applied to them.
- (org-latex--delayed-footnotes-definitions verse-block info)))
+ (org-latex--delayed-footnotes-definitions verse-block info))))
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply related [relevance 5%]
* Displaying verse numbers within a verse block
@ 2020-12-20 21:37 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-20 21:37 UTC (permalink / raw)
To: orgmode
Hi,
One of the many, many things where I use Org Mode is my Spanish translation of Homer's
Odyssey (work in progress). To avoid getting lost inside each Book, I wrote this little
code that helps me navigate through the verses, displaying in the margin (within a verse
block) the verse numbers in sequence of 5 (not counting the empty lines), or allowing
me to jump to a certain verse number.
I've uploaded the code to GitLab in case it could be useful to anyone who also has to work
with long runs of verses (hundreds, thousands...). Of course, this is something I wrote for
my own work, and I'm not a professional programmer either, so the code can be improved for
sure ;-)
https://gitlab.com/maciaschain/org-verse-num
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [TIP] Export to LaTeX and HTML with a watermark
@ 2020-12-23 2:11 8% Juan Manuel Macías
2020-12-23 2:38 6% ` Thomas S. Dye
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-23 2:11 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
Hi,
Recently, I needed to export a document to both LaTeX and HTML with a
watermark background. I came to write this little function (for LaTeX,
the 'draftwatermark' package is used; for html, a bit of CSS. The
optional arg `text' is the text of the watermark; by default what is
printed is "DRAFT"):
#+begin_src org
,#+begin_src emacs-lisp :exports results :results none
(defun my-watermark (&optional text)
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
(concat "#+LaTeX_Header:\\usepackage"
(if text
(format "[text=%s]" (replace-regexp-in-string " " "~" text))
"")
"{draftwatermark}"))
((org-export-derived-backend-p org-export-current-backend 'html)
(concat "@@html:<p id=\"watermark\">"
(if text
(format "%s" text)
"DRAFT")
"</p>@@"))))
,#+end_src
#+end_src
The CSS could be (source:
https://stackoverflow.com/questions/68569/text-watermark-on-website-how-to-do-it):
#+begin_src org
,#+html_HEAD: <style>#watermark {color: #d0d0d0; font-size: 200pt; -webkit-transform: rotate(-45deg); -moz-transform: rotate(-45deg); position: absolute; width: 100%; height: 100%; margin: 0; z-index: -1; left:-100px; top:-200px;}</style>
#+end_src
And then, this replacement macro:
#+begin_src org
,#+MACRO: wmark (eval (if (org-string-nw-p $1)(my-watermark $1)(my-watermark)))
#+end_src
And finally, an example:
#+begin_src org
{{{wmark(Top secret!)}}}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
accumsan nisl.
(...)
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 8%]
* Re: [TIP] Export to LaTeX and HTML with a watermark
2020-12-23 2:11 8% [TIP] Export to LaTeX and HTML with a watermark Juan Manuel Macías
@ 2020-12-23 2:38 6% ` Thomas S. Dye
0 siblings, 0 replies; 200+ results
From: Thomas S. Dye @ 2020-12-23 2:38 UTC (permalink / raw)
To: emacs-orgmode
Nice!
This is the kind of thing I like to find here:
https://orgmode.org/worg/org-hacks.html
Please consider adding it to Worg!
All the best,
Tom
Juan Manuel Macías writes:
> Hi,
>
> Recently, I needed to export a document to both LaTeX and HTML
> with a
> watermark background. I came to write this little function (for
> LaTeX,
> the 'draftwatermark' package is used; for html, a bit of CSS.
> The
> optional arg `text' is the text of the watermark; by default
> what is
> printed is "DRAFT"):
>
> #+begin_src org
> ,#+begin_src emacs-lisp :exports results :results none
> (defun my-watermark (&optional text)
> (cond ((org-export-derived-backend-p
> org-export-current-backend 'latex)
> (concat "#+LaTeX_Header:\\usepackage"
> (if text
> (format "[text=%s]" (replace-regexp-in-string " " "~"
> text))
> "")
> "{draftwatermark}"))
> ((org-export-derived-backend-p org-export-current-backend
> 'html)
> (concat "@@html:<p id=\"watermark\">"
> (if text
> (format "%s" text)
> "DRAFT")
> "</p>@@"))))
>
> ,#+end_src
> #+end_src
>
> The CSS could be (source:
> https://stackoverflow.com/questions/68569/text-watermark-on-website-how-to-do-it):
>
> #+begin_src org
> ,#+html_HEAD: <style>#watermark {color: #d0d0d0; font-size:
> 200pt; -webkit-transform: rotate(-45deg); -moz-transform:
> rotate(-45deg); position: absolute; width: 100%; height: 100%;
> margin: 0; z-index: -1; left:-100px; top:-200px;}</style>
> #+end_src
>
> And then, this replacement macro:
>
> #+begin_src org
> ,#+MACRO: wmark (eval (if (org-string-nw-p $1)(my-watermark
> $1)(my-watermark)))
> #+end_src
>
> And finally, an example:
>
> #+begin_src org
> {{{wmark(Top secret!)}}}
>
> Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
> accumsan nisl.
>
> (...)
> #+end_src
>
> Regards,
>
> Juan Manuel
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 6%]
* Re: *strong* markup not honored at boundary of macro input during HTML export
@ 2020-12-23 15:22 10% ` Juan Manuel Macías
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-23 15:22 UTC (permalink / raw)
To: m27315; +Cc: orgmode
Hello, a possible dirty solution could be defining the macro with two
Unicode zero-width spaces (u+200b):
#+MACRO: quote (eval (concat "@@html:<span class=\"quote\">“@@" "\u200B" $1 "\u200B" "@@html:”</span>@@"))
Regards,
Juan Manuel
m27315 <m27315@gmail.com> writes:
> Resending as plain-text ... If somebody could point me in the direction of
> the code that might be responsible for this, I'll try to take a look.
>
> ....
>
> If the following org file is exported as HTML, any *strong* markup for words
> at the beginning or the end of the input string are ignored. (I have
> included several slight variations to help testing.)
>
> #+TITLE: Test MACRO with *strong* Markup Input
> #+OPTIONS: date:nil timestamp:nil num:nil stat:t title:t toc:nil
>
> #+MACRO: quote @@html:<span class="quote">“@@$1@@html:”</span>@@
>
> * Test macro with non-marked text:
> Demonstrating that, {{{quote(This is a vanilla quote without markup)}}},
> Abraham Lincoln.
>
> {{{quote(This is a similar control quote without markup)}}}, George
> Washington said.
>
> * Test macro with leading *strongly* marked text:
> Wilson quipped, {{{quote(*Not all* quotes are important!)}}}.
>
> {{{quote(*But this* is a very important quote)}}}, Thomas Jefferson replied.
>
> * Test macro with trailing *strongly* marked text:
> Retorted Yoda, {{{quote(Critical if not uncertain\, all *my quotes are*)}}}.
>
> {{{quote(I am certain they are *all uncertain*)}}}, Anakin sneered.
>
> * Test macro with leading, middle, and trailing marked text:
> Darth Vader threatened, {{{quote(*All* of *my quotes* are *heeded
> carefully!*)}}}.
>
> {{{quote(*Nobody* listens to *meesa* quotes. *Why?*)}}}, Jar-Jar whined.
>
> The condensed filtered HTML output is:
>
> ...
> <h2 id="org40a1103">Test macro with non-marked text:</h2>
> <p>Demonstrating that, <span class="quote">“This is a vanilla
> quote without markup”</span>, Abraham Lincoln.</p>
> <p><span class="quote">“This is a similar control quote without
> markup”</span>, George Washington said.</p>
>
> <h2 id="org962a914">Test macro with leading <b>strongly</b> marked
> text:</h2>
> <p>Wilson quipped, <span class="quote">“*Not all* quotes are
> important!”</span>.</p>
> <p><span class="quote">“*But this* is a very important
> quote”</span>, Thomas Jefferson replied.</p>
>
> <h2 id="org47bf84f">Test macro with trailing <b>strongly</b> marked
> text:</h2>
> <p>Retorted Yoda, <span class="quote">“Critical if not uncertain,
> all *my quotes are*”</span>.</p>
> <p><span class="quote">“I am certain they are *all
> uncertain*”</span>, Anakin sneered.</p>
>
> <h2 id="org08c1694">Test macro with leading, middle, and trailing marked
> text:</h2>
> <p>Darth Vader threatened, <span class="quote">“*All* of <b>my
> quotes</b> are *heeded carefully!*”</span>.</p>
> <p><span class="quote">“*Nobody* listens to <b>meesa</b> quotes.
> *Why?*”</span>, Jar-Jar whined.</p>
> ...
>
> Notice how the *strong* marks are only transformed into <b></b> tags inside
> a string, not at the boundaries.
>
> Can anybody confirm or explain what I am doing wrong?
>
> Thanks!
>
> Trevor
>
>
^ permalink raw reply [relevance 10%]
* Re: *strong* markup not honored at boundary of macro input during HTML export
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
@ 2020-12-23 16:05 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-23 16:05 UTC (permalink / raw)
To: m27315; +Cc: orgmode
You're welcome. Some time ago I had a similar problem with a LaTeX
command with arguments that I wanted to include in a macro. Since the
character U+200b is a kind of "ghost space", it can act as an "invisible
barrier" between the emphasis marks and the characters that precede or
follow them. An emergency cure ;-)
Regards,
Juan Manuel
m27315 <m27315@gmail.com> writes:
> Worked like a charm. Thanks, Juan!
>
> On 2020-12-23 9:22 AM, Juan Manuel Macías wrote:
>> quote (eval (concat "@@html:<span class=\"quote\">“@@" "\u200B" $1 "\u200B" "@@html:”</span>@@"))
>
^ permalink raw reply [relevance 10%]
* [tip] Export subfigures to LaTeX (and HTML)
@ 2020-12-25 16:02 7% Juan Manuel Macías
2020-12-28 18:03 5% ` John Kitchin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-25 16:02 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]
Hi,
I have come up with a way to export subfigures to LaTeX (with the subfigure package) by
defining a new link type. The 'subcaption' of the subfigure would be the description of
the link. If we want to add parameters such as width, scale, etc., we can put them next
between the marks '>( ... )'
The code:
#+begin_src emacs-lisp
(org-link-set-parameters
"subfig"
:follow (lambda (file) (find-file file))
:face '(:foreground "chocolate" :weight bold :underline t)
:display 'full
:export (lambda (file desc backend)
(when (eq backend 'latex)
(if (string-match ">(\\(.+\\))" desc)
(concat "\\subfigure[" (replace-regexp-in-string "\s+>(.+)" "" desc) "]"
"{\\includegraphics"
"["
(match-string 1 desc)
"]"
"{"
file
"}}")
(format "\\subfigure[%s]{\\includegraphics{%s}}" desc file)))))
#+end_src
Example:
#+begin_src org
,#+CAPTION: Lorem impsum dolor
,#+ATTR_LaTeX: :options \centering
,#+begin_figure
[[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth)]]
[[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth)]]
[[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth)]]
,#+end_figure
#+end_src
Results:
#+begin_src latex
\begin{figure}\centering
\subfigure[Caption of img1]{\includegraphics[width=.3\textwidth]{img1.jpg}}
\subfigure[Caption of img2]{\includegraphics[width=.3\textwidth]{img2.jpg}}
\subfigure[Caption of img3]{\includegraphics[width=.6\textwidth]{img3.jpg}}
\caption{Lorem impsum dolor}
\end{figure}
#+end_src
If we want to export to HTML it would be something more tricky. In this case, the export
function could be like this (a width parameter would be enclosed between >{ ... }):
#+begin_src emacs-lisp
(lambda (file desc backend)
(cond
((eq backend 'latex)
(if (string-match ">(\\(.+\\))" desc)
(concat "\\subfigure[" (replace-regexp-in-string "\s*>.+" "" desc) "]" "{\\includegraphics" "[" (match-string 1 desc) "]" "{" file "}}")
(format "\\subfigure[%s]{\\includegraphics{%s}}" (replace-regexp-in-string "\s*>.+" "" desc) file)))
((eq backend 'html)
(if (string-match ">{\\(.+\\)}" desc)
(concat "<td><img src=\"" file "\" alt=\"" file "\"" " style=\"width:"
(match-string 1 desc)
"\""
"/><br>"
(replace-regexp-in-string "\s*>.+" "" desc)
"</td>")
(format "<td><img src=\"%s\" alt=\"%s\"/><br>%s</td>"
file file
(replace-regexp-in-string "\s*>.+" "" desc))))))
#+end_src
Example:
#+begin_src org
,#+CAPTION: Lorem impsum dolor
,#+ATTR_LaTeX: :options \centering
,#+begin_figure
@@html:<div class="org-center"><table style="margin-left:auto;margin-right:auto;"><tr>@@
[[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth) >{300px}]]
[[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth) >{300px}]]
@@html:</tr></table><p> </p><table style="margin-left:auto;margin-right:auto;"><tr>@@
[[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth) >{600px}]]
@@html:</tr></table><br>Lorem ipsum dolor</div>@@
,#+end_figure
#+end_src
As you can see, it is not the panacea, and you have to apply some direct format...
Happy holidays
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 7%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
@ 2020-12-27 13:55 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-27 13:55 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: orgmode
Hello,
Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
> Is there a way to avoid the said new lines in the above mentioned
> examples? (NB: A space right _before_ the quote starts is okay.) Or
> alternatively, is there a way to consistently force a new line in the
> HTML export, after each of "Test 1", "Test 2", et al?
A solution could be to 'force' a homogeneous space between all the items
of the list by modifying the 'margin' property
(https://www.w3schools.com/cssref/pr_margin.asp).
For example:
#+HTML_HEAD: <style> li{margin: 15px;}</style>
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-27 18:12 10% ` Juan Manuel Macías
2020-12-27 20:14 6% ` tomas
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-27 18:12 UTC (permalink / raw)
To: Chris Hunt; +Cc: orgmode
Hello,
I think the problem comes because in that url the tilde does not have an
escape character. If it's just that case, you can try replacing each
tilde with %7E (see
https://www.w3schools.com/tags/ref_urlencode.asp). That way the
link description would have to be formatted correctly, without spurious
characters.
Regards
Juan Manuel
Chris Hunt <chrahunt@gmail.com> writes:
> I'm trying to create a link in an org file with this URL:
>
> https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d
>
> and this description: "metrics".
>
> To do it, I followed these steps:
>
> 1. run `emacs -Q test.org`, where test.org is not an existing file
> 2. emacs GUI displays, type `M-x org-insert-link`
> 3. a "Link" prompt is displayed, paste the link and press return
> 4. a "Description" prompt is displayed, type "metrics" and press return
>
> At this point I expect to see only the text "metrics" in the buffer, with normal
> link decoration (underline and highlight).
>
> Instead, I see "~(~'CWAgent~metrics" with some mix of link decoration
> and some other style, as shown in the following image:
>
> https://i.imgur.com/vb9vE43.png
>
> The actual text from the file is
>
> [[https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d][metrics]]
>
> This is emacs 27.1 from http://ppa.launchpad.net/kelleyk/emacs/ubuntu,
> with org version 9.3.
>
> Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.22.30, cairo version 1.15.10)
> of 2020-09-19
> Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
>
> current state:
> ==============
> (setq
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-link-shell-confirm-function 'yes-or-no-p
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
> org-mode-hook '(#[0 "\300\301\302\303\304$\207"
> [add-hook change-major-mode-hook org-show-all append local]
> 5]
> #[0 "\300\301\302\303\304$\207"
> [add-hook change-major-mode-hook org-babel-show-result-all
> append local]
> 5]
> org-babel-result-hide-spec org-babel-hide-all-hashes)
> org-archive-hook '(org-attach-archive-delete-maybe)
> org-confirm-elisp-link-function 'yes-or-no-p
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
> org-babel-pre-tangle-hook '(save-buffer)
> org-tab-first-hook '(org-babel-hide-result-toggle-maybe
> org-babel-header-arg-expand)
> org-occur-hook '(org-first-headline-recenter)
> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-speed-command-hook '(org-speed-command-activate
> org-babel-speed-command-activate)
> org-confirm-shell-link-function 'yes-or-no-p
> org-link-parameters '(("attachment" :follow org-attach-open-link :export
> org-attach-export-link :complete
> org-attach-complete-link)
> ("id" :follow org-id-open)
> ("eww" :follow eww :store org-eww-store-link)
> ("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
> ("mhe" :follow org-mhe-open :store org-mhe-store-link)
> ("irc" :follow org-irc-visit :store org-irc-store-link
> :export org-irc-export)
> ("info" :follow org-info-open :export org-info-export
> :store org-info-store-link)
> ("gnus" :follow org-gnus-open :store
> org-gnus-store-link)
> ("docview" :follow org-docview-open :export
> org-docview-export :store org-docview-store-link)
> ("bibtex" :follow org-bibtex-open :store
> org-bibtex-store-link)
> ("bbdb" :follow org-bbdb-open :export org-bbdb-export
> :complete org-bbdb-complete-link :store
> org-bbdb-store-link)
> ("w3m" :store org-w3m-store-link) ("file+sys")
> ("file+emacs") ("shell" :follow org-link--open-shell)
> ("news" :follow
> #[257 "\301\300\302 Q!\207" ["news" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("mailto" :follow
> #[257 "\301\300\302 Q!\207" ["mailto" browse-url ":"]
> 5 "\n\n(fn URL)"]
> )
> ("https" :follow
> #[257 "\301\300\302 Q!\207" ["https" browse-url ":"]
> 5 "\n\n(fn URL)"]
> )
> ("http" :follow
> #[257 "\301\300\302 Q!\207" ["http" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("ftp" :follow
> #[257 "\301\300\302 Q!\207" ["ftp" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("help" :follow org-link--open-help)
> ("file" :complete org-link-complete-file)
> ("elisp" :follow org-link--open-elisp)
> ("doi" :follow org-link--open-doi))
> org-link-elisp-confirm-function 'yes-or-no-p
> )
>
^ permalink raw reply [relevance 10%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
@ 2020-12-27 19:17 9% ` Juan Manuel Macías
2020-12-27 21:15 6% ` Kashyap Chamarthy
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-27 19:17 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: orgmode
Hello again Kashyap,
Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
> Hmm, that fixes the new line before the "sub bullet under test 3, with
> a quote". However, a new line still remains after the quote ends (and
> before the "Test 4" starts). Is it possible to nuke that too? If
> not, that's okay, I can live with it. :-)
I'd say a vertical space before and after a block quote would be
'typographically' correct. But if you want to eliminate the space after
the block quote, without having to modify it in a general way, it could
be solved with a bit of Elisp, by defining a custom filter so that the
<blockquote> tag would be modified only within a plain list. Thus, with the
configuration that Diego has suggested, everything would be without
vertical space except the space before each block quote:
#+BIND: org-export-filter-plain-list-functions (my-filter-html)
#+begin_src emacs-lisp :exports results :results none
(defun my-filter-html (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "<blockquote>" "<blockquote style=\"margin-bottom:0px\">" text)))
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
2020-12-27 18:12 10% ` Juan Manuel Macías
@ 2020-12-27 20:14 6% ` tomas
2020-12-27 21:33 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: tomas @ 2020-12-27 20:14 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Sun, Dec 27, 2020 at 07:12:42PM +0100, Juan Manuel Macías wrote:
> Hello,
>
> I think the problem comes because in that url the tilde does not have an
> escape character. If it's just that case, you can try replacing each
> tilde with %7E (see
> https://www.w3schools.com/tags/ref_urlencode.asp). That way the
> link description would have to be formatted correctly, without spurious
> characters.
This would be a bug: tilde is an allowed URI character [1]
Cheers
[1] https://tools.ietf.org/html/rfc3986#section-2.3
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 6%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
2020-12-27 19:17 9% ` Juan Manuel Macías
@ 2020-12-27 21:15 6% ` Kashyap Chamarthy
0 siblings, 0 replies; 200+ results
From: Kashyap Chamarthy @ 2020-12-27 21:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Sun, Dec 27, 2020 at 8:17 PM Juan Manuel Macías
<maciaschain@posteo.net> wrote:
>
> Hello again Kashyap,
Hey, Juan
> Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
>
> > Hmm, that fixes the new line before the "sub bullet under test 3, with
> > a quote". However, a new line still remains after the quote ends (and
> > before the "Test 4" starts). Is it possible to nuke that too? If
> > not, that's okay, I can live with it. :-)
>
> I'd say a vertical space before and after a block quote would be
> 'typographically' correct.
You're right, and I agree.
> But if you want to eliminate the space after
> the block quote, without having to modify it in a general way, it could
> be solved with a bit of Elisp, by defining a custom filter so that the
> <blockquote> tag would be modified only within a plain list. Thus, with the
> configuration that Diego has suggested, everything would be without
> vertical space except the space before each block quote:
>
> #+BIND: org-export-filter-plain-list-functions (my-filter-html)
> #+begin_src emacs-lisp :exports results :results none
> (defun my-filter-html (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "<blockquote>" "<blockquote style=\"margin-bottom:0px\">" text)))
> #+end_src
Thank you for the code snippet. My only use of Emacs is Org-Mode, so I
haven't spent much time learning Elisp yet.
Regards,
Kashyap
^ permalink raw reply [relevance 6%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
2020-12-27 20:14 6% ` tomas
@ 2020-12-27 21:33 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-27 21:33 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hello,
<tomas@tuxteam.de> writes:
> This would be a bug: tilde is an allowed URI character [1]
You're right. I have also noticed that if I write links like these:
[[*foo ~foo~ foo]][[foo]]
[[*foo =foo= foo]][[foo]]
There is an anomaly in the description similar to what Chris comments in
his email...
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Org to ConTeXt exporter?
@ 2020-12-28 13:38 10% Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-28 13:38 UTC (permalink / raw)
To: orgmode
Hi,
Just out of curiosity, I am wondering if there are plans to create an
Org to ConTeXt exporter in the future, or if there is already some work
in progress on this front.
I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
but ConTeXt has very interesting features (grid typesetting, for
example) that LaTeX lacks (for now) and has a more monolithic structure,
that is, it does not need to be extended through packages as in LaTeX.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
@ 2020-12-28 15:04 6% ` Marcin Borkowski
2020-12-28 15:38 10% ` Juan Manuel Macías
2020-12-28 16:23 0% ` Diego Zamboni
2021-01-08 2:37 5% ` Jason Ross
2021-01-08 3:52 6% ` Jason Ross
2 siblings, 2 replies; 200+ results
From: Marcin Borkowski @ 2020-12-28 15:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2020-12-28, at 14:38, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> Just out of curiosity, I am wondering if there are plans to create an
> Org to ConTeXt exporter in the future, or if there is already some work
> in progress on this front.
>
> I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> but ConTeXt has very interesting features (grid typesetting, for
> example) that LaTeX lacks (for now) and has a more monolithic structure,
> that is, it does not need to be extended through packages as in LaTeX.
Creating an exporter from scratch is probably easier than you think.
A few years ago I planned a tutorial about this, but another job
happened, then covid happened etc. Now that I finished some big project
taking me a lot of time, I might be tempted to revisit that. Would
there be demand for a DYI Org-exporter-from-scratch tutorial?
Best,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 6%]
* Re: Org to ConTeXt exporter?
2020-12-28 15:04 6% ` Marcin Borkowski
@ 2020-12-28 15:38 10% ` Juan Manuel Macías
2020-12-28 16:09 5% ` Jonathan McHugh
2020-12-28 16:23 0% ` Diego Zamboni
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2020-12-28 15:38 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Hello, Marcin,
Marcin Borkowski <mbork@mbork.pl> writes:
> Creating an exporter from scratch is probably easier than you think.
> A few years ago I planned a tutorial about this, but another job
> happened, then covid happened etc. Now that I finished some big project
> taking me a lot of time, I might be tempted to revisit that. Would
> there be demand for a DYI Org-exporter-from-scratch tutorial?
Thank you for your answer. Actually a tutorial on how to create an
exporter from scratch (I think) would be really interesting. Some time
ago I was tempted to start writing an exporter for ConTeXt, studying the
code of the other exporters, but for time and work reasons I left the
project abandoned.
If you finally write that tutorial, I could also translate it into
Spanish to spread it out among Spanish-speaking Org users.
Regards,
Juan Manuel
> Best,
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
2020-12-28 15:38 10% ` Juan Manuel Macías
@ 2020-12-28 16:09 5% ` Jonathan McHugh
2020-12-28 17:54 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Jonathan McHugh @ 2020-12-28 16:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hello \Context folks,
I have wondered about the interoperability between Context and Latex.
As somebody who (previously) invested a lot of time into Latex, my migration to
Context (due to its emphasis on Lua) grew problematic once other commitments
grew.
The lack of Context support in Org-Mode has made me consider reverting
back to Latex.
However, I have wondered if a possible shortcut is to compile a list of
the semantic differences between the two and attack it from there.
For example, the Context stub, 'From Latex to Context', gives some of the
distinctions:
https://wiki.contextgarden.net/From_LaTeX_to_ConTeXt
... which then cites a 45 page pdf (which may (possibly) be a little out
of date, having been written in 2003):
http://www.berenddeboer.net/tex/LaTeX2ConTeXt.pdf
Perhaps looking at Org-Modes Latex exporter and determining the Context
equivalent would help? After all, they should be satisfing equivalent requirements.
Even better, if a modern list of equivalents were in a locality suitable
for non Org-Mode users then it may become easier for users from either
communities to feed off eachothers work a little easier.
If I had a lot of time it would be wonderful to develop parsing
expression grammars to capture it all, irrespective of direction ... mmm time....
Best wishes,
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello, Marcin,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Creating an exporter from scratch is probably easier than you think.
>> A few years ago I planned a tutorial about this, but another job
>> happened, then covid happened etc. Now that I finished some big project
>> taking me a lot of time, I might be tempted to revisit that. Would
>> there be demand for a DYI Org-exporter-from-scratch tutorial?
>
> Thank you for your answer. Actually a tutorial on how to create an
> exporter from scratch (I think) would be really interesting. Some time
> ago I was tempted to start writing an exporter for ConTeXt, studying the
> code of the other exporters, but for time and work reasons I left the
> project abandoned.
>
> If you finally write that tutorial, I could also translate it into
> Spanish to spread it out among Spanish-speaking Org users.
>
> Regards,
>
> Juan Manuel
>
>> Best,
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 15:04 6% ` Marcin Borkowski
2020-12-28 15:38 10% ` Juan Manuel Macías
@ 2020-12-28 16:23 0% ` Diego Zamboni
2020-12-28 18:03 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Diego Zamboni @ 2020-12-28 16:23 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Juan Manuel Macías, orgmode
[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]
I have never used ConTeXt, but from what I've seen, despite its many
differences, a lot is still similar to TeX/LaTeX (e.g. math). Given this, I
think it might be easier to create a new derived exporter from ox-latex,
and override the parts that differ, instead of creating a new one
completely from scratch.
You can see an example in my own
https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
which uses ox-md as a backend for defining the new ox-markua exporter.
There is also already some documentation at
https://orgmode.org/worg/dev/org-export-reference.html
--Diego
On Mon, Dec 28, 2020 at 4:09 PM Marcin Borkowski <mbork@mbork.pl> wrote:
>
> On 2020-12-28, at 14:38, Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
> > Hi,
> >
> > Just out of curiosity, I am wondering if there are plans to create an
> > Org to ConTeXt exporter in the future, or if there is already some work
> > in progress on this front.
> >
> > I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> > but ConTeXt has very interesting features (grid typesetting, for
> > example) that LaTeX lacks (for now) and has a more monolithic structure,
> > that is, it does not need to be extended through packages as in LaTeX.
>
> Creating an exporter from scratch is probably easier than you think.
> A few years ago I planned a tutorial about this, but another job
> happened, then covid happened etc. Now that I finished some big project
> taking me a lot of time, I might be tempted to revisit that. Would
> there be demand for a DYI Org-exporter-from-scratch tutorial?
>
> Best,
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>
[-- Attachment #2: Type: text/html, Size: 2420 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Org to ConTeXt exporter?
2020-12-28 16:09 5% ` Jonathan McHugh
@ 2020-12-28 17:54 7% ` Juan Manuel Macías
2020-12-28 19:06 5% ` Jonathan McHugh
2020-12-29 21:51 5% ` Jonathan McHugh
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-28 17:54 UTC (permalink / raw)
To: Jonathan McHugh; +Cc: orgmode
Hello, Jonathan,
Jonathan McHugh <indieterminacy@libre.brussels> writes:
> I have wondered about the interoperability between Context and Latex.
>
> As somebody who (previously) invested a lot of time into Latex, my migration to
> Context (due to its emphasis on Lua) grew problematic once other commitments
> grew.
What I like about ConTeXt is its (let's say) avant-garde vocation. But
for my everyday work I prefer LaTeX: more extensible, more versatile,
even more documented. But we must accept that ConTeXt is also an
advanced typographic laboratory where many functionalities also end up
in LaTeX over time. In fact, as far as I know, the future LaTeX3 adopts
some ideas from ConTeXt.
On Lua, LuaLaTeX also has good support. And many new LaTeX packages are
already getting very good use of LuaTeX features.
> The lack of Context support in Org-Mode has made me consider reverting
> back to Latex.
I know some advanced ConTeXt users (I am not) who are very interested in
migrating to Org Mode. In that aspect, I think a native exporter to
ConTeXt would be of great help.
Generally speaking, I think Org is the perfect interface to use TeX and
friends. One of the things I like the most about Org Mode is that it
allows working in (La)TeX at a very high level. Of course, for advanced
use, the more you know about LaTeX and TeX, the better. For example, if
I work on a large book, I usually write the entire configuration (the
preamble, my macros, my LaTeX code, etc.) to an Org file, and then I generate
a Preamble.tex file using tangle. I have a master file and several
subdocuments for the parts and sections of the book. And I make heavy
use of Org Publish. But in all that workflow, LaTeX is always in the
background. It is mainly a matter of comfort: I love TeX and its
derivatives, its power and its typographic refinement, but its language
is very verbose and the sources are difficult to debug. Org mode is much
more human readable. And even much more readable and comfortable than
Markdown.
> If I had a lot of time it would be wonderful to develop parsing
> expression grammars to capture it all, irrespective of direction ... mmm time....
Yes, time is the problem: I think TODO lists were invented to have a
foot of mud in the future :-)
Regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Org to ConTeXt exporter?
2020-12-28 16:23 0% ` Diego Zamboni
@ 2020-12-28 18:03 10% ` Juan Manuel Macías
2020-12-28 19:23 6% ` Diego Zamboni
2020-12-28 20:03 4% ` Marcin Borkowski
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-28 18:03 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hello, Diego,
Diego Zamboni <diego@zzamboni.org> writes:
> I have never used ConTeXt, but from what I've seen, despite its many
> differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
> this, I think it might be easier to create a new derived exporter from
> ox-latex, and override the parts that differ, instead of creating a
> new one completely from scratch.
You are right, maybe it is better to start with ox-latex, since LaTeX
and ConTeXt are related.
> You can see an example in my own
> https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
> which uses ox-md as a backend for defining the new ox-markua exporter.
Thank you very much for the link. As soon as I have some time I will
study your code
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [tip] Export subfigures to LaTeX (and HTML)
2020-12-25 16:02 7% [tip] Export subfigures to LaTeX (and HTML) Juan Manuel Macías
@ 2020-12-28 18:03 5% ` John Kitchin
2020-12-29 15:00 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2020-12-28 18:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
This is an interesting use of links, in particular extending the
information in the description.
You might look at this
http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
for another way to do that.
Check out this alternative approach all together that also uses a
special block.
http://kitchingroup.cheme.cmu.edu/blog/2016/01/17/Side-by-side-figures-in-org-mode-for-different-export-outputs/
I don't use either of these today, and they are old so who knows if they
still work, but they have some fun ideas in them.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> I have come up with a way to export subfigures to LaTeX (with the subfigure package) by
> defining a new link type. The 'subcaption' of the subfigure would be the description of
> the link. If we want to add parameters such as width, scale, etc., we can put them next
> between the marks '>( ... )'
>
> The code:
>
> #+begin_src emacs-lisp
> (org-link-set-parameters
> "subfig"
> :follow (lambda (file) (find-file file))
> :face '(:foreground "chocolate" :weight bold :underline t)
> :display 'full
> :export (lambda (file desc backend)
> (when (eq backend 'latex)
> (if (string-match ">(\\(.+\\))" desc)
> (concat "\\subfigure[" (replace-regexp-in-string "\s+>(.+)" "" desc) "]"
> "{\\includegraphics"
> "["
> (match-string 1 desc)
> "]"
> "{"
> file
> "}}")
> (format "\\subfigure[%s]{\\includegraphics{%s}}" desc file)))))
> #+end_src
>
> Example:
>
> #+begin_src org
> ,#+CAPTION: Lorem impsum dolor
> ,#+ATTR_LaTeX: :options \centering
> ,#+begin_figure
> [[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth)]]
>
> [[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth)]]
>
> [[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth)]]
> ,#+end_figure
> #+end_src
>
> Results:
>
> #+begin_src latex
> \begin{figure}\centering
> \subfigure[Caption of img1]{\includegraphics[width=.3\textwidth]{img1.jpg}}
>
> \subfigure[Caption of img2]{\includegraphics[width=.3\textwidth]{img2.jpg}}
>
> \subfigure[Caption of img3]{\includegraphics[width=.6\textwidth]{img3.jpg}}
> \caption{Lorem impsum dolor}
> \end{figure}
> #+end_src
>
> If we want to export to HTML it would be something more tricky. In this case, the export
> function could be like this (a width parameter would be enclosed between >{ ... }):
>
> #+begin_src emacs-lisp
> (lambda (file desc backend)
> (cond
> ((eq backend 'latex)
> (if (string-match ">(\\(.+\\))" desc)
> (concat "\\subfigure[" (replace-regexp-in-string "\s*>.+" "" desc) "]" "{\\includegraphics" "[" (match-string 1 desc) "]" "{" file "}}")
> (format "\\subfigure[%s]{\\includegraphics{%s}}" (replace-regexp-in-string "\s*>.+" "" desc) file)))
> ((eq backend 'html)
> (if (string-match ">{\\(.+\\)}" desc)
> (concat "<td><img src=\"" file "\" alt=\"" file "\"" " style=\"width:"
> (match-string 1 desc)
> "\""
> "/><br>"
> (replace-regexp-in-string "\s*>.+" "" desc)
> "</td>")
> (format "<td><img src=\"%s\" alt=\"%s\"/><br>%s</td>"
> file file
> (replace-regexp-in-string "\s*>.+" "" desc))))))
> #+end_src
>
> Example:
>
> #+begin_src org
> ,#+CAPTION: Lorem impsum dolor
> ,#+ATTR_LaTeX: :options \centering
> ,#+begin_figure
> @@html:<div class="org-center"><table style="margin-left:auto;margin-right:auto;"><tr>@@
>
> [[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth) >{300px}]]
>
> [[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth) >{300px}]]
>
> @@html:</tr></table><p> </p><table style="margin-left:auto;margin-right:auto;"><tr>@@
>
> [[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth) >{600px}]]
>
> @@html:</tr></table><br>Lorem ipsum dolor</div>@@
> ,#+end_figure
> #+end_src
>
> As you can see, it is not the panacea, and you have to apply some direct format...
>
> Happy holidays
>
> Juan Manuel
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 17:54 7% ` Juan Manuel Macías
@ 2020-12-28 19:06 5% ` Jonathan McHugh
2020-12-29 21:51 5% ` Jonathan McHugh
1 sibling, 0 replies; 200+ results
From: Jonathan McHugh @ 2020-12-28 19:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello Juan,
Thanks for validating my suspicions re Latex and Context.
One area I used a lot was with regards to Tikz. I will have to make many
detours before I get the chance to adapt bespoke Tikz projects to to
something more generic and action from org-mode. Hopefully by then the
choice of an outputting document management system will be less of a
consideration.
I half suspect that the Context author (Hans Hagen) focusing on Metapost
allowed the Context community to not value Tikz so much (transposing the
Tikz manual to Context would be a great win IMHO).
Checking in on Context I see that they have a new generation:
https://wiki.contextgarden.net/LMTX
Im sure there will be some scripts which will need updating given
updated conventions. Im pleased that that the project still has momentum
and look forward to investigating what this means.
A Guix user, it saddens me that it is not packaged properly (time, time,
time) - especially given the LMTX shift.
Broadening the topic, I wonder whether the wider stemming of Tex derived
products should be approached with as much of the equivalent encapsulation as
possible. New to the Emacs and Lisp world, I do not know whether suggesting
Org-Mode outputting Racket's Scribble or Guile's Skribilo is productive
or relevant (or trolling!).
More practically speaking, it is worth noting that Skribilo outputs
Context (in addition to Latex):
https://www.nongnu.org/skribilo/doc/user-38.html#context-engine
It is entirely possible that that community has resolved a lot of the
challenges the Org-Mode contingent is currently deliberating over.
Best wishes,
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello, Jonathan,
>
> Jonathan McHugh <indieterminacy@libre.brussels> writes:
>
>> I have wondered about the interoperability between Context and Latex.
>>
>> As somebody who (previously) invested a lot of time into Latex, my migration to
>> Context (due to its emphasis on Lua) grew problematic once other commitments
>> grew.
>
> What I like about ConTeXt is its (let's say) avant-garde vocation. But
> for my everyday work I prefer LaTeX: more extensible, more versatile,
> even more documented. But we must accept that ConTeXt is also an
> advanced typographic laboratory where many functionalities also end up
> in LaTeX over time. In fact, as far as I know, the future LaTeX3 adopts
> some ideas from ConTeXt.
>
> On Lua, LuaLaTeX also has good support. And many new LaTeX packages are
> already getting very good use of LuaTeX features.
>
>> The lack of Context support in Org-Mode has made me consider reverting
>> back to Latex.
>
> I know some advanced ConTeXt users (I am not) who are very interested in
> migrating to Org Mode. In that aspect, I think a native exporter to
> ConTeXt would be of great help.
>
> Generally speaking, I think Org is the perfect interface to use TeX and
> friends. One of the things I like the most about Org Mode is that it
> allows working in (La)TeX at a very high level. Of course, for advanced
> use, the more you know about LaTeX and TeX, the better. For example, if
> I work on a large book, I usually write the entire configuration (the
> preamble, my macros, my LaTeX code, etc.) to an Org file, and then I generate
> a Preamble.tex file using tangle. I have a master file and several
> subdocuments for the parts and sections of the book. And I make heavy
> use of Org Publish. But in all that workflow, LaTeX is always in the
> background. It is mainly a matter of comfort: I love TeX and its
> derivatives, its power and its typographic refinement, but its language
> is very verbose and the sources are difficult to debug. Org mode is much
> more human readable. And even much more readable and comfortable than
> Markdown.
>
>> If I had a lot of time it would be wonderful to develop parsing
>> expression grammars to capture it all, irrespective of direction ... mmm time....
>
> Yes, time is the problem: I think TODO lists were invented to have a
> foot of mud in the future :-)
>
> Regards,
>
> Juan Manuel
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 18:03 10% ` Juan Manuel Macías
@ 2020-12-28 19:23 6% ` Diego Zamboni
2020-12-28 20:03 4% ` Marcin Borkowski
1 sibling, 0 replies; 200+ results
From: Diego Zamboni @ 2020-12-28 19:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
By the way, I just realized that the ox-pandoc exporter (
https://github.com/kawabata/ox-pandoc) has a number of "context" options,
since Pandoc itself supports ConTeXt output. I have no idea how well it
works, but it could be an option for ConTeXt users for the time being.
--Diego
On Mon, Dec 28, 2020 at 7:03 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hello, Diego,
>
> Diego Zamboni <diego@zzamboni.org> writes:
>
> > I have never used ConTeXt, but from what I've seen, despite its many
> > differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
> > this, I think it might be easier to create a new derived exporter from
> > ox-latex, and override the parts that differ, instead of creating a
> > new one completely from scratch.
>
> You are right, maybe it is better to start with ox-latex, since LaTeX
> and ConTeXt are related.
>
> > You can see an example in my own
> > https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
> > which uses ox-md as a backend for defining the new ox-markua exporter.
>
> Thank you very much for the link. As soon as I have some time I will
> study your code
>
> Regards,
>
> Juan Manuel
>
[-- Attachment #2: Type: text/html, Size: 1844 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org to ConTeXt exporter?
2020-12-28 18:03 10% ` Juan Manuel Macías
2020-12-28 19:23 6% ` Diego Zamboni
@ 2020-12-28 20:03 4% ` Marcin Borkowski
2020-12-29 16:05 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Marcin Borkowski @ 2020-12-28 20:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Diego Zamboni, orgmode
On 2020-12-28, at 19:03, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hello, Diego,
>
> Diego Zamboni <diego@zzamboni.org> writes:
>
>> I have never used ConTeXt, but from what I've seen, despite its many
>> differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
>> this, I think it might be easier to create a new derived exporter from
>> ox-latex, and override the parts that differ, instead of creating a
>> new one completely from scratch.
>
> You are right, maybe it is better to start with ox-latex, since LaTeX
> and ConTeXt are related.
I beg to differ. The relation between LaTeX and ConTeXt is that they
both come from plain TeX, but both came a long way, and there are
significant differences between the two. Personally, I'd rather start
that exporter from scratch. I wrote my exporter a few years ago, it's
not that difficult.
Here's the thing. Some time ago, I have dedicated about 20 minutes per
day (sometimes less, sometimes more, but the average over the past 6
years is about 17 minutes now) to what I call "creative writing" -
mainly the book I was working on for the past 5 years with two more
people (and that book is now complete) and my blog. I will try to use
some of that time to start that tutorial, and maybe I will then publish
it on my blog or somewhere. (I also want to get back to the book on
Elisp I started a long time ago, but that can wait a few more weeks.)
But here's the thing: I'll need help. I know LaTeX very well - I've
been using plain TeX for about 25 years now and LaTeX for about 20
years, including writing quite a few packages and classes - but I don't
know ConTeXt that well. (I did use it a bit, but not very extensively.)
Where could we start working on it? I suppose GitHub/GitLab is out of
question, so?
Best,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 4%]
* Re: [tip] Export subfigures to LaTeX (and HTML)
2020-12-28 18:03 5% ` John Kitchin
@ 2020-12-29 15:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-29 15:00 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
Hello, John,
Thank you very much for the two links.
John Kitchin <jkitchin@andrew.cmu.edu> writes:
> You might look at this
> http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
> for another way to do that.
Your idea of adding attributes to Org links is very interesting and
productive. It also shows the great potential that Org links have.
> Check out this alternative approach all together that also uses a
> special block.
>
> http://kitchingroup.cheme.cmu.edu/blog/2016/01/17/Side-by-side-figures-in-org-mode-for-different-export-outputs/
I also find your approach very interesting. What I like the most is
giving LaTeX a "Lisp skin". It is more elegant and legible. I love
(La)TeX and its potential, but I find its code somewhat ugly, often too
verbose. By the way (offtopic), there is a LaTeX package called
lisp-on-TeX that includes a rudimentary Lisp interpreter:
https://www.ctan.org/pkg/lisp-on-tex. It's interesting, and you can do
some things with it, but I think it's an abandoned project. The TeX
ecosystem has moved to Lua with LuaTeX and LuaMetaTeX, but a LispTeX
would have been wonderful! ;-)
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org to ConTeXt exporter?
2020-12-28 20:03 4% ` Marcin Borkowski
@ 2020-12-29 16:05 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2020-12-29 16:05 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Hello, Marcin,
Marcin Borkowski <mbork@mbork.pl> writes:
> Here's the thing. Some time ago, I have dedicated about 20 minutes per
> day (sometimes less, sometimes more, but the average over the past 6
> years is about 17 minutes now) to what I call "creative writing" -
> mainly the book I was working on for the past 5 years with two more
> people (and that book is now complete) and my blog. I will try to use
> some of that time to start that tutorial, and maybe I will then publish
> it on my blog or somewhere. (I also want to get back to the book on
> Elisp I started a long time ago, but that can wait a few more weeks.)
As I said, I think a tutorial on writing an Org exporter from scratch
would be very interesting and useful. If, finally, you can find time for
it, I could do a translation to publish it on my blog in Spanish
(https://gnutas.juanmanuelmacias.com/). With my translation of Homer's
Odyssey (work in progress) and other projects, I don't have a lot of free
time, but I can always find a moment.
> But here's the thing: I'll need help. I know LaTeX very well - I've
> been using plain TeX for about 25 years now and LaTeX for about 20
> years, including writing quite a few packages and classes - but I don't
> know ConTeXt that well. (I did use it a bit, but not very extensively.)
(In my case) I have not used much ConTeXt. Really, I prefer LaTeX. It's
a personal opinion and a matter of taste, but I find ConTeXt too
"monolithic". One of the main problems it has is (I think) its huge lack
of documentation (compared to LaTeX). I suppose, in part, because his
community is smaller. However, I also think that ConTeXt has interesting
features (grid typesetting, xml integration, etc.), and it would not be
a bad idea to have an alternative to LaTeX in Org. But I don't know if
it would be something feasible in the short term, beyond the concept...
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org to ConTeXt exporter?
2020-12-28 17:54 7% ` Juan Manuel Macías
2020-12-28 19:06 5% ` Jonathan McHugh
@ 2020-12-29 21:51 5% ` Jonathan McHugh
1 sibling, 0 replies; 200+ results
From: Jonathan McHugh @ 2020-12-29 21:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: ludo, orgmode
Hello Juan,
I investigated further the Context engine for Skribilo:
https://git.savannah.gnu.org/gitweb/?p=skribilo.git;a=tree;f=src/guile/skribilo/engine;h=9c6353eb7c6eae70de007c2f0a8f01092ae669a2;hb=HEAD
While I cant comment on it's Context engine functionality or efficacy, it clearly has a
decent breakdown of usecases across its 1300 lines. It appears to have
had low updates frequency, probably as a consequence of the stability of
Context's syntax (rather than the momentum of the DSL). It may be useful
as a checklist of key terms to tick off, if not a consideration for
framing anything to serve Org-Moders.
I have CC’d Ludovic Courtès, who has spearheaded Skribilo and all the
commits for it’s Context engine. Judging by his output within the Guix
community it’s possible that he may have some insights concerning this
thread:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-12/msg00731.html
Part of Skribilo’s homepage blurb intrigued me:
"Last but not least, Skribilo can be thought of as a complete document
programming framework for the Scheme programming language that may be
used to automate a variety of document generation tasks. Technically,
the Skribilo language/API is an embedded domain-specific language
(EDSL), implemented via so-called “deep embedding”. Skribilo uses GNU
Guile 3.0 or 2.x as the underlying Scheme implementation."
https://nongnu.org/skribilo/index.html
Still early in my Lisp journey, I do not know whether it would be
abhorrent/inelegant for the eLisp orientation of Org-Mode to defer to Guile (at the
backend) for outputting in different formats.
Kind regards,
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello, Jonathan,
>
> Jonathan McHugh <indieterminacy@libre.brussels> writes:
>
>> I have wondered about the interoperability between Context and Latex.
>>
>> As somebody who (previously) invested a lot of time into Latex, my migration to
>> Context (due to its emphasis on Lua) grew problematic once other commitments
>> grew.
>
> What I like about ConTeXt is its (let's say) avant-garde vocation. But
> for my everyday work I prefer LaTeX: more extensible, more versatile,
> even more documented. But we must accept that ConTeXt is also an
> advanced typographic laboratory where many functionalities also end up
> in LaTeX over time. In fact, as far as I know, the future LaTeX3 adopts
> some ideas from ConTeXt.
>
> On Lua, LuaLaTeX also has good support. And many new LaTeX packages are
> already getting very good use of LuaTeX features.
>
>> The lack of Context support in Org-Mode has made me consider reverting
>> back to Latex.
>
> I know some advanced ConTeXt users (I am not) who are very interested in
> migrating to Org Mode. In that aspect, I think a native exporter to
> ConTeXt would be of great help.
>
> Generally speaking, I think Org is the perfect interface to use TeX and
> friends. One of the things I like the most about Org Mode is that it
> allows working in (La)TeX at a very high level. Of course, for advanced
> use, the more you know about LaTeX and TeX, the better. For example, if
> I work on a large book, I usually write the entire configuration (the
> preamble, my macros, my LaTeX code, etc.) to an Org file, and then I generate
> a Preamble.tex file using tangle. I have a master file and several
> subdocuments for the parts and sections of the book. And I make heavy
> use of Org Publish. But in all that workflow, LaTeX is always in the
> background. It is mainly a matter of comfort: I love TeX and its
> derivatives, its power and its typographic refinement, but its language
> is very verbose and the sources are difficult to debug. Org mode is much
> more human readable. And even much more readable and comfortable than
> Markdown.
>
>> If I had a lot of time it would be wonderful to develop parsing
>> expression grammars to capture it all, irrespective of direction ... mmm time....
>
> Yes, time is the problem: I think TODO lists were invented to have a
> foot of mud in the future :-)
>
> Regards,
>
> Juan Manuel
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 5%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2020-12-17 17:23 5% [PATCH] " Juan Manuel Macías
@ 2021-01-03 10:25 6% ` TEC
2021-01-03 13:07 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: TEC @ 2021-01-03 10:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan,
Thanks for your patch.
This looks like a fairly sensible addition. Two comments from me:
1. I'm not sure that "options" is a good name for arbitrary LaTeX which
is included inside the verse block. Perhaps something like "insert"
or "include", etc. may be a better fit.
2. It's considered generally nice to document features like this :) The
two documents which I'd think to note this in are ORG-NEWS and the
manual (docs/manual.org).
All the best,
Timothy.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> (Sorry, due to a mistake, the text of my message did not appear in my previous email)
>
> Hi,
>
> I would like to propose this patch to add some LaTeX attributes to the verse block,
> especially to be able to apply certain features from the verse.sty package, which is an
> extension (widely used in Humanities) of the standard LaTeX 'verse' environment.
>
> These attributes would be:
>
> - `:lines' to add verse numbers, according to any numbering sequence
> - `:center' to apply the optical centering of the poem, which is a typographic convention
> whereby a poem or a group of verses is centered on the page, taking the width of the
> longest verse as a reference. In fact, optical centering is the correct arrangement of
> verses in a document.
> - `:versewidth' which expects a text string that is the longest verse of the poem,
> required when applying the `:center' attribute.
>
> As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
> attribute would be used to add arbitrary code within the verse environment.
>
> Consider this complete example with Shakespeare's first sonnet:
>
> #+begin_src org
> ,#+ATTR_LaTeX: :center t :options \small :lines 5
> ,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
> ,#+begin_verse
> From fairest creatures we desire increase,
> That thereby beauty’s rose might never die,
> But as the riper should by time decrease,
> His tender heir mught bear his memeory:
> But thou, contracted to thine own bright eyes,
> Feed’st thy light’st flame with self-substantial fuel,
> Making a famine where abundance lies,
> Thyself thy foe, to thy sweet self too cruel.
> Thou that art now the world’s fresh ornament
> And only herald to the gaudy spring,
> Within thine own bud buriest thy content
> And, tender churl, makest waste in niggarding.
> Pity the world, or else this glutton be,
> To eat the world’s due, by the grave and thee.
> ,#+end_verse
> #+end_src
>
> when exporting to LaTeX we get:
>
> #+begin_src latex
> \settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
> \begin{verse}[\versewidth]
> \poemlines{5}
> \small
> From fairest creatures we desire increase,\\
> That thereby beauty’s rose might never die,\\
> But as the riper should by time decrease,\\
> His tender heir mught bear his memeory:\\
> But thou, contracted to thine own bright eyes,\\
> Feed’st thy light’st flame with self-substantial fuel,\\
> Making a famine where abundance lies,\\
> Thyself thy foe, to thy sweet self too cruel.\\
> Thou that art now the world’s fresh ornament\\
> And only herald to the gaudy spring,\\
> Within thine own bud buriest thy content\\
> And, tender churl, makest waste in niggarding.\\
> Pity the world, or else this glutton be,\\
> To eat the world’s due, by the grave and thee.\\
> \end{verse}
> #+end_src
>
> In an attached image I send a screenshot with the typographic result
>
> And finally, this is the patch I would propose
>
> #+begin_src diff
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 2a14b25d5..bc6b64e78 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3506,6 +3506,16 @@ channel."
> "Transcode a VERSE-BLOCK element from Org to LaTeX.
> CONTENTS is verse block contents. INFO is a plist holding
> contextual information."
> +(let*
> + ((lin (org-export-read-attribute :attr_latex verse-block :lines))
> + (opt (org-export-read-attribute :attr_latex verse-block :options))
> + (cent (org-export-read-attribute :attr_latex verse-block :center))
> + (attr (concat
> + (if cent "[\\versewidth]" "")
> + (if lin (format "\n\\poemlines{%s}" lin) "")
> + (if opt (format "\n%s" opt) "")))
> + (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
> + (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
> (concat
> (org-latex--wrap-label
> verse-block
> @@ -3513,7 +3523,9 @@ contextual information."
> ;; character and change each white space at beginning of a line
> ;; into a space of 1 em. Also change each blank line with
> ;; a vertical space of 1 em.
> - (format "\\begin{verse}\n%s\\end{verse}"
> + (format "%s\\begin{verse}%s\n%s\\end{verse}"
> + vwidth-attr
> + attr
> (replace-regexp-in-string
> "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
> (replace-regexp-in-string
> @@ -3524,7 +3536,7 @@ contextual information."
> info)
> ;; Insert footnote definitions, if any, after the environment, so
> ;; the special formatting above is not applied to them.
> - (org-latex--delayed-footnotes-definitions verse-block info)))
> + (org-latex--delayed-footnotes-definitions verse-block info))))
> #+end_src
>
> Regards,
>
> Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-01-03 10:25 6% ` TEC
@ 2021-01-03 13:07 10% ` Juan Manuel Macías
2021-01-03 13:08 5% ` TEC
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-03 13:07 UTC (permalink / raw)
To: TEC; +Cc: orgmode
Hi Timothy,
TEC <tecosaur@gmail.com> writes:
> Hi Juan,
>
> Thanks for your patch.
>
> This looks like a fairly sensible addition. Two comments from me:
>
> 1. I'm not sure that "options" is a good name for arbitrary LaTeX which
> is included inside the verse block. Perhaps something like "insert"
> or "include", etc. may be a better fit.
> 2. It's considered generally nice to document features like this :) The
> two documents which I'd think to note this in are ORG-NEWS and the
> manual (docs/manual.org).
Thank you very much for your response and your comments.
I agree to name "Insert, include, etc." the attribute to include
arbitrary LaTeX code, better than "options".
Of course, I can add the necessary documentation to the files you tell
me. As I am new to submitting patches, I don't really know how to
proceed: do I have to send you the new version of the patch, with the
documentation? Should I send a new email with all of it to this list?
Best regards,
Juan Manuel
> All the best,
>
> Timothy.
>
^ permalink raw reply [relevance 10%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-01-03 13:07 10% ` Juan Manuel Macías
@ 2021-01-03 13:08 5% ` TEC
2021-01-07 18:52 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: TEC @ 2021-01-03 13:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Thank you very much for your response and your comments.
Seriously, thanks for the patch. I think the ML is usually a bit more
responsive, but it seems to be a bit quiet at the moment.
> I agree to name "Insert, include, etc." the attribute to include
> arbitrary LaTeX code, better than "options".
Glad my feedback seems to have gone down well :). If the only likely use
of this is adjusting the font, perhaps for the sake of consistency we
can match the behaviour of tables, which take a :font LaTeX attribute?
> Of course, I can add the necessary documentation to the files you tell
> me. As I am new to submitting patches, I don't really know how to
> proceed: do I have to send you the new version of the patch, with the
> documentation? Should I send a new email with all of it to this list?
Thanks for asking. Sometimes it seems the maintainers take the trouble of
adding an ORG-NEWS entry or minor touching ups to the patch, but I think
it's nice to leave as little for them to do as possible :)
Announce changes in: etc/ORG-NEWS
Document new/different behaviour in: doc/org-manual.org
I think Markup for /Rich Contents > Paragraphs/ may be the right place
to add a description of this functionality --- verse blocks are
discussed around line 10750.
Regarding how patches on this ML work, this is what I've observed:
- Initial version of patch submitted, with justification/explanation
- Feedback may be given
- Revisions of the patch are attached in replies to feedback
- Process repeats until everyone's happy
- Patch is merged
i.e. it all tends to happen in the same thread.
Hope this helps,
Timothy.
^ permalink raw reply [relevance 5%]
* Re: Inserting LaTex expressions using a filter fails
@ 2021-01-05 21:58 10% ` Juan Manuel Macías
2021-01-06 7:50 6% ` Mart van de Wege
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-05 21:58 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Hello,
Mart van de Wege <mvdwege@gmail.com> writes:
> I'm trying to replace U+00BD in an org buffer with \sfrac{1}{2} during
> export to LaTex, and obviously I'm doing something wrong, or I don't
> understand the documentation.
>
> I use the following code to set up the filter:
>
> #+BIND: org-export-filter-item-functions (latex-replace-half)
> #+BEGIN_SRC emacs-lisp :exports results :results none
>
> (defun latex-replace-half (text backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "½" "\\sfrac{1}{2}" text)))
> #+END_SRC
You must add a double escape character to the backslash:
...
(replace-regexp-in-string "½" "\\\\sfrac{1}{2}" text)))
...
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-05 21:58 10% ` Juan Manuel Macías
@ 2021-01-06 7:50 6% ` Mart van de Wege
2021-01-06 11:51 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Mart van de Wege @ 2021-01-06 7:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Tue, 05 Jan 2021 22:58:33 +0100
Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hello,
>
> Mart van de Wege <mvdwege@gmail.com> writes:
>
> > I'm trying to replace U+00BD in an org buffer with \sfrac{1}{2}
> > during export to LaTex, and obviously I'm doing something wrong, or
> > I don't understand the documentation.
> >
> > I use the following code to set up the filter:
> >
> > #+BIND: org-export-filter-item-functions (latex-replace-half)
> > #+BEGIN_SRC emacs-lisp :exports results :results none
> >
> > (defun latex-replace-half (text backend info)
> > (when (org-export-derived-backend-p backend 'latex)
> > (replace-regexp-in-string "½" "\\sfrac{1}{2}" text)))
> > #+END_SRC
>
> You must add a double escape character to the backslash:
>
> ...
> (replace-regexp-in-string "½" "\\\\sfrac{1}{2}" text)))
> ...
>
Thanks!
But see my answer to Nick Dokos on the list, that does not do anything
either.
Regards,
Mart
^ permalink raw reply [relevance 6%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 7:50 6% ` Mart van de Wege
@ 2021-01-06 11:51 10% ` Juan Manuel Macías
2021-01-06 12:00 6% ` Mart van de Wege
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-06 11:51 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mvdwege@gmail.com> writes:
> Thanks!
>
> But see my answer to Nick Dokos on the list, that does not do anything
> either.
Try putting this variable in your .emacs with non-nil value:
(setq org-export-allow-bind-keywords t)
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 11:51 10% ` Juan Manuel Macías
@ 2021-01-06 12:00 6% ` Mart van de Wege
2021-01-06 12:24 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Mart van de Wege @ 2021-01-06 12:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Wed, 06 Jan 2021 12:51:00 +0100
Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Mart van de Wege <mvdwege@gmail.com> writes:
>
> > Thanks!
> >
> > But see my answer to Nick Dokos on the list, that does not do
> > anything either.
>
> Try putting this variable in your .emacs with non-nil value:
>
> (setq org-export-allow-bind-keywords t)
>
Well whaddayaknow? That works.
Kind of weird it's not mentioned in the docs though (at least not in
the same section as export filters); if you're going to tell people that
you can bind local functions to an org file, then it might be nice to
point out that you do need to turn that on.
Regards,
Mart
^ permalink raw reply [relevance 6%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 12:00 6% ` Mart van de Wege
@ 2021-01-06 12:24 10% ` Juan Manuel Macías
2021-01-06 15:17 6% ` Mart van de Wege
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-06 12:24 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mvdwege@gmail.com> writes:
> Kind of weird it's not mentioned in the docs though (at least not in
> the same section as export filters); if you're going to tell people that
> you can bind local functions to an org file, then it might be nice to
> point out that you do need to turn that on.
You're right. I think an addition could be proposed in the
documentation: for example, a footnote in the section `Defining filters
for individual files', since by default the variable
`org-export-allow-bind-keywords' has value nil.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 15:17 6% ` Mart van de Wege
@ 2021-01-06 15:58 10% ` Juan Manuel Macías
2021-01-06 16:00 6% ` Mart van de Wege
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-06 15:58 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mart@vdwege.eu> writes:
> You're right. I looked up the variable, and there is only one mention
> in the docs, and that is about binding emacs variables locally to the
> org file buffer.
>
> Can I just clone the repo and prepare a patch?
As far as I know, you can create a diff and propose the patch here in
the list, opening a new thread, that includes in the mail subject
something like "[patch] etc"
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Possibility to copy text outside EMACS and send it to orgmode document
@ 2021-01-06 16:31 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-06 16:31 UTC (permalink / raw)
To: Gerardo Moro; +Cc: orgmode
Gerardo Moro <gerardomoro37@gmail.com> writes:
> Basically that: as I copy (Control-C) text from the browser (Chrome),
> I would like those copied sentences to be sent to a ordered list in an
> OrgMode document:
>
> - copied text 1
> - copied text 2
> - etc.
>
> Any ideas? This would be very useful.
> Thanks!
I don't know if it is exactly what you are looking for, but maybe you
might be interested in this extension for chrome and firefox that uses
org-protocol:
https://github.com/sprig/org-capture-extension
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 12:24 10% ` Juan Manuel Macías
@ 2021-01-06 15:17 6% ` Mart van de Wege
2021-01-06 15:58 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Mart van de Wege @ 2021-01-06 15:17 UTC (permalink / raw)
To: Juan Manuel Macías, Mart van de Wege; +Cc: orgmode
On Wed, 2021-01-06 at 13:24 +0100, Juan Manuel Macías wrote:
> Mart van de Wege <mvdwege@gmail.com> writes:
>
> > Kind of weird it's not mentioned in the docs though (at least not
> > in
> > the same section as export filters); if you're going to tell people
> > that
> > you can bind local functions to an org file, then it might be nice
> > to
> > point out that you do need to turn that on.
>
> You're right. I think an addition could be proposed in the
> documentation: for example, a footnote in the section `Defining
> filters
> for individual files', since by default the variable
> `org-export-allow-bind-keywords' has value nil.
You're right. I looked up the variable, and there is only one mention
in the docs, and that is about binding emacs variables locally to the
org file buffer.
Can I just clone the repo and prepare a patch?
Regards,
Mart van de Wege
^ permalink raw reply [relevance 6%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 15:58 10% ` Juan Manuel Macías
@ 2021-01-06 16:00 6% ` Mart van de Wege
0 siblings, 0 replies; 200+ results
From: Mart van de Wege @ 2021-01-06 16:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Wed, 2021-01-06 at 16:58 +0100, Juan Manuel Macías wrote:
> Mart van de Wege <mart@vdwege.eu> writes:
> > Can I just clone the repo and prepare a patch?
>
> As far as I know, you can create a diff and propose the patch here in
> the list, opening a new thread, that includes in the mail subject
> something like "[patch] etc"
Nice. I will make some time then this week. Should my mail follow the
guidelines for commit messages?
Regards,
Mart
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-01-03 13:08 5% ` TEC
@ 2021-01-07 18:52 5% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-07 18:52 UTC (permalink / raw)
To: orgmode; +Cc: TEC
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hi,
I am attaching a new version of my patch for adding LaTeX attributes to
verse blocks. Following the kind suggestions from Timothy, I have also
documented this new features that I propose. I don't know if I have done
it correctly and in the right place...
A short reminder: `lines', `versewidth', and `center' require loading
the LaTeX package verse.sty (https://www.ctan.org/pkg/verse), which is
an extension of the standard LaTeX `verse' environment, and that adds
many features for typesetting poetry. `lines' deals with the marginal
verse numbering; `versewidth' and `center' are related to the optical
centering of the poem. The fourth attribute is to include arbitrary
LaTeX code within the verse environment, so I have provisionally named
it `latexcode'.
Of course, Feedback is welcome.
Regards,
Juan Manuel
[-- Attachment #2: verse-block-patch.diff --]
[-- Type: text/x-patch, Size: 5182 bytes --]
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b015b502c..fe21b5aca 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13870,6 +13870,54 @@ The LaTeX export back-end converts horizontal rules by the specified
-----
#+end_example
+*** Verse blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to special blocks.
+:END:
+
+#+cindex: verse blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+
+The LaTeX export back-end accepts four attributes for verse blocks:
+=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
+require the external LaTeX package =verse.sty=, wich is an extension
+of the standard LaTeX environment. The purpose of these attributes is
+explained below.
+
+- =:lines= :: To add marginal verse numbering. Its value is an
+ integer, the sequence in which the verses should be numbered.
+- =:center= :: With value =t= all the verses on the page are optically
+ centered (a typographic convention for poetry), taking as a
+ reference the longest verse, which must be indicated by the
+ attribute =:versewidth=.
+- =:versewidth= :: Its value is a literal text string with the longest
+ verse.
+- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
+ included within a LaTeX =verse= environment.
+
+A complete example with Shakespeare's first sonnet:
+
+#+begin_src org
+,#+ATTR_LaTeX: :center t :latexcode \color{red} :lines 5
+,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
+,#+begin_verse
+From fairest creatures we desire increase,
+That thereby beauty’s rose might never die,
+But as the riper should by time decrease,
+His tender heir mught bear his memeory:
+But thou, contracted to thine own bright eyes,
+Feed’st thy light’st flame with self-substantial fuel,
+Making a famine where abundance lies,
+Thyself thy foe, to thy sweet self too cruel.
+Thou that art now the world’s fresh ornament
+And only herald to the gaudy spring,
+Within thine own bud buriest thy content
+And, tender churl, makest waste in niggarding.
+Pity the world, or else this glutton be,
+To eat the world’s due, by the grave and thee.
+,#+end_verse
+#+end_src
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5e5f1954d..47e0ec40e 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -149,6 +149,19 @@ Example:
A new =u= mode flag for Calc formulas in Org tables has been added to
enable Calc units simplification mode.
+*** LaTeX attributes for verse blocks
+
+The LaTeX export back-end now accepts four attributes for verse
+blocks:
+
+- =:lines=, for marginal verse numbering;
+- =:center= and =:versewidth=, for optical centering of the verses;
+- =:latexcode=, for any arbitrary LaTeX code that can be included
+ within a LaTeX =verse= environment.
+
+The three first require the external LaTeX package =verse.sty=, wich
+is an extension of the standard LaTeX environment.
+
** Miscellaneous
*** =org-goto-first-child= now works before first heading
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index fb9fc3cd6..0931b7e9c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,17 @@ channel."
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
+ (let*
+ ((lin (org-export-read-attribute :attr_latex verse-block :lines))
+ (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if lin "\n\\poemlines{0}" "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3513,19 +3524,20 @@ contextual information."
;; character and change each white space at beginning of a line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
- (format "\\begin{verse}\n%s\\end{verse}"
+ (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ vwidth
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
"^[ \t]*\\\\\\\\$" "\\vspace*{1em}"
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
- contents nil t) nil t) nil t))
+ contents nil t) nil t) nil t) linreset)
info)
;; Insert footnote definitions, if any, after the environment, so
;; the special formatting above is not applied to them.
- (org-latex--delayed-footnotes-definitions verse-block info)))
-
+ (org-latex--delayed-footnotes-definitions verse-block info))))
\f
;;; End-user functions
[-- Attachment #3: Type: text/plain, Size: 1827 bytes --]
TEC <tecosaur@gmail.com> writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Thank you very much for your response and your comments.
>
> Seriously, thanks for the patch. I think the ML is usually a bit more
> responsive, but it seems to be a bit quiet at the moment.
>
>> I agree to name "Insert, include, etc." the attribute to include
>> arbitrary LaTeX code, better than "options".
>
> Glad my feedback seems to have gone down well :). If the only likely use
> of this is adjusting the font, perhaps for the sake of consistency we
> can match the behaviour of tables, which take a :font LaTeX attribute?
>
>> Of course, I can add the necessary documentation to the files you tell
>> me. As I am new to submitting patches, I don't really know how to
>> proceed: do I have to send you the new version of the patch, with the
>> documentation? Should I send a new email with all of it to this list?
>
> Thanks for asking. Sometimes it seems the maintainers take the trouble of
> adding an ORG-NEWS entry or minor touching ups to the patch, but I think
> it's nice to leave as little for them to do as possible :)
>
> Announce changes in: etc/ORG-NEWS
> Document new/different behaviour in: doc/org-manual.org
>
> I think Markup for /Rich Contents > Paragraphs/ may be the right place
> to add a description of this functionality --- verse blocks are
> discussed around line 10750.
>
> Regarding how patches on this ML work, this is what I've observed:
> - Initial version of patch submitted, with justification/explanation
> - Feedback may be given
> - Revisions of the patch are attached in replies to feedback
> - Process repeats until everyone's happy
> - Patch is merged
>
> i.e. it all tends to happen in the same thread.
>
> Hope this helps,
>
> Timothy.
>
^ permalink raw reply related [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
2021-01-08 2:37 5% ` Jason Ross
@ 2021-01-08 3:52 6% ` Jason Ross
2 siblings, 0 replies; 200+ results
From: Jason Ross @ 2021-01-08 3:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
On 12/28/20 5:38 AM, Juan Manuel Macías wrote:
> Hi,
>
> Just out of curiosity, I am wondering if there are plans to create an
> Org to ConTeXt exporter in the future, or if there is already some work
> in progress on this front.
>
> I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> but ConTeXt has very interesting features (grid typesetting, for
> example) that LaTeX lacks (for now) and has a more monolithic structure,
> that is, it does not need to be extended through packages as in LaTeX.
>
> Regards,
>
> Juan Manuel
>
I recently had the same thought and I've started working on one.
You can see it here:
https://github.com/Jason-S-Ross/ox-context/
It's no substitute for the LaTeX exporter but it implements a lot
of the basics. I'm deriving from the LaTeX exporter but I have
to override most of the transcoders so it may be better to start
from scratch.
Disclaimer: I'm learning elisp as I go, so please excuse the
rough edges.
Jason Ross
^ permalink raw reply [relevance 6%]
* Re: Org to ConTeXt exporter?
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
@ 2021-01-08 2:37 5% ` Jason Ross
2021-01-09 17:42 10% ` Juan Manuel Macías
2021-01-08 3:52 6% ` Jason Ross
2 siblings, 1 reply; 200+ results
From: Jason Ross @ 2021-01-08 2:37 UTC (permalink / raw)
To: maciaschain; +Cc: emacs-orgmode
On 2020-12-28, at 14:38, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> Just out of curiosity, I am wondering if there are plans to create an
> Org to ConTeXt exporter in the future, or if there is already some work
> in progress on this front.
>
> I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> but ConTeXt has very interesting features (grid typesetting, for
> example) that LaTeX lacks (for now) and has a more monolithic structure,
> that is, it does not need to be extended through packages as in LaTeX.
I recently had the same thought and I've started working on one.
You can see it here:
https://github.com/Jason-S-Ross/ox-context/
It's no substitute for the LaTeX exporter but it implements a lot
of the basics. I'm deriving from the LaTeX exporter but I have
to override most of the transcoders so it may be better to start
from scratch.
Disclaimer: I'm learning elisp as I go, so please excuse the
rough edges.
Jason Ross
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2021-01-08 2:37 5% ` Jason Ross
@ 2021-01-09 17:42 10% ` Juan Manuel Macías
2021-01-13 1:16 6% ` Jason Ross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-09 17:42 UTC (permalink / raw)
To: Jason Ross; +Cc: orgmode
Hello, Jason,
Jason Ross <jasonross1024@gmail.com> writes:
> I recently had the same thought and I've started working on one.
> You can see it here:
>
> https://github.com/Jason-S-Ross/ox-context/
>
> It's no substitute for the LaTeX exporter but it implements a lot
> of the basics. I'm deriving from the LaTeX exporter but I have
> to override most of the transcoders so it may be better to start
> from scratch.
>
> Disclaimer: I'm learning elisp as I go, so please excuse the
> rough edges.
That's great news! I've been testing it a bit and it works very good. Of
course, I encourage you to keep up this excellent work.
Regards,
Juan Manuel
>
> Jason Ross
>
--
^ permalink raw reply [relevance 10%]
* A minor mode for inserting things while typing
@ 2021-01-12 22:30 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-12 22:30 UTC (permalink / raw)
To: orgmode
Hi,
I've written a 'lazy' minor mode for inserting things while typing
(without leave the comfort zone of the keyboard) especially when you are
at the end of a paragraph and then you want to insert a block, a list, a
table, a footnote, etc. The idea is: you type ",,," plus one character
-> a white line (with org-return) is inserted -> (depending on the
character typed) something is inserted. For example: ",,,h" inserts a
new heading at the same level; ",,,t", a TODO heading; ",,,-", a list;
",,,1", a numbered list; ",,,k", a check box list; ",,,:", a description
list; ",,,s", a source block; ",,,q", a quote block; ",,,|", a table
(calling org-table-create); ",,,f", a footnote. And so on.
It's a way to insert things that I find more comfortable (in certain
scenarios) than using `org-tempo'.
In case it could be useful to someone, I share it in this GitLab
snippet: https://gitlab.com/-/snippets/2060125
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org to ConTeXt exporter?
2021-01-09 17:42 10% ` Juan Manuel Macías
@ 2021-01-13 1:16 6% ` Jason Ross
0 siblings, 0 replies; 200+ results
From: Jason Ross @ 2021-01-13 1:16 UTC (permalink / raw)
To: emacs-orgmode
I'm happy to hear you're able to use it! Any feedback or criticism
is appreciated, and I'd like to know what your output format looks
like if you're able to share.
Thanks,
Jason
On 1/9/21 9:42 AM, Juan Manuel Macías wrote:
> Hello, Jason,
>
> Jason Ross <jasonross1024@gmail.com> writes:
>
>> I recently had the same thought and I've started working on one.
>> You can see it here:
>>
>> https://github.com/Jason-S-Ross/ox-context/
>>
>> It's no substitute for the LaTeX exporter but it implements a lot
>> of the basics. I'm deriving from the LaTeX exporter but I have
>> to override most of the transcoders so it may be better to start
>> from scratch.
>>
>> Disclaimer: I'm learning elisp as I go, so please excuse the
>> rough edges.
>
> That's great news! I've been testing it a bit and it works very good. Of
> course, I encourage you to keep up this excellent work.
>
> Regards,
>
> Juan Manuel
>
>>
>> Jason Ross
>>
>
^ permalink raw reply [relevance 6%]
* Re: Region-based meta-notes
@ 2021-01-19 22:39 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-19 22:39 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: orgmode
Hello,
Lawrence Bottorff <borgauf@gmail.com> writes:
> So yes, simply being able to select regions and make side notes about
> them could give you a very fine level of control over metadata in a
> file. Is there such a thing in the Emacs/org-mode world?
Take a look at the org-marginalia package:
https://github.com/nobiot/org-marginalia
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Dealing with wide labels in description environment
@ 2021-01-22 11:20 9% ` Juan Manuel Macías
2021-01-22 12:37 6% ` Loris Bennett
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-22 11:20 UTC (permalink / raw)
To: Loris Bennett; +Cc: orgmode
Hello,
"Loris Bennett" <loris.bennett@fu-berlin.de> writes:
> I have tried tweaking options such as labelindent and labelwidth in a
> somewhat haphazard manner with, say,
>
> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>
> but most of my attempts seem to have the main effect of just shifting
> the whole list to the right without right-justifying the labels.
The question is more on the side of LaTeX, and the enumitem package
(which you must have loaded for those options. See:
https://www.ctan.org/pkg/enumitem). For the effect you are looking for
you can try this (for horizontal lengths, it is better to use 'em' than
'ex):
#+LATEX_HEADER: \usepackage{enumitem}
#+attr_latex: :options [labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
- short label :: this looks fine
- very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl,
tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam
tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum
accumsan nisl.
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Dealing with wide labels in description environment
2021-01-22 11:20 9% ` Juan Manuel Macías
@ 2021-01-22 12:37 6% ` Loris Bennett
0 siblings, 0 replies; 200+ results
From: Loris Bennett @ 2021-01-22 12:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello,
>
> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>> I have tried tweaking options such as labelindent and labelwidth in a
>> somewhat haphazard manner with, say,
>>
>> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>>
>> but most of my attempts seem to have the main effect of just shifting
>> the whole list to the right without right-justifying the labels.
>
> The question is more on the side of LaTeX, and the enumitem package
> (which you must have loaded for those options. See:
> https://www.ctan.org/pkg/enumitem). For the effect you are looking for
> you can try this (for horizontal lengths, it is better to use 'em' than
> 'ex):
Yes, of course - using Org for a decade so or has helped me avoid and thus
forget about certain LaTeX details.
> #+LATEX_HEADER: \usepackage{enumitem}
>
> #+attr_latex: :options
> [labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
> - short label :: this looks fine
> - very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer adipiscing
> elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl,
> tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
> dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam
> tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum
> accumsan nisl.
Thank, that's what I needed - 'leftmargin' seems to be the main thing
that was missing.
Gruß
Loris
--
This signature is currently under construction.
^ permalink raw reply [relevance 6%]
* [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
@ 2021-01-23 11:03 7% Juan Manuel Macías
2021-01-24 11:37 4% ` Gustavo Barros
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-23 11:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
Hi,
When I export to LaTeX an Org document that contains a bibliography, I
use bibLaTeX with a very custom style (i.e. quite a few lines of code
related to bibLaTeX in the preamble). I wanted to apply all that
bibLaTeX setting and styles when exporting to HTML too, so I came up
with this method, using make4ht. I share it here, in case it is useful
to someone.
The idea is to compile with make4ht (see:
https://www.ctan.org/pkg/make4ht) a simple file with *only* the
bibliography, and "embed" the HTML output in the Org document. You need
to create in the working directory a tex file, which will serve as a
minimal preamble and which also includes all code related to bibLaTeX.
We can name it preamble.tex, and it would start like this:
#+begin_src latex
\documentclass{article}
\usepackage{fontspec}
\usepackage[<whatever-language>]{babel}
\usepackage[backend=biber,style=authortitle,dashed=true,sorting=nyt]{biblatex}
%% more code related to bibLaTeX...
#+end_src
We also need a small lua file that will control the make4ht compilation.
If we run make4ht in draft mode it will not call Biber. This file can be
named build.lua:
#+begin_src lua
if mode=="draft" then
Make:htlatex {}
else
Make:htlatex {}
Make:biber {}
Make:htlatex {}
end
#+end_src
And finally, this function is defined in Elisp, which takes two
arguments: the preamble-file and the *.bib file to generate the list of
references. The optional draft argument is for make4ht to run in draft
mode (that is, so you don't rebuild the bibliography). In the end Pandoc
is executed with shell output to simplify the resulting HTML:
#+begin_src emacs-lisp
(defun my-biblio-html (preamble bib &optional draft)
(when (org-export-derived-backend-p org-export-current-backend 'html)
(let ((file (file-name-sans-extension bib))
(d (if draft
"-m draft "
"")))
(shell-command (concat
"echo \"\\input{"
preamble
"}"
"\\addbibresource{"
bib
"}"
"\\begin{document}
\\nocite{*}
\\printbibliography[heading=none]
\\end{document}\" > "
file "-bib.tex"))
(shell-command-to-string (concat "make4ht -ule build.lua "
d
file
"-bib.tex > /dev/null && "
"pandoc -f html -t html "
file
"-bib.html")))))
#+end_src
An example:
#+begin_src org
,#+HTML_HEAD: <style> dd { text-indent: -2em; margin-left: 2em; } </style>
,#+HTML_HEAD: <style> .rm-lmri-12{ font-style:italic;} </style>
,* References
,#+begin_src emacs-lisp :exports results :results html
(my-biblio-html "preamble.tex" "file.bib")
,#+end_src
#+end_src
As you can see, the method is somewhat tricky, but it works well, for now. I hope that
be useful!
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 7%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-23 11:03 7% [Tip] Export a bibliography to HTML with bibLaTeX and make4ht Juan Manuel Macías
@ 2021-01-24 11:37 4% ` Gustavo Barros
0 siblings, 1 reply; 200+ results
From: Gustavo Barros @ 2021-01-24 11:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
that's very interesting. Thanks for sharing.
On Sat, 23 Jan 2021 at 12:03, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> When I export to LaTeX an Org document that contains a bibliography, I
> use bibLaTeX with a very custom style (i.e. quite a few lines of code
> related to bibLaTeX in the preamble). I wanted to apply all that
> bibLaTeX setting and styles when exporting to HTML too, so I came up
> with this method, using make4ht. I share it here, in case it is useful
> to someone.
>
> The idea is to compile with make4ht (see:
> https://www.ctan.org/pkg/make4ht) a simple file with *only* the
> bibliography, and "embed" the HTML output in the Org document. You need
> to create in the working directory a tex file, which will serve as a
> minimal preamble and which also includes all code related to bibLaTeX.
> We can name it preamble.tex, and it would start like this:
Indeed, when one actually needs biblatex-biber to process their
bibliography, using Org is really hard. I have some history with this
problem, as I initially approached Emacs (once upon a time) trying to
use Org as a single source and multiple outputs (mainly pdf and odt).
However, as you, I rely on heavily customized styles, which simply won't
work with pandoc/CSL, so I got stuck. I eventually stayed in Emacs and
use Org for a number of things, but for my more formal writing use
AUCTeX + RefTeX, which is great too (alas, no odt..., at least not
easily).
For a long time I fancied trying something about it, pretty much in the
same lines as you are doing here. My idea was to use `preview-latex'
for this, which I still think is promising and, as far as I understand,
pretty much automates what you are doing, which is to generate a
stripped document, with a proper preamble, and run it on a piece of your
actual document. It is used by AUCTeX and LyX (Org too, I presume) to
generate images, but I don't see why it could not be streamlined to
generate a dvi which could then be fed to tex4ht and friends, just as
you do too. I thought that this procedure could, in principle, be used
to export to other formats, but also to Org itself, generating either a
second version of the source document with the citations and
bibliography already processed as text (sort of a
'org-biblatex-citeproc'), or as a preview, such as the ones for math.
Depending on how far you are willing to take your setup, this might be
one path. It should handle two limitations of your procedure, which
are: getting the bibliography with the entries actually cited in the
document and citation callouts. The first one is easy to handle in your
current approach by means of any of the multiple alternatives to
generate a bib file with only the cited entries. The second one, much
harder, as far as I can see.
To my dismay, my own style customizations for biblatex are mainly aimed
at citations (primary/archival sources for Economic History). But it
was quite interesting to see your approach here. So, again, thank you.
Best,
Gustavo.
^ permalink raw reply [relevance 4%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
@ 2021-01-24 19:20 6% ` Juan Manuel Macías
2021-01-24 22:44 4% ` Gustavo Barros
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-24 19:20 UTC (permalink / raw)
To: Gustavo Barros; +Cc: orgmode
Hi Gustavo,
Thank you for your interesting comments.
Gustavo Barros <gusbrs.2016@gmail.com> writes:
> On Sun, 24 Jan 2021 at 08:37, Gustavo Barros <gusbrs.2016@gmail.com>
> wrote:
>
>> It should handle two limitations of your procedure, which
>> are: getting the bibliography with the entries actually cited in the
>> document and citation callouts. The first one is easy to handle in
>> your
>> current approach by means of any of the multiple alternatives to
>> generate a bib file with only the cited entries. The second one, much
>> harder, as far as I can see.
>
> Thinking this through: there is actually a third challenge to the
> approach, which is ensuring the relation of the citation callouts and
> the bibliography is correct. For example, if using a numeric or alpha
> style, how to be sure the labels are the same in the citation and the
> bibliography. Even in other styles, such as author-year, if
> disambiguation rules come into play (e.g. (Smith 1987a, Smith 1987b)),
> how to be sure the same rules are being applied by pandoc/CSL (on the
> citations) and biblatex (in the bibliography). As far as I can tell,
> this will hang on sorting, something which biblatex is known to be
> more capable than other tools, so that I would expect differences (at
> least potentially). Styles such as verbose or author-title would
> probably be safe, I guess. Have you given some thought about this?
> If so, how are you handling the case?
>
I agree with what you comment here and in your previous message. In
fact, I'm afraid this (humble) approach of mine is focused only on
creating a mere list of references in HTML from a bib file, keeping the
same bibliography styles that I have customized in bibLaTeX, but not on
everything related to citations throughout the text and on the
consistency between citations and bibliographies. I would say that my
method is not a good starting point to implement a solution. The
essential problem, of course, is that our customization is LaTeXcentric:
it resides in LaTeX/bibLaTeX and not in Org.
In my case, anyway, I had been using the TeX ecosystem almost
exclusively for my work in typesetting and editorial design (I do not
use DTP software, which is not intended to create books but magazines
and newspapers), and Org Mode for writing and notes. But in recent years
I have come to realize that a workflow based also on Org and Org-Publish
is tremendously productive for me to manage the typesetting of a book,
especially a complex book. Let's say now I also use Org as a high-level
interface for LaTeX. I'm currently working on the /Hispanic Dictionary
of Classical Tradition/ (/Diccionario Hispánico de la Tradición
Clásica/), a volume of multiple authorship and about 1200 pages. The
method I raised in this thread has to do with this scenario, where each
dictionary entry is accompanied by a bibliography. As the dictionary
will have an online secondary version, I wanted to keep the same
bibliography style that I had defined for bibLaTeX. I have not had the
problem of the citations here, since the entries do not contain
citations (bibliographies only). Otherwise, I think an emergency
solution could be to export from Org to *.tex, and then generate the
HTML from there using make4ht and another preamble /ad hoc/, better than
using a mixed csl/bibLaTeX method which, as you say, can result in many
inconsistencies.
Long ago I tended to be more in favor of the idea that a single
source-text should produce multiple identical or interchangeable
formats. I really still believe it with enthusiasm and I have not
completely lost faith in such a utopia ;-) But nuances are necessary and
it must be accepted that each format has its idiosyncrasies and
limitations. For example, TeX and what TeX produces is at a level (let's
say) higher than what can be achieved through HTML/CSS, odt, epub... It
is not only a question of typographic refinement or fancy appearance
(typical of TeX), but also (in my opinion) of the book typography itself as a
form of expression. The other formats will often lag behind TeX, and
this must be taken into account when exporting, pros and cons, etc. On
the other hand, bibLaTeX is powerful and highly customizable, but sadly
depends on LaTeX...
Regards,
Juan Manuel
> Best,
> Gustavo.
>
^ permalink raw reply [relevance 6%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-24 19:20 6% ` Juan Manuel Macías
@ 2021-01-24 22:44 4% ` Gustavo Barros
2021-01-25 17:46 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Gustavo Barros @ 2021-01-24 22:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On Sun, 24 Jan 2021 at 16:20, Juan Manuel Macías
<maciaschain@posteo.net> wrote:
> I agree with what you comment here and in your previous message. In
> fact, I'm afraid this (humble) approach of mine is focused only on
> creating a mere list of references in HTML from a bib file, keeping
> the
> same bibliography styles that I have customized in bibLaTeX, but not
> on
> everything related to citations throughout the text and on the
> consistency between citations and bibliographies. I would say that my
> method is not a good starting point to implement a solution. [...]
>
> In my case, anyway, I had been using the TeX ecosystem almost
> exclusively for my work in typesetting and editorial design (I do not
> use DTP software, which is not intended to create books but magazines
> and newspapers), and Org Mode for writing and notes. But in recent
> years
> I have come to realize that a workflow based also on Org and
> Org-Publish
> is tremendously productive for me to manage the typesetting of a book,
> especially a complex book. Let's say now I also use Org as a
> high-level
> interface for LaTeX. I'm currently working on the /Hispanic Dictionary
> of Classical Tradition/ (/Diccionario Hispánico de la Tradición
> Clásica/), a volume of multiple authorship and about 1200 pages. The
> method I raised in this thread has to do with this scenario, where
> each
> dictionary entry is accompanied by a bibliography. As the dictionary
> will have an online secondary version, I wanted to keep the same
> bibliography style that I had defined for bibLaTeX. I have not had the
> problem of the citations here, since the entries do not contain
> citations (bibliographies only). Otherwise, I think an emergency
> solution could be to export from Org to *.tex, and then generate the
> HTML from there using make4ht and another preamble /ad hoc/, better
> than
> using a mixed csl/bibLaTeX method which, as you say, can result in
> many
> inconsistencies.
Well, I think your approach should work quite well for your use case,
and certainly a number of others. It is just a matter of being aware of
the limitations of the tool. That given, it is great. Of course, I was
also curious how you had figured things from a more general perspective.
> The
> essential problem, of course, is that our customization is
> LaTeXcentric:
> it resides in LaTeX/bibLaTeX and not in Org. [...]
>
I think it is more than just being "LaTeXcentric". Depending on
requirements, there is really no choice. We don't hear this often, but
the fact is that Org does not support citation and bibliography by
itself. A lot of things "work", and in many requirements scenarios that
seems to be enough, but what does work relies on outsourcing that task
to other tools. As far as I know, there are only two ways out of an Org
document with citation and bibliography: LaTeX (and its related tools:
bibtex, biblatex, biber, etc), and pandoc (which uses CSL to process
these features). The first option is extremely featureful, but
restricts us to .pdf output. The only sufficiently general option with
multi output is then pandoc, which in turn bypasses the whole Org export
infrastructure, implying its own trade-offs because of that. Besides,
there is no real link between the LaTeX infrastructure and pandoc/CSL,
so that if you want to reach "best results in LaTeX, and acceptable
results in other formats", you are bound to live with differences in
output for citation/references across formats and to remain under the
restrictions of the least featureful backend.
> Long ago I tended to be more in favor of the idea that a single
> source-text should produce multiple identical or interchangeable
> formats. I really still believe it with enthusiasm and I have not
> completely lost faith in such a utopia ;-)
I'd also would love to see that. ;-)
And I do think Org is, by far, the best placed tool to fill this place.
But I also think citations and bibliography are a big bottleneck in that
regard. Of course, there is a long ongoing effort in that area, in the
`wip-cite' branch, and the related `org-citeproc' package. I'm still in
the hope this will get merged in future not too distant, as it would
change things in that regard. Not in the sense of "magically solving
all of these problems", but in providing a convened base upon which
people can than invest their time and effort, and try to figure each
case out, with time.
Best regards,
Gustavo.
^ permalink raw reply [relevance 4%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-24 22:44 4% ` Gustavo Barros
@ 2021-01-25 17:46 9% ` Juan Manuel Macías
2021-01-25 18:30 5% ` Gustavo Barros
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-25 17:46 UTC (permalink / raw)
To: Gustavo Barros; +Cc: orgmode
Hi Gustavo,
Gustavo Barros <gusbrs.2016@gmail.com> writes:
> I'd also would love to see that. ;-)
>
> And I do think Org is, by far, the best placed tool to fill this
> place. But I also think citations and bibliography are a big
> bottleneck in that regard. Of course, there is a long ongoing effort
> in that area, in the `wip-cite' branch, and the related `org-citeproc'
> package. I'm still in the hope this will get merged in future not too
> distant, as it would change things in that regard. Not in the sense
> of "magically solving all of these problems", but in providing a
> convened base upon which people can than invest their time and effort,
> and try to figure each case out, with time.
I totally agree.
By the way... I have written some code to export the citations using
make4ht. It's just a proof of concept, and not too elegant I'm afraid.
But I wanted to explore a bit more the use of make4ht in this context.
The idea is to write the citations in Org as mere bibLaTeX commands, but
between !!- ... -!! (a provisional regexp, for convenience, and to see
if it works). It can be tested in this Org file, which includes the code
(you have to give a value to the variables `bib' and `preamble'):
https://gitlab.com/-/snippets/2066135
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-25 17:46 9% ` Juan Manuel Macías
@ 2021-01-25 18:30 5% ` Gustavo Barros
0 siblings, 0 replies; 200+ results
From: Gustavo Barros @ 2021-01-25 18:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On Mon, 25 Jan 2021 at 14:46, Juan Manuel Macías
<maciaschain@posteo.net> wrote:
>
> By the way... I have written some code to export the citations using
> make4ht. It's just a proof of concept, and not too elegant I'm afraid.
> But I wanted to explore a bit more the use of make4ht in this context.
>
Nice! I also think make4ht has potential for this
purpose. tex4ht/make4ht is usually a somewhat delicate tool for a
general LaTeX document (powerful, but complex), but the typical output
of citation and bibliography is text with emphasis/bold etc, and perhaps
a list, if we interpret the bibliography environment strictly. This is
much simpler (again, typically) than an arbitrary document, to the point
I believe it could be streamlined reliably for this subset of the
document.
> The idea is to write the citations in Org as mere bibLaTeX commands,
> but
> between !!- ... -!! (a provisional regexp, for convenience, and to see
> if it works). It can be tested in this Org file, which includes the
> code
> (you have to give a value to the variables `bib' and `preamble'):
>
> https://gitlab.com/-/snippets/2066135
>
I understand using the regexp to separate the problems, provisionally,
as you said. If it evolves, you might wish to go with the current state
of things in the wip-cite branch or, I reiterate the suggestion, look at
latex-preview, which allows you to specify the commands of interest, if
I recall correctly.
I hope you find your way trough the approach. If you do, please let me
know. Or, if you wish to discuss a particular issue, feel free to write
me directly.
Best regards,
Gustavo.
^ permalink raw reply [relevance 5%]
* org-attach-git don't automatically commit changes
@ 2021-01-29 16:03 9% Juan Manuel Macías
2021-01-30 5:10 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-29 16:03 UTC (permalink / raw)
To: orgmode
Hi,
I don't know if this is a bug or if I am doing something wrong...
According to the manual:
#+begin_quote
If the directory attached to an outline node is a Git
repository, Org can be configured to automatically commit changes to
that repository when it sees them.
To make Org mode take care of versioning of attachments for you, add the
following to your Emacs config:
(require 'org-attach-git)
#+end_quote
I don't see that org-attach "automatically commit changes when it sees
them". Only when I run in the attached directory `M-:
(org-attach-git-commit) RET' it works fine.
`org-attach-after-change-hook' is set to `(org-attach-git-commit)'.
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
2021-01-29 16:03 9% org-attach-git don't automatically commit changes Juan Manuel Macías
@ 2021-01-30 5:10 6% ` Ihor Radchenko
2021-01-30 13:38 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-01-30 5:10 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I don't see that org-attach "automatically commit changes when it sees
> them". Only when I run in the attached directory `M-:
> (org-attach-git-commit) RET' it works fine.
Note that org "sees" changes in the attachment dir only when you use
M-x org-attach command to manage the attachments. Directly changing the
attachment directory will not be noticed. You can force org-mode to
check for changes in attachment dir by running "C-c C-a z".
I guess using something like inotify might be a good new feature to
make org detect changes automatically.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: org-attach-git don't automatically commit changes
2021-01-30 5:10 6% ` Ihor Radchenko
@ 2021-01-30 13:38 9% ` Juan Manuel Macías
2021-01-31 3:33 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-30 13:38 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Note that org "sees" changes in the attachment dir only when you use
> M-x org-attach command to manage the attachments. Directly changing the
> attachment directory will not be noticed. You can force org-mode to
> check for changes in attachment dir by running "C-c C-a z".
Thanks for the explanation. It seems that I had misinterpreted
what the manual said :-)
Anyway, in my case, it still doesn't work (?). I think it's for a path
problem. In `org-attach-git-commit' there is this variable:
#+begin_src emacs-lisp
;; ...
(let* ((dir (expand-file-name org-attach-id-dir))
;; ...
#+end_src
The default value of `org-attach-id-dir' is "data/", and if I evaluate
`(expand-file-name org-attach-id-dir)' on my current node, it returns a
wrong path to the attached folder. `org-attach-sync' only works for me
if I set in `org-attach-git-commit' the variable like this:
#+begin_src emacs-lisp
;; ...
(let* ((dir (org-attach-dir)) ;; <====
;; ...
#+end_src
In that case, it does recognize the path correctly. Again, I don't
know if I'm missing something...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
2021-01-30 13:38 9% ` Juan Manuel Macías
@ 2021-01-31 3:33 5% ` Ihor Radchenko
2021-01-31 10:29 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-01-31 3:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The default value of `org-attach-id-dir' is "data/", and if I evaluate
> `(expand-file-name org-attach-id-dir)' on my current node, it returns a
> wrong path to the attached folder. `org-attach-sync' only works for me
> if I set in `org-attach-git-commit' the variable like this:
Does it mean that your attachment folder is set in :DIR: property?
> #+begin_src emacs-lisp
> ;; ...
> (let* ((dir (expand-file-name org-attach-id-dir))
> ;; ...
> #+end_src
I suspect that it is a leftover from the major changes in org-attach
when :DIR: property was introduced. The org-attach-git presumes that all
the attachments in current file are stored in sub-directories located
inside org-attach-id-dir, which is no longer guaranteed. In fact, the
existing approach to treat all the attachments to all headings in
current file as files in a single git repo cannot be used. I can see two
possible fixes:
1. Treat each attachment dir as individual git repo (breaking change for
those who are using :ID: property to build the attachment dirs)
2. Treat attachment dirs defined by :DIR: property individually and
leave the :ID:-defined attachments as they were treated before
(inconsistent).
I am in favour of the first approach since I do not like the idea of
keeping all the attachments in the whole file in a single git repo.
I think feedback from other is needed to decide what we need to do here.
P.S. Marking this as a bug.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 3:33 5% ` Ihor Radchenko
@ 2021-01-31 10:29 9% ` Juan Manuel Macías
2021-01-31 10:52 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-31 10:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Does it mean that your attachment folder is set in :DIR: property?
No, my attachment folder is build using :ID: property. For example, in
my heading:
* Test
:PROPERTIES:
:ID: d0e690e2-2ecd-4224-891a-b91257db5389
:END:
And if I evaluate `org-attach-dir' here, it returns the correct path:
#+begin_src emacs-lisp
(org-attach-dir)
#+end_src
#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/d0/e690e2-2ecd-4224-891a-b91257db5389
But if I evaluate this, I get an 'incomplete' path:
#+begin_src emacs-lisp
(expand-file-name org-attach-id-dir)
#+end_src
#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/
So if I replace `(expand-file-name org-attach-id-dir)' with
`(org-attach-dir)' in `(org-attach-git-commit)' [line 7, the `dir'
variable], it works fine when I run 'C-c C-a z'.
Best regards
Juan Manuel
>
> I suspect that it is a leftover from the major changes in org-attach
> when :DIR: property was introduced. The org-attach-git presumes that all
> the attachments in current file are stored in sub-directories located
> inside org-attach-id-dir, which is no longer guaranteed. In fact, the
> existing approach to treat all the attachments to all headings in
> current file as files in a single git repo cannot be used. I can see two
> possible fixes:
> 1. Treat each attachment dir as individual git repo (breaking change for
> those who are using :ID: property to build the attachment dirs)
> 2. Treat attachment dirs defined by :DIR: property individually and
> leave the :ID:-defined attachments as they were treated before
> (inconsistent).
>
> I am in favour of the first approach since I do not like the idea of
> keeping all the attachments in the whole file in a single git repo.
> I think feedback from other is needed to decide what we need to do here.
>
> P.S. Marking this as a bug.
>
> Best,
> Ihor
>
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 10:29 9% ` Juan Manuel Macías
@ 2021-01-31 10:52 5% ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 10% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2021-01-31 10:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> But if I evaluate this, I get an 'incomplete' path:
I think you misunderstood how org-attach-git works.
org-attach-git is:
;; An extension to org-attach. If `org-attach-id-dir' is initialized
;; as a Git repository, then org-attach-git will automatically commit
;; changes when it sees them. Requires git-annex.
So, it is not designed to work when your actual attachment directory is
a git repo, but rather when org-attach-id-dir is a git repo (initialised
manually).
The other thing is that `org-attach-id-dir' makes much less sense from
the time :DIR: property was introduced. So, I believe that
org-attach-git should be updated. Probably, handling attachment dirs as
individual git repos can be one of the ways to upgrade the current
version. I guess, patches welcome.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 10:52 5% ` Ihor Radchenko
@ 2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-31 11:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> I think you misunderstood how org-attach-git works.
>
> org-attach-git is:
>
> ;; An extension to org-attach. If `org-attach-id-dir' is initialized
> ;; as a Git repository, then org-attach-git will automatically commit
> ;; changes when it sees them. Requires git-annex.
>
> So, it is not designed to work when your actual attachment directory is
> a git repo, but rather when org-attach-id-dir is a git repo (initialised
> manually).
Thanks for the explanation: it is clear that I had misinterpreted
`org-attach-id-dir'. Now it makes sense that it didn't work for me.
Anyway, I think the manual at that point is somewhat ambiguous and it
should be more precise, IMHO.
> So, I believe that org-attach-git should be updated. Probably,
> handling attachment dirs as individual git repos can be one of the
> ways to upgrade the current version.
I agree, I think this possibility makes a lot more sense.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 10:52 5% ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
@ 2021-01-31 13:16 10% ` Juan Manuel Macías
2021-01-31 13:40 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-01-31 13:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> The other thing is that `org-attach-id-dir' makes much less sense from
> the time :DIR: property was introduced. So, I believe that
> org-attach-git should be updated. Probably, handling attachment dirs as
> individual git repos can be one of the ways to upgrade the current
> version. I guess, patches welcome.
Do you think a possible patch could simply consist of replacing (as I
have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
in `org-attach-git-commit'? This would allow you to handle attachment
dirs as individual git repos, regardless of :ID: or :DIR: properties,
since "[(org-attach-dir)] Return the directory associated with the
current outline node. First check for DIR property, then ID property
[...]".
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 13:16 10% ` Juan Manuel Macías
@ 2021-01-31 13:40 5% ` Ihor Radchenko
2021-01-31 14:36 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-01-31 13:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Do you think a possible patch could simply consist of replacing (as I
> have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
> in `org-attach-git-commit'? This would allow you to handle attachment
> dirs as individual git repos, regardless of :ID: or :DIR: properties,
> since "[(org-attach-dir)] Return the directory associated with the
> current outline node. First check for DIR property, then ID property
> [...]".
All the instances of (expand-file-name org-attach-id-dir) should be
replaced. There are 3. That's not a big deal.
What is more tricky is making sure that workflow for people using the
old behaviour is not broken. Just changing to (org-attach-dir) will
break existing git repos in org-attach-id-dir. This should also not be
too hard (say, we can introduce a custom variable defaulting to old
behaviour), but exact details may need to be discussed.
In any case, if you provide a patch, it will encourage the org
maintainers to join this discussion and proceed with changes.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 13:40 5% ` Ihor Radchenko
@ 2021-01-31 14:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-31 14:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> What is more tricky is making sure that workflow for people using the
> old behaviour is not broken. Just changing to (org-attach-dir) will
> break existing git repos in org-attach-id-dir. This should also not be
> too hard (say, we can introduce a custom variable defaulting to old
> behaviour), but exact details may need to be discussed.
I agree: I think a custom variable with the current behavior by default
would be fine.
> In any case, if you provide a patch, it will encourage the org
> maintainers to join this discussion and proceed with changes.
OK, this week I will try to propose a patch here, and bring it up for
(possible) discussion. Thanks for the suggestions.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [patch] to allow org-attach-git to handle individual repositories
@ 2021-01-31 19:37 6% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-01-31 19:37 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
Hi,
I would like to propose and discuss this patch for org-attach-git,
following a series of comments and suggestions from Ihor Radchenko in
this thread:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html
This patch would allow org-attach-git to handle individual repositories,
that is, any repository initialized in a directory attached to a node.
A custom variable is provided, that admits two values:
1. default: the default value, which is equivalent to the old behavior
2. individual-repository: which activates the 'new' feature.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-attach-git-individual-repositories.patch --]
[-- Type: text/x-patch, Size: 2664 bytes --]
diff --git a/lisp/org-attach-git.el b/lisp/org-attach-git.el
index 2091cbc61..54df5b9ba 100644
--- a/lisp/org-attach-git.el
+++ b/lisp/org-attach-git.el
@@ -52,9 +52,26 @@ If \\='ask, prompt using `y-or-n-p'. If t, always get. If nil, never get."
(const :tag "always get from annex if necessary" t)
(const :tag "never get from annex" nil)))
+(defcustom org-attach-git-dir 'default
+ "The attachment directory where a Git repository must be
+handled. The default value is `default', which is equivalent to
+`org-attach-id-dir'. If the value is `individual-repository', it
+means that the directory attached to the current node should be
+handled as a individual repository, as long as it has been
+conveniently initialized."
+ :group 'org-attach
+ :package-version '(Org . "9.0")
+ :version "26.1"
+ :type '(choice
+ (const :tag "Default" default)
+ (const :tag "Individual repository" individual-repository)))
+
(defun org-attach-git-use-annex ()
"Return non-nil if git annex can be used."
- (let ((git-dir (vc-git-root (expand-file-name org-attach-id-dir))))
+ (let ((git-dir (vc-git-root (cond ((eq org-attach-git-dir 'default)
+ (expand-file-name org-attach-id-dir))
+ ((eq org-attach-git-dir 'individual-repository)
+ (org-attach-dir))))))
(and org-attach-git-annex-cutoff
(or (file-exists-p (expand-file-name "annex" git-dir))
(file-exists-p (expand-file-name ".git/annex" git-dir))))))
@@ -62,7 +79,10 @@ If \\='ask, prompt using `y-or-n-p'. If t, always get. If nil, never get."
(defun org-attach-git-annex-get-maybe (path)
"Call git annex get PATH (via shell) if using git annex.
Signals an error if the file content is not available and it was not retrieved."
- (let* ((default-directory (expand-file-name org-attach-id-dir))
+ (let* ((default-directory (cond ((eq org-attach-git-dir 'default)
+ (expand-file-name org-attach-id-dir))
+ ((eq org-attach-git-dir 'individual-repository)
+ (org-attach-dir))))
(path-relative (file-relative-name path)))
(when (and (org-attach-git-use-annex)
(not
@@ -86,7 +106,10 @@ This checks for the existence of a \".git\" directory in that directory.
Takes an unused optional argument for the sake of being compatible
with hook `org-attach-after-change-hook'."
- (let* ((dir (expand-file-name org-attach-id-dir))
+ (let* ((dir (cond ((eq org-attach-git-dir 'default)
+ (expand-file-name org-attach-id-dir))
+ ((eq org-attach-git-dir 'individual-repository)
+ (org-attach-dir))))
(git-dir (vc-git-root dir))
(use-annex (org-attach-git-use-annex))
(changes 0))
^ permalink raw reply related [relevance 6%]
* Re: http links translated to html : target "_blank"
@ 2021-02-01 11:03 9% ` Juan Manuel Macías
2021-02-01 13:56 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-01 11:03 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
I think the problem is how the exporter understands the url string.
Note that this:
@@html:<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>@@
[[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
is exported like this:
<p>
<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>
</p>
<p>
<a href="https://www.mpic.de/4747361/risk-calculator%20target=%22_blank%22">Simulador de riesgo con más detalle</a>
</p>
The second link is wrong formatted. A dirty solution could be:
#+BIND: org-export-filter-final-output-functions (correct-target-blank)
#+begin_src emacs-lisp :exports results :results none
(defun correct-target-blank (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
#+end_src
Best regards,
Juan Manuel
Uwe Brauer <oub@mat.ucm.es> writes:
> Hi
>
> I need to produce a html file, with links opening new tabs (pages) as in
>
> <a href="https://apps.apple.com/es/app/radar-covid/id1520443509" target="_blank">Descarga Directa</a>
>
> However
>
> [[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
>
> Did not work
>
> Any ideas?
>
> Thanks and regards
>
> Uwe Brauer
>
>
^ permalink raw reply [relevance 9%]
* Re: http links translated to html : target "_blank"
2021-02-01 11:03 9% ` Juan Manuel Macías
@ 2021-02-01 13:56 1% ` Uwe Brauer
2021-02-01 14:46 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2021-02-01 13:56 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hola Juan
> I think the problem is how the exporter understands the url string.
> Note that this:
> @@html:<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>@@
> [[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
> is exported like this:
> <p>
> <a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>
> </p>
> <p>
> <a href="https://www.mpic.de/4747361/risk-calculator%20target=%22_blank%22">Simulador de riesgo con más detalle</a>
> </p>
> The second link is wrong formatted. A dirty solution could be:
> #+BIND: org-export-filter-final-output-functions (correct-target-blank)
> #+begin_src emacs-lisp :exports results :results none
> (defun correct-target-blank (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
> #+end_src
> Best regards,
Thanks that works, but not for link in a list. The only solution
seems to be this one
#+attr_html: :target _blank
[[https://www.zeit.de/wissen/gesundheit/2020-11/coronavirus-aerosols-infection-risk-hotspot-interiors][Risk simulator]]
#+attr_html: :target _blank
[[https://www.mpic.de/4747361/risk-calculator][Risk simulator with more details]]
1. RocketBook
+ Book A4
#+attr_html: :target _blank
[[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1][Book A4]]
a. Book A4
#+attr_html: :target _blank
[[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1][Book A4]]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: http links translated to html : target "_blank"
2021-02-01 13:56 1% ` Uwe Brauer
@ 2021-02-01 14:46 8% ` Juan Manuel Macías
2021-02-01 15:20 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-01 14:46 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer <oub@mat.ucm.es> writes:
> Thanks that works, but not for link in a list. The only solution
> seems to be this one
Doesn't it work for you in a list? I think it should work also in a
list. If I export this:
#+begin_src org
,#+BIND: org-export-filter-final-output-functions (correct-target-blank)
,#+begin_src emacs-lisp :exports results :results none
(defun correct-target-blank (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
,#+end_src
+ [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
+ [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
#+end_src
I get this:
#+begin_src html
<ul class="org-ul">
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1" target="_blank">Book A4</a></li>
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1" target="_blank">Book A4</a></li>
</ul>
#+end_src
Using `#+attr_html:' is a simpler and cleaner solution, of course, but I think that
would not work with links within a paragraph.
Best regards / saludos,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: http links translated to html : target "_blank"
2021-02-01 14:46 8% ` Juan Manuel Macías
@ 2021-02-01 15:20 0% ` Uwe Brauer
2021-02-01 21:01 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2021-02-01 15:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Uwe,
> Uwe Brauer <oub@mat.ucm.es> writes:
>> Thanks that works, but not for link in a list. The only solution
>> seems to be this one
> Doesn't it work for you in a list? I think it should work also in a
> list. If I export this:
> #+begin_src org
> ,#+BIND: org-export-filter-final-output-functions (correct-target-blank)
> ,#+begin_src emacs-lisp :exports results :results none
> (defun correct-target-blank (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
> ,#+end_src
> + [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
> + [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
> #+end_src
> I get this:
That is odd (maybe my org version is a bit rusty (master june 2020)
I obtain this:
<ul class="org-ul">
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1%20target=%22_blank%22">Book A4</a></li>
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1%20target=%22_blank%22">Book A4</a></li>
</ul>
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: http links translated to html : target "_blank"
2021-02-01 15:20 0% ` Uwe Brauer
@ 2021-02-01 21:01 10% ` Juan Manuel Macías
2021-02-04 14:07 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-01 21:01 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer <oub@mat.ucm.es> writes:
> That is odd (maybe my org version is a bit rusty (master june 2020)
It's strange...
It should work fine for you (as long as you set
`org-export-allow-bind-keywords' as non-nil)
You can also try `org-export-filter-link-functions' instead of
`...-final-output-functions'.
Anyway, if the `#+attr_latex' solution works for you, then all is fine.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: word counts and org-mode drawers
@ 2021-02-01 23:29 10% ` Juan Manuel Macías
2021-02-04 13:50 1% ` Sharon Kimble
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-01 23:29 UTC (permalink / raw)
To: Sharon Kimble; +Cc: orgmode
Hi,
Sharon Kimble <boudiccas@skimble.plus.com> writes:
> How can I exempt an org-mode drawer, and its contents, from word counts
> please. I am using 'wc-mode' but I can't see how to do it.
It is not a solution with wc-mode, but maybe this simple function, based on
`count-words', can serve you. It counts the words in the buffer
excluding all drawers and their contents:
#+begin_src emacs-lisp
(defun my-count-words-in-org-buffer ()
(interactive)
(let ((words 0))
(save-excursion
(save-restriction
(narrow-to-region (point-min) (point-max))
(goto-char (point-min))
(while (forward-word-strictly 1)
(if (org-at-drawer-p)
(re-search-forward ":END:")
(setq words (1+ words))))))
(message "Org buffer has %d word%s."
words (if (= words 1) "" "s"))))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: emphasizing source code words
@ 2021-02-04 12:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-04 12:13 UTC (permalink / raw)
To: Luca Ferrari; +Cc: orgmode
Hi Luca
Luca Ferrari <fluca1978@gmail.com> writes:
> Thanks, but stil Im not able to figure it out. I've searched thru the
> org documentation without any luck.
>
> Luca
To use the minted package as backend (https://www.ctan.org/pkg/minted),
I have in my Emacs:
(setq org-latex-listings 'minted)
(setq org-latex-minted-options
'(("frame" "lines") ("linenos=true") ("breaklines")))
You also need to install the Python pigments library on your OS. In
Arch (in my case) is the python-pygments package.
And you have to make sure that when you export to LaTeX it always compiles
with the -shell-escape option. For example:
(setq org-latex-pdf-process
'("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"))
Lastly, in Org docs you need of course to load the minted package:
#+LaTeX_HEADER: \usepackage{minted}
You can see how the highlighting looks like in this post from my blog (in
Spanish): under the title there is a button to download the entry in PDF
version: https://lunotipia.juanmanuelmacias.com/evitar_funcion_lua.html
Finally, you may be interested in this new package that TEC has written:
https://www.reddit.com/r/emacs/comments/lbkmmz/the_best_syntax_highlighting_in_a_pdf_youll_see_a/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: word counts and org-mode drawers
2021-02-01 23:29 10% ` Juan Manuel Macías
@ 2021-02-04 13:50 1% ` Sharon Kimble
0 siblings, 0 replies; 200+ results
From: Sharon Kimble @ 2021-02-04 13:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Juan.
Thanks very much for this code, it fits my purpose very well, thanks
again.
Thanks
Sharon.
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
> Hi,
>
> Sharon Kimble <boudiccas@skimble.plus.com> writes:
>
>> How can I exempt an org-mode drawer, and its contents, from word counts
>> please. I am using 'wc-mode' but I can't see how to do it.
>
> #+begin_src emacs-lisp
> (defun my-count-words-in-org-buffer ()
> (interactive)
> (let ((words 0))
> (save-excursion
> (save-restriction
> (narrow-to-region (point-min) (point-max))
> (goto-char (point-min))
> (while (forward-word-strictly 1)
> (if (org-at-drawer-p)
> (re-search-forward ":END:")
> (setq words (1+ words))))))
> (message "Org buffer has %d word%s."
> words (if (= words 1) "" "s"))))
> #+end_src
>
> Juan Manuel
>
- --
Debian 10.7, fluxbox 1.3.7, emacs 27.1.50, org 9.4.4
-----BEGIN PGP SIGNATURE-----
iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmAb+6sbHGJvdWRpY2Nh
c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbKfcP/i/rVfnnXUSViX7dD2Rm
Gu2+mvzfwv+lzyRMUsbZoEMi2hYDQ/5CkBChFVtgrG84KqF9+wmxjikCG9q2hL0b
BMYrZ60XNfwMsJ1nd7Q/CHypPgr7//cn6r89B29w2ez0/noWID9OiTDS+dfJFoQQ
8MFv32TeLQtlYiONsiO0Z38iqkyQDGn5aSOtQjMjIxOJ5fiAVAsO/GBiwrNunwbN
yeCrOJQhiooZB/dOQgYwZkd9yDOQ3C/jPfRflLxIBGWUJ3EgCuFqBCuKin+JBnhJ
JUghkoX1BSDfs72QDq5yyzezHTgDnq0IdKBdqz0GVrMH6tkHFxfLDdUbxJgY2KcF
uW/GX17A23EXLT11MhI0C+W3VnG68HWvqZc/x4kY0SKy9pxUbXy9y2BGJFdGl+no
CPMyEn3tA+E8klDVDWe6DSJj2JUxarAT0gaizs7KOJpHCDeHja2i+rN1S0eLZ+t8
PmY32zYHoe5w8yzdwm43V3+mZp6kvusK6SODNalRCIykqPrCeeYMmzolfwXpi6qW
va5g4OigBHmY165SfVdLr8iGzi96VqLlTWkzBN3bCiu9F/fJGqUiPdgDEAR8A2f0
/nFaEbYBNq4h1I8OMAMNhfA2PMeo0qn7vmBsmwboIXn6G+4yaTnQk9R80hb/7JFv
SN043NVKF1XKT5lcjxfDEIWr
=hiQu
-----END PGP SIGNATURE-----
^ permalink raw reply [relevance 1%]
* Re: http links translated to html : target "_blank"
2021-02-01 21:01 10% ` Juan Manuel Macías
@ 2021-02-04 14:07 0% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-02-04 14:07 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer <oub@mat.ucm.es> writes:
>> That is odd (maybe my org version is a bit rusty (master june 2020)
> It's strange...
> It should work fine for you (as long as you set
> `org-export-allow-bind-keywords' as non-nil)
Aha, indeed it was nil! I was not even aware of this variable, after
switching to t, your code worked. Thanks because it save me the hassle
to add manually
#+attr_latex
On the other hand it is good to know that booth solution exits.
Thanks
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: local variables and export processing in hooks
@ 2021-02-10 15:43 6% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-02-10 15:43 UTC (permalink / raw)
To: emacs-orgmode
On 09/02/2021 19:06, Eric S Fraga wrote:
> On Tuesday, 9 Feb 2021 at 12:30, tomas@tuxteam.de wrote:
>> Perhaps a file local variable?
>
> I tried but this doesn't seem to be propagated to the export as the
> export works on a copy of the buffer, not the buffer itself. That's
> what #+BIND is for, supposedly...
I have seen that you have achieved your goal with local variables.
Concerning BIND, there was a topic a month ago that bind has to be
enabled explicitly. Unsure if it makes parameter available early enough
however:
https://orgmode.org/list/87pn2iz3kr.fsf@posteo.net/
On 06/01/2021 18:51, Juan Manuel Macías wrote:
> (setq org-export-allow-bind-keywords t)
^ permalink raw reply [relevance 6%]
* Macros and possible alternatives to the comma character (enhancement?)
@ 2021-02-12 13:01 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-12 13:01 UTC (permalink / raw)
To: orgmode
Hi,
In my Org docs I make a heavy use of replacement macros. I think they
are a powerful and versatile. I only see one problem: in my opinion, the
comma as a character to separate arguments seems unproductive to me. I
often use macros to enter textual content, and I find it a bit tedious
having to constantly escape such a common symbol as the comma (\,). In fact,
for my personal use I have modified the `org-macro-extract-arguments'
function, and now I separate the arguments using '@ (quote + at).
Am I the only one who thinks there should be better alternatives to the
comma?
Do you think it would be good to add these alternatives as a '#+startup'
option?
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [Tip] Write the LaTeX preamble in a source block
@ 2021-02-13 20:38 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-13 20:38 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3656 bytes --]
Hi,
Although I almost always use custom LaTeX classes and a separate file
for the preamble, I came up with this method to take advantage of
the 'latex' source blocks and write the entire preamble there. I guess
there will be a more elegant way to do it, but I think that it works
reasonably well ;-)
First, this function:
#+begin_src emacs-lisp
(defun multiple-latex-header ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "_src\s+latex\s+:latexheader" nil t)
(when (equal (org-element-type (org-element-at-point)) 'src-block)
(save-restriction
(org-narrow-to-block)
(goto-char (point-min))
(let ((lines (split-string (replace-regexp-in-string "#\\+.+" "" (buffer-string)) "\n" nil)))
(delete-region (point-min) (point-max))
(insert (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n"))))))))
#+end_src
And based on this concept, we could also take advantage of the 'lua'
source blocks to generate the luacode environment (with or without
asterisk) and send it to the preamble:
#+begin_src emacs-lisp
(defun env-luacode ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "_src\s+lua\s+:luacode" nil t)
(when (equal (org-element-type (org-element-at-point)) 'src-block)
(save-restriction
(org-narrow-to-block)
(goto-char (point-min))
(let ((luacode (save-excursion
(re-search-forward "\\(luacode\\**\\)" nil t)
(match-string 1))))
(when luacode
(while (re-search-forward "\\(#\\+begin_src\s+lua.+\\)" nil t)
(replace-match (format "\\\\begin{%s}" luacode) t nil))
(while (re-search-forward "\\(#\\+end_src\\)" nil t)
(replace-match (format "\\\\end{%s}" luacode) t nil))
(let ((lines (split-string (buffer-string) "\n" nil)))
(delete-region (point-min) (point-max))
(insert (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n"))))))))))
#+end_src
And finally:
#+begin_src emacs-lisp
(defun luacode-latexheader-filter (backend)
(when (eq backend 'latex)
(env-luacode)
(multiple-latex-header)))
(add-hook 'org-export-before-processing-hook #'luacode-latexheader-filter)
#+end_src
It can be tested with this example that includes a simple function in
Lua (in a luacode* environment) to colorize the texts in 'otherlanguage', but
only in draft mode:
#+begin_src org
,#+LATEX_CLASS: article
,#+LATEX_CLASS_OPTIONS: [draft]
,#+LATEX_COMPILER: lualatex
,#+OPTIONS: toc:nil
,#+LaTeX_Header: \usepackage{luacode}
,#+begin_src lua :luacode*
function foreignlanguage_draft ( text )
text = string.gsub ( text, "(\\begin{otherlanguage}{[^%s]+})", "%1\\color{teal}")
return text
end
,#+end_src
,#+begin_src latex :latexheader
\usepackage{fontspec}
\setmainfont[Numbers=Lowercase]{Linux Libertine O}
\usepackage[english,spanish]{babel}
\usepackage{xcolor}
\usepackage{ifdraft}
\usepackage{lipsum}
\newcommand\babeldraft{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , foreignlanguage_draft , "foreignlanguage_draft" )}}
\ifdraft{%
\AtBeginDocument{\babeldraft}
}{}
,#+end_src
@@latex:\lipsum[1]@@
,#+ATTR_LaTeX: :options {english}
,#+begin_otherlanguage
Most GNU/Linux distributions provide GNU Emacs in their repositories, which is the
recommended way to install Emacs unless you always want to use the latest release.
,#+end_otherlanguage
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 7%]
* 'false' list item
@ 2021-02-15 17:37 10% Juan Manuel Macías
2021-02-21 6:56 6% ` Kyle Meyer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-15 17:37 UTC (permalink / raw)
To: orgmode
Hi,
If a line in a paragraph starts with a digit (or letter) + period +
space, Org misinterprets that as a list item. I almost always notice
this only when I export my document, which is a nuisance.
I wonder if there is any standard solution to that, or if I'm missing
something... All that occurred to me is this "preventive" solution,
using `highlight-regexp':
#+begin_src emacs-lisp
(defface my-lists-item-box
'((t :weight bold :foreground "white" :background "orange"))
"")
(defun my-org-item-highlight ()
(highlight-regexp org-list-full-item-re 'my-lists-item-box))
(add-hook 'org-mode-hook 'my-org-item-highlight)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [question] lisp code in :results header arg.?
@ 2021-02-16 16:30 9% Juan Manuel Macías
2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-16 16:30 UTC (permalink / raw)
To: orgmode
Hi,
I'm exploring some ways to include a complex LaTeX preamble using source
blocks. Consider this (code at the end of this message), that works fine.
My question is: In order to do it all in a single block, would there be
any way to pass the output of the first block as an argument to a
function, and put that function as a header arg (results)...?
Best Regards,
Juan Manuel
#+NAME:preamble
#+begin_src latex :results silent :exports results
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
fonts.handlers.otf.addfeature
{
name = "ktest",
type = "kern",
data =
{
["A"] = { ["V"] = -45 },
},
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src emacs-lisp :var x=preamble :results raw :exports results
(let* ((lines (split-string x "\n" nil))
(headers (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n")))
headers)
#+end_src
#+RESULTS:
#+LaTeX_Header: \usepackage{luacode}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \directlua
#+LaTeX_Header: {
#+LaTeX_Header: fonts.handlers.otf.addfeature
#+LaTeX_Header: {
#+LaTeX_Header: name = "ktest",
#+LaTeX_Header: type = "kern",
#+LaTeX_Header: data =
#+LaTeX_Header: {
#+LaTeX_Header: ["A"] = { ["V"] = -45 },
#+LaTeX_Header: },
#+LaTeX_Header: }
#+LaTeX_Header: }
#+LaTeX_Header: \setmainfont{Linux Libertine O}
#+LaTeX_Header: [RawFeature={+ktest}]
^ permalink raw reply [relevance 9%]
* Re: [question] lisp code in :results header arg.?
2021-02-16 16:30 9% [question] lisp code in :results header arg.? Juan Manuel Macías
@ 2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
2021-02-16 18:25 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Berry, Charles via General discussions about Org-mode. @ 2021-02-16 17:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
> On Feb 16, 2021, at 8:30 AM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi,
>
> I'm exploring some ways to include a complex LaTeX preamble using source
> blocks. Consider this (code at the end of this message), that works fine.
>
> My question is: In order to do it all in a single block, would there be
> any way to pass the output of the first block as an argument to a
> function, and put that function as a header arg (results)...?
[rest deleted]
I think you might do better to use noweb chunks, viz.
#+name: pre-amble
#+begin_src latex :exports none
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
[...]
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src latex :noweb yes :results drawer
,#+LaTeX_HEADER: <<pre-amble>>
#+end_src
Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . t)) gives what I suspect you want.
Note that using a drawer allows replacement of the result.
HTH,
Chuck
^ permalink raw reply [relevance 0%]
* Re: [question] lisp code in :results header arg.?
2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
@ 2021-02-16 18:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-16 18:25 UTC (permalink / raw)
To: Berry, Charles; +Cc: orgmode
"Berry, Charles" <ccberry@health.ucsd.edu> writes:
> I think you might do better to use noweb chunks, viz.
>
> #+name: pre-amble
> #+begin_src latex :exports none
>
> \usepackage{luacode}
> \usepackage{fontspec}
> \directlua
> {
> [...]
> }
> }
> \setmainfont{Linux Libertine O}
> [RawFeature={+ktest}]
> #+end_src
>
> #+begin_src latex :noweb yes :results drawer
> ,#+LaTeX_HEADER: <<pre-amble>>
> #+end_src
>
>
> Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . t)) gives what I suspect you want.
wow, it works great! Many thanks. I did not know this use of noweb ...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [PATCH] Startup option to separate macros arguments with an alternative string
@ 2021-02-18 16:33 6% Juan Manuel Macías
2021-04-19 9:19 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-18 16:33 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Hi,
I would like to propose this (possible) patch.
With `#+STARTUP: macro-arg-sep-other' the macros arguments can be
separated by a string other than comma, whose value is defined in
`org-macro-arg-sep-other' (by default it is "'@").
Rationale for this patch: There are many contexts where the comma character can be
inappropriate as an argument separator, since it has to be escaped many times.
If the patch is relevant, I can take care of writing the documentation and docstrings.
Example:
#+begin_src org
,#+STARTUP: macro-arg-sep-other
,#+MACRO: lg (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 "\u200B" "@@latex:}@@") $2))
{{{lg(latin'@Lorem ipsum dolor sit amet, consectetuer adipiscing elit, donec hendrerit
tempor tellus, donec pretium posuere tellus, proin quam nisl, tincidunt et, mattis eget,
convallis nec, purus.)}}}
With the escaped character:
{{{lg(latin'@Lorem ipsum dolor sit amet \'@)}}}
#+end_src
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-macro-arg-sep.patch --]
[-- Type: text/x-patch, Size: 2302 bytes --]
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index f914a33d6..311eaf9a5 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -82,6 +82,8 @@ directly, use instead:
#+MACRO: name template")
+(defvar org-macro-arg-sep-other "'@")
+
;;; Functions
(defun org-macro--set-template (name value templates)
@@ -277,15 +279,19 @@ Return a list of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
+ (let ((sep (cond ((eq org-startup-macro-arg-sep 'comma)
+ ",")
+ ((eq org-startup-macro-arg-sep 'other)
+ org-macro-arg-sep-other))))
(split-string
(replace-regexp-in-string
- "\\(\\\\*\\),"
+ (format "\\(\\\\*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str))))
(concat (make-string (/ len 2) ?\\)
- (if (zerop (mod len 2)) "\000" ","))))
+ (if (zerop (mod len 2)) "\000" (format "%s" sep)))))
s nil t)
- "\000"))
+ "\000")))
\f
;;; Helper functions and variables for internal macros
diff --git a/lisp/org.el b/lisp/org.el
index 7d8733448..a51893ed3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -974,6 +974,15 @@ case it is too late to set the variable `org-startup-truncated'."
:group 'org-startup
:type 'boolean)
+(defcustom org-startup-macro-arg-sep 'comma
+ "TODO"
+ :group 'org-startup
+ :package-version '(Org . "9.0")
+ :version "26.1"
+ :type '(choice
+ (const :tag "comma" comma)
+ (const :tag "other" other)))
+
(defcustom org-startup-indented nil
"Non-nil means turn on `org-indent-mode' on startup.
This can also be configured on a per-file basis by adding one of
@@ -4187,7 +4196,8 @@ After a match, the following groups carry important information:
("nohideblocks" org-hide-block-startup nil)
("beamer" org-startup-with-beamer-mode t)
("entitiespretty" org-pretty-entities t)
- ("entitiesplain" org-pretty-entities nil))
+ ("entitiesplain" org-pretty-entities nil)
+ ("macro-arg-sep-other" org-startup-macro-arg-sep other))
"Variable associated with STARTUP options for Org.
Each element is a list of three items: the startup options (as written
in the #+STARTUP line), the corresponding variable, and the value to set
^ permalink raw reply related [relevance 6%]
* Re: 'false' list item
2021-02-15 17:37 10% 'false' list item Juan Manuel Macías
@ 2021-02-21 6:56 6% ` Kyle Meyer
2021-02-21 7:05 0% ` Tim Cross
2021-02-21 19:33 10% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Kyle Meyer @ 2021-02-21 6:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías writes:
> If a line in a paragraph starts with a digit (or letter) + period +
> space, Org misinterprets that as a list item. I almost always notice
> this only when I export my document, which is a nuisance.
>
> I wonder if there is any standard solution to that, or if I'm missing
> something... All that occurred to me is this "preventive" solution,
> using `highlight-regexp':
It seems that your approach would do a good job of helping you catch
cases that you don't want to be treated as lists. I'm not aware of any
related functionality in Org, so I don't think you're missing something
there.
Once you know that there is a particular spot that you want to prevent
from being interpreted as a list, you could add a zero-width space in
front of it:
(info "(org)Escape Character")
I'm not sure if that's the sort of solution you're asking for, though.
^ permalink raw reply [relevance 6%]
* Re: 'false' list item
2021-02-21 6:56 6% ` Kyle Meyer
@ 2021-02-21 7:05 0% ` Tim Cross
2021-02-21 14:49 10% ` Juan Manuel Macías
2021-02-21 19:33 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-02-21 7:05 UTC (permalink / raw)
To: emacs-orgmode
Kyle Meyer <kyle@kyleam.com> writes:
> Juan Manuel Macías writes:
>
>> If a line in a paragraph starts with a digit (or letter) + period +
>> space, Org misinterprets that as a list item. I almost always notice
>> this only when I export my document, which is a nuisance.
>>
>> I wonder if there is any standard solution to that, or if I'm missing
>> something... All that occurred to me is this "preventive" solution,
>> using `highlight-regexp':
>
> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists. I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
> (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.
If a line starts with a number, period and space, but that line is
within a paragraph (i.e. no blank line above), then I don't think it
should be interpreted as an enumerated list item. If this is what the OP
is referring to, I would argue it is a bug. If it is a 'paragraph'
starting with a number, period and space, then being interpreted as a
list item would be 'normal'.
--
Tim Cross
^ permalink raw reply [relevance 0%]
* Re: 'false' list item
2021-02-21 7:05 0% ` Tim Cross
@ 2021-02-21 14:49 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-21 14:49 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Hi,
Tim Cross <theophilusx@gmail.com> writes:
> If a line starts with a number, period and space, but that line is
> within a paragraph (i.e. no blank line above), then I don't think it
> should be interpreted as an enumerated list item. If this is what the OP
> is referring to, I would argue it is a bug. If it is a 'paragraph'
> starting with a number, period and space, then being interpreted as a
> list item would be 'normal'.
The problem occurs on the lines within a paragraph (no blank line
above). I have uploaded this screenshot:
https://gnutas.juanmanuelmacias.com/images/false-list-item.webm
It also happens with a clean startup.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
2021-02-21 6:56 6% ` Kyle Meyer
2021-02-21 7:05 0% ` Tim Cross
@ 2021-02-21 19:33 10% ` Juan Manuel Macías
2021-02-21 19:40 7% ` Diego Zamboni
2021-02-21 22:55 6% ` Kyle Meyer
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-21 19:33 UTC (permalink / raw)
To: Kyle Meyer; +Cc: orgmode
Kyle Meyer <kyle@kyleam.com> writes:
> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists. I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
> (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.
Thanks for your advice, Kyle. Adding the U+200B char. works fine to
avoid false positives. Anyway, like Tim Cross says, that situation
maybe should be considered as a bug. I think the ideal behavior would
be for Org to consider a list only when there is a blank line above.
But, well thought out, I am afraid that it would not prevent false
positives, as one may want perfectly write a list at the beginning of
the document, or start a plain paragraph with (for example) a digit + a
period + a space...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
2021-02-21 19:33 10% ` Juan Manuel Macías
@ 2021-02-21 19:40 7% ` Diego Zamboni
2021-02-21 21:27 0% ` Samuel Wales
2021-02-21 22:55 6% ` Kyle Meyer
1 sibling, 1 reply; 200+ results
From: Diego Zamboni @ 2021-02-21 19:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Kyle Meyer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Juan Manuel,
YMMV depending on your needs and habits, but another workaround for this
problem would be to use visual-line-mode instead of filling paragraphs.
--Diego
On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Kyle Meyer <kyle@kyleam.com> writes:
>
> > It seems that your approach would do a good job of helping you catch
> > cases that you don't want to be treated as lists. I'm not aware of any
> > related functionality in Org, so I don't think you're missing something
> > there.
> >
> > Once you know that there is a particular spot that you want to prevent
> > from being interpreted as a list, you could add a zero-width space in
> > front of it:
> >
> > (info "(org)Escape Character")
> >
> > I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.
> But, well thought out, I am afraid that it would not prevent false
> positives, as one may want perfectly write a list at the beginning of
> the document, or start a plain paragraph with (for example) a digit + a
> period + a space...
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 1982 bytes --]
^ permalink raw reply [relevance 7%]
* Re: 'false' list item
2021-02-21 19:40 7% ` Diego Zamboni
@ 2021-02-21 21:27 0% ` Samuel Wales
2021-02-21 22:25 10% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Samuel Wales @ 2021-02-21 21:27 UTC (permalink / raw)
To: Diego Zamboni; +Cc: Juan Manuel Macías, Kyle Meyer, orgmode
perhaps if there is no blank line above or below, then it could be not a list.
On 2/21/21, Diego Zamboni <diego@zzamboni.org> wrote:
> Juan Manuel,
>
> YMMV depending on your needs and habits, but another workaround for this
> problem would be to use visual-line-mode instead of filling paragraphs.
>
> --Diego
>
>
>
>
> On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Kyle Meyer <kyle@kyleam.com> writes:
>>
>> > It seems that your approach would do a good job of helping you catch
>> > cases that you don't want to be treated as lists. I'm not aware of any
>> > related functionality in Org, so I don't think you're missing something
>> > there.
>> >
>> > Once you know that there is a particular spot that you want to prevent
>> > from being interpreted as a list, you could add a zero-width space in
>> > front of it:
>> >
>> > (info "(org)Escape Character")
>> >
>> > I'm not sure if that's the sort of solution you're asking for, though.
>>
>> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
>> avoid false positives. Anyway, like Tim Cross says, that situation
>> maybe should be considered as a bug. I think the ideal behavior would
>> be for Org to consider a list only when there is a blank line above.
>> But, well thought out, I am afraid that it would not prevent false
>> positives, as one may want perfectly write a list at the beginning of
>> the document, or start a plain paragraph with (for example) a digit + a
>> period + a space...
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [relevance 0%]
* Re: 'false' list item
2021-02-21 21:27 0% ` Samuel Wales
@ 2021-02-21 22:25 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-21 22:25 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Samuel Wales <samologist@gmail.com> writes:
> perhaps if there is no blank line above or below, then it could be not a list.
I think this solution would be fine, although plain paragraphs starting
with digit/letter + period + space would be false positives. Anyway,
some kind of highlighting in the items, a defined face as in
markdown-mode (markdown-list-face), would be also helpful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
2021-02-21 19:33 10% ` Juan Manuel Macías
2021-02-21 19:40 7% ` Diego Zamboni
@ 2021-02-21 22:55 6% ` Kyle Meyer
1 sibling, 0 replies; 200+ results
From: Kyle Meyer @ 2021-02-21 22:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías writes:
> Kyle Meyer <kyle@kyleam.com> writes:
>
>> It seems that your approach would do a good job of helping you catch
>> cases that you don't want to be treated as lists. I'm not aware of any
>> related functionality in Org, so I don't think you're missing something
>> there.
>>
>> Once you know that there is a particular spot that you want to prevent
>> from being interpreted as a list, you could add a zero-width space in
>> front of it:
>>
>> (info "(org)Escape Character")
>>
>> I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.
You can find some previous discussion of this longstanding and known
behavior at <https://orgmode.org/list/874ndj13u5.fsf@gmail.com/T/#u>.
^ permalink raw reply [relevance 6%]
* Re: 'false' list item
@ 2021-02-22 0:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-22 0:21 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> The issue is, if we decide this is a bug, can we fix it? Is it a bug or
> is it just an accepted limitation of the org document format and what we
> have to do is ensure either no line starts with a '1. ' or we use
> something like a unicode character so that it doesn't look like a
> number+period+space and therefore not a list item?
Interesting all the points you comment, and this paragraph is important.
I'm thinking that without a clear and explicit environment (a begin/end
marks), any possible solution will always have its exceptions. However,
IMHO, I would not find desirable two explicit marks environment in the
style of LaTeX, since this would go against the virtue of legibility and
lightness in Org. I don't know if Markdown (on what it has in common
with Org as a lightweight markup language) also has similar problems in
lists formatting, since I hardly use Markdown and am not aware of its
many implementations...
I still think that highlighting the items would at least be a preventive
solution for Org.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* false-list-item-mode?
@ 2021-02-23 18:23 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-23 18:23 UTC (permalink / raw)
To: orgmode
Hi,
This is not a solution to what was commented in this recent thread
(https://lists.gnu.org/archive/html/emacs-orgmode/2021-02/msg00239.html)
on the false list item issue. But, in case anyone finds it useful, I
happened to sketch this minor mode to highlight, while typing, *only*
(+/-) those lines in a paragraph that start with a 'false' list item.
The code is in this GitLab snippet:
https://gitlab.com/-/snippets/2081294
And here a short screenshot:
https://gnutas.juanmanuelmacias.com/images/false-list-item-mode-test.mp4
Feedback Welcome!
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Add color space and icc profile information to images
@ 2021-02-25 22:16 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-25 22:16 UTC (permalink / raw)
To: orgmode
Hi,
When working with images for print, I often need to get quickly the
color space and icc profile information of each included image, so I
came up with this function (code at the end of this mail) that I share
here, in case it is useful to someone. The function inserts the
information I need, under each image link in a document. For example:
#+begin_src org
[[file:~/Imágenes/Arte/Lilian_May_Miller_Blue_Hills_and_Crescent_Moon.jpg]]
# COLOR-INFO: Colorspace: sRGB | icc:description: Adobe RGB (1998)
[[file:~/CA/CA10/cubierta.jpg]]
# COLOR-INFO: Colorspace: CMYK | icc:description: ISO Coated v2 300% (ECI)
[[file:~/Escritorio/crespo.jpg]]
# COLOR-INFO: Colorspace: Gray | icc:description: GIMP built-in D65 Grayscale with sRGB TRC
#+end_src
The only problem is that the process is somewhat slow, especially when
the images are large or there are many images in the document. I think
that this is due in part to the imagemagick process itself, and in part
to the little elegance of my function ... ;-)
Best regards,
Juan Manuel
#+begin_src emacs-lisp
(defun my-org-comment-colorspace ()
(interactive)
(save-excursion
(goto-char (point-min))
(while (re-search-forward org-bracket-link-regexp nil t)
(when (string-match (regexp-opt '(".png" ".jpg")) (match-string 1))
(forward-char -1)
(let* ((link (assoc :link (org-context)))
(link-str (when link
(buffer-substring-no-properties (cadr link) (caddr link)))))
(string-match org-bracket-link-regexp link-str)
(let* ((identify-result (shell-command-to-string
(concat "identify -verbose "
"\""
(expand-file-name
(format "%s"
(replace-regexp-in-string
"file:" ""
(substring link-str
(match-beginning 1)
(match-end 1)))))
"\"")))
(colorspace (progn
(string-match "\\(Colorspace:.+\\)" identify-result)
(substring identify-result
(match-beginning 1)
(match-end 1))))
(icc (progn
(string-match "\\(icc:description:.+\\)" identify-result)
(substring identify-result
(match-beginning 1)
(match-end 1)))))
(forward-line 1)
(beginning-of-line)
(when (looking-at "\\(# COLOR-INFO:.+\\)")
(delete-region (match-beginning 0) (match-end 0)))
(insert (format "# COLOR-INFO: %s | %s" colorspace icc))))))))
#+end_src
^ permalink raw reply [relevance 7%]
* Re: content management in emacs
@ 2021-02-27 20:11 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-02-27 20:11 UTC (permalink / raw)
To: Martin Steffen; +Cc: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> I am not sure about the question. If I send to an email list, it's an
> address in BBDB. So I ``invoke'' BBDB (M-x bbdb) and give it the name of
> the entry (say org-mode). That's analogous to send to a person: If you
> remember the name (or part of the name), you find the entry, send then
> compose an email ("m") on the entry.
There is also helm-bbdb, wich is very useful
(https://github.com/emacs-helm/helm-bbdb). For Gnus I have defined this:
#+begin_src emacs-lisp
(require 'helm-bbdb)
(setq message-completion-alist '(("^\\(Newsgroups\\|Followup-To\\|Posted-To\\|Gcc\\):" . message-expand-group)
("^\\(Resent-\\)?\\(To\\|B?Cc\\):" . helm-bbdb-expand-name)
("^\\(Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):" . helm-bbdb-expand-name)
("^\\(Disposition-Notification-To\\|Return-Receipt-To\\):"
. helm-bbdb-expand-name)))
#+end_src
And to insert an address at point (for example, in Org, in the `mail_to'
property):
#+begin_src emacs-lisp
(defun my-insert-mail-address-helm-bbdb (_candidate)
(save-window-excursion
(helm-bbdb--view-person-action-1 (helm-bbdb--marked-contacts))
(call-interactively 'bbdb-mail-address)
(kill-buffer))
(yank))
(add-to-list 'helm-bbdb-actions '("Insert mail address" . my-insert-mail-address-helm-bbdb))
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: printing org table landscape on complete page
@ 2021-02-28 20:53 10% ` Juan Manuel Macías
2021-03-01 0:18 2% ` andrés ramírez
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-02-28 20:53 UTC (permalink / raw)
To: Andrés Ramírez; +Cc: orgmode
Hi,
You can use:
#+ATTR_LaTeX: :float sideways
which is exported to LaTeX with the sidewaystable environment (rotating
package).
And for the table to fit vertically on the page:
#+LaTeX_Header: \usepackage{tabularx}
#+ATTR_LaTeX: :float sideways :environment tabularx :width \textheigtht
Regards,
Juan Manuel
Andrés Ramírez <rrandresf@gmail.com> writes:
> Hi.
>
> I want to print from emacs an org-table like this one:
>
> |-------------+-----------+----------+-----------+----------+---------|
> | DURATION | MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY |
> |-------------+-----------+----------+-----------+----------+---------|
> | 08:30-09:30 | CyT | RELIGION | GERMAN | ENGLISH | ENGLISH |
> |-------------+-----------+----------+-----------+----------+---------|
> | 09:50-10:50 | COMUNICAT | DPCC | COMUNICAT | COMUNIC | CyT |
> |-------------+-----------+----------+-----------+----------+---------|
> | 11:10-12:10 | COMPUTERS | CyT | E.FISICA | ART | GERMAN |
> |-------------+-----------+----------+-----------+----------+---------|
> | 12:30-13:30 | TUTORIA | MATH | MATH | CC.SS | MATH |
>
> on landscape on the content should enlarge to cover the full-page.
>
> Any ideas?
>
> Andrés Ramírez
>
^ permalink raw reply [relevance 10%]
* Re: printing org table landscape on complete page
2021-02-28 20:53 10% ` Juan Manuel Macías
@ 2021-03-01 0:18 2% ` andrés ramírez
0 siblings, 0 replies; 200+ results
From: andrés ramírez @ 2021-03-01 0:18 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi (Como estas). Juan.
>>>>> "Juan" == Juan Manuel Macías <maciaschain@posteo.net> writes:
[...]
Juan> #+ATTR_LaTeX: :float sideways :environment tabularx :width \textheigtht
I have tried it (with M-x org-export-dispatch).
This is the result:
,---- [ ]
| http://0x0.st/-Kgb.pdf
`----
It is centered.
Also I got a second option:
with this snippet and (M-x ps-print-buffer):
--8<---------------cut here---------------start------------->8---
(setq ps-left-margin 0
ps-paper-type 'a4
ps-font-size 16.0
ps-print-header nil
ps-landscape-mode t
ps-number-of-columns 1
ps-printer-name "pdf")
--8<---------------cut here---------------end--------------->8---
This is the result:
,---- [ ]
| http://0x0.st/-KgA.pdf
`----
The second option is going to be very useful when pdflatex is not
available. But it is NOT so well centered as the first option.
Thanks for your help.
Best Regards
^ permalink raw reply [relevance 2%]
* [tip for EXWM users] An alternative method for isolate trees
@ 2021-03-01 12:55 9% Juan Manuel Macías
2021-03-01 13:37 6% ` Julian M. Burgos
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-01 12:55 UTC (permalink / raw)
To: orgmode
Hi,
Since EXWM uses Emacs frames as virtual desktops, I have written this
alternative method of `org-tree-to-indirect-buffer', which I share here.
With this method I can have several isolated trees, with their own name,
and access them quickly (with helm-buffer-list, for example):
#+begin_src emacs-lisp
(defun my-goto-buffer-regexp (regexp)
(dolist (buffer (buffer-list))
(let ((name (buffer-name buffer)))
(when (and name (not (string-equal name ""))
(string-match regexp name))
(switch-to-buffer buffer)))))
(defun my-org-tree-to-indirect-buffer ()
(interactive)
(let ((buf (buffer-name))
(ind-buf (replace-regexp-in-string "\\[.+\\]" "" (nth 4 (org-heading-components))))
(org-indirect-buffer-display 'new-frame))
(org-tree-to-indirect-buffer)
(my-goto-buffer-regexp ind-buf)
(rename-buffer (concat buf "::" ind-buf))))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 12:55 9% [tip for EXWM users] An alternative method for isolate trees Juan Manuel Macías
@ 2021-03-01 13:37 6% ` Julian M. Burgos
2021-03-01 14:10 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Julian M. Burgos @ 2021-03-01 13:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan Manuel,
Thank you, although I tested your functions and compared with the original org-tree-to-indirect-buffer, the only difference I see is that your function creates a new exwm workspace. The original function already creates indirect buffers with their own names (using a slash instead of the double colons). Or I am missing something?
My best,
Julian
Juan Manuel Macías writes:
> Hi,
>
> Since EXWM uses Emacs frames as virtual desktops, I have written this
> alternative method of `org-tree-to-indirect-buffer', which I share here.
> With this method I can have several isolated trees, with their own name,
> and access them quickly (with helm-buffer-list, for example):
>
> #+begin_src emacs-lisp
> (defun my-goto-buffer-regexp (regexp)
> (dolist (buffer (buffer-list))
> (let ((name (buffer-name buffer)))
> (when (and name (not (string-equal name ""))
> (string-match regexp name))
> (switch-to-buffer buffer)))))
>
> (defun my-org-tree-to-indirect-buffer ()
> (interactive)
> (let ((buf (buffer-name))
> (ind-buf (replace-regexp-in-string "\\[.+\\]" "" (nth 4 (org-heading-components))))
> (org-indirect-buffer-display 'new-frame))
> (org-tree-to-indirect-buffer)
> (my-goto-buffer-regexp ind-buf)
> (rename-buffer (concat buf "::" ind-buf))))
> #+end_src
>
> Best regards,
>
> Juan Manuel
--
Julian Mariano Burgos, PhD
Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/
Marine and Freshwater Research Institute
Botnsjávarsviðs / Demersal Division
Fornubúðir 5, IS-220 Hafnarfjörður, Iceland
www.hafogvatn.is
Sími/Telephone : +354-5752037
Netfang/Email: julian.burgos@hafogvatn.is
^ permalink raw reply [relevance 6%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 13:37 6% ` Julian M. Burgos
@ 2021-03-01 14:10 10% ` Juan Manuel Macías
2021-03-01 15:37 5% ` Julian M. Burgos
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-01 14:10 UTC (permalink / raw)
To: Julian M. Burgos; +Cc: orgmode
Hi Julian, thanks for your comment.
"Julian M. Burgos" <julian.burgos@hafogvatn.is> writes:
> Thank you, although I tested your functions and compared with the
> original org-tree-to-indirect-buffer, the only difference I see is
> that your function creates a new exwm workspace. The original function
> already creates indirect buffers with their own names (using a slash
> instead of the double colons). Or I am missing something?
org-tree-to-indirect-buffer creates a new buffer, but (as far as I know)
does not allow accumulating buffers. In other words, you cannot have
several isolated trees at the time. In this method it just occurred to
me to configure org-indirect-buffer-display as new-frame and take
advantage of EXWM frame management.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 14:10 10% ` Juan Manuel Macías
@ 2021-03-01 15:37 5% ` Julian M. Burgos
2021-03-01 16:42 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Julian M. Burgos @ 2021-03-01 15:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
You are right. :) I have not noticed that org-tree-to-indirect-buffer reuses the indirect buffer when you call it for a second time. According to the manual, "with a C-u prefix, do not remove the previously used indirect buffer", but that does not seem to work. When you do Cu-Cc-Cx-b from a buffer that already has an indirect buffer you get a "cannot modify an area being edited in a dedicated buffer". If you try it from a different buffer, the prefix is ignored and the indirect buffer is assigned to the tree from the last buffer.
This does not seem to be a limitation from emacs, as it is possible to open multiple indirect buffers from a base buffer, using for example clone-indirect-buffer. So it should be possible to make a function combining "clone-indirect-buffer" and "org-narrow-to-subtree" perhaps? I am thinking so this option is available not only to EXWM users.
Ideally, there should be an option to allow org-tree-to-indirect-buffer to create more than one indirect buffer if desired.
My best,
Julian
Juan Manuel Macías writes:
> Hi Julian, thanks for your comment.
>
> "Julian M. Burgos" <julian.burgos@hafogvatn.is> writes:
>
>> Thank you, although I tested your functions and compared with the
>> original org-tree-to-indirect-buffer, the only difference I see is
>> that your function creates a new exwm workspace. The original function
>> already creates indirect buffers with their own names (using a slash
>> instead of the double colons). Or I am missing something?
>
> org-tree-to-indirect-buffer creates a new buffer, but (as far as I know)
> does not allow accumulating buffers. In other words, you cannot have
> several isolated trees at the time. In this method it just occurred to
> me to configure org-indirect-buffer-display as new-frame and take
> advantage of EXWM frame management.
>
> Best regards,
>
> Juan Manuel
--
Julian Mariano Burgos, PhD
Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/
Marine and Freshwater Research Institute
Botnsjávarsviðs / Demersal Division
Fornubúðir 5, IS-220 Hafnarfjörður, Iceland
www.hafogvatn.is
Sími/Telephone : +354-5752037
Netfang/Email: julian.burgos@hafogvatn.is
^ permalink raw reply [relevance 5%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 15:37 5% ` Julian M. Burgos
@ 2021-03-01 16:42 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-01 16:42 UTC (permalink / raw)
To: Julian M. Burgos; +Cc: orgmode
Hi Julian,
"Julian M. Burgos" <julian.burgos@hafogvatn.is> writes:
> This does not seem to be a limitation from emacs, as it is possible to
> open multiple indirect buffers from a base buffer, using for example
> clone-indirect-buffer. So it should be possible to make a function
> combining "clone-indirect-buffer" and "org-narrow-to-subtree" perhaps?
> I am thinking so this option is available not only to EXWM users.
I think that combining clone-indirect-buffer and org-narrow-to-subtree
would work well. Another way to isolate several trees at once is by
using the excellent package org-sidebar
(https://github.com/alphapapa/org-sidebar). In fact, I borrowed from
this package the idea of renaming the new buffers with the string :: (if
I open helm and start typing ::, it shows me the list of isolated trees,
so it's very useful to have a dedicated string). Although my method for
isolating each tree is more pedestrian :-). And it only makes sense in
EXWM...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
@ 2021-03-03 2:31 9% ` Juan Manuel Macías
2021-03-03 14:51 6% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-03 2:31 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Hi Rodrigo,
Rodrigo Morales <moralesrodrigo1100@gmail.com> writes:
> I want to be able to
>
> + create a Org link to specific pages of a PDF. I've managed to
> accomplish this by setting the following value.
> [ ... ]
> + create a Org link to specific pages of a PDF and highlight a given
> string.
A possible alternative, which gives you more control over the link, is
`org-link-set-parameters'. For example:
#+begin_src emacs-lisp
(org-link-set-parameters
"pdf-pag"
:follow (lambda (path)
(let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
(match-string 1 path)
(error "no pages")))
(clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
(str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
(match-string 2 path))))
(start-process-shell-command "zathura" nil (concat "zathura "
clean-path
" -P "
pag
(when str
(format " -f '%s' " str)))))))
#+end_src
And then:
#+begin_src org
[[pdf-pag:~/Downloads/grub.pdf::95::do]]
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
2021-03-03 2:31 9% ` Juan Manuel Macías
@ 2021-03-03 14:51 6% ` Maxim Nikulin
2021-03-03 16:11 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-03-03 14:51 UTC (permalink / raw)
To: emacs-orgmode
On 03/03/2021 09:31, Juan Manuel Macías wrote:
> (start-process-shell-command "zathura" nil (concat "zathura "
> clean-path
> " -P "
> pag
> (when str
> (format " -f '%s' " str)))))))
Please, do not forget to pass stings coming from user input through
shell-quote-argument. There is combine-and-quote-strings function but
its docstring tells that it is not safe enough. Ideally shell should be
completely avoided in such cases and arguments should be passed as a
list directly to exec. https://xkcd.com/327/
^ permalink raw reply [relevance 6%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
2021-03-03 14:51 6% ` Maxim Nikulin
@ 2021-03-03 16:11 9% ` Juan Manuel Macías
2021-03-05 13:02 4% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-03 16:11 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim
Thanks for your advice, which I appreciate very much.
Maxim Nikulin <manikulin@gmail.com> writes:
> On 03/03/2021 09:31, Juan Manuel Macías wrote:
>> (start-process-shell-command "zathura" nil (concat "zathura "
>> clean-path
>> " -P "
>> pag
>> (when str
>> (format " -f '%s' " str)))))))
>
> Please, do not forget to pass stings coming from user input through
> shell-quote-argument. There is combine-and-quote-strings function but
> its docstring tells that it is not safe enough. Ideally shell should
> be completely avoided in such cases and arguments should be passed as
> a list directly to exec. https://xkcd.com/327/
So, maybe it would look better like this (`start-process' instead of
`start-process-shell-command')?:
#+begin_src emacs-lisp
(org-link-set-parameters
"pdf-pag"
:follow (lambda (path)
(let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
(format "--page=%s" (match-string 1 path))
(error "no pages")))
(clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
(str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
(format "--find=%s" (match-string 2 path)))))
(if str
(start-process "zathura" nil "/usr/bin/zathura"
clean-path
pag
str)
(start-process "zathura" nil "/usr/bin/zathura"
clean-path
pag)))))
#+end_src
Best reagards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)]
@ 2021-03-05 12:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-05 12:01 UTC (permalink / raw)
To: Qqwy/Wiebe-Marten; +Cc: orgmode
Hi,
Qqwy/Wiebe-Marten <qqwy@gmx.com> writes:
> However, the LaTeX that is exported will still create normal `enumerize`
> lists that do /not/ show up as alphabetical but rather still use `1.`,
> `2.`, `3.` for numbering.
>
> I think this current behaviour is at the very least surprising, and
> possibly unintended.
I use the enumitem package
(http://mirrors.ctan.org/macros/latex/contrib/enumitem/enumitem.pdf) for
lists in LaTeX. For an alphabetical list, for example:
#+begin_src org
,#+LaTeX_Header: \usepackage{enumitem}
,#+ATTR_LaTeX: :options [label=\alph*.,widest=a]
a. Lorem
b. ipsum
c. dolor
#+end_src
And to export to LaTeX and HTML, you can define a macro like this:
#+begin_src org
,#+MACRO: alphalist (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) "#+ATTR_LaTeX: :options [label=\\alph*.,widest=a]" "#+ATTR_HTML: :type a"))
{{{alphalist}}}
a. Lorem
b. ipsum
c. dolor'
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
2021-03-03 16:11 9% ` Juan Manuel Macías
@ 2021-03-05 13:02 4% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-03-05 13:02 UTC (permalink / raw)
To: emacs-orgmode
On 03/03/2021 23:11, Juan Manuel Macías wrote:
> Maxim Nikulin writes:
>>
>> Please, do not forget to pass stings coming from user input through
>> shell-quote-argument.
>
> So, maybe it would look better like this (`start-process' instead of
> `start-process-shell-command')?:
My intention was just to warn you against of opening a door
to shell injections.
Personally, as a workaround I would add an org-file-apps entry with
a single argument combining page and search string and would write
a tiny script that splits such argument and invokes the viewer.
I consider it as a better option in the sense of forward compatibility
since it allows to avoid custom link types. I expect that the bug
will be fixed soon.
I still suppose that it is serious limitation that such link format
does not support named link targets inside PDF files. Maybe the part
before second "::" could be considered as a named target
if it does not look like a number. I am unsure concerning search
strings containing "::", they may require more accurate regexp
or using e.g. percent encoding as in URLs.
> #+begin_src emacs-lisp
> (org-link-set-parameters
> "pdf-pag"
> :follow (lambda (path)
> (let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
> (format "--page=%s" (match-string 1 path))
> (error "no pages")))
> (clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
> (str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
> (format "--find=%s" (match-string 2 path)))))
> (if str
> (start-process "zathura" nil "/usr/bin/zathura"
> clean-path
> pag
> str)
> (start-process "zathura" nil "/usr/bin/zathura"
> clean-path
> pag)))))
> #+end_src
If your are asking my opinion on your function, I think that the
variant with start-process is a better one. There is a low level
alternative make-process but it requires more code, so it is less
convenient. As to the style of lisp code, I am not a proper
person to make suggestions.
I suspect that your function has a problem with page numbers like 10.
I do not like repetition of the regexp and tend to think that minor
variations are unintended. On the other hand a variant I could offer
is not shorter despite just one regexp and just one call of a
match function.
#+begin_src elisp
(defun wa-pdf-destination-zathura-args (target)
(let ((suffix (string-match
"::\\(?:\\([0-9]+\\)?\\(?:::\\(.+\\)\\)?\\|\\(.*\\)\\)$"
target)))
(if (not suffix)
(list (expand-file-name target))
(let* ((invalid (match-string 3 target))
(file (cond
((zerop suffix) (error "No file path in '%s'" target))
(invalid (error "Invalid destination within file: '%s'"
invalid))
(t (substring target 0 suffix))))
(page (match-string 1 target))
(search (match-string 2 target)))
(seq-remove #'null
(list (and page "--page") page
(and search "--find") search
(expand-file-name file)))))))
(defun wa-launch-pdf-viewer (target)
(let ((viewer "zathura")
(command (wa-pdf-destination-zathura-args target))
;; Do not allocate a pty. Really required only if the application
;; spawns background children and exits (xdg-open, gio open,
;; kde-open5), see Emacs Bug #44824.
(process-connection-type nil))
(apply #'start-process viewer "*Messages*" viewer command)))
#+end_src
#+begin_src elisp :results value list
(mapcar #'wa-pdf-destination-zathura-args
'(
"~/Download/grub.pdf::95::do"
"file.pdf::95"
"file.pdf::::do"
"file.pdf"
;; "::"
;; "::95"
;; "file.pdf::a"
;; "file.pdf::95:do"
))
#+end_src
^ permalink raw reply [relevance 4%]
* Org as a book publisher
@ 2021-03-06 19:34 7% Juan Manuel Macías
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-06 19:34 UTC (permalink / raw)
To: orgmode
Hi,
I would like to share here two samples of one of the most intense uses
that I give Org Mode: for typesetting, layout and editorial design. In
other words, I use Org (and Org-Publish) where publishers today use DTP
proprietary software like InDesign or QuarkXpress (a type of software,
on the other hand, that was never intended to compose books but rather
magazines, posters, brochures and so on). The samples are from a book
on classical philology, recently published here in Spain, and from a
fairly extensive dictionary, still work in progress:
https://imgur.com/gallery/yxAVkrY
Naturally, what acts in the background here is TeX and LaTeX
(specifically Lua(La)TeX), so what I really do is use Org and
Org-Publish as a sort of high-level interface for LaTeX. But I don't
mean to avoid LaTeX: in fact, I've been working with LaTeX for a long
time. I like LaTeX and behind these jobs there is a lot of LaTeX code.
But Org gives me a much more light and productive workflow, allowing me
to work at two levels.
The main advantages that I see for this workflow with Org/Org-Publish
are:
1. Lightness: LaTeX is too verbose.
2. Control of the composition process at various points. One of the
qualities of LuaTeX is the possibility to control TeX primitives
through scripts in Lua, and to act at various points in the pre- or
post-process. But I have realized that with the happy fusion of Elisp
and Org we can be much more precise and "surgical" ;-). Here,
Org/LaTeX is much more powerful than LuaLaTeX.
3. Org's synaptic and org-anizational ability to control and manage the
entire process of the creation of a book, from when the originals are
received until everything is prepared to send to the printer.
4. An unique origin. The book can be produced on paper from a single
source, but you can also export, from that source consistently, to
other formats (HTML or Epub).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Org as a book publisher
2021-03-06 19:34 7% Org as a book publisher Juan Manuel Macías
@ 2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
2021-03-07 15:57 6% ` Juan Manuel Macías
2021-03-07 12:08 6% ` Diego Zamboni
` (2 subsequent siblings)
3 siblings, 1 reply; 200+ results
From: M. ‘quintus’ Gülker @ 2021-03-07 9:17 UTC (permalink / raw)
To: emacs-orgmode
Am 06. März 2021 um 20:34 Uhr +0100 schrieb Juan Manuel Macías:
> I would like to share here two samples of one of the most intense
> uses that I give Org Mode: for typesetting, layout and editorial
> design. [...] The samples are from a book on classical philology,
> recently published here in Spain [...]. Naturally, what acts in the
> background here is TeX and LaTeX (specifically Lua(La)TeX), so what
> I really do is use Org and Org-Publish as a sort of high-level
> interface for LaTeX. But I don't mean to avoid LaTeX: in fact, I've
> been working with LaTeX for a long time. I like LaTeX and behind
> these jobs there is a lot of LaTeX code. But Org gives me a much
> more light and productive workflow, allowing me to work at two
> levels.
Thank you very much for sharing. This is an interesting insight. Many
people seem to use org rather than direct LaTeX because they dislike
LaTeX's syntax or find LaTeX too complex, which I never really
understood. But you make some great points for why this combination is
useful other than for that reason.
> 2. Control of the composition process at various points. One of the
> qualities of LuaTeX is the possibility to control TeX primitives
> through scripts in Lua, and to act at various points in the pre- or
> post-process. But I have realized that with the happy fusion of Elisp
> and Org we can be much more precise and "surgical" ;-). Here,
> Org/LaTeX is much more powerful than LuaLaTeX.
For those who still use pdfLaTeX rather than LuaLaTeX (probably due to
Microtype) there is not even an equivalent available.
> 4. An unique origin. The book can be produced on paper from a single
> source, but you can also export, from that source consistently, to
> other formats (HTML or Epub).
This is actually a strong argument. Even though I enjoy writing LaTeX
code, this one is a tough nut to crack with pure LaTeX, where I
achieved the best results with LaTeXML, but it was still lots of work.
May I ask what tooling you use to go from org to Epub?
-quintus
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | For security:
Passau, Germany | kontakt@guelker.eu | () Avoid HTML e-mail
European Union | PGP: see homepage | /\ http://asciiribbon.org
^ permalink raw reply [relevance 5%]
* Re: Org as a book publisher
2021-03-06 19:34 7% Org as a book publisher Juan Manuel Macías
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
@ 2021-03-07 12:08 6% ` Diego Zamboni
2021-03-07 13:15 0% ` Vikas Rawal
2021-03-07 16:03 8% ` Juan Manuel Macías
[not found] ` <87ft16hn62.fsf@emailmessageidheader.nil>
3 siblings, 2 replies; 200+ results
From: Diego Zamboni @ 2021-03-07 12:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
Hi Juan Manuel,
Thanks for sharing this - the output looks very nice.
I think with Org and a setup like you describe, we are one step closer to
separating content (what) from form (how) in a document. This was one of
the original goals of LaTeX, but of course in a LaTeX document much of the
"how" is still visible through the "what". With Org the separation becomes
clearer, by hiding the LaTeX structures (almost) completely, and by
allowing to produce multiple formats from the same source document.
I have done something similar with my books, which I publish through
Leanpub. I keep the source of each book in Org, and from there the exporter
takes care of producing the Leanpub markup and format, which in turn takes
care of converting it to PDF, ePub or other formats.
Best,
--Diego
On Sat, Mar 6, 2021 at 8:35 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I would like to share here two samples of one of the most intense uses
> that I give Org Mode: for typesetting, layout and editorial design. In
> other words, I use Org (and Org-Publish) where publishers today use DTP
> proprietary software like InDesign or QuarkXpress (a type of software,
> on the other hand, that was never intended to compose books but rather
> magazines, posters, brochures and so on). The samples are from a book
> on classical philology, recently published here in Spain, and from a
> fairly extensive dictionary, still work in progress:
>
> https://imgur.com/gallery/yxAVkrY
>
> Naturally, what acts in the background here is TeX and LaTeX
> (specifically Lua(La)TeX), so what I really do is use Org and
> Org-Publish as a sort of high-level interface for LaTeX. But I don't
> mean to avoid LaTeX: in fact, I've been working with LaTeX for a long
> time. I like LaTeX and behind these jobs there is a lot of LaTeX code.
> But Org gives me a much more light and productive workflow, allowing me
> to work at two levels.
>
> The main advantages that I see for this workflow with Org/Org-Publish
> are:
>
> 1. Lightness: LaTeX is too verbose.
> 2. Control of the composition process at various points. One of the
> qualities of LuaTeX is the possibility to control TeX primitives
> through scripts in Lua, and to act at various points in the pre- or
> post-process. But I have realized that with the happy fusion of Elisp
> and Org we can be much more precise and "surgical" ;-). Here,
> Org/LaTeX is much more powerful than LuaLaTeX.
> 3. Org's synaptic and org-anizational ability to control and manage the
> entire process of the creation of a book, from when the originals are
> received until everything is prepared to send to the printer.
> 4. An unique origin. The book can be produced on paper from a single
> source, but you can also export, from that source consistently, to
> other formats (HTML or Epub).
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 3585 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org as a book publisher
2021-03-07 12:08 6% ` Diego Zamboni
@ 2021-03-07 13:15 0% ` Vikas Rawal
2021-03-07 16:03 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Vikas Rawal @ 2021-03-07 13:15 UTC (permalink / raw)
To: Diego Zamboni; +Cc: Juan Manuel Macías, orgmode
A few years ago, I had produced this book entirely on orgmode: https://cup.columbia.edu/book/ending-malnutrition/9789382381648. The source files of the book are here: https://github.com/vikasrawal/endingmalnutrition.
This was some years back, and there has been some change in the org mode syntax since then and the files would need some fixing before they could be compiled with the current versions of orgmode.
Vikas
On Sun, Mar 07, 2021 at 01:08:20PM +0100, Diego Zamboni wrote:
> Hi Juan Manuel,
>
> Thanks for sharing this - the output looks very nice.
>
> I think with Org and a setup like you describe, we are one step closer to
> separating content (what) from form (how) in a document. This was one of
> the original goals of LaTeX, but of course in a LaTeX document much of the
> "how" is still visible through the "what". With Org the separation becomes
> clearer, by hiding the LaTeX structures (almost) completely, and by
> allowing to produce multiple formats from the same source document.
>
> I have done something similar with my books, which I publish through
> Leanpub. I keep the source of each book in Org, and from there the exporter
> takes care of producing the Leanpub markup and format, which in turn takes
> care of converting it to PDF, ePub or other formats.
>
> Best,
> --Diego
>
>
>
> On Sat, Mar 6, 2021 at 8:35 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
> > Hi,
> >
> > I would like to share here two samples of one of the most intense uses
> > that I give Org Mode: for typesetting, layout and editorial design. In
> > other words, I use Org (and Org-Publish) where publishers today use DTP
> > proprietary software like InDesign or QuarkXpress (a type of software,
> > on the other hand, that was never intended to compose books but rather
> > magazines, posters, brochures and so on). The samples are from a book
> > on classical philology, recently published here in Spain, and from a
> > fairly extensive dictionary, still work in progress:
> >
> > https://imgur.com/gallery/yxAVkrY
> >
> > Naturally, what acts in the background here is TeX and LaTeX
> > (specifically Lua(La)TeX), so what I really do is use Org and
> > Org-Publish as a sort of high-level interface for LaTeX. But I don't
> > mean to avoid LaTeX: in fact, I've been working with LaTeX for a long
> > time. I like LaTeX and behind these jobs there is a lot of LaTeX code.
> > But Org gives me a much more light and productive workflow, allowing me
> > to work at two levels.
> >
> > The main advantages that I see for this workflow with Org/Org-Publish
> > are:
> >
> > 1. Lightness: LaTeX is too verbose.
> > 2. Control of the composition process at various points. One of the
> > qualities of LuaTeX is the possibility to control TeX primitives
> > through scripts in Lua, and to act at various points in the pre- or
> > post-process. But I have realized that with the happy fusion of Elisp
> > and Org we can be much more precise and "surgical" ;-). Here,
> > Org/LaTeX is much more powerful than LuaLaTeX.
> > 3. Org's synaptic and org-anizational ability to control and manage the
> > entire process of the creation of a book, from when the originals are
> > received until everything is prepared to send to the printer.
> > 4. An unique origin. The book can be produced on paper from a single
> > source, but you can also export, from that source consistently, to
> > other formats (HTML or Epub).
> >
> > Best regards,
> >
> > Juan Manuel
> >
> >
^ permalink raw reply [relevance 0%]
* Re: Org as a book publisher
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
@ 2021-03-07 15:57 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-07 15:57 UTC (permalink / raw)
To: M. ‘quintus’ Gülker; +Cc: orgmode
Hi Quintus:
Thank you very much for your comments.
M. ‘quintus’ Gülker <post+orgmodeml@guelker.eu> writes:
> [...] Many people seem to use org rather than direct LaTeX because they
> dislike LaTeX's syntax or find LaTeX too complex, which I never really
> understood. But you make some great points for why this combination is
> useful other than for that reason.
I think Org does a good job with what it offers out of the box for
`simple' documents, when the user also does not have a special interest
in LaTeX code and typographic `refinement'. But as the document becomes
more and more complex, there is a duty to study LaTeX and learn to write
code in LaTeX (even in pure TeX, if things get too demanding); and also
to study the documentation of the packages involved, because the great
power of LaTeX lies in its rich and extensive package ecosystem (two or
three new packages always appear every week!). If Org was a complete
translation of everything that each LaTeX package is capable of, then
Org would become as (needlessly) complex as LaTeX. The good thing about
Org is that it provides us with the tools needed to work with our LaTeX
code in the background. A simple example that comes to me now are the
lists, which in LaTeX can be managed in a very clean way with packages
like enumitem. In an Org document it would then be enough to put before
a list `#+ATTR_LaTeX: :options [enumitem options]' (or to write a
replacement macro), but of course the user have to read the enumitem
documentation...
(By the way, it seems that a fellow 'co-lister' is working on an Org to
Context exporter: https://github.com/Jason-S-Ross/ox-context/)
> For those who still use pdfLaTeX rather than LuaLaTeX (probably due to
> Microtype) there is not even an equivalent available.
Well, Microtype can already be used in LuaLaTeX. Except for a few minor
limitations, protrusion and expansion properties work well. In fact I
recently wrote a custom table of protrusion values for a font, and
microtype reads them perfectly in LuaLaTeX. In general nowadays the
migration from pdfTeX to LuaTeX is quite smooth, and it is worth it, for
various reasons: for example, there are a few cool new packages that
take advantage of LuaTeX. And there is also the LuaTeX ability to use
otf fonts and manage opentypes features. XeTeX can do that too, but
with LuaTeX we can even define new otf features on the fly, in Lua, for
a document (like kerning, contextual substitution, etc.) and apply them
to a certain font, without need to edit that font with a dedicated
software (fontforge).
But yeah, for pre-/post-process control I prefer Elisp/Org a thousand
times over Lua :-) Recently I needed to modify certain combining
diacritical marks only in the italics, and with Org it's a delight to do
that (writing a filter for org-export-filter-italic-functions)
> [...] May I ask what tooling you use to go from org to Epub?
Ox-epub works reasonably well, in my short experience: I'm afraid I
haven't explored the Epub output much, partly because this is a format
that I do not like, and I have used it for editorial requirements only.
And, in fact, it is a very limited format for certain types of books.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Org as a book publisher
2021-03-07 12:08 6% ` Diego Zamboni
2021-03-07 13:15 0% ` Vikas Rawal
@ 2021-03-07 16:03 8% ` Juan Manuel Macías
2021-03-08 10:46 6% ` Jonathan McHugh
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-07 16:03 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hi Diego,
Thank you very much for your comments.
Diego Zamboni <diego@zzamboni.org> writes:
> I think with Org and a setup like you describe, we are one step closer
> to separating content (what) from form (how) in a document. This was
> one of the original goals of LaTeX, but of course in a LaTeX document
> much of the "how" is still visible through the "what". With Org the
> separation becomes clearer, by hiding the LaTeX structures (almost)
> completely, and by allowing to produce multiple formats from the same
> source document.
I Totally agree. Leslie Lamport originally created LaTeX (as far as I
know) as a simplified way of handling TeX for his own documents, since
the other format of TeX, plainTeX, was quite spartan. Then LaTeX has
grown incredibly thanks to its extensibility qualities: a small kernel
(unlike ConTeXt, which is more monolithic) and a ecosystem of macro
packages. If we make an analogy with the old days of mechanical
printing, I always say that TeX is the typographer, the one who gets his
hands dirty with ink, while LaTeX wears a tie and is in the editorial
design department. TeX works on the merely physical plane, and he is
only interested in how each element on the page is positioned in
relation to other elements. Here the minimum indivisible element would
be the letter, which to TeX's eyes is a box with certain dimensions.
LaTeX lives more on a semantic plane: for LaTeX there is no lines or
letters or paragraphs, but rather headings, heading levels, lists,
quotes, verses, chapters, tables, equations, tables of contents... But,
as you say, in LaTeX you can still see too many gears. With Org we can
work on a lighter and cleaner document. And with a single source for
multiple formats!
Before moving to Org, I applied this `philosophy' to the markdown/pandoc
tandem. But since I migrated to Emacs/Org a few years ago, it's almost
like having superpowers :-D
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Org as a book publisher
@ 2021-03-07 18:30 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-07 18:30 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: orgmode
Hi Arne,
Thank you very much for sharing the code of your book. It seems very
interesting, I have to take a closer look at it. I want to upload to
GitLab all the code of those two books of my samples, but I need to
rearrange it before, as most of that code is in Spanish :-)
But, broadly speaking, my workflow (especially in these books that are
so long) consists of using Org Publish and compiling everything at the
end with the latexmk script. Each part of the book (chapters, or letters
in the case of the dictionary) are Org documents. And then I have
another Org document which works as a master document (which is the one
I compile in the end with latexmk; the rest of the documents are
exported to * .tex using org-publish, and I automate all that process
through a function in Elisp). I have also another Org document just for
the preamble and my LaTeX code (which is tangled to a tex file), another
document only with the Elisp code involved in the process of the books
(export filters) and, finally, a .setup file. I also add a * .xdy file,
since I use xindy for the index, instead of makeindex. The xdy file is
in Common Lisp, and unfortunately I don't have much knowledge of CL,
but I manage for a few adjustments.
Of course, some Emacs packages are very useful to me too, like the
excellent Org-Ref, Magit or Projectile.
Best regards,
Juan Manuel
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> Hi Juan,
>
> I’ve been going that route for a few years now, and I setup an autotools
> pipeline with all the little tweaks and hacks I needed to make
> everything work well together.
>
> I’m using LaTeX (pdflatex), scribus, calibre and imagemagick to publish
> a roleplaying book with charactersheet,
>
> Maybe some of it can help you. The entrypoints are the Makefile, the
> setup, and the configure.ac (for the hacks):
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/Makefile.am
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/basesetup.tex
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews30setup.tex
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews30setup.el
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/configure.ac
>
> The main document is
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews.org
>
> I also have some derived documents that use the included tables as data.
> Most complex example:
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in
>
>
> Best wishes,
> Arne
^ permalink raw reply [relevance 8%]
* Re: Org as a book publisher
[not found] ` <87ft16hn62.fsf@emailmessageidheader.nil>
@ 2021-03-07 20:20 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-07 20:20 UTC (permalink / raw)
To: Bob Newell; +Cc: orgmode
Hi Bob, thank you for your comment.
Bob Newell <bobnewell@bobnewell.net> writes:
> Aloha,
>
> Thank you for your interesting and useful post.
>
> I must really look into your examples and process. I have
> published quite a number of books with LaTeX but my process
> has been to write in org-mode, then export, and do all the
> design and typesetting directly in LaTeX. I end up with a good
> result but I would really rather work more in org-mode.
>
> Layouts require a lot of fine-tuning, particularly complex
> layouts with multiple columns. If some or most of that could
> be accomplished in org-mode, it would be a great benefit.
Multiple column layout, for example, can be achieved from Org with a
special block (and loading the multicol package). For example:
#+LaTeX_Header: \usepackage{multicol}
#+ATTR_LaTeX: :options {2}
#+begin_multicols
...
#+end_multicols
As I mentioned in a previous message, I have to organize and clean all
the code in those two books of my samples, and upload it to GitLab, in
case it could be useful to someone...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org as a book publisher
2021-03-07 16:03 8% ` Juan Manuel Macías
@ 2021-03-08 10:46 6% ` Jonathan McHugh
0 siblings, 0 replies; 200+ results
From: Jonathan McHugh @ 2021-03-08 10:46 UTC (permalink / raw)
To: emacs-orgmode
To build on your analogy, would Tikz be the Graphics Designer?
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Diego,
>
> Thank you very much for your comments.
>
> Diego Zamboni <diego@zzamboni.org> writes:
>
>> I think with Org and a setup like you describe, we are one step closer
>> to separating content (what) from form (how) in a document. This was
>> one of the original goals of LaTeX, but of course in a LaTeX document
>> much of the "how" is still visible through the "what". With Org the
>> separation becomes clearer, by hiding the LaTeX structures (almost)
>> completely, and by allowing to produce multiple formats from the same
>> source document.
>
> I Totally agree. Leslie Lamport originally created LaTeX (as far as I
> know) as a simplified way of handling TeX for his own documents, since
> the other format of TeX, plainTeX, was quite spartan. Then LaTeX has
> grown incredibly thanks to its extensibility qualities: a small kernel
> (unlike ConTeXt, which is more monolithic) and a ecosystem of macro
> packages. If we make an analogy with the old days of mechanical
> printing, I always say that TeX is the typographer, the one who gets his
> hands dirty with ink, while LaTeX wears a tie and is in the editorial
> design department. TeX works on the merely physical plane, and he is
> only interested in how each element on the page is positioned in
> relation to other elements. Here the minimum indivisible element would
> be the letter, which to TeX's eyes is a box with certain dimensions.
> LaTeX lives more on a semantic plane: for LaTeX there is no lines or
> letters or paragraphs, but rather headings, heading levels, lists,
> quotes, verses, chapters, tables, equations, tables of contents... But,
> as you say, in LaTeX you can still see too many gears. With Org we can
> work on a lighter and cleaner document. And with a single source for
> multiple formats!
>
> Before moving to Org, I applied this `philosophy' to the markdown/pandoc
> tandem. But since I migrated to Emacs/Org a few years ago, it's almost
> like having superpowers :-D
>
> Best regards,
>
> Juan Manuel
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 6%]
* Nested macros and fontification
@ 2021-03-15 17:10 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-15 17:10 UTC (permalink / raw)
To: orgmode
Hi,
I make heavy use of replacement macros, and often my Org documents are
full of nested macros (in the 'LaTeX way') throughout the text. The
problem is that `org-fontify-macros' breaks the macro fontification when
it is a nested construction.
I've found a simple high level solution that consists in ensuring that the
macros have a look identical to normal text (in my theme):
(set-face-attribute org-macro nil :bold nil :foreground black)
And then I only highlight the macro boundaries with `highlight-regexp'. I
think that this gives me a more legible and consistent text, without
that 'rainbow effect' that many themes apply to macros. I share a couple
of samples, in case this little solution is helpful to someone who also
uses a lot of (nested) replacement macros:
https://imgur.com/a/fSPHH0w
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-17 22:07 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-17 22:07 UTC (permalink / raw)
To: Atlas Cove; +Cc: orgmode
Hi,
Atlas Cove <Atlas48@gmx.com> writes:
> Code-wise, the use of the '\\' symbol is only tentative, as I
> understand that '\' has special meaning elsewhere in org's syntax, (I
> was even going to submit a patch to add two special symbols somewhere
> down the line). '\\' (or whatever symbol is decided on) would cause
> the org parser to concatenate the next line into the outputted
> previous cell, rendering the output of the first example identical to
> the second example.
I agree that what you are commenting on is the great problem of Org Mode
tables. Just a question. If I have understood it correctly, with this
new syntax you propose, should Org understand all the 'concatenated
text'
Very Citrusy! Very \\
nice indeed!
as a single row (and not as multiple rows)? If so that would be
great, since the best way to deal with this kind of tables with a lot of
text in LaTeX is with the tabularx package. For example, I would export
your table like this:
#+begin_src org
,#+LaTeX_Header:\usepackage{tabularx,array}
,#+ATTR_LaTeX: :environment tabularx :align l>{\raggedright\arraybackslash}Xl :width .6\textwidth :center t
| Name | Description | Price |
|--------------+-------------------------------------------------------+-------|
| Orange Juice | Very Citrusy! Very nice indeed! ... and a lot of text | 5.00 |
| Grape Juice | It's like wine, but you can have it all day! | 6.00 |
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-18 15:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-18 15:15 UTC (permalink / raw)
To: Atlas Cove; +Cc: orgmode
Atlas Cove <Atlas48@gmx.com> writes:
> In effect, yes. I'm proposing it as a syntax addition to make it easier to read, export, and manage, larger tables.
> I'm unsure if this would fit within the scope of org, but [[https://github.com/RedBug312/markdown-it-multimd-table][other projects]],
> like [[https://fletcher.github.io/MultiMarkdown-6/MMD_Users_Guide.html#tables][MultiMarkdown]] have exactly what I want in terms of table use.
> Since I've already proposed a single, solitary addition to org, we won't discuss all of those nice features /just/ yet!
Thanks for your clarification. I strongly support your proposal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-18 22:41 10% ` Juan Manuel Macías
2021-03-19 8:08 5% ` tomas
2021-03-20 22:49 6% ` Samuel Wales
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-18 22:41 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> From watching these discussions in the past, I think the big stumbling
> block is how easily multi-row columns can be added and maintained in the
> various export formats. Some are easy, like HTML, but others are less
> so. In particular, I know from my many years working with Latex,
> multi-row columns are not straight-forward. There are lots of edge cases
> to deal with and it is hard to get a consistent result programatically.
>
> Proposals like this one can seem simple and straight-forward on the
> surface. However, implementation is another matter. All of the exporters
> will need to be updated to handle this new syntax and it will probably
> take a fair bit of work to handle it correctly in just plain org files
> (formatting, highlighting etc).
I don't know if anyone has come up with this other possibility: if the
problem is (usually) the inconvenience of editing cells with a lot of
text within an Org document (since when exporting to LaTeX for example,
it makes no difference whether the cell content is on a single line, if
the tabularx package is used properly), then the possibility of editing
a cell in a dedicated buffer would be very practical here. A kind of
`org-edit-special' for cells... That could be combined with
`org-table-toggle-column-width'.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-18 22:41 10% ` Juan Manuel Macías
@ 2021-03-19 8:08 5% ` tomas
2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-20 22:49 6% ` Samuel Wales
1 sibling, 1 reply; 200+ results
From: tomas @ 2021-03-19 8:08 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
On Thu, Mar 18, 2021 at 11:41:11PM +0100, Juan Manuel Macías wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
> > From watching these discussions in the past, I think the big stumbling
> > block is how easily multi-row columns can be added and maintained in the
> > various export formats [...]
> I don't know if anyone has come up with this other possibility: if the
> problem is (usually) the inconvenience of editing cells with a lot of
> text within an Org document (since when exporting to LaTeX [...]
I think this point is very important: "multi-row" is ambiguous.
Does it mean the rendering in Org? In someother output format? Are the
row breaks chosen by the user (and thus they have /some/ "meaning") or
are they chosen by some rendering mechanism (word wrap, perhaps
hyphenation)?
> the possibility of editing a cell in a dedicated buffer would be very
> practical here.
If the aim is "just rendering in Org" and "breaks have no special
meaning" (so each render is allowed to re-flow), then your approach
makes sense (I think Org table has something like that: you can
set the column width and shrink/expand the column appropriately.
Personally, I've found that somewhat awkward, so I don't use it,
but OTOH I'm not a heavy table user: perhaps that's why).
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 8:08 5% ` tomas
@ 2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-19 8:53 5% ` tomas
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-19 8:44 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hi Tomas,
<tomas@tuxteam.de> writes:
> If the aim is "just rendering in Org" and "breaks have no special
> meaning" (so each render is allowed to re-flow), then your approach
> makes sense (I think Org table has something like that: you can
> set the column width and shrink/expand the column appropriately.
> Personally, I've found that somewhat awkward, so I don't use it,
> but OTOH I'm not a heavy table user: perhaps that's why).
I was writing yesterday some rudimentary code (just a proof of concept)
and I've made this screencast:
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 8:44 10% ` Juan Manuel Macías
@ 2021-03-19 8:53 5% ` tomas
2021-03-19 9:22 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: tomas @ 2021-03-19 8:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
On Fri, Mar 19, 2021 at 09:44:48AM +0100, Juan Manuel Macías wrote:
> Hi Tomas,
[...]
> I was writing yesterday some rudimentary code (just a proof of concept)
> and I've made this screencast:
>
> https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
Looks nice. And for a heavy table user, it might be useful.
It seems you are in the "table row is a big unstructured text" camp.
For my case, as I said, I'm not a heavy table user anyway.
Opening another window is (to me, at least) so disruptive
that I'd be motivated to find alternatives (I very rarely
use C-c ', org-edit-special for source blocks for the same
reason).
But I can envision people needing that badly.
My post was rather a warning that "multi-line" will mean
different things to different people.
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 8:53 5% ` tomas
@ 2021-03-19 9:22 9% ` Juan Manuel Macías
2021-03-19 10:14 6% ` tomas
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-19 9:22 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> My post was rather a warning that "multi-line" will mean
> different things to different people.
Yes I agree. It is not the same as how a table is represented in Org and
how it should be rendered when exported to some typographic format like
(let's say) LaTeX. I think also 'multi-line' is a very imprecise concept
for Org tables. If we are talking about a cell whose content is a
paragraph, then for LaTeX it is no problem, with the help of the
tabularx package (in these contexts it is the best solution).
The problem here (IMHO) is a problem of discomfort of edit within Org,
when the cell has a lot of text and when we are under the 'tyranny' of
the single line. Luckily it is not a very extended issue, and the tables
in Org are much easier to view and edit than in LaTeX code, when it
comes to simple cells. What happens is that the LaTeX's `tabular(x)'
environment encompasses many more (typographic) contexts than the
concept of `table' in Org. It is a translation problem between Org and
LaTeX and vice versa...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 9:22 9% ` Juan Manuel Macías
@ 2021-03-19 10:14 6% ` tomas
2021-03-19 10:53 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: tomas @ 2021-03-19 10:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Fri, Mar 19, 2021 at 10:22:20AM +0100, Juan Manuel Macías wrote:
> tomas@tuxteam.de writes:
>
> > My post was rather a warning that "multi-line" will mean
> > different things to different people.
>
> Yes I agree. It is not the same as how a table is represented in Org and
> how it should be rendered when exported to some typographic format like
> (let's say) LaTeX [...]
Exactly :-)
> The problem here (IMHO) is a problem of discomfort of edit within Org,
> when the cell has a lot of text and when we are under the 'tyranny' of
> the single line.
I understood that this is your focus. And it's IMHO a good idea to
separate things and solve one at a time.
For export formats, there could be (yet another) "signal" to convey
"new paragraph here" which then is the exporter's job. Perhaps an
empty line (as is traditional in TeX) or something else.
But that's another building site :)
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 10:14 6% ` tomas
@ 2021-03-19 10:53 9% ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
2021-03-19 13:43 6% ` tomas
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-19 10:53 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> For export formats, there could be (yet another) "signal" to convey
> "new paragraph here" which then is the exporter's job. Perhaps an
> empty line (as is traditional in TeX) or something else.
I think that signal would be a good solution within a single line. For
example, for an emergency a simple macro would suffice, something as:
#+MACRO: par @@latex:\par{}@@
Anyway, I suspect that Org tables are not originally intended for such a
'literary' content :-) ... LaTeX tabular(x) environment and Org tables
have in common that they are plain text, but that’s where the
similarities end. Org tables are visual (close to the WYSIWYG concept),
which is why they are wonderful when it comes to mere data tables (and n
files x n rows). The LaTeX tabular environment is crude, it is not
'visual' (except for the facilities provided by the editor), and when
the table becomes large and complex it can be a torture working in
there... So perhaps (IMHO) the solution to edit a cell in a dedicated
buffer could be the least traumatic in complex cells, in case one wants
to avoid going crazy by editing this kind of huge and literary tables in
LaTeX ;-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 10:53 9% ` Juan Manuel Macías
@ 2021-03-19 11:08 12% ` Juan Manuel Macías
2021-03-19 13:43 6% ` tomas
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-19 11:08 UTC (permalink / raw)
To: tomas; +Cc: orgmode
* sorry for the typo. I meant "...n columns x n rows..."
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ... LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end. Org tables are visual (close to the WYSIWYG concept),
> which is why they are wonderful when it comes to mere data tables (and n
> files x n rows). The LaTeX tabular environment is crude, it is not
> 'visual' (except for the facilities provided by the editor), and when
> the table becomes large and complex it can be a torture working in
> there... So perhaps (IMHO) the solution to edit a cell in a dedicated
> buffer could be the least traumatic in complex cells, in case one wants
> to avoid going crazy by editing this kind of huge and literary tables in
> LaTeX ;-)
^ permalink raw reply [relevance 12%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 10:53 9% ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
@ 2021-03-19 13:43 6% ` tomas
2021-03-19 15:07 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: tomas @ 2021-03-19 13:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
On Fri, Mar 19, 2021 at 11:53:14AM +0100, Juan Manuel Macías wrote:
> tomas@tuxteam.de writes:
>
> > For export formats, there could be (yet another) "signal" to convey
> > "new paragraph here" which then is the exporter's job. Perhaps an
> > empty line (as is traditional in TeX) or something else.
>
> I think that signal would be a good solution within a single line. For
> example, for an emergency a simple macro would suffice, something as:
>
> #+MACRO: par @@latex:\par{}@@
Yes, something like that. My point was that it probably makes sense to
separate concerns here.
> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ...
That's right. OTOH, people will try to stretch it in every conceivable
direction. That's in a way Org's biggest strength (and at the same time
its biggest weakness :)
> LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end [...]
Rigth. (La)TeX is a typesetting language. Cool things can be done,
but they have a cost.
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 13:43 6% ` tomas
@ 2021-03-19 15:07 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-19 15:07 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> [...] My point was that it probably makes sense to separate concerns
> here.
Yes, that separation is essential. I agree.
> That's right. OTOH, people will try to stretch it in every conceivable
> direction. That's in a way Org's biggest strength (and at the same time
> its biggest weakness :)
Great truth! I always try to take things to the extreme :-D, and I
continue thinking that Org is (among many other things) an excellent
'interface' for LaTeX (maybe the best). But I have to admit that a table
with a lot of complexity is a special case when maybe you have to write
LaTeX code, and get lost between all those & and backslashes, at least
if the goal is the typographic refinement. The greatest power of Org
resides in his lightness and in its chameleon versatility, but his worst
temptation may be to become in a (poor) LaTeX 'translation'.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-20 10:40 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-20 10:40 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> It has also been stated that the Latex exporter won't be a problem as
> tabularx (and other Latex packages) will just handle this. Sadly, I
> don't think it is that simple. I have used that package a lot over the
> years and there have been times I've had to render tables with
> multiple columns and rows. While the various latex table like packages
> do provide a much better outcome for tables with more complex cell
> structure, it is rare that you don't need to do a fair amount of
> tweaking to actually get good looking complex tables. Handling a cell
> with a couple of lines may be fine, but it is very easy to hit the
> limits of what the package can handle without some tweaking. This is
> where I think things begin to fall down. My suspicion is that the
> amount of work needed to make the Latex exporter handle the majority
> of common use cases for this new syntax is much larger and more
> complex than it seems and getting this to work reliably and
> consistently will be extremely difficult.
tabularx does a fairly acceptable job out of the box on tables whose
cells have complex or 'multi-line' content, such as paragraphs. But,
naturally, it all depends on the context and scenarios: table, page
dimensions, book type and many more factors. The typography, when
demanding, is the art of exceptions. And I think this is valid even in
such an 'automated' tool like LaTeX (fortunately, LaTeX and TeX are also
very ductile, if you know the code well).
In any case, I agree that it would not be a good idea to translate the
LaTeX tabular environment, with all its nuances, to Org tables. In
addition to the fact that Org would be burdened with a unnecessary
complexity, is the fact that the syntax of both types of tables differ
essentially. Org tables have a more visual character; the tabular
environment is a pure "what you see is what you mean".
In a tabular environment I see no problem in writing something like
this row (ugly, but acceptable) in 3 lines:
#+begin_src latex
lorem & Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin
quam nisl, tincidunt et, mattis eget, convallis nec, purus & ipsum \\
#+end_src
But in an Org table I don't see how it could be done without messing up
the spirit of its syntax ... that's why I think (IMHO) the least
traumatic option, in cases where cells have 'a lot of content', is the
possibility of edit cells in a dedicated buffer, like this proof of
concept that I did:
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
And if the table is very complex then I don't see any other option than
writing directly the LaTeX code (in case the intended target is only
LaTeX/PDF).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-18 22:41 10% ` Juan Manuel Macías
2021-03-19 8:08 5% ` tomas
@ 2021-03-20 22:49 6% ` Samuel Wales
2021-03-21 8:43 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Samuel Wales @ 2021-03-20 22:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Tim Cross, orgmode
i like that. such an org edit special type feature could efven in
principle work for a column or a row all at once.
On 3/18/21, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> From watching these discussions in the past, I think the big stumbling
>> block is how easily multi-row columns can be added and maintained in the
>> various export formats. Some are easy, like HTML, but others are less
>> so. In particular, I know from my many years working with Latex,
>> multi-row columns are not straight-forward. There are lots of edge cases
>> to deal with and it is hard to get a consistent result programatically.
>>
>> Proposals like this one can seem simple and straight-forward on the
>> surface. However, implementation is another matter. All of the exporters
>> will need to be updated to handle this new syntax and it will probably
>> take a fair bit of work to handle it correctly in just plain org files
>> (formatting, highlighting etc).
>
> I don't know if anyone has come up with this other possibility: if the
> problem is (usually) the inconvenience of editing cells with a lot of
> text within an Org document (since when exporting to LaTeX for example,
> it makes no difference whether the cell content is on a single line, if
> the tabularx package is used properly), then the possibility of editing
> a cell in a dedicated buffer would be very practical here. A kind of
> `org-edit-special' for cells... That could be combined with
> `org-table-toggle-column-width'.
>
> Best regards,
>
> Juan Manuel
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [relevance 6%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-20 22:49 6% ` Samuel Wales
@ 2021-03-21 8:43 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-21 8:43 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Hi Samuel,
Samuel Wales <samologist@gmail.com> writes:
> i like that. such an org edit special type feature could efven in
> principle work for a column or a row all at once.
I like the idea of being able to edit rows or columns as well...
As I mentioned in a previous message, I made this rudimentary proof of
concept (only with cells):
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
The idea is that the content of the cell would be 'filled' while it is in
the edit buffer and, back to the cell, it would be a single line again.
Certain marks (in my sample it is a simple macro (nl = latex \newline)
would cause a line break in the edit buffer, to facilitate editing.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Items with emphasis marks are not sorted properly in a list
@ 2021-03-22 21:59 10% Juan Manuel Macías
2021-03-23 8:36 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-22 21:59 UTC (permalink / raw)
To: orgmode
Hi,
Consider this list:
- vol.
- adj.
- /circa/
- /vid./
If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list'
doesn't sort correctly items that contain an emphasis mark:
- /circa/
- /vid./
- adj.
- vol.
I don't know if there is any solution to this, or if I'm doing something wrong...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Items with emphasis marks are not sorted properly in a list
2021-03-22 21:59 10% Items with emphasis marks are not sorted properly in a list Juan Manuel Macías
@ 2021-03-23 8:36 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-23 8:36 UTC (permalink / raw)
To: orgmode
Hello again:
I think I have found where the problem is. On line 7 of
`org-sort-remove-invisible' there are two spurious spaces (in the `format'
expression):
7 org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
When the spaces are removed, then the items with emphasis marks are
sorted correctly in the list:
7 org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
Can this be a fix? Or were those spaces there for any other reason?
Best regards,
Juan Manuel
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> Consider this list:
>
> - vol.
> - adj.
> - /circa/
> - /vid./
>
> If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list'
> doesn't sort correctly items that contain an emphasis mark:
>
> - /circa/
> - /vid./
> - adj.
> - vol.
>
> I don't know if there is any solution to this, or if I'm doing something wrong...
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 13%]
* Re: "Org" source blocks and minted
@ 2021-03-24 4:18 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-24 4:18 UTC (permalink / raw)
To: Michael Gauland; +Cc: orgmode
Hi Mike,
Michael Gauland <mikelygee@gmail.com> writes:
> I want to include an "org" source block in a document as an example,
> and have it formatted with minted. Unfortunately, minted doesn't seem
> to recognize "org" as a language,and the block is missing in the
> resulting PDF. For the moment, I've changed this to a "text" source
> block, but it would be nice to have syntax highlighting in the export.
>
> Have any of you done this, or something similar?
>
> Kind regards,
> Mike
>
You can write your own pygments lexer:
https://pygments.org/docs/lexerdevelopment
But it seems that someone already did the work of writing a lexer for
Org Mode:
https://github.com/or/pygments-orgmode-lexer
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* An interesting LaTeX package
@ 2021-03-25 9:40 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-25 9:40 UTC (permalink / raw)
To: orgmode
Hi all,
This is not directly related to Org-Mode (apologies for the light
off-topic), but I thought this new LaTeX package uploaded to CTAN could
be of interest to those who regularly export from Org to LaTeX and want
to get a document as 'perfect' as possible, typographically speaking ;-)
The Lua-typo package (according to its description): "tracks common
typographic flaws in LuaLaTeX documents, especially widows, orphans,
hyphenated words split over two pages, consecutive lines ending with
hyphens, paragraphs ending on too short lines, etc."
(https://ctan.org/pkg/lua-typo).
This package can detect any of the following scenarios (taken from the
package documentation):
- paragraph’s last line nearly full?
- paragraph’s last line too short?
- nearly empty page (just a few lines)?
- overfull lines?
- underfull lines?
- widows (top of page)?
- orphans (bottom of page)
- hyphenated word split across two pages?
- too many consecutive hyphens?
- paragraph’s last full line hyphenated?
- short words (1 or 2 chars) at end of line?
- same (part of) word starting two consecutive lines?
- same (part of) word ending two consecutive lines?
It should be noted that the package works only in LuaLaTeX, and that it
highlights flaws only (in draft mode), but does not correct them. It's
similar to another older package, Impnattypo
(https://ctan.org/pkg/impnattypo).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: "Org" source blocks and minted
@ 2021-03-26 11:55 10% ` Juan Manuel Macías
2021-04-01 8:07 6% ` Michael Gauland
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-26 11:55 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
I really like your approach. And it is org/emacscentric! Minted has
never quite convinced me, and gives me some trouble with certain
packages in LuaLaTeX that I have not been able to solve. Thank you for
this promising alternative.
Best regards,
Juan Manuel
Timothy <tecosaur@gmail.com> writes:
> Juan mentioned an Org lexer exists, but another approach that may be of
> interest is using Emacs' own font-lock. I wrote a package that's like
> HTMLize but works with LaTeX and currently have it sitting in my config.
>
> I plan on submitting a patch to Org at some point on this, but for now:
> - https://github.com/tecosaur/engrave-faces
> - https://tecosaur.github.io/emacs-config/config.html#pretty-code-blocks
>
> Sample output: all the code blocks in
> https://tecosaur.github.io/emacs-config/config.pdf
>
> Since this uses Emacs' font-lock, this means that you can use any
> language that you have a syntax-highlighting-mode for :)
^ permalink raw reply [relevance 10%]
* Re: About exporting
@ 2021-03-29 21:31 7% ` Juan Manuel Macías
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-29 21:31 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Hi,
Ypo <ypuntot@gmail.com> writes:
> LaTeX: I can see some masters here that make professional books, and I
> have some friends that publish scientific papers using LaTeX. But, it
> looks like a like a rabbit hole to me, since even the masters seem to
> have to modify the tex file directly (is this correct?), not being
> sufficient orgmode to culminate the work by itself. And to learn LaTeX
> seems a lifelong activity (almost like "learning" orgmode). BTW, when
> I export to LaTeX although it gets the job done, it sends a lot of
> error messages.
I can tell you some points about my experience with the export to LaTeX,
since that's what I work the most with.
The advantages of using Org instead of "pure" LaTeX (as I already
discussed in another thread) are, IMHO, (a) being able to work on a much
lighter and human readable source (consider, for example, what a list
looks like in Org and what it looks like in LaTeX); and (b) be able to
export to various formats consistently from a single source. Therefore,
it would not be necessary to edit the *.tex document, as we would lose
the latter advantage.
Of course, if you want to use Org to create "refined" documents or books
with LaTeX, you're going to have to learn LaTeX. But "learning LaTeX" is
a imprecise term, since LaTeX has a minimal kernel concept expanded by a
(infinity of) macro packages. Even you can write your own packages, if
you know how to do it. That is, learning latex involves: a) learning
LaTeX syntax (which is not especially arduous) and b) learn the packages
you are going to use (and, therefore, *study its documentation*). The
documentation for each package is on CTAN (https://www.ctan.org/); you
also have, of course, lots of online documentation about LaTeX and TeX
in general. A very good place is https://tex.stackexchange.com/
My personal story has been to use LaTeX for years, until I decided to do
it from Org, but still using LaTeX ...
It also depends on the type of book/document you want to make. When
deals with very large books I usually create the preamble in a Org
document separately, and then I tangle the code in a tex file. And I
also use Org Publish to separate the parts of the book into small
documents (very useful).
Another great thing about Org, on the other hand, is that it has many
resources for control the export process. For example, in a book I'm
working on I noticed that the font has a kerning (separation
between characters) too close between the sign "(" and the italic "f",
producing a rather ugly effect. Simply, with a simple function in Elisp
I was able to readjust that space in the export process (see:
https://orgmode.org/manual/Advanced-Export-Configuration.html#Advanced-Export-Configuration)
All of this that I have discussed, of course, may sound too abstract.
But I can comment in more detail on more specific issues, if you have
any questions :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: About exporting
@ 2021-03-30 11:04 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-30 11:04 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 30 Mar 2021 at 09:06, Tim Cross wrote:
>> The trick with Latex is to go with the flow, not against it.
>
> +1
>
> This is the first thing I tell my students. LaTeX knows much much more
> about how to make documents look good than any of us ever will.
If you don't know anything about typography, perhaps it is preferable to
let LaTeX do its work. With the standard classes (or non-standard ones,
like Koma) and a few packages the result it will always be better than
in a Word-style word processor. For example, TeX justifies paragraphs in
a very more intelligent way, understanding the paragraph as a whole, and
not line by line, as word processors do. In fact, the Plass-Knuth
algorithm (see:
http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf) from TeX was
implemented by Adobe for its layout software InDesign. pdfTeX
implemented, in addition, micro-typographic features (protrusion and
expansion), based on the theories of the great German typographer
Hermann Zapf (author of typefaces such as Palatino and Optima and friend
of Donald Knuth). Those properties were picked up by LuaTeX, which in
turn picked up the legacy of a TeX experimental variant (that I
used quite a bit in the early 2000), Omega, later Aleph.
So, yes, you can get very high-quality documents using LaTeX. And there
is also ConTeXt, another TeX format with a radically different
conception compared to LaTeX, more monolithic and, in certain aspects,
more avant-garde. But that does not mean that LaTeX, used as is, produce
a typographically finished result. LaTeX is the means, not the end. Of
course, through packages we can adjust many things at a high level. An
obvious example is the geometry package, but to establish good page
dimensions you have to know what you are doing... But other things can
only be adjusted by hand, visually, unless someday some AI comes to do
that job ;-)
A very typical example: the \raggedbottom option is almost never
acceptable in a book. The \flushbottom option requires that the height
of the composition box is a multiple of the line spacing. TeX also does
very good work with the vertical stretch gaps (glues), but we also want
to modify them depending on the chosen font, the main text body, etc.
And a penalty of widow and orphan lines will also be desirable. There
are many ways to do it (including packages), but the simplest is to add
a couple of TeX primitives to the preamble, with these values:
\widowpenalty=10000
\clubpenalty=10000
But if we have penalized widows or orphans we will get pages that have
one line less, *unacceptable* in a book. That we will have to fix
manually, probably adding a line to the paragraph (\looseness=1), but it
will depend on the context. If we use LuaTeX we can apply things like
the ones discussed in this thread:
https://tex.stackexchange.com/questions/372062/paragraph-callback-to-help-with-widows-orphans-hand-tuning
There are, in short, many things in a 'standard' LaTeX document that
require fine adjustment. Packages like lua-typo or impnattypo are
helpful in this regard. But some typography skills are required. Of
course, this knowledge is accessible to everyone. There are so many
bibliography, but I would highly recommend the writings of Stanley
Morison, author of the Times Roman and a great theorist of the modern
typography. Of course, as for TeX, the TeX Book is always an almost
obligatory (and exciting) read :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: About exporting
@ 2021-03-30 15:44 7% ` Juan Manuel Macías
2021-03-31 9:59 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-30 15:44 UTC (permalink / raw)
To: Martin Steffen; +Cc: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> In my experience, ith latex, it's possible to write text together for
> well-intended people. Publishing houses tell you ``these are the classes
> and style files (among perhaps others) that you _have_ to use, and also
> do the following...'' (same possible for wisiwyg-editors, I assume),
> and if you don't mess that up (like overwriting the defaults) you have a
> chance to get a uniformely looking output (and on a halfway portable
> platform, like a CTAN compatible latex installation). I cannot imagine
> that publishers would prescibe ``this is the org-settings and features
> you as author must to use to publish with us''.
Unfortunately today the old 'division of powers' that always worked has
been broken in many scenarios: the author writes, the typesetter
composes the book and the publisher publishes it, and neither of them
interferes in the other's work, although all three live together in the
same body. The WYSIWYG word processors have had a lot to do with
distracting the author in untimely typographical concerns by imposing an
unnatural way of writing, where the format is confused with the content
and its structure. And DTP software, on the other hand, which is
intended for magazines and graphic design, have imposed a rather
negligent way of producing books.
Knuth created TeX in the '70s for his own books, because he was
disgusted with the result he was getting from an increasingly poor
publishing industry, in the transition from mechanical printing and
photocomposition to computerized editorial production. But somehow he
also reinvented the printing press of the digital age, since TeX is
first and foremost an emulator of the art and technique of ancient
linotypists, monotypists, typesetters and so on. Lamport wrote LaTeX for
his own documents, as a high-level language for TeX, since TeX only
works on the physical plane, and plainTeX was quite spartan. But time
has shown that LaTeX (and later ConTeXt) is the perfect semantic layer
of TeX. Tex and LaTeX are essentially *typographic* tools, with true
professional demands, but which authors can use on "autopilot" (a very
small part of LaTeX).
However, *I would not recommend anyone to use LaTeX for writing*. A
light markup language is more comfortable and efficient for me. Some
people prefer Markdown, but IMHO, Org Mode represents the most natural
way (aside from paper) to write. It helps me organize my ideas. And when
I write I don't worry about typographical problems at all, although I
work as a professional typesetter. Of course, with LaTeX and its
autopilot (standard classes, basic packages, no direct formatting, no
custom code, etc., etc.) you can do the same. But Org represents one
more step in confort and productivity.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: About exporting
2021-03-30 15:44 7% ` Juan Manuel Macías
@ 2021-03-31 9:59 6% ` Eric S Fraga
2021-03-31 18:28 3% ` Martin Steffen
0 siblings, 1 reply; 200+ results
From: Eric S Fraga @ 2021-03-31 9:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
> However, *I would not recommend anyone to use LaTeX for writing*. A
> light markup language is more comfortable and efficient for me.
Totally agree! Although, over the years, I have written many papers in
LaTeX directly, in the past decade I have increasingly relied on org as
the writing tool. It imposes much less friction on the creative process
and, as you say, it enables better management of the writing task. And,
as it gives direct access to LaTeX when necessary, you lose nothing by
writing in org.
And *tables*! Enough said. :-)
But, as always, YMMV.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
^ permalink raw reply [relevance 6%]
* Re: About exporting
2021-03-31 9:59 6% ` Eric S Fraga
@ 2021-03-31 18:28 3% ` Martin Steffen
0 siblings, 1 reply; 200+ results
From: Martin Steffen @ 2021-03-31 18:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
>>>>> "Eric" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:
Eric> On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
>> However, *I would not recommend anyone to use LaTeX for
>> writing*. A light markup language is more comfortable and
>> efficient for me.
Eric> Totally agree! Although, over the years, I have written many
Eric> papers in LaTeX directly, in the past decade I have
Eric> increasingly relied on org as the writing tool. It imposes
Eric> much less friction on the creative process and, as you say, it
Eric> enables better management of the writing task. And, as it
Eric> gives direct access to LaTeX when necessary, you lose nothing
Eric> by writing in org.
I would not go so far as not recommend latex (over org) for _anyone_ at
all. I for my part will stick with latex for a certain documents; for
others, org is better (has to do with the mentioned creative process,
and other advantages).
However, I write papers heavy in math-notation (in the more theoretical
corners of conmputer science). There is a lot of math discplay (and I
like to rely heavily on macros etc).
For me, part of the preference of latex is the ratio between math and
similar things over ``text''. a blog-like text (not heavy on math), or a
note, or a wiki-like document etc, all that's great with org.
For math-typesetting, that's less of a ``creative flow of ideas
thing''. Of course, as having been mentioned, I can always escape to
latex inline or for displays etc. And I can also import my
macro-definitions etc (and I do that).
But actually, when typing, I think I am faster in latex. There are a
couple of features, I like (and my muscle-memory of my fingers rely in
them) in latex-modes of emacs.
Tab completion for environments and macros, remembering the last
environments I used, support of bibtex (like also completion or showing
the reference). Indentention of environments plus highlighting. And last
not least; if I ``compile'' the document (firing off latex, bibtex, or
index or whatever), the compilation runs in the background. As far as I
do that in org (exporting to pdf), it blocks emacs. Not that it's a
huge delay even, at least for smaller documents, I hate that an editor
or some tool is slower than me, it gets on my nerves if the computer
slows me down. And there is a final thing which (for me) seem to work
better in latex-mode compared to org. That's jumping to the ``next
error'' with some key stroke. That's important, LaTeX's own error
output it quite poor, but jumping to error locations is vital.
I would not be surprised if some of that is somehow supported by org as
well (for TeX), only I have not figured it out, or perhaps I was too
lazy to figure it out how. Too lazy because LateX mode works for me fine
even for challenging and long documents (where for simpler ones or where
the focus is not on typesetting org works).
Martin
Eric> And *tables*! Enough said. :-)
Eric> But, as always, YMMV.
Eric> -- : Eric S Fraga via Emacs 28.0.50, Org
Eric> release_9.4.4-254-g37749c
^ permalink raw reply [relevance 3%]
* Re: About exporting
@ 2021-03-31 18:56 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-31 18:56 UTC (permalink / raw)
To: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> [...] And last not least; if I ``compile'' the document (firing off latex,
> bibtex, or index or whatever), the compilation runs in the background.
> As far as I do that in org (exporting to pdf), it blocks emacs. Not
> that it's a huge delay even, at least for smaller documents, I hate
> that an editor or some tool is slower than me, it gets on my nerves if
> the computer slows me down.
There is the async-export (C-a) option in org-export-dispatcher.
Anyway, I usually use the latexmk script a lot, even with Org
(combined with Org Publish: I export sub-documents to *tex from Org and
compile later with latexmk the master document. latexmk with the -pvc
options is wonderful.
I agree that AUCTeX is excellent; maybe (IMHO) the best LaTeX editor out
there.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: "Org" source blocks and minted
2021-03-26 11:55 10% ` Juan Manuel Macías
@ 2021-04-01 8:07 6% ` Michael Gauland
0 siblings, 0 replies; 200+ results
From: Michael Gauland @ 2021-04-01 8:07 UTC (permalink / raw)
To: emacs-orgmode
Yes, this looks very promising. I'm looking forward to playing with it
when I have more time.
On 27/03/21 12:55 am, Juan Manuel Macías wrote:
> Hi Timothy,
>
> I really like your approach. And it is org/emacscentric! Minted has
> never quite convinced me, and gives me some trouble with certain
> packages in LuaLaTeX that I have not been able to solve. Thank you for
> this promising alternative.
>
> Best regards,
>
> Juan Manuel
>
> Timothy <tecosaur@gmail.com> writes:
>
>> Juan mentioned an Org lexer exists, but another approach that may be of
>> interest is using Emacs' own font-lock. I wrote a package that's like
>> HTMLize but works with LaTeX and currently have it sitting in my config.
>>
>> I plan on submitting a patch to Org at some point on this, but for now:
>> - https://github.com/tecosaur/engrave-faces
>> - https://tecosaur.github.io/emacs-config/config.html#pretty-code-blocks
>>
>> Sample output: all the code blocks in
>> https://tecosaur.github.io/emacs-config/config.pdf
>>
>> Since this uses Emacs' font-lock, this means that you can use any
>> language that you have a syntax-highlighting-mode for :)
>
^ permalink raw reply [relevance 6%]
* Re: About exporting
@ 2021-04-01 14:21 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-01 14:21 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well. And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file. This definitely adds friction!
These days I'm working on a book (a dictionary) of over 1000 pages. The
preamble contains 1813 lines of code (+/-), and is written separately in
a Org document, through literary programming. Contains: a) A lot of
(La)TeX code written (or perpetrated) by me, b) some Lua functions to
control certain parts of the process, c) all the configuration for Xindy
(the indexes) in Common Lisp (inside a filecontents* environment).
Everything, of course, ordered by sections. With this cocktail it seems
that something can go wrong at some point :-) However I find it very
easy to debug having things well separated. And I can always tangle
different versions of the preamble...
As I have already mentioned, I use Org Publish intensively. Some parts
of my Org Publish setup for this project are:
[...]
:base-directory "~/Git/DHTC/libro/org/"
:base-extension "org"
; *.tex files and output
:publishing-directory "~/Git/DHTC/libro/tex/"
:publishing-function org-latex-publish-to-latex
:body-only t
:exclude "DHTC-master\\.org\\|bibli-dhtc\\.org"
Each part of the book is an *org document that I export to *tex using
Org-Publish (:body-only t). And each document only includes at the
beginning:
#+SETUPFILE: diccionario.setup
#+INCLUDE: "elisp"
(that is, a setup file and a file that I have named `elisp' where I include
functions and filters).
And then I have a master document, as simple as possible, where the
preamble and the subdocuments are added through '\input{...}'. I have
defined this macro:
#+MACRO: input (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\input{@@" $1 ".tex" "@@latex:}@@") $1))
And, with a simple Elisp function, I compile the final document (or
parts of it) using latexmk (with `start-process-shell-command'). I add
an argument so that a dedicated buffer is generated with the output of
latexmk. As latexmk runs in interactive mode, every time I do a change
in a subdocument and call Org-Publish again, latexmk rebuilds everything
automatically. The latexmk output is very neat and warns of possible
errors. Also I always have an alternative branch in the repository to do
tests when I put 'experimental' code.
By all this I mean that using LaTeX from Org (but without stopping using
LaTeX) gives me a pretty productive and organized workflow. I recommend
try it out for large books.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-02 18:15 9% Juan Manuel Macías
2021-04-09 22:28 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-02 18:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Hi all,
I have noticed that a couple of (spurious?) spaces in a `format'
expression of `org-sort-remove-invisible' is causing `org-sort-list' not
to sort correctly (alphabetically) the items that contain emphasis marks
in a plain list. I propose this very simple patch to fix that problem.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-sort-remove-invisible_remove_spaces.patch --]
[-- Type: text/x-patch, Size: 494 bytes --]
diff --git a/lisp/org.el b/lisp/org.el
index 04da1afcd..d10cc2f5c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8114,7 +8114,7 @@ Optional argument WITH-CASE means sort case-sensitively."
(replace-regexp-in-string
org-verbatim-re (lambda (m) (format "%s " (match-string 4 m)))
(replace-regexp-in-string
- org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
+ org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
(org-link-display-format s)
t t) t t))
^ permalink raw reply related [relevance 9%]
* Re: Including Email Address in the Reply in Mailing-list
@ 2021-04-02 23:45 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-02 23:45 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> I have no issue with this suggestion and am happy to try and comply.
>
> The challenge for many will be that they either
>
> - need to remember to remove the email details manually (line/header
> automatically added by mail client) while sorting out either
>
> - how to modify mail client for all replies (may not be appropriate for
> non-ML replies), or
>
> - how to modify mail client for just ML replies
> [...]
For Gnus users, one possibility might be:
(defun my-gnus-reply-ml ()
(interactive)
(let*
((message-citation-line-format "%N writes:\n")
(message-citation-line-function 'message-insert-formatted-citation-line))
(gnus-article-reply-with-original)))
...And then assign any free key to gnus-article-mode-map
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: First steps exporting to tex
@ 2021-04-03 12:10 7% ` Juan Manuel Macías
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 12:10 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Hi Ypo,
I think that, as a starting point, the concepts that belong to Org and
those that belong to LaTeX should be separated.
Ypo writes:
> [...]
> 2 template.tex -> this could be added to the SETUPFILE:
> #+LATEX_HEADER: \input{template.tex}. But it seems to have no effect
> on the PDF output. BTW, I can't use emacs HOME path (~/) in the
> input header, like \input{~//export//template.tex}.
The keyword #+LaTeX_Header pass literal LaTeX commands in a single line
to thepreamble. The LaTeX \input{...} command should follow the path of
the file you want include, but I see that you are indicating the path
with a double //. The correct way is \input{~/export/template.tex}
> 3 Another friend told me that .sty templates were the best way.
A *.sty file is what is known in LaTeX jargon as a "package", and it
would come to be the equivalent of what is a *.el file in Emacs,
/mutatis mutandis/. In a sty file you can put whatever you want, but a
different syntax must be used and these files are subject to a series of
good practices. Therefore, a sty file is more indicated to introduce
'heavy' code that you want reuse in other documents (defined commands
and macros, etc.). In short, what comes to be a package ;-) At the user
level, and unless you want to write your own package (see:
https://www.overleaf.com/learn/latex/Writing_your_own_package), it is
almost never necessary.
> 4 I see some people that create customized LaTeX classes and add the
> desired class to the orgmode buffer.
Great care must be taken here. One thing is a LaTeX class, which is
something laborious and complex to write, and another thing what Org
understands for a LaTeX class :-) Classen and the class concept are a
essential component for LaTeX, as a class is the first thing you must
declare in a preamble with the command \documentclass{}. There are the
standard classes (article, book and others) and other ones, more
specialized. A class changes globally the behavior of the document and
all LaTeX commands as \section, \subsection and many more, and add its
own commands.
A 'LaTeX class' for Org is a light translation of the above. It is
actually "what type of LaTeX document you want to get".
You can easily define your own LaTeX 'classes' for Org documents. For
example: I have an 'empty class', to be able to add the entire preamble,
without Org charging me anything before the \begin{document}
(add-to-list 'org-latex-classes
'("empty"
"[NO-DEFAULT-PACKAGES]
[PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
And I have in my ~/.emacs:
(setq org-latex-default-class "empty")
(setq org-latex-default-packages-alist nil)
(setq org-latex-packages-alist nil)
(setq org-latex-hyperref-template nil)
My advice, as has already been commented here, is that you get familiar
with LaTeX for a while, and then see how you can fit LaTeX in your Org
workflow, if that's more productive for you.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: First steps exporting to tex
@ 2021-04-03 17:49 8% ` Juan Manuel Macías
2021-04-03 18:36 4% ` Jean Louis
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-03 17:49 UTC (permalink / raw)
To: William Denton; +Cc: orgmode
William Denton writes:
> [...] and it looks like a published book or journal article!
Something similar I thought, in my student days, when at the early '90 I
saw a document printed in word perfect, just because it had a book
typeface (Times Roman), footnotes and many more fancy stuff. It looked
/almost/ like a book.
With LaTeX something similar happens for the user who is not trained in
professional typesetting. TeX as a typographic engine makes an excellent
work at the 'physical' level, but as we say in Spain, the trees do
not let us see the forest. A LaTeX document produced from standard way
will need (likely) a lot of fine tuning, and a solid typographic culture
acquired by those who check it out.
On the other hand, I think that if an Org user is going to export often
to LaTeX, he should know LaTeX reasonably well. I do not say that he
become a LaTeXpert, but at least the user should have clear which
concepts are from Org and which concepts are from LaTeX. The LaTeX
packages you may need as you want to do more complex things, and how to
use those packages. Etc. On the Org side there are many and excellent
resources to control the export process. But in any translation process
you have to know the source language (Org) and what can be expressed in
the final language (LaTeX) and how. And the the same happens if the
output is HTML, Epub or whatever. I think Org is an excellent tool, full
of possibilities (maybe a lot of them don't explored yet) and wonderful
things, but it is not magic, although its logo is an unicorn ;-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: First steps exporting to tex
2021-04-03 17:49 8% ` Juan Manuel Macías
@ 2021-04-03 18:36 4% ` Jean Louis
2021-04-03 20:46 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Jean Louis @ 2021-04-03 18:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: William Denton, orgmode
* Juan Manuel Macías <maciaschain@posteo.net> [2021-04-03 20:51]:
> William Denton writes:
>
> > [...] and it looks like a published book or journal article!
>
> Something similar I thought, in my student days, when at the early '90 I
> saw a document printed in word perfect, just because it had a book
> typeface (Times Roman), footnotes and many more fancy stuff. It looked
> /almost/ like a book.
>
> With LaTeX something similar happens for the user who is not trained in
> professional typesetting. TeX as a typographic engine makes an excellent
> work at the 'physical' level, but as we say in Spain, the trees do
> not let us see the forest. A LaTeX document produced from standard way
> will need (likely) a lot of fine tuning, and a solid typographic culture
> acquired by those who check it out.
TeX and LaTeX must be prime chose who need professional typesetting.
Org mode offers limited insight into powers of LaTeX.
Org offers quick document creation by using LaTeX and LaTeX may be
used to extend Org. It cannot satisfy all people by default. Each
person may need customization.
Do you have a specific remark on what would be major wrong with the
default LaTeX export from your viewpoint?
For me, I like larger letters and more space on paper. I find it
narrow and not enough legible. But that is not typographically
technical comment.
> On the other hand, I think that if an Org user is going to export often
> to LaTeX, he should know LaTeX reasonably well.
Opposite may be said as well. Exporting to LaTeX may be just a side
effect in order to create a PDF file. Org user may not need nothing
about LaTeX. Even if exporting is often, Org user need not know
nothing about LaTeX. Other converter like `pandoc' also offer
conversion to LaTeX and user need not know nothing about it. That is
the beauty. It does not help the professional though, as professional
must know all the specific details.
> I do not say that he
> become a LaTeXpert, but at least the user should have clear which
> concepts are from Org and which concepts are from LaTeX. The LaTeX
> packages you may need as you want to do more complex things, and how to
> use those packages. Etc. On the Org side there are many and excellent
> resources to control the export process. But in any translation process
> you have to know the source language (Org) and what can be expressed in
> the final language (LaTeX) and how.
What you describe relates to advanced LaTeX users who need good
quality or who have special needs. Average Org user who knows that Org
can export to LaTeX will rather use it as side effect in order to get
PDF file.
> And the the same happens if the
> output is HTML, Epub or whatever. I think Org is an excellent tool, full
> of possibilities (maybe a lot of them don't explored yet) and wonderful
> things, but it is not magic, although its logo is an unicorn ;-)
It is not magic. Yet integration provided by developers brought it to
point that simple Org file, text file, can be quickly converted into
nice PDF documents. It does not matter if files are edited remotely on
mobile devices by using any kind of editor, once file is processed by
Emacs and exported it becomes universally accepted.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/
^ permalink raw reply [relevance 4%]
* Re: How to get a table into a variable in a shell code block?
@ 2021-04-03 19:01 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 19:01 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg and William,
Greg Minshall writes:
> William,
>
> try
>
> #+begin_src shell :results output :var n=numbers
> echo ${n[1]}
> #+end_src
>
> cheers, Greg
I don't know if I'm saying something wrong, but wouldn't it be better
this way?:
#+begin_src shell :results output :var n=numbers
echo ${n[@]}
#+end_src
echo ${n[1]} returns the second element (two) of the list (0, returns
one and 2 returns three)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: First steps exporting to tex
2021-04-03 18:36 4% ` Jean Louis
@ 2021-04-03 20:46 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 20:46 UTC (permalink / raw)
To: Jean Louis; +Cc: orgmode
Hi Jean Louis,
Jean Louis writes:
> Do you have a specific remark on what would be major wrong with the
> default LaTeX export from your viewpoint?
>
> For me, I like larger letters and more space on paper. I find it
> narrow and not enough legible. But that is not typographically
> technical comment.
It would be too long to comment here... The flaws of a typical LaTeX
ouput could be divided into formal defects and orthotypographic defects.
It's not LaTeX's fault (actually TeX and LaTeX represent the greatest
advance in typography since Gutenberg); the problem is that a book needs
a lot of fixes before reaching the printing press. And everything also
depends on each type of book and each book in particular: typography is
the science of exceptions. Luckily, TeX offers a lot of resources and
packages for fine tuning, and LuaTeX even more. I invite you to read the
documentation of these two packages: impnattypo
(https://www.ctan.org/pkg/impnattypo) and lua-typo
(https://www.ctan.org/pkg/lua-typo) where a part of these issues is
discussed.
Anyway, I am not saying that all average users should become experts in
typesetting. I just wanted emphasize that LaTeX is /just/ the tool (like
linotypes and monotypes were in his time) but LaTeX does not do
everything, although his standard output is of very good
quality compared to other systems. But that is so because TeX works very
well, it justifies very well the paragraphs, etc.
> [...]
> Org user may not need nothing about LaTeX. Even if exporting is often,
> Org user need not know nothing about LaTeX. Other converter like
> `pandoc' also offer conversion to LaTeX and user need not know nothing
> about it.
An average Org user does not need to know almost anything about LaTeX if
what he wants is just to produce /simple/ PDF documents. I agree. But
when he wants to do more complex things, he will need to know how to do
them in LaTeX and how to do them also from Org (in case he wants to
continue working in Org: even I work in Org when I do professional
typesetting, because for me Org is, among other things, the /almost/
perfect interface for LaTeX). If Org users get covered eyes with LaTeX
and LaTeX processes, then they will end up filling the Org forums with
questions that should rather be asked in the LaTeX forums (I am not
saying that it should not be asked here, but if no one knows anything
about LaTeX, no one could give answers to problems that are related to
LaTeX and not to Org). Let's imagine this hypothetical case:
User X enters the Org forum Z and asks: "How can I export to PDF with a
two colums layout?"
The correct answer is on the LaTeX side: "you have to use the multicol
package (and read the package documentation, if fine-tuning is
required)",
Once the LaTeX oracle has given its answer, the Org oracle will declare
that a multicols environment can be created in Org with a special block:
#+begin_src org
,#+ATTR_LaTeX: :options {2}
,#+begin_multicols
.............
,#+end_multicols
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: How to expand macro in LaTeX export? How to use different options per export type?
@ 2021-04-03 21:57 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 21:57 UTC (permalink / raw)
To: Jean Louis; +Cc: orgmode
Jean Louis writes:
> Another issue related to this setup is that I would like:
>
> - for HTML export: title:t toc:t
>
> - for LaTeX PDF export: title:nil toc:nil
>
> Is there way to have options different for different exports?
You can do it with a macro like this:
#+MACRO: titletoc (eval (cond ((org-export-derived-backend-p org-export-current-backend 'latex) "#+OPTIONS: title:nil\n#+OPTIONS: toc:nil")((org-export-derived-backend-p org-export-current-backend 'html) "#+OPTIONS: title:t\n#+OPTIONS: toc:t")))
{{{titletoc}}}
...
But maybe it would be better to use a block here:
#+begin_src emacs-lisp :exports results :results raw
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
"#+OPTIONS: title:t\n#+OPTIONS: toc:t")
((org-export-derived-backend-p org-export-current-backend 'html)
"#+OPTIONS: title:nil\n#+OPTIONS: toc:nil"))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: First steps exporting to tex
@ 2021-04-04 11:04 6% ` Ypo
2021-04-04 11:36 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ypo @ 2021-04-04 11:04 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 8063 bytes --]
>>>>>>> El 03/04/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
> Message: 34
> Date: Sun, 04 Apr 2021 00:31:24 +1100
> To:emacs-orgmode@gnu.org
> Subject: Re: First steps exporting to tex
> Message-ID:<871rbr7ag1.fsf@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
>
> Why do you think you need any of this for your 'first steps'. Start by
> just writing your org file and exporting it to LaTeX or pdf. Then, once
> you have your first document, see what you think needs changing and come
> back and ask advice on what you need to do to make the changes you want.
> In your first document, don't use any LaTeX commands, header options or
> anything else - just write your document using standard org mode.
>
> Org already sets up a reasonable starting default. Once you know what
> the default is, then we can discuss what you may need to change. For
> many documents, you may not need to change much at all and you may not
> need any templates - for example, you will likely want to change the
> margin sizes (this is a common request) or you may want to see what some
> of the other 'standard' LaTeX document classes are like. All of this can
> be achieved with just minor configuration of org mode.
>
> The org export to LaTeX only needs to be as complicated as you need it
> to be. Org has variables which can be used to add/remove things from the
> preamble and once you have those configured, you don't have to put
> anything in the org file itself. Start simple and add as you find a need
> rather than try to start with something complex which might not be
> necessary.
>
> -- Tim Cross
Hi Tim
I have been exporting from orgmode to PDF time ago, but very basic PDFs,
playing with some basic options of orgmode. When I tried to produce a
meeting minute with a logo in the heading, I decided that I should learn
better a way of exporting, because the minute meeting was a first
challenge, but many more would come. For example, for that task I
started with this code, which I think it goes far beyond what the "LaTeX
Defaults" can offer (I must yet "play around" a lot with it):
#+BEGIN_SRC
#+options: toc:nil
#+options: num:1
#+options: d:nil
#+export_file_name: BORRAR
#+options: broken-links:mark
#+LaTeX_header_extra: \usepackage{fancyhdr}
#+begin_export LaTeX
\thispagestyle{fancy}
\lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN
CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO ANAGRAMAS/SELLO1_grueso.png}}
\rhead{Student Name: John Doe\\
Student ID: 1234\\
Course: IDB 601 (Fall 2020)}
#+end_export
#+END_SRC
The buffer I exported my meeting notes from has much more information
which is not related with meetings nor with the logo. So I foresaw 3
things:
1. A fast cluttering of the buffers with LaTeX headings would happen,
as I will learn more about LaTeX and I will want to add more and
more packages.
2. A need for flexibility to be able to export different kinds of
documents from the same buffer, ideally achieved just by changing a
line (or few lines) in the buffer. Although, from my example, it
seems that ~#+begin_export...~ contents can't be added in that way.
3. A great potential if it were possible to use already existing, and
well curated, LaTeX templates frictionless through orgmode.
I find quite useful to analyse the default generated TeX file though.
Best regards
>>>>>>> El 03/04/2021 a las 12:15, Martin Steffen escribió:
Good morning, Martin
> For the "preamble" of a latex document, the general setup that comes
> _before_ \begin{document} and before any output is generated, I use
> native latex using instructions like
>
> #+BEGIN_SRC
> #+latex_header: \input{switches}
> #+latex_header: \input{preamble}
> #+latex_header: \input{style/style-common}
> #+latex_header: \input{macros}
> #+END_SRC
Thanks for your input. I'll keep with that.
> As far controlling input is concerned, I also rely on latex-specific
> setting (outside org, also outside emacs), things like environment
> settings like $TEXINPUT, a path-specification, where one can control
> where LaTeX finds (additional) stylefiles, outside of the standard
> ``load-path''.
>
> Thus, I often try to avoid to use hardcoded things, like
>
> >>> \input{~//export//template.tex}
>
> I would use \input{template} (".tex" is not needed) and I make sure, the
> templatex.tex file is included in the $TEXINPUTS-path. Typically, the
> current directory "./" should be included by default (and stuff from
> the latex-installation is also routinely found)
Thanks. But I can read in this post:
https://tex.stackexchange.com/questions/93712/definition-of-the-texinputs-variable
that ~$TEXINPUT~ could give some problems with LuaLaTeX, could it be? It
seems important, since LuaLaTeX is the safe recommendation of our
mailing list pal Juan Manuel Macías [maciaschain@...].
>>>>>>> El 03/04/2021 a las 12:43, Dr. Arne Babenhauserheide escribió:
A pleasure, Arne.
> Alternatively you can use #+INCLUDE: template.org
> to grab more than just the org-setup.
And there you show me a different way: ~#+INCLUDE,~ "competing" with
~\input{}~. What would be the difference?
> Have a look at \DeclareUnicodeCharacter:
> https://www.draketo.de/light/english/emacs/char-not-setup-latex
Does that mean that some symbols must be declared one by one in order to
be exported using LaTeX?
>>>>>>> El 03/04/2021 a las 14:10, Juan Manuel Macías escribió:
Hi, Juan Manuel :-)
> The correct way is \input{~/export/template.tex}
I've already tried that. But it doesn't seem to understand the HOME
directory ~~/~. At least at Windows.
> A *.sty file is what is known in LaTeX jargon as a "package", and it
> would come to be the equivalent of what is a *.el file in Emacs,
> /mutatis mutandis/. In a sty file you can put whatever you want, but a
> different syntax must be used and these files are subject to a series of
> good practices. Therefore, a sty file is more indicated to introduce
> 'heavy' code that you want reuse in other documents (defined commands
> and macros, etc.). In short, what comes to be a package ;-) At the user
> level, and unless you want to write your own package (see:
> https://www.overleaf.com/learn/latex/Writing_your_own_package), it is
> almost never necessary.
So I will keep myself far away from .sty by now.
> Great care must be taken here. One thing is a LaTeX class, which is
> something laborious and complex to write, and another thing what Org
> understands for a LaTeX class :-) Classen and the class concept are a
> essential component for LaTeX, as a class is the first thing you must
> declare in a preamble with the command \documentclass{}. There are the
> standard classes (article, book and others) and other ones, more
> specialized. A class changes globally the behavior of the document and
> all LaTeX commands as \section, \subsection and many more, and add its
> own commands.
>
> A 'LaTeX class' for Org is a light translation of the above. It is
> actually "what type of LaTeX document you want to get".
>
> You can easily define your own LaTeX 'classes' for Org documents. For
> example: I have an 'empty class', to be able to add the entire preamble,
> without Org charging me anything before the \begin{document}
> (add-to-list 'org-latex-classes
> '("empty"
> "[NO-DEFAULT-PACKAGES]
> [PACKAGES]
> [EXTRA]"
> ("\\section{%s}" . "\\section*{%s}")
> ("\\subsection{%s}" . "\\subsection*{%s}")
> ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
> ("\\paragraph{%s}" . "\\paragraph*{%s}")
> ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>
> And I have in my ~/.emacs:
>
> (setq org-latex-default-class "empty")
> (setq org-latex-default-packages-alist nil)
> (setq org-latex-packages-alist nil)
> (setq org-latex-hyperref-template nil)
Thanks for your class. I suppose that "nulls" the orgmode LaTeX export
defaults, so you can control it completely.
Thank you all
[-- Attachment #2: Type: text/html, Size: 12095 bytes --]
^ permalink raw reply [relevance 6%]
* Re: how to export (latex) a image without using figure
@ 2021-04-04 11:17 10% ` Juan Manuel Macías
2021-04-04 11:33 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-04 11:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Try:
#+ATTR_LaTeX: :float nil
#+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
[[./images/dfp_03.png]]
Best regards,
Juan Manuel
Uwe Brauer writes:
> Hi
>
> Currently
>
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> #+NAME: fig:plotcalor23
>
> [[./images/dfp_03.png]]
>
> Gets translated to
>
> \begin{figure}[htbp]
> \centering
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \caption{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
> \end{figure}
>
> For reasons that needs a longer explanation I would need.
>
>
>
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \captionof{figure}{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
>
>
> How can this be achieved?
>
> Thanks
>
> Uwe Brauer
>
>
>
>
^ permalink raw reply [relevance 10%]
* Re: how to export (latex) a image without using figure
2021-04-04 11:17 10% ` Juan Manuel Macías
@ 2021-04-04 11:33 1% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-04-04 11:33 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan,
> Hi Uwe,
> Try:
> #+ATTR_LaTeX: :float nil
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> [[./images/dfp_03.png]]
Muchas gracias, I mean thank you very much.
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: First steps exporting to tex
2021-04-04 11:04 6% ` Ypo
@ 2021-04-04 11:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-04 11:36 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> I've already tried that. But it doesn't seem to understand the HOME
> directory ~~/~. At least at Windows.
I haven't touched Windows for a thousand years :-), but maybe this thread
can help you:
https://stackoverflow.com/questions/13584118/how-to-write-a-path-with-latex
best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [tip] search this mailing list with helm-surfraw
@ 2021-04-05 9:25 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-05 9:25 UTC (permalink / raw)
To: orgmode
Hi all,
I am a fanatic Helm user, and within Helm I make intensive use of
helm-surfraw. It is necessary to install Surfraw on the system (in Arch
it is in the community repository). For who does not know, Surfraw
(https://en.wikipedia.org/wiki/Surfraw) is a script written by Julian
Assange that lets you perform searches across many engines and internet
sites. Every kind of search is controlled by a set of scripts called
elvi. We can also write our custom elvis, and save them in the
~/.config/surfraw/elvi/ folder. I have written some elvis for my
personal use, among them this simple script to search this mailing list,
which I share here in case someone finds it useful:
#+begin_src sh :shebang #!/bin/sh :tangle ~/.config/surfraw/elvi/orgmode-ml
# DESC: search Org Mode mailing list archives
# elvis: orgmode-ml -- Search Org Mode mailing list archives (https://lists.gnu.org/archive/html/emacs-orgmode/)
. surfraw || exit 1
w3_usage_hook () {
cat <<EOF
Usage: $w3_argv0 [search words]...
Description:
Search in Org Mode mailing list (https://lists.gnu.org/archive/html/emacs-orgmode/)
EOF
w3_global_usage
}
w3_config
w3_parse_args "$@"
if test -z "$w3_args"; then
w3_browse_url "https://lists.gnu.org/archive/html/emacs-orgmode/"
else
escaped_args=`w3_url_of_arg $w3_args`
w3_browse_url "https://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=emacs-orgmode&sort=score&result=normal&max=20&submit=Search!&query=${escaped_args}"
fi
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-05 20:48 6% Juan Manuel Macías
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
2021-04-07 14:16 6% ` Diego Zamboni
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-05 20:48 UTC (permalink / raw)
To: orgmode
Hi all,
There have been some threads recently about exporting to LaTeX, but I
think something that I consider interesting for novice Org/LaTeX users
has not been commented: the choice of the TeX engine. I think this is
important because although people often say they "use LaTeX", what they
actually use is TeX via the La-TeX format. What TeX engine to choose? I
would dare to say the following: unless you want to maintain some
backward compatibility with old documents, I highly recommend using
LuaTeX or XeTeX, especially LuaTeX. Although pdfTeX is very popular
among average or veterans LaTeX users, I think using it nowadays doesn't
make much sense (IMHO). LuaTeX is the natural evolution of pdfTeX and
adds the great advantage of accesing the TeX internals through Lua
scripting.
(What follows is specially intended for those Org users who haven't used
XeTeX or LuaTeX yet).
LuaTeX and XeTeX are *100% Unicode-based* and you can use your system
fonts (open type, true type, etc.) in your documents in a simple way
through the fontspec (https://www.ctan.org/pkg/fontspec) package, which
provides a very neat interface and manages all OpenType features (LuaTeX
and XeTeX use HarfBuzz as otf rendering engine). In LuaTeX also you can
use any font that is not installed in your system: just indicate the
path to the fonts files. This is very useful to test new fonts without
installing them... In all modern word processing systems the user has
always been able to pick a font easily, and that has been historically
quite complex, hard and complicated in the (La)TeX ecosystem.
For example, if we want to use globally the Palatino Linotype family in
our LuaLaTeX document:
\setmainfont{Palatino Linotype}
We can add some OpenType features, like old style numbering:
\setmainfont{Linux Libertine O}[Numbers=LowerCase]
And if we want to use another font for italics, with certain properties
(color[1] and scaling):
\setmainfont{Crimson}
[Numbers=Lowercase,
ItalicFont=MinionPro-It.otf,
ItalicFeatures={Color=red,
Scale=MatchLowercase}]
([1] Requires the xcolor package)
We can also define our own family with its properties (for example, with
upper case numbers and letters tracking):
\newfontfamily\myfamily{crimson}
[Numbers=Lining,LetterSpace=3.0]
Furthermore (for more advanced users), in LuaTeX we can define new
opentype features on the fly, both positional and of substitution (as
long as the typeface includes the glyphs needed to replace). For
example, if I use the Crimson typeface, a contextual substitution for
character Q + u can be defined, by including some Lua code through the
LuaTeX primitive `directlua':
\directlua{
fonts.handlers.otf.addfeature{
name = "mycontextual",
type = "chainsubstitution",
lookups = {
{
type = "substitution",
data = {
["Q"] = "Q.alt01",
},
},
},
data = {
rules = {
{
after = { { "u" } },
current = { { "Q" } },
lookups = { 1 },
},
},
},
}
}
... And add anywhere in the text:
\addfontfeature{RawFeature=+mycontextual}
If I had to choose, finally, between XeTeX and LuaTeX, I would choose
LuaTeX, for things like these and many other reasons. In addition, there
are emerging cool new packages that only work with LuaTeX.
Anyway, XeTeX is another very good option too, especially for users who
prefer something that works more "out of the box" and is less esotheric
than LuaTeX.
To export to PDF always with LuaTeX we can put in our ~ /.emacs:
(setq org-latex-pdf-process
'("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"))
Or with latexmk, which will take care of compiling as many times as
necessary for indexes, bibliographies, etc .:
(setq org-latex-pdf-process
'("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape %%S/' %f"))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-05 20:48 6% Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
@ 2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
2021-04-05 21:36 9% ` Juan Manuel Macías
2021-04-07 14:16 6% ` Diego Zamboni
1 sibling, 1 reply; 200+ results
From: Dr. Arne Babenhauserheide @ 2021-04-05 21:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> would dare to say the following: unless you want to maintain some
> backward compatibility with old documents, I highly recommend using
> LuaTeX or XeTeX, especially LuaTeX. Although pdfTeX is very popular
> among average or veterans LaTeX users, I think using it nowadays doesn't
> make much sense (IMHO).
Except if there is any feature you want to use that doesn’t work under
LuaTeX.
pdfpages for example says that it only supports pdflatex and vtex.
Is there a way to replicate the functionality with LuaTeX? Possibly, but
you have to find out how, and it’s not the first hit on stackoverflow.
Currently LaTeX hasn’t converged on one implementation (which would imply
that all features exist in the implementation it converged on and all
packages were ported or have obvious replacements), so I don’t see a
clearcut decision.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
@ 2021-04-05 21:36 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-05 21:36 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: orgmode
Hi Arne,
Dr. Arne Babenhauserheide writes:
> Except if there is any feature you want to use that doesn’t work under
> LuaTeX.
>
> pdfpages for example says that it only supports pdflatex and vtex.
pdfpages works perfectly with both LuaTeX and XeTeX. I've been using it
in LuaLaTeX for quite some time, by the way. Please read the first page
on the package documentation:
http://mirrors.ctan.org/macros/latex/contrib/pdfpages/pdfpages.pdf
Currently There are very few things that will not work under luatex, for
now (certain microtype properties, like letter tracking, and little
else). In fact, the current trend is the opposite: many new packages
that are emerging do not work under pdftex. The natural evolution of the
TeX ecosystem is heading to LuaTeX, although it is normal for the TeX
community to be cautious about backward compatibility and still mantain
pdfTeX. But the present is already LuaTeX, clearly. The future, who
knows...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 19:13 9% ` Juan Manuel Macías
2021-04-07 16:57 4% ` physiculus
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-06 19:13 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hi physiculus,
physiculus writes:
> Hello,
> i use LuaTex / LuaLatex successfully after some configs and readings.
> The result (quality and speed) for me is better then with the old latex engine.
> I'm satisfied.
> BUT one thing isn't working and as far as i read here, there is no
> solution yet :-(
> The latex-preview inside org-mode is not possible, because it seems,
> that org-mode needs the dvi subprocess for running the neccessary tools.
> With LuaLatex there is no dvi file, because it produces a pdf right
> away.
> Any solution will be wellcome.
I have this in my ~/.emacs:
#+begin_src emacs-lisp
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq luasvg
'(luasvg
:programs ("lualatex" "dvisvgm")
:description "dvi > svg"
:message "you need to install lualatex and dvisvgm."
:use-xcolor t
:image-input-type "dvi"
:image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
:image-converter ("dvisvgm %f -n -b min -c %S -o %O")))
(add-to-list 'org-preview-latex-process-alist luasvg)
(setq org-preview-latex-default-process 'luasvg)
#+end_src
You can set 'org-preview-latex-default-process' to luasvg or luamagick
Best regards,
Juan Manuel
--
--
------------------------------------------------------
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 20:09 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-06 20:09 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hi Tomas,
tomas@tuxteam.de writes:
> AFAIK Lua(La)Tex can output dvi (and Juan Manuel's answer implies
> thati, too). Either via the option --output-format=dvi or invoking
> it as "dviluatex".
>
> But perhaps I missed something.
Yes, the first option I have commented in my previous mail (setq
luamagick etc ...) converts from pdf to png via 'convert' (imagemagick);
in the second option (setq luasvg etc ...) compiles with the option
`-output-format dvi' and then the converter is dvisvgm.
Best regards,
Juan Manuel
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 10%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 20:44 3% Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2021-04-06 20:44 UTC (permalink / raw)
To: maciaschain, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Thanks, Juan Manuel, if LuaTeX just solved the "symbols problem" it
would be a great feature.
But.., why nothing in TeX seems to be easy?! ;D
lualatex: security risk: running with elevated privileges
This is LuaHBTeX, Version 1.12.0 (MiKTeX 20.11)
system commands enabled.
lualatex: file not writable for security reasons: .log
! I can't write on file `.log'.
Please type another transcript file name
! Emergency stop
! ==> Fatal error occurred, no output PDF file produced!
Probably a Windowz problem, don't care. Just moaning ;D
But I take your advise and save it.
Best regards
> *From*: Juan Manuel Macías
> *Subject*: Choosing a LaTeX Compiler (my predilection for LuaTeX)
> *Date*: Mon, 05 Apr 2021 22:48:48 +0200
> *User-agent*: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
>
[-- Attachment #2: Type: text/html, Size: 2455 bytes --]
^ permalink raw reply [relevance 3%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-05 20:48 6% Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
@ 2021-04-07 14:16 6% ` Diego Zamboni
2021-04-07 15:29 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Diego Zamboni @ 2021-04-07 14:16 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 5025 bytes --]
Hi Juan Manuel,
Thank you for writing this, which is the clearest explanation I have seen
of the advantages of LuaLaTeX/XeLaTeX. I have been using LaTeX for nearly
30 years, but stopped using it intensively every day when pdfLaTeX was
still the bleeding edge. When I started again in the last couple of years,
it has been a bit confusing to understand why and what all these different
versions are. These days I use LuaLaTeX as well, but most of the documents
I process are exported from Org-mode.
Best,
--Diego
On Mon, Apr 5, 2021 at 10:49 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi all,
>
> There have been some threads recently about exporting to LaTeX, but I
> think something that I consider interesting for novice Org/LaTeX users
> has not been commented: the choice of the TeX engine. I think this is
> important because although people often say they "use LaTeX", what they
> actually use is TeX via the La-TeX format. What TeX engine to choose? I
> would dare to say the following: unless you want to maintain some
> backward compatibility with old documents, I highly recommend using
> LuaTeX or XeTeX, especially LuaTeX. Although pdfTeX is very popular
> among average or veterans LaTeX users, I think using it nowadays doesn't
> make much sense (IMHO). LuaTeX is the natural evolution of pdfTeX and
> adds the great advantage of accesing the TeX internals through Lua
> scripting.
>
> (What follows is specially intended for those Org users who haven't used
> XeTeX or LuaTeX yet).
>
> LuaTeX and XeTeX are *100% Unicode-based* and you can use your system
> fonts (open type, true type, etc.) in your documents in a simple way
> through the fontspec (https://www.ctan.org/pkg/fontspec) package, which
> provides a very neat interface and manages all OpenType features (LuaTeX
> and XeTeX use HarfBuzz as otf rendering engine). In LuaTeX also you can
> use any font that is not installed in your system: just indicate the
> path to the fonts files. This is very useful to test new fonts without
> installing them... In all modern word processing systems the user has
> always been able to pick a font easily, and that has been historically
> quite complex, hard and complicated in the (La)TeX ecosystem.
>
> For example, if we want to use globally the Palatino Linotype family in
> our LuaLaTeX document:
>
> \setmainfont{Palatino Linotype}
>
> We can add some OpenType features, like old style numbering:
>
> \setmainfont{Linux Libertine O}[Numbers=LowerCase]
>
> And if we want to use another font for italics, with certain properties
> (color[1] and scaling):
>
> \setmainfont{Crimson}
> [Numbers=Lowercase,
> ItalicFont=MinionPro-It.otf,
> ItalicFeatures={Color=red,
> Scale=MatchLowercase}]
>
> ([1] Requires the xcolor package)
>
> We can also define our own family with its properties (for example, with
> upper case numbers and letters tracking):
>
> \newfontfamily\myfamily{crimson}
> [Numbers=Lining,LetterSpace=3.0]
>
> Furthermore (for more advanced users), in LuaTeX we can define new
> opentype features on the fly, both positional and of substitution (as
> long as the typeface includes the glyphs needed to replace). For
> example, if I use the Crimson typeface, a contextual substitution for
> character Q + u can be defined, by including some Lua code through the
> LuaTeX primitive `directlua':
>
> \directlua{
> fonts.handlers.otf.addfeature{
> name = "mycontextual",
> type = "chainsubstitution",
> lookups = {
> {
> type = "substitution",
> data = {
> ["Q"] = "Q.alt01",
> },
> },
> },
> data = {
> rules = {
> {
> after = { { "u" } },
> current = { { "Q" } },
> lookups = { 1 },
> },
> },
> },
> }
> }
>
> ... And add anywhere in the text:
>
> \addfontfeature{RawFeature=+mycontextual}
>
> If I had to choose, finally, between XeTeX and LuaTeX, I would choose
> LuaTeX, for things like these and many other reasons. In addition, there
> are emerging cool new packages that only work with LuaTeX.
>
> Anyway, XeTeX is another very good option too, especially for users who
> prefer something that works more "out of the box" and is less esotheric
> than LuaTeX.
>
> To export to PDF always with LuaTeX we can put in our ~ /.emacs:
>
> (setq org-latex-pdf-process
> '("lualatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"
> "lualatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"
> "lualatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"))
>
> Or with latexmk, which will take care of compiling as many times as
> necessary for indexes, bibliographies, etc .:
>
> (setq org-latex-pdf-process
> '("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape
> %%S/' %f"))
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 5923 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 14:16 6% ` Diego Zamboni
@ 2021-04-07 15:29 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-07 15:29 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hi Diego
Diego Zamboni writes:
> Hi Juan Manuel,
>
> Thank you for writing this, which is the clearest explanation I have
> seen of the advantages of LuaLaTeX/XeLaTeX. I have been using LaTeX
> for nearly 30 years, but stopped using it intensively every day when
> pdfLaTeX was still the bleeding edge. When I started again in the last
> couple of years, it has been a bit confusing to understand why and
> what all these different versions are. These days I use LuaLaTeX as
> well, but most of the documents I process are exported from Org-mode.
Certainly, LuaTeX has many possibilities, although perhaps we would have
liked more if there was a "LispTeX" :-D (by the way, the most lispy thing
I've seen on planet TeX is this strange and interesting package [a Lisp
interpreter written in TeX! language]:
https://www.ctan.org/pkg/lisp-on-tex)
This is a very simple example of what can be done in LuaTeX through its
Lua interpreter (from Org): we define a command, with a simple Lua
function, that put all capital letters of the document in TeX Gyre
Pagella font, in red and scaled; and all digits in bold. (Anyway, this
can also be done in Org Mode with a custom filter...):
#+NAME:luacode
#+begin_src lua :exports none
function change_test ( text )
text = string.gsub ( text, "%d", "\\textbf{%0}" )
text = string.gsub ( text, "%u", "{\\myfamily %0}" )
return text
end
#+end_src
#+NAME:latexcode
#+begin_src latex :exports none :noweb yes
\usepackage{fontspec}
\usepackage{luacode}
\usepackage{xcolor}
\setmainfont{Linux Libertine O}
\newfontfamily\myfamily{TeX Gyre Pagella}[Scale=2,Color=red]
\begin{luacode}
<<luacode>>
\end{luacode}
\newcommand\change{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , change_test , "change_test" )}}
\newcommand\nochange{\directlua{luatexbase.remove_from_callback
( "process_input_buffer" , "change_test" )}}
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<latexcode>>
#+end_src
#+LaTeX:\change
Lorem ImpsuM DoloR Sit aMet
1234567890
#+LaTeX:\nochange
Lorem ImpsuM DoloR Sit aMet
1234567890
x-----
For more esoteric features I recommend trying the chickenize
package (very didactic): https://www.ctan.org/pkg/chickenize
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-06 19:13 9% ` Juan Manuel Macías
@ 2021-04-07 16:57 4% ` physiculus
2021-04-07 17:26 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: physiculus @ 2021-04-07 16:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, physiculus
Am Di, 2021-04-06, 21:13 +0200, Juan Manuel Macías <maciaschain@posteo.net> schrieb:
Hello again,
thanks for the snippet, but unfortunately it doesn't work :-(
Now it doesn't stop with error, it happens nothing.
here is my config.
Variable:
org-preview-latex-default-process is a variable defined in ‘org.el’.
Its value is ‘luasvg’
Original value was ‘dvipng’
Variable:
org-preview-latex-process-alist
Value:
((luasvg :programs
("lualatex" "dvisvgm")
:description "dvi > svg" :message "you need to install lualatex and dvisvgm." :use-xcolor t :image-input-type "dvi" :image-output-type "svg" :image-size-adjust
(1.7 . 1.5)
:latex-compiler
("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
:image-converter
("dvisvgm %f -n -b min -c %S -o %O"))
(dvipng :programs
("latex" "dvipng")
:description "dvi > png" :message "you need to install the programs: latex and dvipng." :image-input-type "dvi" :image-output-type "png" :image-size-adjust
(1.0 . 1.0)
:latex-compiler
("latex -interaction nonstopmode -output-directory %o %f")
:image-converter
("dvipng -D %D -T tight -o %O %f"))
(dvisvgm :programs
("latex" "dvisvgm")
:description "dvi > svg" :message "you need to install the programs: latex and dvisvgm." :image-input-type "dvi" :image-output-type "svg" :image-size-adjust
(1.7 . 1.5)
:latex-compiler
("latex -interaction nonstopmode -output-directory %o %f")
:image-converter
("dvisvgm %f -n -b min -c %S -o %O"))
(imagemagick :programs
("latex" "convert")
:description "pdf > png" :message "you need to install the programs: latex and imagemagick." :image-input-type "pdf" :image-output-type "png" :image-size-adjust
(1.0 . 1.0)
:latex-compiler
("pdflatex -interaction nonstopmode -output-directory %o %f")
:image-converter
("convert -density %D -trim -antialias %f -quality 100
%O")))
here is the testfile:
\begin{displaymath}
\sqrt{a^2-b^2}=c
\end{displaymath}
\begin{equation} % arbitrary environments,
x=\sqrt{b} % even tables, figures
\end{equation} % etc
If $a^2=b$ and \( b=2 \), then the solution must be
either $$ a=+\sqrt{2} $$ or \[ a=-\sqrt{2} \].
I use your luasvg snippet.
Do i have to do anything else?
Any command afterwards?
Hope someone could help :-)
Regards
Poul
> Hi physiculus,
>
> physiculus writes:
>
>> Hello,
>> i use LuaTex / LuaLatex successfully after some configs and readings.
>> The result (quality and speed) for me is better then with the old latex engine.
>> I'm satisfied.
>> BUT one thing isn't working and as far as i read here, there is no
>> solution yet :-(
>> The latex-preview inside org-mode is not possible, because it seems,
>> that org-mode needs the dvi subprocess for running the neccessary tools.
>> With LuaLatex there is no dvi file, because it produces a pdf right
>> away.
>> Any solution will be wellcome.
>
> I have this in my ~/.emacs:
>
> #+begin_src emacs-lisp
> (setq luamagick
> '(luamagick
> :programs ("lualatex" "convert")
> :description "pdf > png"
> :message "you need to install lualatex and imagemagick."
> :use-xcolor t
> :image-input-type "pdf"
> :image-output-type "png"
> :image-size-adjust (1.7 . 1.5)
> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
> (add-to-list 'org-preview-latex-process-alist luamagick)
>
> (setq luasvg
> '(luasvg
> :programs ("lualatex" "dvisvgm")
> :description "dvi > svg"
> :message "you need to install lualatex and dvisvgm."
> :use-xcolor t
> :image-input-type "dvi"
> :image-output-type "svg"
> :image-size-adjust (1.7 . 1.5)
> :latex-compiler ("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
> :image-converter ("dvisvgm %f -n -b min -c %S -o %O")))
> (add-to-list 'org-preview-latex-process-alist luasvg)
> (setq org-preview-latex-default-process 'luasvg)
> #+end_src
>
> You can set 'org-preview-latex-default-process' to luasvg or luamagick
>
> Best regards,
>
> Juan Manuel
>
> --
> --
> ------------------------------------------------------
> https://juanmanuelmacias.com/
>
--
Jens Reimer
^ permalink raw reply [relevance 4%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 16:57 4% ` physiculus
@ 2021-04-07 17:26 9% ` Juan Manuel Macías
2021-04-07 17:53 6% ` physiculus
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-07 17:26 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hello,
physiculus writes:
> Hello again,
>
> thanks for the snippet, but unfortunately it doesn't work :-(
>
> Now it doesn't stop with error, it happens nothing.
> here is my config.
>
> Variable:
> org-preview-latex-default-process is a variable defined in ‘org.el’.
> Its value is ‘luasvg’
> Original value was ‘dvipng’
It's weird, it should work :-( ... I assume you have dvisvgm installed
in your TeX Live installation, is that right? (You can excute something
like 'dvisvgm --help' in your terminal)
What is your SO?
Anyway, you can try the imagemagick option:
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq org-preview-latex-default-process 'luamagick)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 17:26 9% ` Juan Manuel Macías
@ 2021-04-07 17:53 6% ` physiculus
2021-04-07 19:52 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: physiculus @ 2021-04-07 17:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, physiculus
Am Mi, 2021-04-07, 19:26 +0200, Juan Manuel Macías <maciaschain@posteo.net> schrieb:
Yes that works!
usually i do not use imagemagick. I use graphicsmagick, but ido not know
how i have to set the right command line.
SVG does nothing.
Very sad :-(
I want to use this because of quality reasons.
Do you know, how i can test svg?
Regards
Poul
>
> It's weird, it should work :-( ... I assume you have dvisvgm installed
> in your TeX Live installation, is that right? (You can excute something
> like 'dvisvgm --help' in your terminal)
>
> What is your SO?
>
> Anyway, you can try the imagemagick option:
>
> (setq luamagick
> '(luamagick
> :programs ("lualatex" "convert")
> :description "pdf > png"
> :message "you need to install lualatex and imagemagick."
> :use-xcolor t
> :image-input-type "pdf"
> :image-output-type "png"
> :image-size-adjust (1.0 . 1.0)
> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
> (add-to-list 'org-preview-latex-process-alist luamagick)
>
> (setq org-preview-latex-default-process 'luamagick)
^ permalink raw reply [relevance 6%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 17:53 6% ` physiculus
@ 2021-04-07 19:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-07 19:52 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hello again,
physiculus writes:
> Yes that works!
> usually i do not use imagemagick. I use graphicsmagick, but ido not know
> how i have to set the right command line.
> SVG does nothing.
> Very sad :-(
> I want to use this because of quality reasons.
> Do you know, how i can test svg?
the dvisvgm option with luatex is definitely wrong, since dvisvgm does
not support opentype fonts. Sorry for having you confused with my other
snippet. The good news, it seems, is that dvisvgm will support opentype
fonts as of version 2.10, which I assume the next version of texlive
will include it. The actual version is 2.9.1 (command dvisvgm
--version).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-02 18:15 9% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
@ 2021-04-09 22:28 6% ` Nicolas Goaziou
2021-04-10 0:01 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-09 22:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have noticed that a couple of (spurious?) spaces in a `format'
> expression of `org-sort-remove-invisible' is causing `org-sort-list' not
> to sort correctly (alphabetically) the items that contain emphasis marks
> in a plain list. I propose this very simple patch to fix that problem.
Thank you.
Could you apply the same fix to the `org-verbatim-re' match above, and
provide an appropriate commit message?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-09 22:28 6% ` Nicolas Goaziou
@ 2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
2021-04-17 13:27 5% ` Maxim Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-10 0:01 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Hellow Nicolas:
Nicolas Goaziou writes:
> Thank you.
>
> Could you apply the same fix to the `org-verbatim-re' match above, and
> provide an appropriate commit message?
Done! I've attached the corrected patch. Sorry for the flaws in me
previous patch: I'm a bit of a novice at submitting patches...
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-spurious-spaces-in-org-sort-remove-invisible.patch --]
[-- Type: text/x-patch, Size: 1172 bytes --]
From ab104bb079e3e32d622a6ff53824b5047dc25c14 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 2 Apr 2021 21:20:17 +0200
Subject: [PATCH] Remove spurious spaces in org-sort-remove-invisible
Some spurious spaces in org-sort-remove-invisible is causing
org-sort-list not to sort correctly (alphabetically) the items that
contain emphasis marks in a plain list
---
lisp/org.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 675a614e2..74e2afac9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8113,9 +8113,9 @@ Optional argument WITH-CASE means sort case-sensitively."
"Remove invisible part of links and emphasis markers from string S."
(remove-text-properties 0 (length s) org-rm-props s)
(replace-regexp-in-string
- org-verbatim-re (lambda (m) (format "%s " (match-string 4 m)))
+ org-verbatim-re (lambda (m) (format "%s" (match-string 4 m)))
(replace-regexp-in-string
- org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
+ org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
(org-link-display-format s)
t t) t t))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 0:01 9% ` Juan Manuel Macías
@ 2021-04-10 10:19 6% ` Nicolas Goaziou
2021-04-10 11:41 10% ` Juan Manuel Macías
2021-04-17 13:27 5% ` Maxim Nikulin
1 sibling, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-10 10:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Done! I've attached the corrected patch. Sorry for the flaws in me
> previous patch: I'm a bit of a novice at submitting patches...
No problem. Thank you.
Do you have a simple test case to reproduce the problem? Currently
sorting the following trivial lists causes no issue:
- b
- *a*
and
- *b*
- a
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 10:19 6% ` Nicolas Goaziou
@ 2021-04-10 11:41 10% ` Juan Manuel Macías
2021-04-13 17:31 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-10 11:41 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello Nicolas,
Nicolas Goaziou writes:
> Do you have a simple test case to reproduce the problem? Currently
> sorting the following trivial lists causes no issue:
>
> - b
> - *a*
>
> and
>
> - *b*
> - a
Consider this (unordered) list:
- a
- b
- /v/
- /a/
The current result is wrong:
- /a/
- /v/
- a
- b
With the spaces removed in `org-sort-remove-invisible', this would be the
expected result[1]:
- a
- /a/
- b
- /v/
[1] According to the National Information Standards Organization:
"Different typefaces (italic, boldface, blackletter, etc.) do not affect
the arrangement of letters." (see p. 3 on:
https://www.niso.org/sites/default/files/2017-08/tr03.pdf)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-12 13:50 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-12 13:50 UTC (permalink / raw)
To: orgmode
Nicolas Goaziou writes:
> I cannot reproduce it. With your initial list, and a minimal init file,
> I get:
>
> - /a/
> - a
> - b
> - /v/
>
> Could you try with a minimal Emacs, too?
That's weird ... I have tried launching emacs -q in a virtual machine,
and I keep getting the wrong result (git version, master branch):
- /a/
- /v/
- a
- b
I have tried with the typical keyboard shortcut and also with M-: and
evaluating (org-sort-list t? a nil nil nil)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-12 23:18 10% ` Juan Manuel Macías
2021-04-12 23:52 6% ` Samuel Wales
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-12 23:18 UTC (permalink / raw)
To: Ypo; +Cc: orgmode, Nicolas Goaziou
Hi Ypo,
Ypo writes:
> This is my result after doing "org-sort-list a":
>
> - /a/
> - /v/
> - a
> - b
>
> Regards
Thanks for trying. So it seems that you can reproduce the problem as
well... I wonder if anyone else is able to reproduce it, preferably in a
minimal emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-12 23:18 10% ` Juan Manuel Macías
@ 2021-04-12 23:52 6% ` Samuel Wales
2021-04-13 14:16 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Samuel Wales @ 2021-04-12 23:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ypo, orgmode, Nicolas Goaziou
probably not a relevant non-confirmation but in recent maint, my config:
- a
- /a/
- b
On 4/12/21, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi Ypo,
>
> Ypo writes:
>
>> This is my result after doing "org-sort-list a":
>>
>> - /a/
>> - /v/
>> - a
>> - b
>>
>> Regards
>
> Thanks for trying. So it seems that you can reproduce the problem as
> well... I wonder if anyone else is able to reproduce it, preferably in a
> minimal emacs.
>
> Best regards,
>
> Juan Manuel
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-12 23:52 6% ` Samuel Wales
@ 2021-04-13 14:16 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-13 14:16 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Hi Samuel,
Samuel Wales writes:
> probably not a relevant non-confirmation but in recent maint, my config:
>
> - a
> - /a/
> - b
Thanks for trying. I've uploaded this screencast with a minimal Emacs on
a virtual machine:
https://gnutas.juanmanuelmacias.com/images/org-sort-issue-2021-04-13_15.44.52.mp4
and, as you can see, in my case `org-sort-list' can not sort the list
correctly. Maybe it's something related to locales (??), but the only
thing that I can confirm is that if I remove those spaces in
`org-sort-remove-invisible', the list is then sorted correctly.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 11:41 10% ` Juan Manuel Macías
@ 2021-04-13 17:31 5% ` Maxim Nikulin
2021-04-13 19:08 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-04-13 17:31 UTC (permalink / raw)
To: emacs-orgmode
On 10/04/2021 18:41, Juan Manuel Macías wrote:
> Nicolas Goaziou writes:
>
>> Do you have a simple test case to reproduce the problem? Currently
>> sorting the following trivial lists causes no issue:
>>
>> - b
>> - *a*
>>
>> and
>>
>> - *b*
>> - a
>
> The current result is wrong:
>
> - /a/
> - /v/
> - a
> - b
I could reproduce such result but I am in doubt if it is a reason to
merge the patch. I believe, the following behavior is almost expected
list.org:
- v
- /v/
- /a/
- a
LC_COLLATE=C.UTF-8 LC_ALL= LANGUAGE= \
emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
(org-sort-list t ?a)
- /a/
- /v/
- a
- v
LC_COLLATE=en_US.UTF-8 LC_ALL= LANGUAGE= \
emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
(org-sort-list t ?a)
- /a/
- a
- /v/
- v
Collation rules depend on language. The question is if emphasized
variant should be sorted first.
P.S. The thread is broken. Some new messages do not have proper
In-Reply-To header. Original question was not referenced in the message
with patch as well: https://orgmode.org/list/87blbac0k0.fsf@posteo.net/
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-13 17:31 5% ` Maxim Nikulin
@ 2021-04-13 19:08 9% ` Juan Manuel Macías
2021-04-14 15:42 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-13 19:08 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi, Maxim,
Thanks for clearing things up. So it seems obvious that the root
of the problem is in the locales and the collation rules.
The situation is that with locales configured for Spanish from Spain
(en_ES.UTF-8) the list is not ordered correctly, unless those three
spaces from org-sort-remove-invisible are removed. But I couldn't say
why or if that would be appropriate as a patch...
Regarding the collation rule of forms with emphasis, at least in Spanish
these should come after the non-emphasized forms. I don't know if this
is a general rule also for other languages (at least it seems more
natural that the forms without emphasis are placed before).
Best regards,
Juan Manuel
Maxim Nikulin writes:
> I could reproduce such result but I am in doubt if it is a reason to
> merge the patch. I believe, the following behavior is almost expected
>
> list.org:
> - v
> - /v/
> - /a/
> - a
>
> LC_COLLATE=C.UTF-8 LC_ALL= LANGUAGE= \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> (org-sort-list t ?a)
>
> - /a/
> - /v/
> - a
> - v
>
> LC_COLLATE=en_US.UTF-8 LC_ALL= LANGUAGE= \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> (org-sort-list t ?a)
>
> - /a/
> - a
> - /v/
> - v
>
> Collation rules depend on language. The question is if emphasized
> variant should be sorted first.
>
> P.S. The thread is broken. Some new messages do not have proper
> In-Reply-To header. Original question was not referenced in the
> message with patch as well:
> https://orgmode.org/list/87blbac0k0.fsf@posteo.net/
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-13 19:08 9% ` Juan Manuel Macías
@ 2021-04-14 15:42 5% ` Maxim Nikulin
2021-04-14 17:07 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-04-14 15:42 UTC (permalink / raw)
To: emacs-orgmode
On 14/04/2021 02:08, Juan Manuel Macías wrote:
>
> The situation is that with locales configured for Spanish from Spain
> (en_ES.UTF-8) the list is not ordered correctly, unless those three
> spaces from org-sort-remove-invisible are removed. But I couldn't say
> why or if that would be appropriate as a patch...
Did not you get a warning like the following one?
(process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
library.
Using the fallback 'C' locale.
> Regarding the collation rule of forms with emphasis, at least in Spanish
> these should come after the non-emphasized forms. I don't know if this
> is a general rule also for other languages (at least it seems more
> natural that the forms without emphasis are placed before).
LANG=es_ES.UTF-8 \
emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
- a
- /a/
- v
- /v/
So it works accordingly to your expectation. Emacs 25.2.2, Ubuntu-18.04
container.
I have generated es_ES.UTF-8 locale using
dpkg-reconfigure locales
Depending on linux distribution you run, the locale may be ready to use
or not. I tend to think that in minimal environment of virtual machine
it was missed.
I had an idea to add a test for sorting of items including emphasized
ones but test-org-list/sort forces C locale. Maybe it was done to avoid
failures due to missed locale.
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-14 15:42 5% ` Maxim Nikulin
@ 2021-04-14 17:07 9% ` Juan Manuel Macías
2021-04-14 21:36 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-14 17:07 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Thanks again. In my case, I keep getting the wrong result. In addition
to the test I did in a virtual machine with Fedora, I use Arch Linux in
my every day computers, with locales correctly (I hope) configured as
es_ES.UTF-8 (there was a typo in my previous mail, sorry:
'en_ES.UTF-8'). In my /etc/locale.conf file I have:
LANG=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_IDENTIFICATION=es_ES.UTF-8
LC_MEASUREMENT=es_ES.UTF-8
LC_MONETARY=es_ES.UTF-8
LC_NAME=es_ES.UTF-8
LC_NUMERIC=es_ES.UTF-8
LC_PAPER=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_TIME=es_ES.UTF-8
And with locale -a, I get a list of enabled locales:
C
en_US.utf8
es_ES.utf8
POSIX
However, I keep getting the wrong result :-( (Arch, Emacs 27.2).
Even with
LANG=en_EN.UTF-8 \
emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
Maybe the problem is on Arch's side (?), although it was also reproducible
in the test I did with Fedora in virtual machine and Emacs 27.
Best regards,
Juan Manuel
Maxim Nikulin writes:
> On 14/04/2021 02:08, Juan Manuel Macías wrote:
>> The situation is that with locales configured for Spanish from Spain
>> (en_ES.UTF-8) the list is not ordered correctly, unless those three
>> spaces from org-sort-remove-invisible are removed. But I couldn't say
>> why or if that would be appropriate as a patch...
>
> Did not you get a warning like the following one?
>
> (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
> library.
> Using the fallback 'C' locale.
>
>> Regarding the collation rule of forms with emphasis, at least in Spanish
>> these should come after the non-emphasized forms. I don't know if this
>> is a general rule also for other languages (at least it seems more
>> natural that the forms without emphasis are placed before).
>
> LANG=es_ES.UTF-8 \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> - a
> - /a/
> - v
> - /v/
>
> So it works accordingly to your expectation. Emacs 25.2.2,
> Ubuntu-18.04 container.
>
> I have generated es_ES.UTF-8 locale using
>
> dpkg-reconfigure locales
>
> Depending on linux distribution you run, the locale may be ready to
> use or not. I tend to think that in minimal environment of virtual
> machine it was missed.
>
> I had an idea to add a test for sorting of items including emphasized
> ones but test-org-list/sort forces C locale. Maybe it was done to
> avoid failures due to missed locale.
>
>
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-14 17:07 9% ` Juan Manuel Macías
@ 2021-04-14 21:36 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-14 21:36 UTC (permalink / raw)
To: orgmode
Hello again,
Since I have an old Emacs version (24.5.1) on my Raspberry, I've done
a few more tests. The situation is the following:
1. On Arch Linux and Emacs 27.2:
- The system locales are set to "es_ES.UTF-8". When, inside Emacs, I do M-x
getenv RET LANG RET, I get "es_ES.UTF-8".
org-sort-list a -> wrong result;
- Launching Emacs from terminal with
LANG=es_ES.UTF-8 \
etc...
org-sort-list a -> wrong result again.
2. On Fedora 32 (virtual machine) and Emacs 27.1
- Everything as in the previous case.
3. On Raspian stretch and Emacs 24.5.1:
- The system locales are set to "es_ES.UTF-8" as well. When, inside a
normal Emacs session, I do M-x getenv RET lang RET, I get "es_ES.UTF-8".
org-sort-list a -> wrong result;
- Launching Emacs from terminal with
LANG=es_ES.UTF-8 \
etc...
In this case the list is ordered correctly, but I observe that similar
forms with or without emphasis are not always ordered in the same way.
Sometimes the non-emphasized forms are ordered before and sometimes
they are ordered after (?).
I don't know if I'm missing something...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi Maxim,
>
> Thanks again. In my case, I keep getting the wrong result. In addition
> to the test I did in a virtual machine with Fedora, I use Arch Linux in
> my every day computers, with locales correctly (I hope) configured as
> es_ES.UTF-8 (there was a typo in my previous mail, sorry:
> 'en_ES.UTF-8'). In my /etc/locale.conf file I have:
>
> LANG=es_ES.UTF-8
> LC_ADDRESS=es_ES.UTF-8
> LC_IDENTIFICATION=es_ES.UTF-8
> LC_MEASUREMENT=es_ES.UTF-8
> LC_MONETARY=es_ES.UTF-8
> LC_NAME=es_ES.UTF-8
> LC_NUMERIC=es_ES.UTF-8
> LC_PAPER=es_ES.UTF-8
> LC_TELEPHONE=es_ES.UTF-8
> LC_TIME=es_ES.UTF-8
>
> And with locale -a, I get a list of enabled locales:
>
> C
> en_US.utf8
> es_ES.utf8
> POSIX
>
> However, I keep getting the wrong result :-( (Arch, Emacs 27.2).
>
> Even with
>
> LANG=en_EN.UTF-8 \
> emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> Maybe the problem is on Arch's side (?), although it was also reproducible
> in the test I did with Fedora in virtual machine and Emacs 27.
>
> Best regards,
>
> Juan Manuel
>
> Maxim Nikulin writes:
>
>> On 14/04/2021 02:08, Juan Manuel Macías wrote:
>>> The situation is that with locales configured for Spanish from Spain
>>> (en_ES.UTF-8) the list is not ordered correctly, unless those three
>>> spaces from org-sort-remove-invisible are removed. But I couldn't say
>>> why or if that would be appropriate as a patch...
>>
>> Did not you get a warning like the following one?
>>
>> (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
>> library.
>> Using the fallback 'C' locale.
>>
>>> Regarding the collation rule of forms with emphasis, at least in Spanish
>>> these should come after the non-emphasized forms. I don't know if this
>>> is a general rule also for other languages (at least it seems more
>>> natural that the forms without emphasis are placed before).
>>
>> LANG=es_ES.UTF-8 \
>> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
>> list.org
>>
>> - a
>> - /a/
>> - v
>> - /v/
>>
>> So it works accordingly to your expectation. Emacs 25.2.2,
>> Ubuntu-18.04 container.
>>
>> I have generated es_ES.UTF-8 locale using
>>
>> dpkg-reconfigure locales
>>
>> Depending on linux distribution you run, the locale may be ready to
>> use or not. I tend to think that in minimal environment of virtual
>> machine it was missed.
>>
>> I had an idea to add a test for sorting of items including emphasized
>> ones but test-org-list/sort forces C locale. Maybe it was done to
>> avoid failures due to missed locale.
>>
>>
>
^ permalink raw reply [relevance 12%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-15 18:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-15 18:21 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim
Maxim Nikulin writes:
> I can reproduce the issue with emacs-27.1 from ubuntu-21.04 beta live
> image running in qemu. Org mode is current git HEAD. It seems that
> something is changed in emacs since locale is correct:
>
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
> | LANG=C.UTF-8 sort
> - /a/
> - /v/
> - a
> - v
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
> | LANG=es_ES.UTF-8 sort
> - /a/
> - a
> - /v/
> - v
>
> Concerning org-sort-list, I do not see any problem with en_US.UTF-8,
> it_IT.UTF-8, and ru_RU.UTF-8 locales. However emphasized items are
> sorted first for at least es_ES.UTF-8, es_MX.UTF-8, and es_US.UTF-8.
> I have found some evidence that the problem is on the org side
>
> cat list.el
> (message "%S" (sort '("- /v/" "- v" "- a" "- /a/")
> #'string-collate-lessp))
>
> LC_ALL=C.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- /v/" "- a" "- v")
>
> LC_ALL=en_US.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- a" "- /v/" "- v")
>
> LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- a" "- /v/" "- v")
>
> So even string-collate-lessp works as expected.
>
> I'm puzzled why the problem is specific to org-sort-list and namely to
> Spanish locales.
>
>
Well that's pretty weird ... I wonder if the (spurious?) spaces in
`org-sort-remove-invisible' that I mentioned at the beginning may be
helpful to keep a track, or if it's just something that masks the
problem.
Anyway, I have noticed that the only space that seems determinant (from
some way that escapes me) is this (where I put the @ sign):
org-emph-re (lambda (m) (format "@%s " (match-string 4 m)))
Following your examples, it occurred to me to try this, which I don't
know if it is relevant or if I have entered a dead end:
#+begin_src emacs-lisp :tangle list-var.el
(message "%S" (sort '("-\s\sv" "-\sv" "-\sa" "-\s\sa")
#'string-collate-lessp))
#+end_src
#+begin_src sh
exec 2>&1
LC_ALL=en_US.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
#+RESULTS:
: - a" "- a" "- v" "- v
#+begin_src sh
exec 2>&1
LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
#+RESULTS:
: - a" "- v" "- a" "- v
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
@ 2021-04-17 13:27 5% ` Maxim Nikulin
2021-04-18 17:52 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-04-17 13:27 UTC (permalink / raw)
To: emacs-orgmode
On 10/04/2021 07:01, Juan Manuel Macías wrote:
> Nicolas Goaziou writes:
>> Could you apply the same fix to the `org-verbatim-re' match above, and
>> provide an appropriate commit message?
>
> Done! I've attached the corrected patch. Sorry for the flaws in me
> previous patch: I'm a bit of a novice at submitting patches...
I have not read yet the following documents to realize what pitfalls
could be expected due to significant space added to Spanish and Polish
collation rules in libc.
http://www.unicode.org/reports/tr10/
Unicode® Technical Standard #10
Unicode Collation Algorithm
http://www.unicode.org/reports/tr35/tr35-collation.html#CLDR_Collation_Algorithm
Unicode Technical Standard #35
Unicode Locale Data Markup Language (LDML)
Part 5: Collation
In the meanwhile I have realized that org-sort-remove-invisible function
has rather strange behavior. There are no tests, so I am in doubt if the
following result is expected and intended (unpatched version)
(org-sort-remove-invisible "- (*bold*)")
"- bold "
I would expect
"- (bold)"
P.S.
On 10/04/2021 17:19, Nicolas Goaziou wrote:
>
> Do you have a simple test case to reproduce the problem? Currently
> sorting the following trivial lists causes no issue:
After the lengthy discussion the problem is traced down to the following:
- Ensure that you have *compiled* recent enough es_ES.UTF-8 locale
(description includes
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hp=d17612f6726d0c098ac981e06f3702106540bb23;hb=159738548130d5ac4fe6178977e940ed5f8cfdc4;hpb=ce6636b06b67d6bb9b3d6927bf2a926b9b7478f5)
- LC_ALL= LANG=es_ES.UTF-8 emacs
- (org-sort-list t ?a) for the following snippet
- /a/
- a
- /v/
- v
Significance of space should be better illustrated with multi-word items
but I am not ready to provide an impressive example yet.
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-17 13:27 5% ` Maxim Nikulin
@ 2021-04-18 17:52 9% ` Juan Manuel Macías
2021-04-18 21:20 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-18 17:52 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Maxim Nikulin writes:
> On 10/04/2021 07:01, Juan Manuel Macías wrote:
>> Nicolas Goaziou writes:
>>> Could you apply the same fix to the `org-verbatim-re' match above, and
>>> provide an appropriate commit message?
>> Done! I've attached the corrected patch. Sorry for the flaws in me
>> previous patch: I'm a bit of a novice at submitting patches...
>
> I have not read yet the following documents to realize what pitfalls
> could be expected due to significant space added to Spanish and Polish
> collation rules in libc.
>
> http://www.unicode.org/reports/tr10/
> Unicode® Technical Standard #10
> Unicode Collation Algorithm
>
> http://www.unicode.org/reports/tr35/tr35-collation.html#CLDR_Collation_Algorithm
> Unicode Technical Standard #35
> Unicode Locale Data Markup Language (LDML)
> Part 5: Collation
>
> In the meanwhile I have realized that org-sort-remove-invisible
> function has rather strange behavior. There are no tests, so I am in
> doubt if the following result is expected and intended (unpatched
> version)
All this research you've done on spaces and collation rules is very
interesting and enlightening.
Certainly, space is important, as the following list in Spanish is
correctly ordered as:
- lo raro
- lo vano
- localidad
However, with the 'unpatched' version of org-sort-remove invisible I get
this result (which is correct) for this list:
- lo bueno
- lo /bueno/
- lo vano
- lo /vano/
And with the patched version, I get this, which is wrong (!):
- lo bueno
- lo vano
- lo /bueno/
- lo /vano/
It seems that what I was proposing as a patch at the beginning is not,
finally, a viable solution for all contexts...
The problem is that, if the first space is removed, we get this
abnormal result:
#+begin_src emacs-lisp
(org-sort-remove-invisible "- lo /bueno/")
#+end_src
#+RESULTS:
: - lobueno
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-18 17:52 9% ` Juan Manuel Macías
@ 2021-04-18 21:20 11% ` Juan Manuel Macías
2021-04-19 8:33 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-18 21:20 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> It seems that what I was proposing as a patch at the beginning is not,
> finally, a viable solution for all contexts...
>
> The problem is that, if the first space is removed, we get this
> abnormal result:
>
> #+begin_src emacs-lisp
> (org-sort-remove-invisible "- lo /bueno/")
> #+end_src
>
> #+RESULTS:
> : - lobueno
I wonder if this other approach can be viable or if it is something
crazy: if the spaces in org-sort-remove-invisible are a
problem only for the first emphasis of each item, how about this
fix to org-sort-list? (not modifying org-sort-remove-invisible):
@@ -2940,10 +2940,20 @@ function is being called interactively."
(org-sort-remove-invisible
(buffer-substring (match-end 0) (point-at-eol)))))
((= dcst ?a)
- (funcall case-func
- (org-sort-remove-invisible
- (buffer-substring
- (match-end 0) (point-at-eol)))))
+ (if (save-excursion
+ (beginning-of-line)
+ (forward-char)
+ (looking-at-p org-emph-re))
+ (replace-regexp-in-string
+ "\\(^\\)\s+" "\\1"
+ (funcall case-func
+ (org-sort-remove-invisible
+ (buffer-substring
+ (match-end 0) (point-at-eol)))))
+ (funcall case-func
+ (org-sort-remove-invisible
+ (buffer-substring
+ (match-end 0) (point-at-eol))))))
((= dcst ?t)
(cond
;; If it is a timer list, convert timer to seconds
^ permalink raw reply [relevance 11%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-18 21:20 11% ` Juan Manuel Macías
@ 2021-04-19 8:33 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-19 8:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I wonder if this other approach can be viable or if it is something
> crazy: if the spaces in org-sort-remove-invisible are a
> problem only for the first emphasis of each item, how about this
> fix to org-sort-list? (not modifying org-sort-remove-invisible):
I think `org-sort-remove-invisible' is wrong, so it is the one that
needs to be fixed.
Could you try the following instead?
--8<---------------cut here---------------start------------->8---
(defun org-sort-remove-invisible (s)
"Remove invisible part of links and emphasis markers from string S."
(let ((remove-markers
(lambda (m)
(concat (match-string 1 m)
(match-string 4 m)
(match-string 5 m)))))
(remove-text-properties 0 (length s) org-rm-props s)
(replace-regexp-in-string
org-verbatim-re remove-markers
(replace-regexp-in-string org-emph-re remove-markers (org-link-display-format s) t tt)
t t)))
--8<---------------cut here---------------end--------------->8---
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-02-18 16:33 6% [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
@ 2021-04-19 9:19 5% ` Nicolas Goaziou
2021-04-20 13:56 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-19 9:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I would like to propose this (possible) patch.
>
> With `#+STARTUP: macro-arg-sep-other' the macros arguments can be
> separated by a string other than comma, whose value is defined in
> `org-macro-arg-sep-other' (by default it is "'@").
Even though Org syntax partly is, I don't think parameterizable syntax
is a way to go. I'd rather have less variables controlling it. (I'm
looking at you `org-list-allow-alphabetical', and
`org-plain-list-ordered-item-terminator'.)
That being said, we can discuss syntax that is not depending upon some
variable. For example macro names are written with a limited set of
characters (alphanumeric, dash, underscore). We might allow the optional
argument separator to be located right before the opening parenthesis,
e.g.,
{{{macroname@(latin@Lorem ipsum dolor sit amet, ...)}}}
{{{macroname|(latin|Lorem ipsum dolor sit amet, ...)}}}
But see below.
> Rationale for this patch: There are many contexts where the comma character can be
> inappropriate as an argument separator, since it has to be escaped
> many times.
That's true. But I wonder if you're hitting a limit of replacement
macros use case. IMO, macros are good for short text. For bigger ones,
you may want to use some Babel code, in the language of your choice.
WDYT?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-19 9:19 5% ` Nicolas Goaziou
@ 2021-04-20 13:56 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-20 13:56 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas
Nicolas Goaziou writes:
> Even though Org syntax partly is, I don't think parameterizable syntax
> is a way to go. I'd rather have less variables controlling it. (I'm
> looking at you `org-list-allow-alphabetical', and
> `org-plain-list-ordered-item-terminator'.)
Thanks for your explanations. I understand that the use of variables
here is perhaps not the happiest solution. Naturally, I speak of
'solution' assuming there is a 'problem', the choice of the comma as an
argument separator; but I also assume that what is a problem for me, it
doesn't have to be for other users, as here everything is subjective.
Anyway, I couldn't think of another way to respect the original comma
(and backward compatibility), but leaving the user some freedom to
choose a different separator. I also understand that implementing that
can lead to confusion.
>> Rationale for this patch: There are many contexts where the comma character can be
>> inappropriate as an argument separator, since it has to be escaped
>> many times.
>
> That's true. But I wonder if you're hitting a limit of replacement
> macros use case. IMO, macros are good for short text. For bigger ones,
> you may want to use some Babel code, in the language of your choice.
> WDYT?
I think replacement macros have huge potential, that I often explore in
my daily work and (I admit) wearing the things to the limit, which means
struggling with resistance to the material ;-) Perhaps that emerging
potential was not originally foreseen ... Of course, the scenario is
always in short texts, I agree. But even in those scenarios, the comma
as an argument separator is somewhat uncomfortable and confusing. That
is, macros have great potential (IMHO) in contrast to an "ugly" syntax.
But at this point it has a difficult solution...
A typical use case for macros (for me) can be to export to LaTeX with
the command \foreignlanguage{lang}{short text} in multilingual documents
(see this screenshot:
https://gnutas.juanmanuelmacias.com/images/macros-sample.png). I can't
think of another way to do (easily) something like that (with the plus
of being able to evaluate some Elisp in there and add a conditional for
the backend, etc.).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-21 15:45 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-21 15:45 UTC (permalink / raw)
To: orgmode
Hi all,
Maxim Nikulin writes:
> I think, new variant should be committed even it does not fix Juan's
> case. He have not confirmed the fix yet.
Sorry, I have been busy with other matters and had lost the thread of
the discussion. I'm catching up on the messages...
I have tried the Nicolas' patch (latest version) and I see that the
items with emphasis are already ordered well. However, it seems that the
problem with identical items with or without emphasis still persists:
which items should go before and in what order? For example, in the
following list I get:
- /a/
- *a*
- a
- *b*
- /b/
- b
- /v/
- *v*
- v
Anyway, I think it is a minor problem (I can't think of many
scenarios in real life where this problem is relevant). In a more
realistic case, the result is correct:
- lo /bueno/
- lo bueno
- lo /vano/
- lo vano
...
- /a/
- b
- /v/
- *z*
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
Results 1-200 of ~1600 next (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-11-28 16:59 Remembrance Agents Gerardo Moro
2020-11-28 18:26 ` Jean Louis
2020-11-29 13:07 ` Gerardo Moro
2020-11-29 13:52 ` Eric S Fraga
2020-11-29 17:29 ` Jean Louis
2020-11-29 17:47 ` Eric S Fraga
2020-11-30 11:15 ` Jean Louis
2021-01-06 6:41 ` Possibility to copy text outside EMACS and send it to orgmode document Gerardo Moro
2021-01-06 16:31 10% ` Juan Manuel Macías
2020-12-01 12:08 6% Footnote definition within a verse block has spurious line breaks when exported to LaTeX Juan Manuel Macías
2020-12-05 9:09 6% ` Nicolas Goaziou
2020-12-05 13:47 10% ` Juan Manuel Macías
2020-12-08 11:35 Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] Charis Michelakis
2020-12-09 15:06 10% ` Juan Manuel Macías
[not found] ` <69288122-6dfb-4235-47bf-d38344c730b0@gmail.com>
2020-12-09 15:31 6% ` Juan Manuel Macías
2020-12-10 22:17 9% Accessing a DLNA server through an Org link Juan Manuel Macías
2020-12-13 16:28 #+include and org-export-before-processing-hook Eric S Fraga
2020-12-13 17:26 10% ` Juan Manuel Macías
2020-12-13 20:05 6% ` Nicolas Goaziou
2020-12-15 17:21 8% [Small suggestion] on exporting verse blocks to LaTeX and vertical spaces Juan Manuel Macías
2020-12-17 17:11 5% [patch] A proposal to add LaTeX attributes to verse blocks Juan Manuel Macías
2020-12-17 17:23 5% [PATCH] " Juan Manuel Macías
2021-01-03 10:25 6% ` TEC
2021-01-03 13:07 10% ` Juan Manuel Macías
2021-01-03 13:08 5% ` TEC
2021-01-07 18:52 5% ` Juan Manuel Macías
2020-12-20 21:37 9% Displaying verse numbers within a verse block Juan Manuel Macías
2020-12-22 17:12 *strong* markup not honored at boundary of macro input during HTML export m27315
2020-12-23 14:58 ` m27315
2020-12-23 15:22 10% ` Juan Manuel Macías
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
2020-12-23 16:05 10% ` Juan Manuel Macías
2020-12-23 2:11 8% [TIP] Export to LaTeX and HTML with a watermark Juan Manuel Macías
2020-12-23 2:38 6% ` Thomas S. Dye
2020-12-25 16:02 7% [tip] Export subfigures to LaTeX (and HTML) Juan Manuel Macías
2020-12-28 18:03 5% ` John Kitchin
2020-12-29 15:00 9% ` Juan Manuel Macías
2020-12-27 13:02 A way to avoid unwanted new lines when using paragraph quotes? Kashyap Chamarthy
2020-12-27 13:55 10% ` Juan Manuel Macías
2020-12-27 15:52 ` Diego Zamboni
2020-12-27 18:33 ` Kashyap Chamarthy
2020-12-27 19:17 9% ` Juan Manuel Macías
2020-12-27 21:15 6% ` Kashyap Chamarthy
2020-12-27 16:44 Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] Chris Hunt
2020-12-27 18:12 10% ` Juan Manuel Macías
2020-12-27 20:14 6% ` tomas
2020-12-27 21:33 10% ` Juan Manuel Macías
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
2020-12-28 15:38 10% ` Juan Manuel Macías
2020-12-28 16:09 5% ` Jonathan McHugh
2020-12-28 17:54 7% ` Juan Manuel Macías
2020-12-28 19:06 5% ` Jonathan McHugh
2020-12-29 21:51 5% ` Jonathan McHugh
2020-12-28 16:23 0% ` Diego Zamboni
2020-12-28 18:03 10% ` Juan Manuel Macías
2020-12-28 19:23 6% ` Diego Zamboni
2020-12-28 20:03 4% ` Marcin Borkowski
2020-12-29 16:05 9% ` Juan Manuel Macías
2021-01-08 2:37 5% ` Jason Ross
2021-01-09 17:42 10% ` Juan Manuel Macías
2021-01-13 1:16 6% ` Jason Ross
2021-01-08 3:52 6% ` Jason Ross
2021-01-05 18:33 Inserting LaTex expressions using a filter fails Mart van de Wege
2021-01-05 21:58 10% ` Juan Manuel Macías
2021-01-06 7:50 6% ` Mart van de Wege
2021-01-06 11:51 10% ` Juan Manuel Macías
2021-01-06 12:00 6% ` Mart van de Wege
2021-01-06 12:24 10% ` Juan Manuel Macías
2021-01-06 15:17 6% ` Mart van de Wege
2021-01-06 15:58 10% ` Juan Manuel Macías
2021-01-06 16:00 6% ` Mart van de Wege
2021-01-12 22:30 9% A minor mode for inserting things while typing Juan Manuel Macías
2021-01-19 22:05 Region-based meta-notes Lawrence Bottorff
2021-01-19 22:39 10% ` Juan Manuel Macías
2021-01-22 9:20 Dealing with wide labels in description environment Loris Bennett
2021-01-22 11:20 9% ` Juan Manuel Macías
2021-01-22 12:37 6% ` Loris Bennett
2021-01-23 11:03 7% [Tip] Export a bibliography to HTML with bibLaTeX and make4ht Juan Manuel Macías
2021-01-24 11:37 4% ` Gustavo Barros
2021-01-24 13:00 ` Gustavo Barros
2021-01-24 19:20 6% ` Juan Manuel Macías
2021-01-24 22:44 4% ` Gustavo Barros
2021-01-25 17:46 9% ` Juan Manuel Macías
2021-01-25 18:30 5% ` Gustavo Barros
2021-01-29 16:03 9% org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30 5:10 6% ` Ihor Radchenko
2021-01-30 13:38 9% ` Juan Manuel Macías
2021-01-31 3:33 5% ` Ihor Radchenko
2021-01-31 10:29 9% ` Juan Manuel Macías
2021-01-31 10:52 5% ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 10% ` Juan Manuel Macías
2021-01-31 13:40 5% ` Ihor Radchenko
2021-01-31 14:36 10% ` Juan Manuel Macías
2021-01-31 19:37 6% [patch] to allow org-attach-git to handle individual repositories Juan Manuel Macías
2021-02-01 9:10 http links translated to html : target "_blank" Uwe Brauer
2021-02-01 11:03 9% ` Juan Manuel Macías
2021-02-01 13:56 1% ` Uwe Brauer
2021-02-01 14:46 8% ` Juan Manuel Macías
2021-02-01 15:20 0% ` Uwe Brauer
2021-02-01 21:01 10% ` Juan Manuel Macías
2021-02-04 14:07 0% ` Uwe Brauer
2021-02-01 12:51 emphasizing source code words Luca Ferrari
2021-02-01 12:55 ` TEC
2021-02-04 11:38 ` Luca Ferrari
2021-02-04 12:13 9% ` Juan Manuel Macías
2021-02-01 15:17 word counts and org-mode drawers Sharon Kimble
2021-02-01 23:29 10% ` Juan Manuel Macías
2021-02-04 13:50 1% ` Sharon Kimble
2021-02-09 10:13 local variables and export processing in hooks Eric S Fraga
2021-02-09 11:30 ` tomas
2021-02-09 12:06 ` Eric S Fraga
2021-02-10 15:43 6% ` Maxim Nikulin
2021-02-12 13:01 9% Macros and possible alternatives to the comma character (enhancement?) Juan Manuel Macías
2021-02-13 20:38 7% [Tip] Write the LaTeX preamble in a source block Juan Manuel Macías
2021-02-15 17:37 10% 'false' list item Juan Manuel Macías
2021-02-21 6:56 6% ` Kyle Meyer
2021-02-21 7:05 0% ` Tim Cross
2021-02-21 14:49 10% ` Juan Manuel Macías
2021-02-21 19:33 10% ` Juan Manuel Macías
2021-02-21 19:40 7% ` Diego Zamboni
2021-02-21 21:27 0% ` Samuel Wales
2021-02-21 22:25 10% ` Juan Manuel Macías
2021-02-21 22:31 ` Tim Cross
2021-02-22 0:21 9% ` Juan Manuel Macías
2021-02-21 22:55 6% ` Kyle Meyer
2021-02-16 16:30 9% [question] lisp code in :results header arg.? Juan Manuel Macías
2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
2021-02-16 18:25 10% ` Juan Manuel Macías
2021-02-18 16:33 6% [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
2021-04-19 9:19 5% ` Nicolas Goaziou
2021-04-20 13:56 8% ` Juan Manuel Macías
2021-02-23 18:23 10% false-list-item-mode? Juan Manuel Macías
2021-02-25 22:16 7% Add color space and icc profile information to images Juan Manuel Macías
[not found] <mailman.47.1614445226.20994.emacs-orgmode@gnu.org>
2021-02-27 18:57 ` content management in emacs Ian Garmaise
2021-02-27 19:16 ` Martin Steffen
2021-02-27 20:11 9% ` Juan Manuel Macías
2021-02-28 20:21 printing org table landscape on complete page Andrés Ramírez
2021-02-28 20:53 10% ` Juan Manuel Macías
2021-03-01 0:18 2% ` andrés ramírez
2021-03-01 12:55 9% [tip for EXWM users] An alternative method for isolate trees Juan Manuel Macías
2021-03-01 13:37 6% ` Julian M. Burgos
2021-03-01 14:10 10% ` Juan Manuel Macías
2021-03-01 15:37 5% ` Julian M. Burgos
2021-03-01 16:42 9% ` Juan Manuel Macías
2021-03-02 20:07 Org mode links: Open a PDF file at a given page and highlight a given string Rodrigo Morales
2021-03-03 2:31 9% ` Juan Manuel Macías
2021-03-03 14:51 6% ` Maxim Nikulin
2021-03-03 16:11 9% ` Juan Manuel Macías
2021-03-05 13:02 4% ` Maxim Nikulin
2021-03-04 15:38 Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)] Qqwy/Wiebe-Marten
2021-03-05 12:01 9% ` Juan Manuel Macías
2021-03-06 19:34 7% Org as a book publisher Juan Manuel Macías
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
2021-03-07 15:57 6% ` Juan Manuel Macías
2021-03-07 12:08 6% ` Diego Zamboni
2021-03-07 13:15 0% ` Vikas Rawal
2021-03-07 16:03 8% ` Juan Manuel Macías
2021-03-08 10:46 6% ` Jonathan McHugh
2021-03-07 17:46 ` Dr. Arne Babenhauserheide
2021-03-07 18:30 8% ` Juan Manuel Macías
[not found] ` <87ft16hn62.fsf@emailmessageidheader.nil>
2021-03-07 20:20 10% ` Juan Manuel Macías
2021-03-15 17:10 9% Nested macros and fontification Juan Manuel Macías
2021-03-17 20:29 Syntax Proposal: Multi-line Table Cells/Text Wrapping Atlas Cove
2021-03-17 22:07 9% ` Juan Manuel Macías
2021-03-18 13:38 ` Atlas Cove
2021-03-18 15:15 10% ` Juan Manuel Macías
2021-03-18 14:26 ` Timothy
2021-03-18 14:31 ` Atlas Cove
2021-03-18 21:58 ` Tim Cross
2021-03-18 22:41 10% ` Juan Manuel Macías
2021-03-19 8:08 5% ` tomas
2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-19 8:53 5% ` tomas
2021-03-19 9:22 9% ` Juan Manuel Macías
2021-03-19 10:14 6% ` tomas
2021-03-19 10:53 9% ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
2021-03-19 13:43 6% ` tomas
2021-03-19 15:07 9% ` Juan Manuel Macías
2021-03-20 22:49 6% ` Samuel Wales
2021-03-21 8:43 9% ` Juan Manuel Macías
2021-03-19 13:33 ` Eric S Fraga
2021-03-19 21:33 ` Tim Cross
2021-03-20 10:40 7% ` Juan Manuel Macías
2021-03-22 21:59 10% Items with emphasis marks are not sorted properly in a list Juan Manuel Macías
2021-03-23 8:36 13% ` Juan Manuel Macías
2021-03-24 1:33 "Org" source blocks and minted Michael Gauland
2021-03-24 4:18 10% ` Juan Manuel Macías
2021-03-24 4:24 ` Timothy
2021-03-26 11:55 10% ` Juan Manuel Macías
2021-04-01 8:07 6% ` Michael Gauland
2021-03-25 9:40 8% An interesting LaTeX package Juan Manuel Macías
[not found] <mailman.51.1617033608.26133.emacs-orgmode@gnu.org>
2021-03-29 19:37 ` About exporting Ypo
2021-03-29 21:31 7% ` Juan Manuel Macías
2021-03-29 22:06 ` Tim Cross
2021-03-30 6:17 ` Eric S Fraga
2021-03-30 11:04 6% ` Juan Manuel Macías
2021-03-30 11:54 ` Martin Steffen
2021-03-30 12:44 ` autofrettage
2021-03-30 14:35 ` Martin Steffen
2021-03-30 15:44 7% ` Juan Manuel Macías
2021-03-31 9:59 6% ` Eric S Fraga
2021-03-31 18:28 3% ` Martin Steffen
2021-04-01 6:52 ` Eric S Fraga
2021-04-01 14:21 7% ` Juan Manuel Macías
2021-03-31 9:40 How to expand macro in LaTeX export? How to use different options per export type? Jean Louis
2021-04-03 21:57 9% ` Juan Manuel Macías
2021-03-31 18:56 10% About exporting Juan Manuel Macías
2021-04-02 15:54 Including Email Address in the Reply in Mailing-list Husain Alshehhi
2021-04-02 23:08 ` Tim Cross
2021-04-02 23:45 10% ` Juan Manuel Macías
2021-04-02 18:15 9% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
2021-04-09 22:28 6% ` Nicolas Goaziou
2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
2021-04-10 11:41 10% ` Juan Manuel Macías
2021-04-13 17:31 5% ` Maxim Nikulin
2021-04-13 19:08 9% ` Juan Manuel Macías
2021-04-14 15:42 5% ` Maxim Nikulin
2021-04-14 17:07 9% ` Juan Manuel Macías
2021-04-14 21:36 12% ` Juan Manuel Macías
2021-04-15 14:58 ` Maxim Nikulin
2021-04-15 18:21 9% ` Juan Manuel Macías
2021-04-17 13:27 5% ` Maxim Nikulin
2021-04-18 17:52 9% ` Juan Manuel Macías
2021-04-18 21:20 11% ` Juan Manuel Macías
2021-04-19 8:33 5% ` Nicolas Goaziou
2021-04-19 12:34 ` Maxim Nikulin
2021-04-19 16:08 ` Nicolas Goaziou
2021-04-20 12:20 ` Maxim Nikulin
2021-04-20 13:57 ` Nicolas Goaziou
2021-04-20 15:51 ` Maxim Nikulin
2021-04-20 20:37 ` Nicolas Goaziou
2021-04-21 13:10 ` Maxim Nikulin
2021-04-21 15:45 9% ` Juan Manuel Macías
2021-04-03 9:31 First steps exporting to tex Ypo
2021-04-03 10:15 ` Martin Steffen
2021-04-04 11:04 6% ` Ypo
2021-04-04 11:36 10% ` Juan Manuel Macías
2021-04-03 12:10 7% ` Juan Manuel Macías
2021-04-03 13:31 ` Tim Cross
2021-04-03 16:55 ` Diego Zamboni
2021-04-03 17:07 ` William Denton
2021-04-03 17:49 8% ` Juan Manuel Macías
2021-04-03 18:36 4% ` Jean Louis
2021-04-03 20:46 7% ` Juan Manuel Macías
2021-04-03 18:45 How to get a table into a variable in a shell code block? Greg Minshall
2021-04-03 19:01 10% ` Juan Manuel Macías
2021-04-04 10:31 how to export (latex) a image without using figure Uwe Brauer
2021-04-04 11:17 10% ` Juan Manuel Macías
2021-04-04 11:33 1% ` Uwe Brauer
2021-04-05 9:25 8% [tip] search this mailing list with helm-surfraw Juan Manuel Macías
2021-04-05 20:48 6% Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
2021-04-05 21:36 9% ` Juan Manuel Macías
2021-04-06 19:03 ` physiculus
2021-04-06 19:13 9% ` Juan Manuel Macías
2021-04-07 16:57 4% ` physiculus
2021-04-07 17:26 9% ` Juan Manuel Macías
2021-04-07 17:53 6% ` physiculus
2021-04-07 19:52 10% ` Juan Manuel Macías
2021-04-06 19:46 ` tomas
2021-04-06 20:09 10% ` Juan Manuel Macías
2021-04-07 14:16 6% ` Diego Zamboni
2021-04-07 15:29 8% ` Juan Manuel Macías
2021-04-06 20:44 3% Ypo
2021-04-12 13:50 10% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
[not found] <mailman.57.1618243212.17744.emacs-orgmode@gnu.org>
2021-04-12 18:51 ` Ypo
2021-04-12 23:18 10% ` Juan Manuel Macías
2021-04-12 23:52 6% ` Samuel Wales
2021-04-13 14:16 10% ` Juan Manuel Macías
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).