* Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
@ 2021-09-26 12:49 6% ` Bastien
0 siblings, 0 replies; 200+ results
From: Bastien @ 2021-09-26 12:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have consulted the log, and the patch was already applied by Nicololas
> in commit
Oops, sorry for the noise and thanks for confirming!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [BUG] Conflict between org-emphasis and org-latex
@ 2021-09-26 12:57 10% ` Juan Manuel Macías
2021-09-26 16:57 7% ` Léo Ackermann
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-26 12:57 UTC (permalink / raw)
To: Léo Ackermann; +Cc: orgmode
Hi Léo,
Léo Ackermann writes:
> Hi!
> I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
> following happens:
> When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the
> two stars match together, causing "and" to appear in bold case.
>
> Any idea to fix this unwanted behavior ?
You can insert a zero width space character (U+200B), to prevent that
segment is fontified as emphasis [see the Manual in the section `Escape
Character']. It is enough with insert the character after one of the
asterisks: M-x insert-char RET 200b RET. I also recommend that you look
at this section on Timothy's blog `This Month in Org':
https://blog.tecosaur.com/tmio/2021-05-31-async.html#easy-zero-width
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [BUG] Conflict between org-emphasis and org-latex
2021-09-26 12:57 10% ` Juan Manuel Macías
@ 2021-09-26 16:57 7% ` Léo Ackermann
2021-09-26 18:29 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Léo Ackermann @ 2021-09-26 16:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
Hi Juan Manuel,
I agree that some tricks exist in order to prevent this behavior.
Nevertheless, I think that this bug has been introduced recently (I never
noticed it before) and has to be corrected properly (as this is a really
basic use of org-mode).
Unfortunately, I can barely understand elisp... so writing a patch is far
away from what I can do :/
Best,
Leo
Le dim. 26 sept. 2021 à 14:57, Juan Manuel Macías <maciaschain@posteo.net>
a écrit :
> Hi Léo,
>
> Léo Ackermann writes:
>
> > Hi!
> > I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
> > following happens:
> > When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the
> > two stars match together, causing "and" to appear in bold case.
> >
> > Any idea to fix this unwanted behavior ?
>
> You can insert a zero width space character (U+200B), to prevent that
> segment is fontified as emphasis [see the Manual in the section `Escape
> Character']. It is enough with insert the character after one of the
> asterisks: M-x insert-char RET 200b RET. I also recommend that you look
> at this section on Timothy's blog `This Month in Org':
> https://blog.tecosaur.com/tmio/2021-05-31-async.html#easy-zero-width
>
> Best regards,
>
> Juan Manuel
>
[-- Attachment #2: Type: text/html, Size: 1816 bytes --]
^ permalink raw reply [relevance 7%]
* Re: [BUG] Conflict between org-emphasis and org-latex
2021-09-26 16:57 7% ` Léo Ackermann
@ 2021-09-26 18:29 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-26 18:29 UTC (permalink / raw)
To: Léo Ackermann, Timothy; +Cc: orgmode
Hi Léo and Timothy,
Léo Ackermann writes:
> [...]
> I think that this bug has been introduced recently (I
> never noticed it before)
I don't know if I'm pointing in the right direction, or I am missing
something, but I would say that this is a problem (or consequence) of
`org-emphasis-regexp-components'. According to the docstring, it is a list
with five parts:
("-[:space:]('\"{"
"-[:space:].,:!?;'\")}\\["
"[:space:]"
"." ;; <<====
15)
where part 4, body-regexp, is: "A regexp like "." to match a body
character. Don’t use non-shy groups here, and don’t allow
newline here".
Therefore, the segment "} and {" is fontized here as emphasis
For a LaTeX fragment I think you can do:
(setq org-highlight-latex-and-related 'script)
According to the docstrip:
Non-nil means highlight LaTeX related syntax in the buffer.
When non-nil, the value should be a list containing any of the
following symbols:
‘native’ Highlight LaTeX snippets and environments natively.
‘latex’ Highlight LaTeX snippets and environments.
‘script’ Highlight subscript and superscript.
‘entities’ Highlight entities.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: LaTeX export: grffile is a stub package
@ 2021-09-27 17:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-27 17:00 UTC (permalink / raw)
To: meedstrom; +Cc: orgmode
Hi,
meedstrom@teknik.io writes:
> According to https://ctan.org/pkg/grffile, since 2019-11-08, grffile
> is a stub that just loads graphicx, part of texlive-latex-graphics,
> part of texlive-base. My system (Guix) doesn't have a package for
> grffile, so I can't generate a PDF, which is silly because it's a stub
> anyway.
>
> Suggest fixing by removing \usepackage{grffile} in LaTeX export.
>
> A caveat: some distributions seem to still package an old TeXLive full
> distribution, going by Guix which provides a three-gigabyte "texlive"
> package from 2019-04-10. I'm not sure what sort of deprecation time we
> allow.
grffile is a deprecated LaTeX package, but it is included in TeX live
2021 (Arch). The Arch version of TeXlive is identical to the official
version (except that it does not include the documentation, which must
be installed using an AUR package). My recommendation: unless you are in
Arch or one of its derivatives, it is better to always install *the
official and lastest version* of TeX live (with its own installer and
its own package manager); the versions included in the repositories of
many distros (except for Arch and very few others) are usually outdated
or incomplete, and it is better to avoid them. The current version of
TeXlive is TeXlive 2021. There is, by tradition, a version per year and
in each one many things are modified and quite bugs fixed.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Possible bug? Combine emphasis marker faces?
@ 2021-09-28 16:54 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-28 16:54 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: orgmode
Hi Protesilaos,
Protesilaos Stavrou writes:
> Is there a way to get composite styles? Such as bold and italic or
> verbatim and underline, etc.?
A somewhat dirty solution (without patching the code) could be
evaluating highlight-regexp, for example as a local variable:
#+begin_src emacs-lisp
(defface my/org-it-bold
'((t :slant italic :bold t))
"")
(highlight-regexp "\\([-[:space:]('\"{]\\|^\\)\\(\\([*/_+]\\)\\([*/_+]\\)\\([^[:space:]]\\|[^[:space:]].*?\\(?:
.*?\\)\\{0,15\\}[^[:space:]]\\)\\3\\)\\([-[:space:].,:!?;'\")}\\[]\\|$\\)" 'my/org-it-bold)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: how to export checkboxes to odt?
@ 2021-09-28 20:47 10% ` Juan Manuel Macías
2021-09-29 6:29 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-28 20:47 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> Any idea how to export checkboxes to odt?
>
> I mean not just simply having [ ] in the odt document but having them translated as actual boxes.
You can try:
(defun my/org-odt--checkbox (item)
"Return check-box string associated to ITEM."
(let ((checkbox (org-element-property :checkbox item)))
(if (not checkbox) ""
(format "<text:span text:style-name=\"%s\">%s</text:span>"
"OrgCode" (cl-case checkbox
(on "\u2611 ") ; CHECK MARK
(off "\u2610 ")
(trans "[-] ")))))) ;; I don't know which character to choose here...
(advice-add 'org-odt--checkbox :override #'my/org-odt--checkbox)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: how to export checkboxes to odt?
2021-09-28 20:47 10% ` Juan Manuel Macías
@ 2021-09-29 6:29 1% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-09-29 6:29 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 1383 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan,
> Hi Uwe,
> Uwe Brauer writes:
>> Any idea how to export checkboxes to odt?
>>
>> I mean not just simply having [ ] in the odt document but having them translated as actual boxes.
> You can try:
> (defun my/org-odt--checkbox (item)
> "Return check-box string associated to ITEM."
> (let ((checkbox (org-element-property :checkbox item)))
> (if (not checkbox) ""
> (format "<text:span text:style-name=\"%s\">%s</text:span>"
> "OrgCode" (cl-case checkbox
> (on "\u2611 ") ; CHECK MARK
> (off "\u2610 ")
> (trans "[-] ")))))) ;; I don't know which character to choose here...
> (advice-add 'org-odt--checkbox :override #'my/org-odt--checkbox)
Thanks very much, I saw it too late to respond yesterday. A couple of remarks
1. (on "\u2611 ") ; CHECK MARK: I rather prefer 2612 but this is a
question of taste
2. It seems not to work, I loaded the function and Executed the
advice, but
When I tried to export this minimal example
* Check the conversion of checkboxes
1. Latex $\boxtimes$
2. UTF8 ☒, ▢ □
3. Org [ ] and [X]
4. Org [] [-]
I obtained a odt file in which 3 and 4 were *not* converted to UTF8. I
attach the file. What do I miss?
Regards
Uwe
[-- Attachment #1.2: checkbox.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 12057 bytes --]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: [PATCH] Fix some typos
@ 2021-09-29 10:34 7% ` Max Nikulin
2021-09-29 11:09 0% ` Marco Wahl
2021-09-29 11:11 0% ` Bastien Guerry
0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2021-09-29 10:34 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Juan Manuel Macías, Marco Wahl
Bastien,
A message in this thread
https://orgmode.org/list/87tuiaxivh.fsf@posteo.net/ (Juan Manuel Macías,
Fri, 24 Sep 2021 12:23:14 +0000) contains a patch that fixes a
Shakespeare's sonnet in org-manual.org
Due to updated ORG-NEWS file, it could not be applied directly. I had it
applied after
commit d74a82448bc28dd9be7b57611038bbb4c7172bce
Author: Sébastien Miquel <sebastien.miquel@posteo.eu>
Date: Fri May 28 21:14:22 2021 +0200
and in such form it could be rebased to main. Alternatively ORG-NEWS
part could be just dropped (and applied later).
The story is the following:
- 91373e15c8 doc/org-manual.org 13905 (Juan Manuel Macías
2021-05-15 15:44:36 +0200 13906)
a documentation for verse formatting was added with a strange variant
(spread over net though)
- 215d80d02b doc/org-manual.org 13907 (Stefan Kangas
2021-09-16 14:40:12 -0700 13909)
besides other typos, one in this verse was fixed
- 4271f228db doc/org-manual.org 13909 (Marco Wahl
2021-09-20 12:09:31 +0200 13909)
reverted one edit by Stefan likely assuming old English spelling.
Nobody has an idea concerning origin of current variant (particular
edition of Shakespeare's book), so Juan Manuel created the patch with
variant published in recent books.
In https://orgmode.org/list/sin28h$ufv$1@ciao.gmane.io/
I tried to add the following header
X-Woof-Patch: org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and
another typo
but the patch is not tracked currently on updates.orgmode.org
On 25/09/2021 18:08, Marco Wahl wrote:
> Juan Manuel Macías writes:
>
>> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
>> replaced by the version included in Wikipedia (Shakespeare, William.
>> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
>> p. 113). I also removed a spurious phrase that I put in that patch
>> (Org-News).
>
> Thanks for the fix of the ORGNEWS entry. Nitpick: I'd prefer the fix of
> the ORGNEWS in a further patch for a little bit of more clarity.
I agree with such remark, however I still suppose that the patch could
be applied even in current variant.
^ permalink raw reply [relevance 7%]
* Re: [PATCH] Fix some typos
2021-09-29 10:34 7% ` Max Nikulin
@ 2021-09-29 11:09 0% ` Marco Wahl
2021-09-29 11:11 0% ` Bastien Guerry
1 sibling, 0 replies; 200+ results
From: Marco Wahl @ 2021-09-29 11:09 UTC (permalink / raw)
To: Max Nikulin; +Cc: Bastien, Juan Manuel Macías, orgmode
Max Nikulin <manikulin@gmail.com> writes:
> Bastien,
>
> A message in this thread
> https://orgmode.org/list/87tuiaxivh.fsf@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +0000) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org
>
> Due to updated ORG-NEWS file, it could not be applied directly. I had
> it applied after
>
> commit d74a82448bc28dd9be7b57611038bbb4c7172bce
> Author: Sébastien Miquel <sebastien.miquel@posteo.eu>
> Date: Fri May 28 21:14:22 2021 +0200
>
> and in such form it could be rebased to main. Alternatively ORG-NEWS
> part could be just dropped (and applied later).
>
> The story is the following:
> - 91373e15c8 doc/org-manual.org 13905 (Juan Manuel Macías
> 2021-05-15 15:44:36 +0200 13906)
> a documentation for verse formatting was added with a strange variant
> (spread over net though)
> - 215d80d02b doc/org-manual.org 13907 (Stefan Kangas 2021-09-16
> 14:40:12 -0700 13909)
> besides other typos, one in this verse was fixed
> - 4271f228db doc/org-manual.org 13909 (Marco Wahl 2021-09-20
> 12:09:31 +0200 13909)
> reverted one edit by Stefan likely assuming old English spelling.
>
> Nobody has an idea concerning origin of current variant (particular
> edition of Shakespeare's book), so Juan Manuel created the patch with
> variant published in recent books.
>
> In https://orgmode.org/list/sin28h$ufv$1@ciao.gmane.io/
> I tried to add the following header
> X-Woof-Patch: org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and
> another typo
> but the patch is not tracked currently on updates.orgmode.org
>
> On 25/09/2021 18:08, Marco Wahl wrote:
>> Juan Manuel Macías writes:
>>
>>> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
>>> replaced by the version included in Wikipedia (Shakespeare, William.
>>> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
>>> p. 113). I also removed a spurious phrase that I put in that patch
>>> (Org-News).
>> Thanks for the fix of the ORGNEWS entry. Nitpick: I'd prefer the
>> fix of
>> the ORGNEWS in a further patch for a little bit of more clarity.
>
> I agree with such remark, however I still suppose that the patch could
> be applied even in current variant.
Please go ahead with the patches as you like! That nitpick is meant as
a hint for commits to come!
Regards,
--
Marco
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Fix some typos
2021-09-29 10:34 7% ` Max Nikulin
2021-09-29 11:09 0% ` Marco Wahl
@ 2021-09-29 11:11 0% ` Bastien Guerry
1 sibling, 0 replies; 200+ results
From: Bastien Guerry @ 2021-09-29 11:11 UTC (permalink / raw)
To: Max Nikulin; +Cc: Juan Manuel Macías, Marco Wahl, orgmode
Hi Max,
Max Nikulin <manikulin@gmail.com> writes:
> A message in this thread
> https://orgmode.org/list/87tuiaxivh.fsf@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +0000) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org
Thanks for bringing this to my attention: I've now applied Juan's
change in the main branch.
--
Bastien
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Fix some typos
@ 2021-09-29 11:14 6% ` Bastien
1 sibling, 0 replies; 200+ results
From: Bastien @ 2021-09-29 11:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Marco Wahl, Loris Bennett, orgmode, Max Nikulin
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I also removed a spurious phrase that I put in that patch
> (Org-News).
Applied too! Thanks.
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: Grabbing the link to a message on the archive
@ 2021-10-01 15:07 4% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2021-10-01 15:07 UTC (permalink / raw)
To: emacs-orgmode
On 30/09/2021 12:18, Timothy wrote:
> Hi Greg,
>
>> i love the searching on list.orgmode.org, but i have this recurrent
>> dream: that some day each e-mail message will come with a header listing
>> the URL for that message on <https://list.orgmode.org>. (though i also
>> worry this might open us up to some sort of spam, or other, attack?)
>>
>> and, i’ll add my thanks and congratulations on 9.5!
>>
>> cheers, Greg
>
> If you use mu4e, the following may be of some interest:
> ┌────
> │ (defun +mu4e-ml-message-link (msg)
> │ (cond
> │ ((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
> │ (message "Link %s copied to clipboard" (gui-select-text (format "https://list.orgmode.org/%s" (mu4e-message-field msg :message-id)))))
> │ (t (user-error "Mailing list %s not supported" (mu4e-message-field msg :mailing-list)))))
> │ (add-to-list 'mu4e-view-actions (cons "link to message ML" #'+mu4e-ml-message-link t))
> └────
>
> I expect this could be adapted to other clients (notmuch, gnus, etc.)
> without much trouble :)
lists.gnu.org allows to map Message-ID to URL as well:
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%2Bmessage-id%3A87tuolhyl7.fsf%40posteo.net&idxname=emacs-orgmode
Unfortunately I have no idea how to get Message-ID having a link to
particular message on lists.gnu.org without search by e.g. subject and
author.
I had an impression that mailman mangles links like
https://list.orgmode.org/87tuolhyl7.fsf@posteo.net
since they resemble email addresses, so should be protected from
spammers. I do not have links to prove it for mailman but debbugs
certainly does it. In this sense links to lists.gnu.org are safer:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00133.html
A cheat for debbugs maybe the following: replace "@" to "%40"
https://list.orgmode.org/87tuolhyl7.fsf%40posteo.net/T/#u
(Message that I used in these examples: Juan Manuel Macías. [tip] search
this mailing list with helm-surfraw. 2021-04-05 9:25 UTC)
list.orgmode.org (public inbox) is an ordinary subscriber just as you,
so it can not add any link to messages delivered to you. There is a
dedicated header Archived-At that mail list may add, unfortunately
mailman does not know URL at the time of message processing, so it adds
only a link to whole archive as List-Archive.
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/rfc-2369.html#archive-headers
Curiously news.gmane.io still adds Archived-At despite web interface was
disabled years ago.
^ permalink raw reply [relevance 4%]
* Re: export dispatch → change the default "Contents" string
@ 2021-10-01 16:35 9% ` Juan Manuel Macías
2021-10-01 16:45 1% ` Jean-Christophe Helary
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-01 16:35 UTC (permalink / raw)
To: Jean-Christophe Helary; +Cc: orgmode
Hi, jean-Christophe,
Jean-Christophe Helary writes:
> What is the parameter to change the default "Contents" ToC string when exporting to PDF ?
If I'm not wrong, I think there is no native Org way to change the
default string for LaTeX literals. But if you use babel (the LaTeX
package), you can add this command:
#+LaTeX_Header: \addto{\captionsenglish}{\renewcommand\contentsname{foo}}
That's the old way of doing it, and it still works. The latest Babel
versions also incorporate this other variant:
\setlocalecaption{language-name}{caption-name}{string}
for example:
\setlocalecaption{english}{contents}{Table of Contents}
NB: I strongly recommend using babel always for LaTeX, in any of its
flavors (pdfLaTeX, XeLaTeX, LuaLaTeX), instead of polyglossia, which is
a very buggy package. This package came up when babel didn't support
XeTeX and LuaTeX, years ago, but now it doesn't sense to use it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: export dispatch → change the default "Contents" string
2021-10-01 16:35 9% ` Juan Manuel Macías
@ 2021-10-01 16:45 1% ` Jean-Christophe Helary
0 siblings, 0 replies; 200+ results
From: Jean-Christophe Helary @ 2021-10-01 16:45 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Thank you Juan.
It does not seem to work as I expected, but that's OK, I just removed the ToC.
Jean-Christophe
> On Oct 2, 2021, at 1:35, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi, jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> What is the parameter to change the default "Contents" ToC string when exporting to PDF ?
>
> If I'm not wrong, I think there is no native Org way to change the
> default string for LaTeX literals. But if you use babel (the LaTeX
> package), you can add this command:
>
> #+LaTeX_Header: \addto{\captionsenglish}{\renewcommand\contentsname{foo}}
>
> That's the old way of doing it, and it still works. The latest Babel
> versions also incorporate this other variant:
>
> \setlocalecaption{language-name}{caption-name}{string}
>
> for example:
>
> \setlocalecaption{english}{contents}{Table of Contents}
>
> NB: I strongly recommend using babel always for LaTeX, in any of its
> flavors (pdfLaTeX, XeLaTeX, LuaLaTeX), instead of polyglossia, which is
> a very buggy package. This package came up when babel didn't support
> XeTeX and LuaTeX, years ago, but now it doesn't sense to use it.
>
> Best regards,
>
> Juan Manuel
>
>
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
^ permalink raw reply [relevance 1%]
* [Question] A single *-language-alist in ox-latex.el?
@ 2021-10-02 10:48 12% Juan Manuel Macías
2021-10-02 11:08 5% ` Stefan Nobis
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-02 10:48 UTC (permalink / raw)
To: orgmode
Hi,
I have seen that `org-latex-polyglossia-language-alist' contains far
more languages than `org-latex-babel-language-alist'.
Well, if I'm not mistaken, the situation in the LaTeX ecosystem is this:
Polyglossia appeared as a babel replacement for XelaTeX and LuaLaTeX,
since babel, at that time, had no support for these two new Unicode
based TeX engines. I think those two separate lists in ox-latex.el
translate that situation. But the reality is different now: babel has
full support now for LuaTeX and XeTeX and supports more languages than
polyglossia (and also supports language variants. See
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf p.
20). In addition, babel is part of the LaTeX core and is, therefore,
better mantained.
Of course, anyone who wants to use polyglossia in their documents can
keep doing it without problems. But I think it does not make much sense
to mantain in ox-latex.el two separate lists today. Maybe, for
simplicity, it would be better to unify the two lists in a single db,
something like `org-latex-language-alist'. What do you think?
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 12%]
* Re: [Question] A single *-language-alist in ox-latex.el?
2021-10-02 10:48 12% [Question] A single *-language-alist in ox-latex.el? Juan Manuel Macías
@ 2021-10-02 11:08 5% ` Stefan Nobis
2021-10-02 19:20 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Stefan Nobis @ 2021-10-02 11:08 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Well, if I'm not mistaken, the situation in the LaTeX ecosystem is
> this: Polyglossia appeared as a babel replacement for XelaTeX and
> LuaLaTeX, since babel, at that time, had no support for these two
> new Unicode based TeX engines.
And, as far as I remember, babel development had nearly ceased during
that period.
Since quite some years, the development has gained much more traction
for babel and, as far as I read, babel is today as good or superior to
polyglossia in many regards (but polyglossia is also in quite a good
shape today). See for example:
https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019
In short: Babel is a very good choice in almost all cases, maybe
except for right-to-left texts set with XeLaTeX.
> But I think it does not make much sense to mantain in ox-latex.el
> two separate lists today. Maybe, for simplicity, it would be better
> to unify the two lists in a single db, something like
> `org-latex-language-alist'. What do you think?
+1
--
Until the next mail...,
Stefan.
^ permalink raw reply [relevance 5%]
* Re: [Question] A single *-language-alist in ox-latex.el?
2021-10-02 11:08 5% ` Stefan Nobis
@ 2021-10-02 19:20 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-02 19:20 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode
Hi Stefan,
Stefan Nobis writes:
> And, as far as I remember, babel development had nearly ceased during
> that period.
>
> Since quite some years, the development has gained much more traction
> for babel and, as far as I read, babel is today as good or superior to
> polyglossia in many regards (but polyglossia is also in quite a good
> shape today). See for example:
>
> https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019
>
> In short: Babel is a very good choice in almost all cases, maybe
> except for right-to-left texts set with XeLaTeX.
Indeed, Javier Bezos (who is also the author of very popular packages
like enumitem or titlesec/titletoc) is doing a great job with Babel (you can
see the latest news here: https://latex3.github.io/babel/). And he has
added a lot of powerful features, such as babel replacements (with Lua code)
or the possibility to load languages via ini files and define new
languages with \babelprovide
I've been doing some testing, and I think this hypothetical new
unified list could support two types of members:
1. A member with 2 elements:
("lang-id" "lang-name"),
i.e.: ("it" "italian")
2. A member with 4 elements (for variants):
("lang-id" "babel-lang-name" "polyglossia-lang-name" "polyglossia-variant")
i.e.: ("la-classic" "classiclatin" "latin" "classic")
And then it would be necessary to make some minor modifications in
org-latex-guess-polyglossia-language and org-latex-guess-babel-language.
I will try to write a patch (or at least a proof of concept) in the next days ...
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 12%]
* [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2021-10-03 15:28 5% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-03 15:28 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
Hi all,
I'm attaching a patch with a proposal to unify in a single constant
(named `org-latex-language-alist')
`org-latex-polyglossia-language-alist' and
`org-latex-babel-language-alist', along with some necessary (minor)
modifications in `org-latex-guess-polyglossia-language' and
`org-latex-guess-babel-language'
The new list, which is not exhaustive, is built taking as a reference
the documentation of Babel and Polyglossia in their latest versions
within TeX live 2021. It also assumes the latest improvements in the
babel package (on the current state of the art regarding the babel and
polyglossia packages, see this previous thread:
https://list.orgmode.org/87wnmv4s87.fsf@posteo.net/). I have also
corrected some minor inconsistencies in the previous two lists.
This new alist supports three types of members:
- Members with two elements: CODE BABEL/POLYGLOSSIA-OPTION.
i.e.: ("ar" "arabic")
- Members with three elements: CODE BABEL/POLYGLOSSIA-OPTION ASTERISK
(the presence of the asterisk indicates that this language is not loaded
in Babel using the old method of ldf files but using ini files. If Babel
is loaded in an Org document with these languages, the \"AUTO \"
argument is just removed, to avoid compilation errors. The new babel
method with ini files is not supported, for backward
compatibility with 'old' ldf method).
i.e. ("bo" "tibetan" "*")
- Members with four elements (for variants of languages): CODE
BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT
i.e. ("es" "spanishmx" "spanish" "mexican")
==> babel:
\usepackage[mexican]{babel}
==> polyglossia:
\usepackage{polyglossia}
\setmainlanguage[variant=mexican]{spanish}
I also attach an Org document for testing.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-Unify-in-one-list-babel-and-polyglossia-.patch --]
[-- Type: text/x-patch, Size: 8021 bytes --]
From 389a4e43756a7c195c2c1f751b7dc9c03447526d Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 3 Oct 2021 16:55:31 +0200
Subject: [PATCH] ox-latex.el: Unify in one list babel and polyglossia language
alists
* lisp/ox-latex.el (org-latex-language-alist): Unify in a single list `org-latex-polyglossia-language-alist' and `org-latex-babel-language-alist'
---
lisp/ox-latex.el | 167 +++++++++++++++++++----------------------------
1 file changed, 68 insertions(+), 99 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..de03470fa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -160,144 +160,109 @@
\f
;;; Internal Variables
-(defconst org-latex-babel-language-alist
- '(("af" . "afrikaans")
- ("bg" . "bulgarian")
- ("ca" . "catalan")
- ("cs" . "czech")
- ("cy" . "welsh")
- ("da" . "danish")
- ("de" . "germanb")
- ("de-at" . "naustrian")
- ("de-de" . "ngerman")
- ("el" . "greek")
- ("en" . "english")
- ("en-au" . "australian")
- ("en-ca" . "canadian")
- ("en-gb" . "british")
- ("en-ie" . "irish")
- ("en-nz" . "newzealand")
- ("en-us" . "american")
- ("es" . "spanish")
- ("et" . "estonian")
- ("eu" . "basque")
- ("fi" . "finnish")
- ("fr" . "french")
- ("fr-ca" . "canadien")
- ("gl" . "galician")
- ("hr" . "croatian")
- ("hu" . "hungarian")
- ("id" . "indonesian")
- ("is" . "icelandic")
- ("it" . "italian")
- ("la" . "latin")
- ("ms" . "malay")
- ("nl" . "dutch")
- ("nb" . "norsk")
- ("nn" . "nynorsk")
- ("no" . "norsk")
- ("pl" . "polish")
- ("pt" . "portuguese")
- ("pt-br" . "brazilian")
- ("ro" . "romanian")
- ("ru" . "russian")
- ("sa" . "sanskrit")
- ("sb" . "uppersorbian")
- ("sk" . "slovak")
- ("sl" . "slovene")
- ("sq" . "albanian")
- ("sr" . "serbian")
- ("sv" . "swedish")
- ("ta" . "tamil")
- ("tr" . "turkish")
- ("uk" . "ukrainian"))
- "Alist between language code and corresponding Babel option.")
-
-(defconst org-latex-polyglossia-language-alist
- '(("am" "amharic")
+(defconst org-latex-language-alist
+ '(("am" "amharic" "*")
("ar" "arabic")
- ("ast" "asturian")
+ ("ast" "asturian" "*")
("bg" "bulgarian")
- ("bn" "bengali")
- ("bo" "tibetan")
+ ("bn" "bengali" "*")
+ ("bo" "tibetan" "*")
("br" "breton")
("ca" "catalan")
- ("cop" "coptic")
+ ("cop" "coptic" "*")
("cs" "czech")
("cy" "welsh")
("da" "danish")
- ("de" "german" "german")
- ("de-at" "german" "austrian")
- ("de-de" "german" "german")
- ("dsb" "lsorbian")
- ("dv" "divehi")
+ ("de" "ngerman" "german" "german")
+ ("de-at" "naustrian" "german" "austrian")
+ ("dsb" "lsorbian" "*")
+ ("dv" "divehi" "*")
("el" "greek")
- ("en" "english" "usmax")
- ("en-au" "english" "australian")
- ("en-gb" "english" "uk")
- ("en-nz" "english" "newzealand")
- ("en-us" "english" "usmax")
+ ("el-polyton" "polutonikogreek" "greek" "polytonic")
+ ("en" "american" "english" "usmax")
+ ("en-au" "australian" "english" "australian")
+ ("en-gb" "british" "english" "uk")
+ ("en-nz" "newzealand" "english" "newzealand")
+ ("en-us" "american" "english" "usmax")
("eo" "esperanto")
("es" "spanish")
+ ("es" "spanishmx" "spanish" "mexican")
("et" "estonian")
("eu" "basque")
("fa" "farsi")
("fi" "finnish")
("fr" "french")
- ("fu" "friulan")
+ ("fr-ca" "canadien" "french" "canadian")
+ ("fur" "friulan")
("ga" "irish")
("gd" "scottish")
("gl" "galician")
("he" "hebrew")
("hi" "hindi")
("hr" "croatian")
- ("hsb" "usorbian")
+ ("hsb" "uppersorbian" "sorbian" "upper")
("hu" "magyar")
- ("hy" "armenian")
+ ("hy" "armenian" "*")
("ia" "interlingua")
- ("id" "bahasai")
+ ("id" "bahasai" "*")
("is" "icelandic")
("it" "italian")
- ("kn" "kannada")
- ("la" "latin" "modern")
- ("la-classic" "latin" "classic")
- ("la-medieval" "latin" "medieval")
- ("la-modern" "latin" "modern")
- ("lo" "lao")
+ ("kn" "kannada" "*")
+ ("la" "latin")
+ ("la-classic" "classiclatin" "latin" "classic")
+ ("la-medieval" "medievallatin" "latin" "medieval")
+ ("la-ecclesiastic" "ecclesiasticlatin" "latin" "ecclesiastic")
+ ("lo" "lao" "*")
("lt" "lithuanian")
("lv" "latvian")
- ("ml" "malayalam")
- ("mr" "maranthi")
- ("nb" "norsk")
- ("nko" "nko")
+ ("ml" "malayalam" "*")
+ ("mr" "maranthi" "*")
+ ("nb" "norsk" "norwegian" "bokmal")
("nl" "dutch")
- ("nn" "nynorsk")
+ ("nn" "nynorsk" "norwegian" "nynorsk")
("no" "norsk")
("oc" "occitan")
("pl" "polish")
("pms" "piedmontese")
("pt" "portuges")
("pt-br" "brazilian")
- ("rm" "romansh")
+ ("rm" "romansh" "*")
("ro" "romanian")
("ru" "russian")
- ("sa" "sanskrit")
- ("se" "samin")
+ ("sa" "sanskrit" "*")
("sk" "slovak")
- ("sl" "slovenian")
+ ("sl" "slovene")
("sq" "albanian")
("sr" "serbian")
("sv" "swedish")
- ("syr" "syriac")
- ("ta" "tamil")
- ("te" "telugu")
+ ("syr" "syriac" "*")
+ ("ta" "tamil" "*")
+ ("te" "telugu" "*")
("th" "thai")
("tk" "turkmen")
("tr" "turkish")
("uk" "ukrainian")
- ("ur" "urdu")
+ ("ur" "urdu" "*")
("vi" "vietnamese"))
- "Alist between language code and corresponding Polyglossia option.")
+ "Alist between language code and corresponding Babel/Polyglossia option.
+
+For the names of the languages, the Babel nomenclature is
+preferred to that of Polyglossia, in those cases where both
+coincide.
+
+The alist supports three types of members:
+
+- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
+
+- Members with three elements: CODE BABEL/POLYGLOSSIA OPTION
+ASTERISK (the presence of the asterisk indicates that this
+language is not loaded in Babel using the old method of ldf
+files but using ini files. If Babel is loaded in an Org
+document with these languages, the \"AUTO \" argument is just
+removed, to avoid compilation errors).
+
+- Members with four elements (for variants of languages): CODE
+BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT")
(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
("qbordermatrix" . "\\cr")
@@ -1409,14 +1374,16 @@ Return the new header."
header
(let ((options (save-match-data
(org-split-string (match-string 1 header) ",[ \t]*")))
- (language (cdr (assoc-string language-code
- org-latex-babel-language-alist t))))
+ (language (nth 1 (assoc language-code
+ org-latex-language-alist))))
;; If LANGUAGE is already loaded, return header without AUTO.
;; Otherwise, replace AUTO with language or append language if
;; AUTO is not present.
(replace-match
(mapconcat (lambda (option) (if (equal "AUTO" option) language option))
(cond ((member language options) (delete "AUTO" options))
+ ((let ((l (assoc language-code org-latex-language-alist)))
+ (and (consp l) (= (length l) 3))) (delete "AUTO" options))
((member "AUTO" options) options)
(t (append options (list language))))
", ")
@@ -1462,15 +1429,17 @@ Return the new header."
(concat "\\usepackage{polyglossia}\n"
(mapconcat
(lambda (l)
- (let ((l (or (assoc l org-latex-polyglossia-language-alist)
+ (let ((l (or (assoc l org-latex-language-alist)
l)))
(format (if main-language-set "\\setotherlanguage%s{%s}\n"
(setq main-language-set t)
"\\setmainlanguage%s{%s}\n")
- (if (and (consp l) (= (length l) 3))
- (format "[variant=%s]" (nth 2 l))
+ (if (and (consp l) (= (length l) 4))
+ (format "[variant=%s]" (nth 3 l))
"")
- (nth 1 l))))
+ (if (and (consp l) (= (length l) 4))
+ (nth 2 l)
+ (nth 1 l)))))
languages
""))
t t header 0)))))
--
2.32.0
[-- Attachment #3: test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1525 bytes --]
^ permalink raw reply related [relevance 5%]
* [PATCH] org-manual.org: List the languages supported by smart quotes feature
@ 2021-10-03 17:39 2% Juan Manuel Macías
2021-10-25 13:56 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-03 17:39 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
Hi,
I think a footnote with a list of (currently) supported languages could
be helpful for users who want to apply this feature.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-org-manual.org-List-the-languages-supported-by-smart.patch --]
[-- Type: text/x-patch, Size: 25508 bytes --]
From 26f799a5a53b35f7f3e6e3df10689855832dbebd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 3 Oct 2021 19:11:48 +0200
Subject: [PATCH] org-manual.org: List the languages supported by smart quotes
feature
* doc/org-manual.org (Export Settings): A footnote is added.
---
doc/org-manual.org | 159 +++++++++++++++++++++++----------------------
1 file changed, 82 insertions(+), 77 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..195ed1d46 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11637,9 +11637,9 @@ following arguments.
#+vindex: org-export-with-smart-quotes
Toggle smart quotes (~org-export-with-smart-quotes~). Depending on
- the language used, when activated, Org treats pairs of double quotes
- as primary quotes, pairs of single quotes as secondary quotes, and
- single quote marks as apostrophes.
+ the language used[fn:124], when activated, Org treats pairs of
+ double quotes as primary quotes, pairs of single quotes as secondary
+ quotes, and single quote marks as apostrophes.
- ~*~ ::
@@ -11869,7 +11869,7 @@ keyword:
#+cindex: excluding entries from table of contents
#+cindex: table of contents, exclude entries
Org includes both numbered and unnumbered headlines in the table of
-contents[fn:124]. If you need to exclude an unnumbered headline,
+contents[fn:125]. If you need to exclude an unnumbered headline,
along with all its children, set the =UNNUMBERED= property to =notoc=
value.
@@ -11988,7 +11988,7 @@ be omitted to use the obvious defaults.
| =#+INCLUDE: "~/.emacs" :lines "10-"= | Include lines from 10 to EOF |
Inclusions may specify a file-link to extract an object matched by
-~org-link-search~[fn:125] (see [[*Search Options in File Links]]). The
+~org-link-search~[fn:126] (see [[*Search Options in File Links]]). The
ranges for =:lines= keyword are relative to the requested element.
Therefore,
@@ -12028,7 +12028,7 @@ following syntax:
: #+MACRO: name replacement text; $1, $2 are arguments
#+texinfo: @noindent
-which can be referenced using ={{{name(arg1, arg2)}}}=[fn:126]. For
+which can be referenced using ={{{name(arg1, arg2)}}}=[fn:127]. For
example
#+begin_example
@@ -12147,7 +12147,7 @@ are not exported.
Finally, a =COMMENT= keyword at the beginning of an entry, but after
any other keyword or priority cookie, comments out the entire subtree.
In this case, the subtree is not exported and no code block within it
-is executed either[fn:127]. The command below helps changing the
+is executed either[fn:128]. The command below helps changing the
comment status of a headline.
- {{{kbd(C-c ;)}}} (~org-toggle-comment~) ::
@@ -12419,7 +12419,7 @@ should in principle be exportable as a Beamer presentation.
- Org exports a Beamer frame's objects as block environments. Org can
enforce wrapping in special block types when =BEAMER_ENV= property
- is set[fn:128]. For valid values see
+ is set[fn:129]. For valid values see
~org-beamer-environments-default~. To add more values, see
~org-beamer-environments-extra~.
#+vindex: org-beamer-environments-default
@@ -13007,7 +13007,7 @@ as-is.
#+vindex: org-html-mathjax-options~
LaTeX math snippets (see [[*LaTeX fragments]]) can be displayed in two
different ways on HTML pages. The default is to use the [[https://www.mathjax.org][MathJax]],
-which should work out of the box with Org[fn:129][fn:130]. Some MathJax
+which should work out of the box with Org[fn:130][fn:131]. Some MathJax
display options can be configured via ~org-html-mathjax-options~, or
in the buffer. For example, with the following settings,
@@ -13019,7 +13019,7 @@ in the buffer. For example, with the following settings,
#+texinfo: @noindent
equation labels are displayed on the left margin and equations are
five em from the left margin. In addition, it loads the two MathJax
-extensions =cancel.js= and =noErrors.js=[fn:131].
+extensions =cancel.js= and =noErrors.js=[fn:132].
#+vindex: org-html-mathjax-template
See the docstring of ~org-html-mathjax-options~ for all supported
@@ -13082,7 +13082,7 @@ line.
#+vindex: org-export-html-todo-kwd-class-prefix
#+vindex: org-export-html-tag-class-prefix
You can modify the CSS style definitions for the exported file. The
-HTML exporter assigns the following special CSS classes[fn:132] to
+HTML exporter assigns the following special CSS classes[fn:133] to
appropriate parts of the document---your style specifications may
change these, in addition to any of the standard classes like for
headlines, tables, etc.
@@ -13319,7 +13319,7 @@ LaTeX export back-end finds the compiler version to use from
Org file. See the docstring for the
~org-latex-default-packages-alist~ for loading packages with certain
compilers. Also see ~org-latex-bibtex-compiler~ to set the
-bibliography compiler[fn:133].
+bibliography compiler[fn:134].
*** LaTeX specific export settings
:PROPERTIES:
@@ -13779,7 +13779,7 @@ objects through the attributes =:float= and =:options=. For =:float=:
The LaTeX export back-end passes string values in =:options= to LaTeX
packages for customization of that specific source block. In the
example below, the =:options= are set for Minted. Minted is a source
-code highlighting LaTeX package with many configurable options[fn:134].
+code highlighting LaTeX package with many configurable options[fn:135].
#+begin_example
,#+ATTR_LATEX: :options commentstyle=\bfseries
@@ -14030,7 +14030,7 @@ a limit to a level before the absolute limit (see [[*Export Settings]]).
The ODT export back-end handles creating of OpenDocument Text (ODT)
format. Documents created by this exporter use the
-{{{cite(OpenDocument-v1.2 specification)}}}[fn:135] and are compatible
+{{{cite(OpenDocument-v1.2 specification)}}}[fn:136] and are compatible
with LibreOffice 3.4.
*** Pre-requisites for ODT export
@@ -14431,7 +14431,7 @@ document in one of the following ways:
variables ~org-latex-to-mathml-convert-command~ and
~org-latex-to-mathml-jar-file~.
- If you prefer to use MathToWeb[fn:136] as your converter, you can
+ If you prefer to use MathToWeb[fn:137] as your converter, you can
configure the above variables as shown below.
#+begin_src emacs-lisp
@@ -14442,7 +14442,7 @@ document in one of the following ways:
#+end_src
#+texinfo: @noindent
- or, to use LaTeXML[fn:137] instead,
+ or, to use LaTeXML[fn:138] instead,
#+begin_src emacs-lisp
(setq org-latex-to-mathml-convert-command
@@ -14761,7 +14761,7 @@ with the =#+ATTR_ODT= line. For a discussion on default formatting of
tables, see [[*Tables in ODT export]].
This feature closely mimics the way table templates are defined in the
-OpenDocument-v1.2 specification[fn:138].
+OpenDocument-v1.2 specification[fn:139].
#+vindex: org-odt-table-styles
For quick preview of this feature, install the settings below and export the
@@ -14795,7 +14795,7 @@ templates, define new styles there.
To use this feature proceed as follows:
-1. Create a table template[fn:139].
+1. Create a table template[fn:140].
A table template is set of =table-cell= and =paragraph= styles for
each of the following table cell categories:
@@ -14834,7 +14834,7 @@ To use this feature proceed as follows:
=</office:automatic-styles>= element of the content template file
(see [[x-orgodtcontenttemplate-xml][Factory styles]]).
-2. Define a table style[fn:140].
+2. Define a table style[fn:141].
#+vindex: org-odt-table-styles
To define a table style, create an entry for the style in the
@@ -15948,7 +15948,7 @@ If you want to publish the Org file as an =.org= file but with
~org-org-publish-to-org~. This produces =file.org= and puts it in the
publishing directory. If you want a htmlized version of this file,
set the parameter ~:htmlized-source~ to ~t~. It produces
-=file.org.html= in the publishing directory[fn:141].
+=file.org.html= in the publishing directory[fn:142].
Other files like images only need to be copied to the publishing
destination; for this you can use ~org-publish-attachment~. For
@@ -17457,13 +17457,13 @@ See [[*Languages]] to enable other languages.
#+kindex: C-c C-v e
#+findex: org-babel-execute-src-block
Org provides many ways to execute code blocks. {{{kbd(C-c C-c)}}} or
-{{{kbd(C-c C-v e)}}} with the point on a code block[fn:142] calls the
+{{{kbd(C-c C-v e)}}} with the point on a code block[fn:143] calls the
~org-babel-execute-src-block~ function, which executes the code in the
block, collects the results, and inserts them in the buffer.
#+cindex: @samp{CALL}, keyword
#+vindex: org-babel-inline-result-wrap
-By calling a named code block[fn:143] from an Org mode buffer or
+By calling a named code block[fn:144] from an Org mode buffer or
a table. Org can call the named code blocks from the current Org mode
buffer or from the "Library of Babel" (see [[*Library of Babel]]).
@@ -17664,7 +17664,7 @@ they are mutually exclusive.
- =value= ::
- Default for most Babel libraries[fn:143]. Functional mode. Org
+ Default for most Babel libraries[fn:144]. Functional mode. Org
gets the value by wrapping the code in a function definition in the
language of the source block. That is why when using =:results
value=, code should execute like a function and return a value. For
@@ -18352,7 +18352,7 @@ for Python and Emacs Lisp languages.
#+cindex: @samp{noweb-ref}, header argument
Source code blocks can include references to other source code blocks,
-using a noweb[fn:144] style syntax:
+using a noweb[fn:145] style syntax:
: <<CODE-BLOCK-ID>>
@@ -18863,7 +18863,7 @@ Org Tempo expands snippets to structures defined in
~org-structure-template-alist~ and ~org-tempo-keywords-alist~. For
example, {{{kbd(< s TAB)}}} creates a code block. Enable it by
customizing ~org-modules~ or add =(require 'org-tempo)= to your Emacs
-init file[fn:145].
+init file[fn:146].
#+attr_texinfo: :columns 0.1 0.9
| {{{kbd(a)}}} | =#+BEGIN_EXPORT ascii= ... =#+END_EXPORT= |
@@ -18943,7 +18943,7 @@ in the desired amount with hard spaces and hiding leading stars.
To display the buffer in the indented view, activate Org Indent minor
mode, using {{{kbd(M-x org-indent-mode)}}}. Text lines that are not
headlines are prefixed with virtual spaces to vertically align with
-the headline text[fn:146].
+the headline text[fn:147].
#+vindex: org-indent-indentation-per-level
To make more horizontal space, the headlines are shifted by two
@@ -18971,9 +18971,9 @@ use =STARTUP= keyword as follows:
It is possible to use hard spaces to achieve the indentation instead,
if the bare ASCII file should have the indented look also outside
-Emacs[fn:147]. With Org's support, you have to indent all lines to
+Emacs[fn:148]. With Org's support, you have to indent all lines to
line up with the outline headers. You would use these
-settings[fn:148]:
+settings[fn:149]:
#+begin_src emacs-lisp
(setq org-adapt-indentation t
@@ -19244,7 +19244,7 @@ changes.
#+vindex: org-startup-indented
Dynamic virtual indentation is controlled by the variable
- ~org-startup-indented~[fn:149].
+ ~org-startup-indented~[fn:150].
| =indent= | Start with Org Indent mode turned on. |
| =noindent= | Start with Org Indent mode turned off. |
@@ -20101,7 +20101,7 @@ Tags]]) only for those set in these variables.
#+vindex: org-mobile-directory
The mobile application needs access to a file directory on
-a server[fn:150] to interact with Emacs. Pass its location through
+a server[fn:151] to interact with Emacs. Pass its location through
the ~org-mobile-directory~ variable. If you can mount that directory
locally just set the variable to point to that directory:
@@ -20122,7 +20122,7 @@ With a public server, consider encrypting the files. Org also
requires OpenSSL installed on the local computer. To turn on
encryption, set the same password in the mobile application and in
Emacs. Set the password in the variable
-~org-mobile-use-encryption~[fn:151]. Note that even after the mobile
+~org-mobile-use-encryption~[fn:152]. Note that even after the mobile
application encrypts the file contents, the file name remains visible
on the file systems of the local computer, the server, and the mobile
device.
@@ -20138,15 +20138,15 @@ The command ~org-mobile-push~ copies files listed in
~org-mobile-files~ into the staging area. Files include agenda files
(as listed in ~org-agenda-files~). Customize ~org-mobile-files~ to
add other files. File names are staged with paths relative to
-~org-directory~, so all files should be inside this directory[fn:152].
+~org-directory~, so all files should be inside this directory[fn:153].
Push creates a special Org file =agendas.org= with custom agenda views
-defined by the user[fn:153].
+defined by the user[fn:154].
Finally, Org writes the file =index.org=, containing links to other
files. The mobile application reads this file first from the server
to determine what other files to download for agendas. For faster
-downloads, it is expected to only read files whose checksums[fn:154]
+downloads, it is expected to only read files whose checksums[fn:155]
have changed.
*** Pulling from the mobile application
@@ -20163,7 +20163,7 @@ data in an inbox file format, through the following steps:
1.
#+vindex: org-mobile-inbox-for-pull
- Org moves all entries found in =mobileorg.org=[fn:155] and appends
+ Org moves all entries found in =mobileorg.org=[fn:156] and appends
them to the file pointed to by the variable
~org-mobile-inbox-for-pull~. It should reside neither in the
staging area nor on the server. Each captured entry and each
@@ -20457,9 +20457,9 @@ of these strategies:
#+cindex: @LaTeX{}, and Orgtbl mode
To wrap a source table in LaTeX, use the =comment= environment
-provided by =comment.sty=[fn:156]. To activate it, put
+provided by =comment.sty=[fn:157]. To activate it, put
~\usepackage{comment}~ in the document header. Orgtbl mode inserts
-a radio table skeleton[fn:157] with the command {{{kbd(M-x
+a radio table skeleton[fn:158] with the command {{{kbd(M-x
orgtbl-insert-radio-table)}}}, which prompts for a table name. For
example, if =salesfigures= is the name, the template inserts:
@@ -20478,7 +20478,7 @@ The line =#+ORGTBL: SEND= tells Orgtbl mode to use the function
~orgtbl-to-latex~ to convert the table to LaTeX format, then insert
the table at the target (receive) location named =salesfigures=. Now
the table is ready for data entry. It can even use spreadsheet
-features[fn:158]:
+features[fn:159]:
#+begin_example
% BEGIN RECEIVE ORGTBL salesfigures
@@ -20694,7 +20694,7 @@ Dynamic blocks, like any other block, can be narrowed with
#+vindex: org-agenda-skip-function
#+vindex: org-agenda-skip-function-global
Org provides a special hook to further limit items in agenda views:
-~agenda~, ~agenda*~[fn:159], ~todo~, ~alltodo~, ~tags~, ~tags-todo~,
+~agenda~, ~agenda*~[fn:160], ~todo~, ~alltodo~, ~tags~, ~tags-todo~,
~tags-tree~. Specify a custom function that tests inclusion of every
matched item in the view. This function can also skip as much as is
needed.
@@ -20737,7 +20737,7 @@ meaningful string suitable for the agenda view.
#+vindex: org-agenda-skip-function
Search for entries with a limit set on levels for the custom search.
This is a general approach to creating custom searches in Org. To
-include all levels, use =LEVEL>0=[fn:160]. Then to selectively pick
+include all levels, use =LEVEL>0=[fn:161]. Then to selectively pick
the matched entries, use ~org-agenda-skip-function~, which also
accepts Lisp forms, such as ~org-agenda-skip-entry-if~ and
~org-agenda-skip-subtree-if~. For example:
@@ -22096,127 +22096,132 @@ this timestamp are exported.
Beamer---, the =org-latex-package-alist= variable needs further
configuration. See [[LaTeX specific export settings]].
-[fn:124] At the moment, some export back-ends do not obey this
+[fn:124] Currently the following languages are supported for this
+feature: Arabic, Danish, English, French, German, Greek, Icelandic,
+Italian, Norsk, Nynorsk, Romanian, Russian, Slovenian, Spanish,
+Swedish.
+
+[fn:125] At the moment, some export back-ends do not obey this
specification. For example, LaTeX export excludes every unnumbered
headline from the table of contents.
-[fn:125] Note that ~org-link-search-must-match-exact-headline~ is
+[fn:126] Note that ~org-link-search-must-match-exact-headline~ is
locally bound to non-~nil~. Therefore, ~org-link-search~ only matches
headlines and named elements.
-[fn:126] Since commas separate the arguments, commas within arguments
+[fn:127] Since commas separate the arguments, commas within arguments
have to be escaped with the backslash character. So only those
backslash characters before a comma need escaping with another
backslash character.
-[fn:127] For a less drastic behavior, consider using a select tag (see
+[fn:128] For a less drastic behavior, consider using a select tag (see
[[*Export Settings]]) instead.
-[fn:128] If =BEAMER_ENV= is set, Org export adds =B_environment= tag
+[fn:129] If =BEAMER_ENV= is set, Org export adds =B_environment= tag
to make it visible. The tag serves as a visual aid and has no
semantic relevance.
-[fn:129] By default Org loads MathJax from [[https://cdnjs.com][cdnjs.com]] as recommended by
+[fn:130] By default Org loads MathJax from [[https://cdnjs.com][cdnjs.com]] as recommended by
[[https://www.mathjax.org][MathJax]].
-[fn:130] Please note that exported formulas are part of an HTML
+[fn:131] Please note that exported formulas are part of an HTML
document, and that signs such as =<=, =>=, or =&= have special
meanings. See [[http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX support]].
-[fn:131] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
+[fn:132] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
about extensions.
-[fn:132] If the classes on TODO keywords and tags lead to conflicts,
+[fn:133] If the classes on TODO keywords and tags lead to conflicts,
use the variables ~org-html-todo-kwd-class-prefix~ and
~org-html-tag-class-prefix~ to make them unique.
-[fn:133] This does not allow setting different bibliography compilers
+[fn:134] This does not allow setting different bibliography compilers
for different files. However, "smart" LaTeX compilation systems, such
as latexmk, can select the correct bibliography compiler.
-[fn:134] Minted uses an external Python package for code highlighting,
+[fn:135] Minted uses an external Python package for code highlighting,
which requires the flag =-shell-escape= to be added to
~org-latex-pdf-process~.
-[fn:135] See [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][Open Document Format for Office Applications
+[fn:136] See [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][Open Document Format for Office Applications
(OpenDocument) Version 1.2]].
-[fn:136] See [[http://www.mathtoweb.com/cgi-bin/mathtoweb_home.pl][MathToWeb]].
+[fn:137] See [[http://www.mathtoweb.com/cgi-bin/mathtoweb_home.pl][MathToWeb]].
-[fn:137] See [[http://dlmf.nist.gov/LaTeXML/]].
+[fn:138] See [[http://dlmf.nist.gov/LaTeXML/]].
-[fn:138] [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][OpenDocument-v1.2 Specification]]
+[fn:139] [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][OpenDocument-v1.2 Specification]]
-[fn:139] See the =<table:table-template>= element of the
+[fn:140] See the =<table:table-template>= element of the
OpenDocument-v1.2 specification.
-[fn:140] See the attributes =table:template-name=,
+[fn:141] See the attributes =table:template-name=,
=table:use-first-row-styles=, =table:use-last-row-styles=,
=table:use-first-column-styles=, =table:use-last-column-styles=,
=table:use-banding-rows-styles=, and =table:use-banding-column-styles=
of the =<table:table>= element in the OpenDocument-v1.2 specification.
-[fn:141] If the publishing directory is the same as the source
+[fn:142] If the publishing directory is the same as the source
directory, =file.org= is exported as =file.org.org=, so you probably
do not want to do this.
-[fn:142] The option ~org-babel-no-eval-on-ctrl-c-ctrl-c~ can be used
+[fn:143] The option ~org-babel-no-eval-on-ctrl-c-ctrl-c~ can be used
to remove code evaluation from the {{{kbd(C-c C-c)}}} key binding.
-[fn:143] Actually, the constructs =call_<name>()= and =src_<lang>{}=
+[fn:144] Actually, the constructs =call_<name>()= and =src_<lang>{}=
are not evaluated when they appear in a keyword (see [[*Summary of
In-Buffer Settings]]).
-[fn:144] For noweb literate programming details, see
+[fn:145] For noweb literate programming details, see
http://www.cs.tufts.edu/~nr/noweb/.
-[fn:145] For more information, please refer to the commentary section
+[fn:146] For more information, please refer to the commentary section
in =org-tempo.el=.
-[fn:146] Org Indent mode also sets ~wrap-prefix~ correctly for
+[fn:147] Org Indent mode also sets ~wrap-prefix~ correctly for
indenting and wrapping long lines of headlines or text. This minor
mode also handles Visual Line mode and directly applied settings
through ~word-wrap~.
-[fn:147] This works, but requires extra effort. Org Indent mode is
+[fn:148] This works, but requires extra effort. Org Indent mode is
more convenient for most applications.
-[fn:148] ~org-adapt-indentation~ can also be set to ='headline-data=,
+[fn:149] ~org-adapt-indentation~ can also be set to ='headline-data=,
in which case only data lines below the headline will be indented.
-[fn:149] Note that Org Indent mode also sets the ~wrap-prefix~
+[fn:150] Note that Org Indent mode also sets the ~wrap-prefix~
property, such that Visual Line mode (or purely setting ~word-wrap~)
wraps long lines, including headlines, correctly indented.
-[fn:150] For a server to host files, consider using a WebDAV server,
+[fn:151] For a server to host files, consider using a WebDAV server,
such as [[https://nextcloud.com][Nextcloud]]. Additional help is at this [[https://orgmode.org/worg/org-faq.html#mobileorg_webdav][FAQ entry]].
-[fn:151] If Emacs is configured for safe storing of passwords, then
+[fn:152] If Emacs is configured for safe storing of passwords, then
configure the variable ~org-mobile-encryption-password~; please read
the docstring of that variable.
-[fn:152] Symbolic links in ~org-directory~ need to have the same name
+[fn:153] Symbolic links in ~org-directory~ need to have the same name
as their targets.
-[fn:153] While creating the agendas, Org mode forces =ID= properties
+[fn:154] While creating the agendas, Org mode forces =ID= properties
on all referenced entries, so that these entries can be uniquely
identified if Org Mobile flags them for further action. To avoid
setting properties configure the variable
~org-mobile-force-id-on-agenda-items~ to ~nil~. Org mode then relies
on outline paths, assuming they are unique.
-[fn:154] Checksums are stored automatically in the file
+[fn:155] Checksums are stored automatically in the file
=checksums.dat=.
-[fn:155] The file will be empty after this operation.
+[fn:156] The file will be empty after this operation.
-[fn:156] https://www.ctan.org/pkg/comment
+[fn:157] https://www.ctan.org/pkg/comment
-[fn:157] By default this works only for LaTeX, HTML, and Texinfo.
+[fn:158] By default this works only for LaTeX, HTML, and Texinfo.
Configure the variable ~orgtbl-radio-table-templates~ to install
templates for other modes.
-[fn:158] If the =TBLFM= keyword contains an odd number of dollar
+[fn:159] If the =TBLFM= keyword contains an odd number of dollar
characters, this may cause problems with Font Lock in LaTeX mode. As
shown in the example you can fix this by adding an extra line inside
the =comment= environment that is used to balance the dollar
@@ -22224,9 +22229,9 @@ expressions. If you are using AUCTeX with the font-latex library,
a much better solution is to add the =comment= environment to the
variable ~LaTeX-verbatim-environments~.
-[fn:159] The ~agenda*~ view is the same as ~agenda~ except that it
+[fn:160] The ~agenda*~ view is the same as ~agenda~ except that it
only considers /appointments/, i.e., scheduled and deadline items that
have a time specification =[h]h:mm= in their time-stamps.
-[fn:160] Note that, for ~org-odd-levels-only~, a level number
+[fn:161] Note that, for ~org-odd-levels-only~, a level number
corresponds to order in the hierarchy, not to the number of stars.
--
2.32.0
^ permalink raw reply related [relevance 2%]
* [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
@ 2021-10-04 14:27 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-04 14:27 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
Hi all,
I believe that an html attribute to display marginal verse numbers in
sequence could be useful for certain content, as philological texts
(like here:
https://en.wikisource.org/wiki/The_Iliad_and_Odyssey_of_Homer_(Cowper)/Volume_2/The_Odyssey/Book_I)
The `lines' property must be a digit that is equivalent to the verse
numbers sequence:
#+ATTR_HTML: :lines 5
#+begin_verse
some verses...
#+end_verse
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-html.el-add-verse-numbers-html-attribute-to-verse.patch --]
[-- Type: text/x-patch, Size: 3032 bytes --]
From 9f1bbef52989532e16873a1f75331af0c7b0401f Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 3 Oct 2021 22:12:44 +0200
Subject: [PATCH] ox-html.el: add verse numbers html attribute to verse blocks
* lisp/ox-html.el (org-html-verse-block): add `lines' html attribute
---
lisp/ox-html.el | 45 +++++++++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index a150b1fdb..4889bbe45 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -281,6 +281,7 @@ property on the headline itself.")
.underline { text-decoration: underline; }
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
p.verse { margin-left: 3%; }
+ .versenum {float:right;}
pre {
border: 1px solid #e6e6e6;
border-radius: 3px;
@@ -3754,20 +3755,36 @@ information."
;;;; Verse Block
-(defun org-html-verse-block (_verse-block contents info)
- "Transcode a VERSE-BLOCK element from Org to HTML.
-CONTENTS is verse block contents. INFO is a plist holding
-contextual information."
- (format "<p class=\"verse\">\n%s</p>"
- ;; Replace leading white spaces with non-breaking spaces.
- (replace-regexp-in-string
- "^[ \t]+" (lambda (m) (org-html--make-string (length m) " "))
- ;; Replace each newline character with line break. Also
- ;; remove any trailing "br" close-tag so as to avoid
- ;; duplicates.
- (let* ((br (org-html-close-tag "br" nil info))
- (re (format "\\(?:%s\\)?[ \t]*\n" (regexp-quote br))))
- (replace-regexp-in-string re (concat br "\n") contents)))))
+(defun org-html-verse-block (verse-block contents info)
+ "Transcode a VERSE-BLOCK element from Org to HTML.
+ CONTENTS is verse block contents. INFO is a plist holding
+ contextual information."
+ (let* ((lin (org-export-read-attribute :attr_html verse-block :lines))
+ (versenum (if lin 0 ""))
+ (seqverse (if lin (string-to-number lin) ""))
+ (contents (if lin
+ (with-temp-buffer
+ (insert contents)
+ (save-excursion
+ (goto-char (point-min))
+ (while (re-search-forward "^.+" nil t seqverse)
+ (re-search-forward "$" nil t)
+ (replace-match (concat "<span class=\"versenum\">"
+ (number-to-string
+ (setf versenum (+ versenum seqverse)))
+ "</span>"))))
+ (buffer-string))
+ contents)))
+ (format "<p class=\"verse\">\n%s</p>"
+ ;; Replace leading white spaces with non-breaking spaces.
+ (replace-regexp-in-string
+ "^[ \t]+" (lambda (m) (org-html--make-string (length m) " "))
+ ;; Replace each newline character with line break. Also
+ ;; remove any trailing "br" close-tag so as to avoid
+ ;; duplicates.
+ (let* ((br (org-html-close-tag "br" nil info))
+ (re (format "\\(?:%s\\)?[ \t]*\n" (regexp-quote br))))
+ (replace-regexp-in-string re (concat br "\n") contents))))))
\f
;;; Filter Functions
--
2.32.0
^ permalink raw reply related [relevance 8%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
@ 2021-10-07 11:24 9% ` Juan Manuel Macías
2021-10-07 12:28 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-07 11:24 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode, Eric S Fraga
Uwe Brauer writes:
> I searched about google, but it seems that the only way to have a 10 or
> 11 pt font size is, again, by using styles. Am I right?
Yes, you are right. Word processors handle paragraph and character
styles. Anything that is not styled is applied by direct formatting,
manually, which is often bad practice.
Fun fact: 11pt (for example) in libreoffice or M$ Word is not the same
as 11pt in LaTeX. The reason is that TeX uses by default the classic
point "pt", traditionally used in English-speaking countries. 12pt=1pc
(pica). Word processors and DTP programs like InDesign or QuarkXpress
use the postscript point, which is somewhat higher. In TeX the
postscript point is called 'big point' (bp). There is also the didot
point, which in TeX is called "dd" (12dd = 1 cicero). See:
https://github.com/tweh/tex-units
With the calc-units package you can easily convert between these TeX
units in Elisp. For instance:
(require 'calc-units)
(calc-eval (math-convert-units (calc-eval "11texpt" 'raw) (calc-eval
"texbp" 'raw)))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
2021-10-07 11:24 9% ` Juan Manuel Macías
@ 2021-10-07 12:28 0% ` Uwe Brauer
2021-10-07 12:58 9% ` Juan Manuel Macías
2021-10-07 12:59 0% ` Peter Neilson
0 siblings, 2 replies; 200+ results
From: Uwe Brauer @ 2021-10-07 12:28 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> I searched about google, but it seems that the only way to have a 10 or
>> 11 pt font size is, again, by using styles. Am I right?
> Yes, you are right. Word processors handle paragraph and character
> styles. Anything that is not styled is applied by direct formatting,
> manually, which is often bad practice.
> Fun fact: 11pt (for example) in libreoffice or M$ Word is not the same
> as 11pt in LaTeX. The reason is that TeX uses by default the classic
> point "pt", traditionally used in English-speaking countries. 12pt=1pc
> (pica). Word processors and DTP programs like InDesign or QuarkXpress
> use the postscript point, which is somewhat higher. In TeX the
> postscript point is called 'big point' (bp). There is also the didot
> point, which in TeX is called "dd" (12dd = 1 cicero). See:
> https://github.com/tweh/tex-units
> With the calc-units package you can easily convert between these TeX
> units in Elisp. For instance:
> (require 'calc-units)
> (calc-eval (math-convert-units (calc-eval "11texpt" 'raw) (calc-eval
> "texbp" 'raw)))
Thanks, but it seems 11TeXpt-->10.95
So it is not that different.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
2021-10-07 12:28 0% ` Uwe Brauer
@ 2021-10-07 12:58 9% ` Juan Manuel Macías
2021-10-07 12:59 0% ` Peter Neilson
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-07 12:58 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Thanks, but it seems 11TeXpt-->10.95
>
> So it is not that different.
In typography it's a significant difference. It's not dramatic, but it
can produce different results in a book using the same body text and the
same line spacing, same margins, page dims. etc. Also TeX uses more
decimals. It all depends on more factors, of course: the font or the
microtype properties of pdfTeX and LuaTeX, especially horizontal
scaling, which can also have a significant influence, when activated, on
the appearance of text and pagination.
In any case, what I said was nothing more than a fun typographic fact,
since most people think that there is only one type of point.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
2021-10-07 12:28 0% ` Uwe Brauer
2021-10-07 12:58 9% ` Juan Manuel Macías
@ 2021-10-07 12:59 0% ` Peter Neilson
1 sibling, 0 replies; 200+ results
From: Peter Neilson @ 2021-10-07 12:59 UTC (permalink / raw)
To: emacs-orgmode
On Thu, 07 Oct 2021 08:28:03 -0400, Uwe Brauer <oub@mat.ucm.es> wrote:
>>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Uwe Brauer writes:
>>> I searched about google, but it seems that the only way to have a 10 or
>>> 11 pt font size is, again, by using styles. Am I right?
>
>> Yes, you are right. Word processors handle paragraph and character
>> styles. Anything that is not styled is applied by direct formatting,
>> manually, which is often bad practice.
>
>> Fun fact: 11pt (for example) in libreoffice or M$ Word is not the same
>> as 11pt in LaTeX. The reason is that TeX uses by default the classic
>> point "pt", traditionally used in English-speaking countries. 12pt=1pc
>> (pica). Word processors and DTP programs like InDesign or QuarkXpress
>> use the postscript point, which is somewhat higher. In TeX the
>> postscript point is called 'big point' (bp). There is also the didot
>> point, which in TeX is called "dd" (12dd = 1 cicero). See:
>> https://github.com/tweh/tex-units
>
>> With the calc-units package you can easily convert between these TeX
>> units in Elisp. For instance:
>
>> (require 'calc-units)
>
>> (calc-eval (math-convert-units (calc-eval "11texpt" 'raw) (calc-eval
>> "texbp" 'raw)))
>
> Thanks, but it seems 11TeXpt-->10.95
>
> So it is not that different.
Sometimes that kind of difference can cause minor sessions of
tearing-out-the-hair, like when the expected pagination is off, with just
one word hanging off into the wilderness of another separate page. Manual
typesetting, back in the dark ages of hand-set lead type, or even
Linotype, encountered those problems, too. What did the stymied typesetter
do? He'd leave out words! Yes, really!! "This sentence no verb."
^ permalink raw reply [relevance 0%]
* [tip] Go to the org node from the attached directory
@ 2021-10-07 14:57 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-07 14:57 UTC (permalink / raw)
To: orgmode
Hi,
I often come across the following use case:
helm-locate leads me to a file named (for example) document.pdf, which
is in an attached folder of an Org node. I open the document and then I
would like to jump from there to the Org node. I don't know if anyone
has found any solutions for this or if there is any specific package. I
have come up with this poor man's solution: add a local variable to the
attached directory, which should contain the org node ID.
The function that adds the variable after I run org-attach:
#+begin_src emacs-lisp
(defun my-org-attach/add-dir-variable (&rest _ignore)
(let* ((dir (org-attach-dir))
(id (org-id-get-create))
(default-directory dir))
(unless (file-exists-p (concat dir "/" ".dir-locals.el"))
(save-window-excursion
(add-dir-local-variable nil 'node-id id)
(save-buffer)
(read (current-buffer))
(kill-buffer)))))
#+end_src
and then:
#+begin_src emacs-lisp
(advice-add 'org-attach :after #'my-org-attach/add-dir-variable)
#+end_src
and the function to jump from the attached folder to the org node:
#+begin_src emacs-lisp
(defun my-org-attach/goto-node ()
(interactive)
(org-id-goto node-id))
#+end_src
(of course this only works if there is only one attached directory per
node).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
@ 2021-10-10 2:52 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-10 2:52 UTC (permalink / raw)
To: copropriete27ruemoret; +Cc: orgmode
copropriete27ruemoret@gmail.com writes:
> Unless you insist on using Computer Modern with a word processing
> programm (yes, it can be done, at least with the OTF versions of these
> fonts), or Times New Roman/Cambria with LaTeX (again possible thanks to
> their OTF incarnation) and slaving to force LaTeX choices on Word (or
> Word choices on LaTeX, much harder and probably abysmally stupid), your
> resulting documents will vary for much larger reasons : floats
> handling, table structures, layout structure, different ligatures,
> different kernings, etc...
It is not enough to use the same font nor the same font technology
(otf). In my previous post I referred to microtypegraphical processes
that influence drastically the formal aspect, regardless of the font and
the 'glyph level', layout, and other macro typographycal elements. Word
processors do not have the TeX line breaking algorithm, for example, nor
the horizontal scaling and optical margin alignment properties that were
first implemented in pdfTeX (these properties are based on the theories
of Herman Zapf on the Gutenberg Bible and were implemented for the first
time in an experimental software older than TeX called hz-program). That
is why I always recommend that documents made in a word processor are
never fully justified: word processors *do not know how to justify*
(HTML also does not know how to do it) and the result is usually bad and
full of rivers. And there is the fact also that word processors work on
postscript points. As I said in the previous message, there are many
more factors, but these merely physical (and 'invisible') factors are
important.
Even software like Adobe InDesign, which implements the TeX algorithm
and the microtype properties of Zapf (in a rather sloppy way, since it
does so with generic values applied to the character and not to the
glyph) does not achieve the precision of TeX; therefore, there may be
variations.
In any case, I am talking about processes at the lowest level
(microtypographical). Generally speaking, word processors cannot imitate
TeX. But TeX can imitate word: just disable TeX algorithm (\sloppypar)
and use postscript points values. But, except as an experiment, it
doesn't make much sense...
> BTW: since most of what is typeset nowadays will be used as PDF, HTML
> and/or epub (and paper-printed only for archival purposes), it is high
> time to revisit typography funamentals (currently based on more than 5
> centuries of use of the *physics* of the "paper" medium) to adapt them
> to the physics of computer display and the physiology of human reading
> of this new medium (which is *not* the same as "paper" reading).
The PDF format has evolved a lot since the 90s, but it is still, in
essence, 'printed paper that you can see on screen', device independent.
Paradoxically, it was a revolution in printing, and it was of crucial
importance in the extinction of the old photomechanical printing
methods, which were complex and extremely expensive. As for the
relationship of typography with digital media, or new media, that is a
long topic. But, in any possible medium, I think that what Stanley
Morison (author of Times Roman) said will always prevail in good
typography:
#+begin_quote
Typography is the efficient means to an essentially
utilitarian and only accidentally aesthetic end, for the enjoyment of
patterns is rarely the reader’s chief aim. Therefore, any disposition of
printing material which, whatever the intention, has the effect of
coming between the author and the reader is wrong.
#+end_quote
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* [minor tip] "TeXify" strings "TeX" and "LaTeX" when exporting to HTML
@ 2021-10-15 16:56 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-15 16:56 UTC (permalink / raw)
To: orgmode
Hi all,
I wrote this simple filter for my blogs, which formats "TeX" and "LaTeX"
strings in the TeX 'typographic' style (or something similar).
First, these variables:
#+begin_src emacs-lisp
(setq my/tex-html-string "<span style=\"font-family:serif;\">T<span
style=\"vertical-align:-0.4ex;font-size:smaller;\">E</span>X</span>")
(setq my/latex-html-string "<span style=\"font-family:serif;\">L<span
style=\"vertical-align:0.5ex;font-size:smaller;margin-left:-0.3em;\">A</span>T<span
style=\"vertical-align:-0.4ex;font-size:smaller;\">E</span>X</span>")
#+end_src
Of course, the strings can be improved. Another alternative would be to use the wikipedia images:
<img
src=\"https://wikimedia.org/api/rest_v1/media/math/render/svg/45c5b62b0f454f4ed8caa486d6d3cd0e0c065232\"
style=\"vertical-align: -1.005ex; width:5.094ex; height:2.843ex;\"
alt=\"TeX\"/>
<img
src=\"https://wikimedia.org/api/rest_v1/media/math/render/svg/fa952935eafe23237c5a52922460c192fde88435\"
style=\"vertical-align: -1.005ex; width:7.107ex; height:2.843ex;\"
alt=\"LaTeX\"/>
The function:
#+begin_src emacs-lisp
(defun my/latex-string-html-filter (text backend info)
(interactive)
(when (org-export-derived-backend-p backend 'html)
(let ((case-fold-search nil))
(with-temp-buffer
(insert text)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\([^La]\\)TeX" nil t)
(replace-match (concat "\\1" my/tex-html-string))))
(save-excursion
(goto-char (point-min))
(while (re-search-forward "LaTeX" nil t)
(replace-match my/latex-html-string)))
(setq text (buffer-string))))))
#+end_src
And, finally:
#+begin_src emacs-lisp
(add-to-list 'org-export-filter-plain-text-functions #'my/latex-string-html-filter)
#+end_src
Fun fact. Donald Knuth explains in the first chapter of his /TeX book/,
"The Name of the Game", the origin of the term TeX, and why it is
formatted that way:
#+begin_quote
English words like `technology' stem from a Greek root beginning with
the letters τεχ...; and this same Greek word means /art/ as well as
technology.
[...]
Insiders pronounce the χ of TeX as a Greek chi, not as an `x', so that
TeX rhymes with the word blecchhh. It's the `ch' sound in Scottish words
like /loch/ or German words like /ach/; it's a Spanish `j' and a Russian
`kh'.
[...]
On the other hand, it's important to notice another thing about TeX's
name: The `E' is out of kilter. This logo displaced `E' is a reminder
that TeX is about typesetting, and it distinguishes TeX from other
system names. [...] The correct way to refer to TeX in a computer file,
or when using some other medium that doesn't allow lowering of the `E',
is to type `TeX'. Then there will be no confusion with similar names,
and people will be primed to pronounce everything properly.
#+end_quote
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Unable to configure emacs 27.2 to use org 9.5
@ 2021-10-18 22:28 13% ` Juan Manuel Macías
2021-10-19 8:32 5% ` [mostly solved] " Detlef Steuer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-18 22:28 UTC (permalink / raw)
To: Detlef Steuer; +Cc: orgmode
Hi Detlef,
Detlef Steuer writes:
> I have installed 9.5 with package-install in a clean emacs session,
> it is shown as installed, too, but whatever I try, my org-version is
> shown as 9.4.6, which is included in 27.2.
> (I assume, and therefore citeproc unavailable)
Have you looked in your elpa directory if you see this path: .../elpa/org-9.5/?
Have you tried uninstalling Org and reinstalling it?
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 13%]
* [mostly solved] Re: Unable to configure emacs 27.2 to use org 9.5
2021-10-18 22:28 13% ` Juan Manuel Macías
@ 2021-10-19 8:32 5% ` Detlef Steuer
0 siblings, 0 replies; 200+ results
From: Detlef Steuer @ 2021-10-19 8:32 UTC (permalink / raw)
To: emacs-orgmode
Am Mon, 18 Oct 2021 22:28:42 +0000
schrieb Juan Manuel Macías <maciaschain@posteo.net>:
> Hi Detlef,
>
> Detlef Steuer writes:
>
> > I have installed 9.5 with package-install in a clean emacs session,
> > it is shown as installed, too, but whatever I try, my org-version is
> > shown as 9.4.6, which is included in 27.2.
> > (I assume, and therefore citeproc unavailable)
>
> Have you looked in your elpa directory if you see this path:
> .../elpa/org-9.5/?
Yes, it is there.
I now tried on a second machine and everything worked as expected,
after I removed org-plus-contrib from my elpa directory there.
On machine number one there is no such directory. I will try to
re-initialize everything elpa there and see what will happen.
So there is hope and nano may remain a desperate threat :-)
Thank you!
Detlef
>
> Have you tried uninstalling Org and reinstalling it?
>
> Best regards,
>
> Juan Manuel
>
--
"Wozu leben wir, wenn nicht dazu, uns gegenseitig das Leben
einfacher zu machen. (George Eliot)"
Dr. Detlef Steuer
Helmut-Schmidt-Universität
Fakultät WiSo
Holstenhofweg 85
22043 Hamburg
Tel: 040/6541-2819
mail: steuer@hsu-hh.de
^ permalink raw reply [relevance 5%]
* Fancy underlines in Org to LaTeX
@ 2021-10-20 14:57 13% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-20 14:57 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Hi,
A very interesting LaTeX package, soulpos (by Javier Bezos), has
recently been uploaded to CTAN, which allows you to define personalized
underlining styles in a very free way:
https://www.ctan.org/pkg/soulpos
I have tried to adapt its use to Org, so I am attaching a small test
document here. In the preamble I have defined a command \myuline (with
the xparse syntax), with five different values for \uline:
- \myuline the default value, a single underline,
- \myuline[ul1], \myuline[ul2], \myuline[ul3] and \myuline[ul4], four
different underline styles, taken from the examples in the soulpos
documentation.
See this screenshot: https://i.imgur.com/UK6W8sl.png
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
[-- Attachment #2: soulpos-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 4018 bytes --]
^ permalink raw reply [relevance 13%]
* [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt)
@ 2021-10-22 15:01 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-22 15:01 UTC (permalink / raw)
To: orgmode
Hi,
Sometimes I need to export an Org document with certain "meta-comments",
so I wrote this export filter to export those footnotes that start with
the string "!annot" to:
- [LaTeX] PDF annotations (requires the pdfcomment LaTeX package),
- [odt] Comments.
#+BIND: org-export-filter-footnote-reference-functions (my-custom-filters/export-footnote-as-annotation)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/export-footnote-as-annotation (text backend info)
(interactive)
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match-p "!annot" text))
(replace-regexp-in-string "\\\\footnote{\s*!annot\s*"
"\\\\pdfcomment[icon=Note,opacity=0.4,color=gray,date]{"
text))
((and (org-export-derived-backend-p backend 'odt)
(string-match-p "!annot" text))
(with-temp-buffer
(insert text)
(let* ((from (save-excursion
(goto-char (point-min))
(re-search-forward "!annot" nil t)
(point)))
(to (save-excursion
(goto-char from)
(re-search-forward "</text:p>" nil t)
(- (point) 9)))
(contents (buffer-substring-no-properties from to)))
(delete-region (point-min) (point-max))
(insert (concat
"<office:annotation loext:resolved=\"false\"><dc:creator>"
(car (plist-get info :author))
"</dc:creator><dc:date>"
;; date in iso format
(org-odt--format-timestamp (plist-get info :date) nil t)
"</dc:date><text:p text:style-name=\"P5\"><text:span text:style-name=\"T1\">"
contents
"</text:span></text:p></office:annotation> "))
(setq text (buffer-string)))))))
#+end_src
Example:
Lorem[fn:1] ipsum dolor sit amet,
[fn:1] !annot This note will be exported as an annotation...
And this other filter does not export the notes that start with the
string "!noannot" (although it could be merged with the previous
filter):
#+BIND: org-export-filter-footnote-reference-functions (my-custom-filters/disable-footnote-as-annotation)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/disable-footnote-as-annotation (text backend info)
(interactive)
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match-p "!noannot" text))
(replace-regexp-in-string ".+"
""
text))
((and (org-export-derived-backend-p backend 'odt)
(string-match-p "!noannot" text))
(replace-regexp-in-string ".+"
""
text))))
#+end_src
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías --
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 10%]
* Re: Sub-figures in Org Mode
@ 2021-10-23 0:00 10% ` Juan Manuel Macías
2021-10-26 17:46 5% ` Jason Ross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-23 0:00 UTC (permalink / raw)
To: Jason Ross; +Cc: orgmode
Hi Jason,
Jason Ross <jasonross1024@gmail.com> writes:
> Are there any workarounds people use to create subfigures in Org Mode
> when exporting to LaTeX? Example output:
In this thread I explain a procedure to export images as subfigures
using org links: https://list.orgmode.org/87mty1an66.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* A quick LaTeX reference guide in Org
@ 2021-10-24 14:23 9% Juan Manuel Macías
2021-10-24 20:18 6% ` Tim Cross
2021-10-25 0:42 7% ` Thomas S. Dye
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-24 14:23 UTC (permalink / raw)
To: orgmode
Hi,
The TeXstudio editor includes a comprehensive LaTeX reference guide in
HTML
(https://github.com/texstudio-org/texstudio/blob/master/utilities/latexhelp.html).
I have converted it to Org with Pandoc (and then cleaned it up and fixed
some broken links). It can be downloaded here:
https://cloud.disroot.org/s/krGSf7TmFZRiyZL
I think it may be useful for a quick LaTeX query. You could even use
org-ql and define a function like this:
(require 'org-ql)
(defun my-latex-apropos ()
(interactive)
(let ((regexp (if (not (current-word t t))
(read-from-minibuffer "Find (regexp): ")
(read-from-minibuffer "Find: " (current-word t t)))))
(org-ql-search
"/path-to/latexreference.org"
`(regexp ,regexp))))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: A quick LaTeX reference guide in Org
2021-10-24 14:23 9% A quick LaTeX reference guide in Org Juan Manuel Macías
@ 2021-10-24 20:18 6% ` Tim Cross
2021-10-25 11:35 10% ` Juan Manuel Macías
2021-10-25 0:42 7% ` Thomas S. Dye
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-10-24 20:18 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> The TeXstudio editor includes a comprehensive LaTeX reference guide in
> HTML
> (https://github.com/texstudio-org/texstudio/blob/master/utilities/latexhelp.html).
> I have converted it to Org with Pandoc (and then cleaned it up and fixed
> some broken links). It can be downloaded here:
> https://cloud.disroot.org/s/krGSf7TmFZRiyZL
>
> I think it may be useful for a quick LaTeX query. You could even use
> org-ql and define a function like this:
>
> (require 'org-ql)
> (defun my-latex-apropos ()
> (interactive)
> (let ((regexp (if (not (current-word t t))
> (read-from-minibuffer "Find (regexp): ")
> (read-from-minibuffer "Find: " (current-word t t)))))
> (org-ql-search
> "/path-to/latexreference.org"
> `(regexp ,regexp))))
>
>
There is also a latex2e.info package 'out there'. I have it installed
from my Linux distro and find being able to run (info)Latex very useful
as a basic reference.
^ permalink raw reply [relevance 6%]
* Re: A quick LaTeX reference guide in Org
2021-10-24 14:23 9% A quick LaTeX reference guide in Org Juan Manuel Macías
2021-10-24 20:18 6% ` Tim Cross
@ 2021-10-25 0:42 7% ` Thomas S. Dye
1 sibling, 0 replies; 200+ results
From: Thomas S. Dye @ 2021-10-25 0:42 UTC (permalink / raw)
To: emacs-orgmode
Aloha Juan Manuel,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> The TeXstudio editor includes a comprehensive LaTeX reference
> guide in
> HTML
> (https://github.com/texstudio-org/texstudio/blob/master/utilities/latexhelp.html).
> I have converted it to Org with Pandoc (and then cleaned it up
> and fixed
> some broken links). It can be downloaded here:
> https://cloud.disroot.org/s/krGSf7TmFZRiyZL
>
> I think it may be useful for a quick LaTeX query. You could even
> use
> org-ql and define a function like this:
>
> (require 'org-ql)
> (defun my-latex-apropos ()
> (interactive)
> (let ((regexp (if (not (current-word t t))
> (read-from-minibuffer "Find (regexp): ")
> (read-from-minibuffer "Find: " (current-word t t)))))
> (org-ql-search
> "/path-to/latexreference.org"
> `(regexp ,regexp))))
>
> Best regards,
>
> Juan Manuel
Such a handy utility! Thanks for sharing.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 7%]
* Re: A quick LaTeX reference guide in Org
2021-10-24 20:18 6% ` Tim Cross
@ 2021-10-25 11:35 10% ` Juan Manuel Macías
2021-10-25 12:30 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-25 11:35 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> There is also a latex2e.info package 'out there'. I have it installed
> from my Linux distro and find being able to run (info)Latex very useful
> as a basic reference.
Thank you very much for this information, I did not know it. I just saw
that there is a `latex2e-help-texinfo' package in my distro (Arch), not in
the official repositories but in the AUR. Very useful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: A quick LaTeX reference guide in Org
2021-10-25 11:35 10% ` Juan Manuel Macías
@ 2021-10-25 12:30 6% ` Eric S Fraga
2021-10-25 12:58 0% ` John Hendy
2021-10-25 14:10 10% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Eric S Fraga @ 2021-10-25 12:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Tim Cross, orgmode
On Monday, 25 Oct 2021 at 11:35, Juan Manuel Macías wrote:
> Thank you very much for this information, I did not know it. I just saw
> that there is a `latex2e-help-texinfo' package in my distro (Arch), not in
> the official repositories but in the AUR. Very useful.
It's in CTAN, the official (?) LaTeX repository.
--
Professor Eric S Fraga
Fresa: https://tinyurl.com/5t8t5auv & doi:10.5281/zenodo.5045812
PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
Latest paper (10 Sep 2021): doi:10.1016/j.nucengdes.2021.111432
^ permalink raw reply [relevance 6%]
* Re: A quick LaTeX reference guide in Org
2021-10-25 12:30 6% ` Eric S Fraga
@ 2021-10-25 12:58 0% ` John Hendy
2021-10-25 14:10 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: John Hendy @ 2021-10-25 12:58 UTC (permalink / raw)
To: Juan Manuel Macías, Tim Cross, orgmode
On Mon, Oct 25, 2021 at 7:49 AM Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>
> On Monday, 25 Oct 2021 at 11:35, Juan Manuel Macías wrote:
> > Thank you very much for this information, I did not know it. I just saw
> > that there is a `latex2e-help-texinfo' package in my distro (Arch), not in
> > the official repositories but in the AUR. Very useful.
>
> It's in CTAN, the official (?) LaTeX repository.
As an arch user, just confirming. For what it's worth, the way to find
the package's "home base" is in the upstream url, which is as Eric
says.
https://aur.archlinux.org/packages/latex2e-help-texinfo/
"""
Upstream URL: https://ctan.org/pkg/latex2e-help-texinfo
"""
>
> --
> Professor Eric S Fraga
> Fresa: https://tinyurl.com/5t8t5auv & doi:10.5281/zenodo.5045812
> PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
>
> Latest paper (10 Sep 2021): doi:10.1016/j.nucengdes.2021.111432
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] org-manual.org: List the languages supported by smart quotes feature
2021-10-03 17:39 2% [PATCH] org-manual.org: List the languages supported by smart quotes feature Juan Manuel Macías
@ 2021-10-25 13:56 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2021-10-25 13:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> I think a footnote with a list of (currently) supported languages could
> be helpful for users who want to apply this feature.
Looks useful. It is also a good idea to mention
org-export-smart-quotes-alist variable. Otherwise, we may forget to
update this footnote in future when new languages are supported.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: A quick LaTeX reference guide in Org
2021-10-25 12:30 6% ` Eric S Fraga
2021-10-25 12:58 0% ` John Hendy
@ 2021-10-25 14:10 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-25 14:10 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga writes:
> It's in CTAN, the official (?) LaTeX repository.
I just saw it now there. CTAN is an infinite bazaar :-)
By the way, in CTAN there is also the /TeX for the Impatient/ book (I
love that title), which is a very good manual for programming at low
level in TeX/plainTeX: https://www.ctan.org/pkg/impatient (it's more
concise than Knuth's /TeX book/, which I bought on paper a long time
ago, for 'historical' reasons...)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Support for tabularray in LaTeX export
@ 2021-10-25 14:18 10% ` Juan Manuel Macías
2021-10-25 17:25 0% ` Thomas Dye
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-25 14:18 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Vikas Rawal writes:
>>
>> Hi Vikas,
>>
>> You can define a modified version of `org-latex--org-table',
>> adding a new LaTeX attribute `:options'. Something like this:
>
> Is there a case for incorporating this in orgmode itself? There is some general utility for this in my view.
I can prepare a patch based on that code, if you consider it useful
(https://list.orgmode.org/87ilzjgyqg.fsf@posteo.net/)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Support for tabularray in LaTeX export
2021-10-25 14:18 10% ` Juan Manuel Macías
@ 2021-10-25 17:25 0% ` Thomas Dye
0 siblings, 0 replies; 200+ results
From: Thomas Dye @ 2021-10-25 17:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Vikas Rawal, orgmode
> On Oct 25, 2021, at 4:23 AM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Vikas Rawal writes:
>
>>>
>>> Hi Vikas,
>>>
>>> You can define a modified version of `org-latex--org-table',
>>> adding a new LaTeX attribute `:options'. Something like this:
>>
>> Is there a case for incorporating this in orgmode itself? There is some general utility for this in my view.
>
> I can prepare a patch based on that code, if you consider it useful
> (https://list.orgmode.org/87ilzjgyqg.fsf@posteo.net/)
>
> Best regards,
>
> Juan Manuel
>
+1
All the best,
Tom
^ permalink raw reply [relevance 0%]
* [patch] ox-latex.el: add `:options' LaTeX attribute to tables
@ 2021-10-26 16:05 9% Juan Manuel Macías
2021-11-03 16:32 6% ` Nicolas Goaziou
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-26 16:05 UTC (permalink / raw)
To: orgmode; +Cc: Vikas Rawal
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Hi,
The `:options' attr. allows adding an optional argument with various
table options (between brackets in LaTeX export), since certain tabular
environments, such as `longtblr' of the `tabularray' LaTeX package,
provides this structure (see:
https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=DuaBB28nCsVqEA@mail.gmail.com/#r)
Example:
#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
#+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}
==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet}]{colspec = {XXX}, width = 0.85\linewidth}
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-options-latex-attribute-to-tables.patch --]
[-- Type: text/x-patch, Size: 1495 bytes --]
From 9b51d999029f91adc93a6009bc3ddf56bba7ba4a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 26 Oct 2021 12:29:55 +0200
Subject: [PATCH] ox-latex.el: add `options' latex attribute to tables
* lisp/ox-latex.el (org-latex--org-table): The `:options' LaTeX
attribute allows adding an optional argument (\begin{env}[opt]), since
certain tabular environments, such as longtblr, accept optional
arguments.
---
lisp/ox-latex.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..409d92164 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3314,6 +3314,7 @@ This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
(let* ((attr (org-export-read-attribute :attr_latex table))
(alignment (org-latex--align-string table info))
+ (opt (org-export-read-attribute :attr_latex table :options))
(table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
(width
@@ -3343,8 +3344,9 @@ This function assumes TABLE has `org' as its `:type' property and
(format "\\end{%s}" table-env)
(and fontsize "}"))))
(t
- (let ((output (format "\\begin{%s}%s{%s}\n%s\\end{%s}"
+ (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
+ (if opt (format "[%s]" opt) "")
width
alignment
contents
--
2.33.0
^ permalink raw reply related [relevance 9%]
* Re: Sub-figures in Org Mode
2021-10-23 0:00 10% ` Juan Manuel Macías
@ 2021-10-26 17:46 5% ` Jason Ross
2021-10-30 14:28 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Jason Ross @ 2021-10-26 17:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On 10/22/21 5:00 PM, Juan Manuel Macías wrote:
> Hi Jason,
>
> Jason Ross <jasonross1024@gmail.com> writes:
>
>> Are there any workarounds people use to create subfigures in Org Mode
>> when exporting to LaTeX? Example output:
>
> In this thread I explain a procedure to export images as subfigures
> using org links: https://list.orgmode.org/87mty1an66.fsf@posteo.net/
>
> Best regards,
>
> Juan Manuel
>
Those are some really clever solutions. I hadn't considered using a
dsl for figure options.
I'm looking at declaring a "figure" block the way you are, but
`org-element-map'ing over the links inside the block and processing them
with the "normal" link-handling machinery. That way, image options work
the same way in a subfigure as they do normally.
Here's what I'm messing with for the ConTeXt backend (this relies
on some changes to figure handling I haven't pushed yet):
#+begin_src elisp
(defun org-context--special-block-figure (orig-fun special-block
contents info)
(let ((type (org-element-property :type special-block)))
(if (string= "figure" (downcase type))
(let* ((attr (org-export-read-attribute :attr_context
special-block))
(links (org-element-map special-block 'link #'identity))
(placefigure-options
(org-context--format-arguments
(org-context--get-placefigure-options special-block
info)))
(captionp
(mapcan
(lambda (link)
(let* ((parent (org-export-get-parent-element link))
(caption (org-string-nw-p
(org-context--caption/label-string parent info))))
(and caption (list caption))))
links))
(image-codes
(mapconcat
(lambda (link)
(let ((figure-string
(org-context--get-link-figure-string link info)))
(if captionp
(let ((caption
(org-string-nw-p
(org-context--caption/label-string
(org-export-get-parent-element link)
info))))
(format "{%s}\n{%s}"
figure-string (or caption "")))
(format "{%s}" figure-string)))
)
links
"\n"))
(dimensions
(let* ((rows (plist-get attr :rows))
(cols (plist-get attr :cols))
(nlinks (length links)))
(if
(and rows cols)
(cons (string-to-number rows) (string-to-number
cols))
(cons 1 nlinks))))
combination-options)
(if captionp
(push (cons "alternative" "text") combination-options)
(push (cons "alternative" "label") combination-options))
(push (cons "nx" (format "%s" (cdr dimensions)))
combination-options)
(push (cons "ny" (format "%s" (car dimensions)))
combination-options)
(message (format "%S" combination-options))
(format "\\startplacefigure[%s]
\\startcombination[%s]
%s
\\stopcombination
\\stopplacefigure"
placefigure-options
(org-context--format-arguments combination-options)
image-codes))
(funcall orig-fun special-block contents info))))
(advice-add 'org-context-special-block :around
#'org-context--special-block-figure)
#+end_src
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
@ 2021-10-27 15:52 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-27 15:52 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Hi Vikas,
Vikas Rawal writes:
> This is excellent. There is only one improvement that I would like you to consider. Is it possible to allow multiple ":options " lines that are appended when exported to
> +latex? Something like this:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
> #+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}
> #+ATTR_LATEX: :options remark{Source} = {The source of data}
>
> ==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet},
> remark{Source} = {The source of data}]{colspec = {XXX}, width = 0.85\linewidth}
>
> This would be more elegant since table notes can be elaborate and putting them all in one line would make them unwieldy.
>
> At the moment, only the last ":options" line is considered.
The normal behavior is that you cannot put more than one property
`:foo', because in that case only the value of the last one is added
when exporting to LaTeX (ther is a property list where each property has
a string value).
I can think of a somewhat tricky solution, in case you want to adapt it
to your use case:
First, you need to convert a plist to an alist (source:
https://caiorss.github.io/Emacs-Elisp-Programming/Elisp_Programming.html#sec-1-8-4):
#+begin_src emacs-lisp
(defun plist->alist (plist)
(if (null plist)
'()
(cons
(list (car plist) (cadr plist))
(plist->alist (cddr plist)))))
#+end_src
And this would be the modified function:
#+begin_src emacs-lisp
(defun org-latex--org-table (table contents info)
"Return appropriate LaTeX code for an Org table.
TABLE is the table type element to transcode. CONTENTS is its
contents, as a string. INFO is a plist used as a communication
channel.
This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
(let* ((attr (org-export-read-attribute :attr_latex table))
(alignment (org-latex--align-string table info))
;; various `:options' props ;;;; <== modified from here
(attr-alist (plist->alist attr))
(options-list)
(options-str (progn
(mapc (lambda (m)
(when (eq (car m) :options)
(add-to-list 'options-list (cdr m))))
attr-alist)
(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list " ")))
;;;;;;;; < == to here
(table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
(width
(let ((w (plist-get attr :width)))
(cond ((not w) "")
((member table-env '("tabular" "longtable")) "")
((member table-env '("tabu" "longtabu"))
(format (if (plist-get attr :spread) " spread %s "
" to %s ")
w))
(t (format "{%s}" w)))))
(caption (org-latex--caption/label-string table info))
(above? (org-latex--caption-above-p table info)))
(cond
((member table-env '("longtable" "longtabu"))
(let ((fontsize (let ((font (plist-get attr :font)))
(and font (concat font "\n")))))
(concat (and fontsize (concat "{" fontsize))
(format "\\begin{%s}%s{%s}\n" table-env width alignment)
(and above?
(org-string-nw-p caption)
(concat caption "\\\\\n"))
contents
(and (not above?)
(org-string-nw-p caption)
(concat caption "\\\\\n"))
(format "\\end{%s}" table-env)
(and fontsize "}"))))
(t
(let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
;; modified here
(if options-list (format "[%s]" options-str) "")
width
alignment
contents
table-env)))
(org-latex--decorate-table output attr caption above? info))))))
#+end_src
Pleas tell me if it works for you.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
@ 2021-10-28 18:02 6% ` Juan Manuel Macías
2021-10-28 19:39 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-28 18:02 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Vikas Rawal writes:
> This still seems to exporting the second "options" value only.
Do you still keep this line in your init:
(advice-add 'org-latex--org-table :override #'my/org-latex--org-table) ?
If so, rename the function from my previous email as
`my/org-latex-org-table' and re-evaluate it. And comment the old
`my/org-latex-org-table'.
The new function works well for me. E.g. this:
#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align align
#+ATTR_LATEX: :options options 1
#+ATTR_LATEX: :options options 2
#+ATTR_LATEX: :options options 3
#+ATTR_LATEX: :options options 4
| lorem | lorem | lorem | lorem | lorem |
|-------+-------+-------+-------+-------|
| ipsum | ipsum | ipsum | ipsum | ipsum |
produces in LaTeX this:
\begin{longtblr}[options 1 options 2 options 3 options 4]{align}
lorem & lorem & lorem & lorem & lorem\\
\hline
ipsum & ipsum & ipsum & ipsum & ipsum\\
\end{longtblr}
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
2021-10-28 18:02 6% ` Juan Manuel Macías
@ 2021-10-28 19:39 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-28 19:39 UTC (permalink / raw)
To: Vikas Rawal; +Cc: orgmode
Juan Manuel Macías writes:
> \begin{longtblr}[options 1 options 2 options 3 options 4]{align}
PS: I think the options should be separated by commas. In this
case, it's necessary to replace the line:
(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list " ")))
by this line:
(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list ",")))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: Introducing Org-transclusion
@ 2021-10-30 12:31 10% ` Juan Manuel Macías
2021-11-01 9:17 6% ` Noboru Ota
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-30 12:31 UTC (permalink / raw)
To: Noboru Ota; +Cc: orgmode
Hi Noboru,
Noboru Ota writes:
> I would like to introduce an add-on package I have been developing for
> about one year and ask for discussion / advice.
>
> The package is named "Org-transclusion", and is available on GitHub at
> https://github.com/nobiot/org-transclusion. Simply put, it lets you
> insert a copy of text content via a file link or ID link within an Org
> file. The GitHub repository contains links short video presentations
> and documentation in detail.
I installed your package a few months ago and I have to say that it
works quite well, although I have not had, at the moment, the
opportunity to make intensive use of it. What I can say is that the
concept seems very interesting to me. Very nice package.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Sub-figures in Org Mode
2021-10-26 17:46 5% ` Jason Ross
@ 2021-10-30 14:28 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-30 14:28 UTC (permalink / raw)
To: Jason Ross; +Cc: orgmode
Hi Jason, sorry for the late reply.
Jason Ross writes:
> I'm looking at declaring a "figure" block the way you are, but
> `org-element-map'ing over the links inside the block and processing them
> with the "normal" link-handling machinery. That way, image options work
> the same way in a subfigure as they do normally.
I really like your idea, and it's more consistent with the Org syntax,
since (as you say) the images behave like images and it is not necessary
to enter the options via marks within the link description, which is somewhat
hacky. I think your idea could also be adapted to LaTeX (and HTML)
backends...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Introducing Org-transclusion
2021-10-30 12:31 10% ` Juan Manuel Macías
@ 2021-11-01 9:17 6% ` Noboru Ota
0 siblings, 0 replies; 200+ results
From: Noboru Ota @ 2021-11-01 9:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I installed your package a few months ago and I have to say that it
> works quite well, although I have not had, at the moment, the
> opportunity to make intensive use of it. What I can say is that the
> concept seems very interesting to me. Very nice package.
Thank you for your kind words.
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
2021-10-26 16:05 9% [patch] ox-latex.el: add `:options' LaTeX attribute to tables Juan Manuel Macías
@ 2021-11-03 16:32 6% ` Nicolas Goaziou
2021-11-03 17:38 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-11-03 16:32 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Vikas Rawal, orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The `:options' attr. allows adding an optional argument with various
> table options (between brackets in LaTeX export), since certain tabular
> environments, such as `longtblr' of the `tabularray' LaTeX package,
> provides this structure (see:
> https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=DuaBB28nCsVqEA@mail.gmail.com/#r)
>
> Example:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
> #+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}
>
> ==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet}]{colspec = {XXX}, width = 0.85\linewidth}
Thank you.
Could you also document it in the manual?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
2021-11-03 16:32 6% ` Nicolas Goaziou
@ 2021-11-03 17:38 10% ` Juan Manuel Macías
2021-11-03 18:33 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-03 17:38 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Nicolas Goaziou writes:
> Thank you.
>
> Could you also document it in the manual?
Of course, tomorrow I will upload an updated version of the patch with
the documentation in the manual. Should I also add an entry in ORG-NEWS,
in "Version 9.6" node?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
2021-11-03 17:38 10% ` Juan Manuel Macías
@ 2021-11-03 18:33 6% ` Nicolas Goaziou
2021-11-04 20:59 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-11-03 18:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Of course, tomorrow I will upload an updated version of the patch with
> the documentation in the manual. Should I also add an entry in ORG-NEWS,
> in "Version 9.6" node?
Good idea. Thanks.
Regards,
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
2021-11-03 18:33 6% ` Nicolas Goaziou
@ 2021-11-04 20:59 6% ` Juan Manuel Macías
2021-11-06 13:51 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-04 20:59 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 122 bytes --]
Hi Nicolas,
Nicolas Goaziou writes:
> Good idea. Thanks.
Attached here the updated patch.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-options-latex-attribute-to-tables.patch --]
[-- Type: text/x-patch, Size: 5073 bytes --]
From fc9062caf43956ac68b72f16afbd5584ec84e687 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Thu, 4 Nov 2021 21:38:26 +0100
Subject: [PATCH] ox-latex.el: add `options' latex attribute to tables
* lisp/ox-latex.el (org-latex--org-table): The `:options' LaTeX
attribute allows adding an optional argument (`\begin{env}[opt]'),
since certain tabular environments, such as `longtblr', accept optional
arguments.
* doc/org-manual.org (Tables in LaTeX export): this feature in the manual.
* etc/ORG-NEWS (New :options attribute when exporting tables to
LaTeX): this feature in `ORG-NEWS'.
---
doc/org-manual.org | 9 +++++++++
etc/ORG-NEWS | 14 ++++++++++++++
lisp/ox-latex.el | 4 +++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index af88b8506..50cdb9101 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13572,6 +13572,14 @@ include:
The LaTeX export back-end uses these attributes for regular tables
to set their alignments, fonts, and widths.
+- =:options= ::
+
+ The =:options= attribute allows adding an optional argument with a
+ list of various table options (between brackets in LaTeX export),
+ since certain tabular environments, such as =longtblr= of the
+ =tabularray= LaTeX package, provides this structure. For example:
+ =:options remark{Note}={note},remark{Source}={source}=.
+
- =:spread= ::
When =:spread= is non-~nil~, the LaTeX export back-end spreads or
@@ -19770,6 +19778,7 @@ moves across a special context.
(add-to-list 'org-tab-first-hook 'yas/org-very-safe-expand)
(define-key yas/keymap [tab] 'yas/next-field)))
#+end_src
+
** Using Org on a TTY
:PROPERTIES:
:DESCRIPTION: Using Org on a tty.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index d73d0d3c3..626e19335 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -53,6 +53,13 @@ structures is supported. Storing references between different
variables is also supported (see =:inherit= key in
~org-persist-register~).
+*** New :options attribute when exporting tables to LaTeX
+
+The =:options= attribute allows adding an optional argument with a
+list of various table options (between brackets in LaTeX export),
+since certain tabular environments, such as =longtblr= of the
+=tabularray= LaTeX package, provides this structure.
+
** New functions and changes in function arguments
*** New function ~org-element-cache-map~ for quick mapping across Org elements
@@ -1555,6 +1562,7 @@ the headline to use for making the table of contents.
,* Another section
,#+TOC: headlines 1 :target "#TargetSection"
#+end_example
+
** New functions
*** ~org-dynamic-block-insert-dblock~
@@ -1845,6 +1853,7 @@ CIDER version which has not =sesman= integrated, only has
(dissoc Clojure 'JVM)
(conj clojurists "stardiviner")
#+end_src
+
*** Add ~:results link~ support for Babel
With this output format, create a link to the file specified in
@@ -1863,14 +1872,17 @@ wget -c "https://ben.akrin.com/crackzor/crackzor_1.0.c.gz"
#+begin_src js :session "*Javascript REPL*"
console.log("stardiviner")
#+end_src
+
*** Add ~:session~ support of ob-js for Indium
#+begin_src js :session "*JS REPL*"
console.log("stardiviner")
#+end_src
+
*** Add ~:session~ support of ob-js for skewer-mode
#+begin_src js :session "*skewer-repl*"
console.log("stardiviner")
#+end_src
+
*** Add support for links to LaTeX equations in HTML export
Use MathJax links when enabled (by ~org-html-with-latex~), otherwise
add a label to the rendered equation.
@@ -1957,6 +1969,7 @@ you should expect to see something like:
#+BEGIN_EXAMPLE
,#+STARTUP: shrink
#+END_EXAMPLE
+
*** Allow to filter by tags/property when capturing colview
You can now use =:match= to filter entries using a todo/tags/properties
@@ -2339,6 +2352,7 @@ To use =vertica= in an sql =SRC_BLK= set the =:engine= like this:
SELECT * FROM nodes;
,#+END_SRC
#+END_EXAMPLE
+
**** C++: New header ~:namespaces~
The new ~:namespaces~ export option can be used to specify namespaces
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..409d92164 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3314,6 +3314,7 @@ This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
(let* ((attr (org-export-read-attribute :attr_latex table))
(alignment (org-latex--align-string table info))
+ (opt (org-export-read-attribute :attr_latex table :options))
(table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
(width
@@ -3343,8 +3344,9 @@ This function assumes TABLE has `org' as its `:type' property and
(format "\\end{%s}" table-env)
(and fontsize "}"))))
(t
- (let ((output (format "\\begin{%s}%s{%s}\n%s\\end{%s}"
+ (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
+ (if opt (format "[%s]" opt) "")
width
alignment
contents
--
2.33.1
^ permalink raw reply related [relevance 6%]
* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
2021-11-04 20:59 6% ` Juan Manuel Macías
@ 2021-11-06 13:51 6% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-11-06 13:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Attached here the updated patch.
Applied. Thank you.
I added two spaces between sentences in org-manual.org.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* A function to include a PDF with LaTeX commands for specific pages
@ 2021-11-09 16:25 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-09 16:25 UTC (permalink / raw)
To: orgmode
Hi,
Sometimes I need to include a pre-compiled PDF in my main document. Of
course, this can be done simply with the `pdfpages' LaTeX package. If we
want to insert a complete PDF, it would be enough to add:
#+latex: \includepdf[pages=-,noautoscale=true,page-command={\thispagestyle(plain}]{file.pdf}
But the 'problem' arises when we want to add multiple page-commands such
as \label{...} and \index{...} to specific pages of the PDF. It would
have to be done explicitly by putting multiple lines of \includepdf{etc},
which can be a bit monotonous. To simplify that scenario it occurred to
me to write this function:
(my-org/insert-pdfpages PDF &optional PAGE-COMMANDS-ALL PAGE-COMMANDS-PER-PAGE)
PAGE-COMMANDS-ALL is the command that should be applied to all pages;
PAGE-COMMANDS-PER-PAGE must be a list, with the page number and the
commands for that page (a possible improvement could be to allow adding
page ranges...). For example:
#+LaTeX_Header: \usepackage{pdfpages}
#+begin_src emacs-lisp :exports results :results latex
(my-org/insert-pdfpages "file.pdf" "\\thispagestyle{plain}" '((2 "\\label{label1}")
(3 "\\label{label2}\\index{index1}")
(7 "\\label{label3}\\index{index2}")
(12 "\\index{index3}")))
#+end_src
Only tested on GNU/Linux; mupdf-tools is required, to be able to get the
number of pages of the PDF. And the function:
#+begin_src emacs-lisp
(defun my-org/insert-pdfpages (pdf &optional page-commands-all page-commands-per-page)
(let ((pdfpages-result))
(setq pdfpages-result
(with-temp-buffer
(let ((counter 0)
(pags-pdf (shell-command-to-string
(format "mutool info %s | grep '^Pages' | cut -d ' ' -f 2"
pdf))))
(dotimes (num (string-to-number pags-pdf))
(insert (concat
"\n\\includepdf[pages={"
(number-to-string
(setf counter (+ counter 1)))
"},"
"noautoscale=true,"
(if page-commands-all
(format "pagecommand={%s}" page-commands-all) "")
"]{"
pdf
"}"))))
(if page-commands-per-page
(mapc (lambda (x)
(let ((pag (number-to-string (car x)))
(str (cadr x)))
(save-excursion
(goto-char (point-min))
(while (re-search-forward (concat "pages={" pag "}") nil t)
(if (re-search-forward "\\(pagecommand={\\)")
(replace-match (concat "\\1" "\\" str ","))
(re-search-forward "\\(\\[\\)" nil t)
(replace-match (concat "\\1" "pagecommand={" "\\" str "},")))))))
page-commands-per-page)
"")
(buffer-string)))
pdfpages-result))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: whitespace in org source files
@ 2021-11-13 12:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-13 12:57 UTC (permalink / raw)
To: excalamus; +Cc: Tim Cross, orgmode
Hi,
excalamus--- via "General discussions about Org-mode." writes:
> I've not used the email contribution style before and have had
> whitespace issues in the past with GitHub PRs. I typically run
> whitespace-cleanup with the before-save-hook which changes tabs to
> spaces.
I agree with Tim that running whitespace-cleanup is usually a bad idea
within a Git repository. I also have, like you, whitespace-cleanup
hooked to before-save-hook, like a relic of my first Emacs setups. In
case it helps, I have added to my init this function:
(defun my-whitespace-cleanup-no-git ()
(let ((buf (buffer-file-name)))
(when (not (vc-git-responsible-p buf))
(whitespace-cleanup))))
and then:
(add-hook 'before-save-hook 'my-whitespace-cleanup-no-git)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Should be possible to export list items emphasized by default?
@ 2021-11-17 13:33 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-17 13:33 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> /1. Introduction/
>
> It doesn't work as a list item
>
> 1. /Introduction/
>
> It works as a list item but, when exporting, it doesn't export the
> whole item emphasized.
If I have understood correctly, you want to export the label emphasized
as well, not just the item content... It does not make much sense to
emphasize a label within a list by direct formatting: the style of the
labels must be homogeneous and consistent. On the other hand, the style
for a list environment must be modified in LaTeX globally. The easy way
is to use the enumitem package. For example, if you want all labels in
italics:
#+LaTeX_Header: \usepackage{enumitem}
#+ATTR_LaTeX: :options [label=\emph{\arabic*}.]
1. /foo/
2. /bar/
3. /baz/
The :options attribute pass an optional argument to the `enumerate'
environment, with all the options for the environment (a list of comma
separated keyval values):
\begin{enumerate}[label=\emph{\arabic*}.]
\item \emph{foo}
\item \emph{bar}
\item \emph{baz}
\end{enumerate}
See: https://www.ctan.org/pkg/enumitem
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: insert automatically a reference to a section header and a link
@ 2021-11-17 15:42 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-17 15:42 UTC (permalink / raw)
To: Stefan Nobis; +Cc: Uwe Brauer, orgmode
Stefan Nobis writes:
> Hmmm... for me, the default way to link to headings is just fine, I
> seldom need more control over the generated labels:
>
> #+begin_src org
> ,* Intro
>
> Lorem ipsum dolor sit amet...
>
> ,* Another section
>
> As seen in [[*Intro]] there is not much to say.
> #+end_src
Completely agree. I also tend to use `org-super-link'
(https://github.com/toshism/org-super-links). It can be run with
helm-org-ql, so if there are a lot of headings in the document, I just
have to navigate through them using helm-org-ql, and insert a link at
point to the chosen candidate. And in the destination header a back link
is also inserted.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: insert automatically a reference to a section header and a link
@ 2021-11-17 18:17 10% ` Juan Manuel Macías
2021-11-17 19:00 6% ` Stefan Nobis
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-17 18:17 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode
Stefan Nobis writes:
> #+begin_src emacs-lisp
> (defun sn/ox-latex-filter-special-ref-vref (text backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "\\\\ref{" "\\\\vref{" text)))
>
> (add-to-list 'org-export-filter-link-functions #'sn/ox-latex-filter-special-ref-vref)
> #+end_src
In Org 9.5 there is a new variable `org-latex-reference-command'. You
can do something like:
(setq org-latex-reference-command "\\vref{%s}")
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: insert automatically a reference to a section header and a link
2021-11-17 18:17 10% ` Juan Manuel Macías
@ 2021-11-17 19:00 6% ` Stefan Nobis
0 siblings, 0 replies; 200+ results
From: Stefan Nobis @ 2021-11-17 19:00 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> In Org 9.5 there is a new variable `org-latex-reference-command'.
Thanks for the reminder! I once read about it, but forgot to use it
after upgrading to 9.5. :)
--
Until the next mail...,
Stefan.
^ permalink raw reply [relevance 6%]
* org-critical-edition (new version)
@ 2021-11-21 15:36 13% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-21 15:36 UTC (permalink / raw)
To: orgmode
Hi all,
For philologists who might be interested, I have uploaded a new version
of my package `org-critical-edition', with some new features, such as the
ability to use multi-level nested critical notes:
https://gitlab.com/maciaschain/org-critical-edition
It occurred to me to write org-critical-edition as a sort of org-centric
alternative to TEI-XML for the semantic markup of literary texts. My
idea is for a more scholar-friendly, human-readable tool.
Here's a screenshot of a LaTeX/reledmac export sample:
https://i.imgur.com/S9MXzIA.png
Feedback welcome.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 13%]
* Dired images in an Org buffer
@ 2021-11-23 16:52 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-23 16:52 UTC (permalink / raw)
To: orgmode
Hi,
I don't like image-dired thumbnails, so I wrote this function to preview all
images in a directory in an Org buffer. I share it here, in case it is
useful to someone:
#+begin_src emacs-lisp
(defun my-org-img-dired-preview ()
(interactive)
(if (not (derived-mode-p 'dired-mode))
(error "not in dired")
(let* ((dir-name default-directory)
(buf (concat "*" dir-name "--images *")))
(setq my-img-dired-list nil)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\.png\\|\\.jpg\\|\\.tif" nil t)
(let* ((img-path (dired-get-filename)))
(add-to-list 'my-img-dired-list img-path t))))
(when (get-buffer buf)
(kill-buffer buf))
(get-buffer-create buf)
(set-buffer buf)
(org-mode)
(let ((img-list (mapconcat (lambda (el)
(let ((link (concat "[[file:" el "]]")))
link))
my-img-dired-list
"\n\n"))
(img-num (number-to-string
(length my-img-dired-list))))
(insert (concat "* Images in " dir-name "\n\n"))
(insert (concat img-num " files:\n\n"))
(insert img-list)
(org-toggle-inline-images))
(pop-to-buffer buf)
(beginning-of-buffer))))
(with-eval-after-load 'dired
(define-key dired-mode-map (kbd "P") 'my-org-img-dired-preview))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: "Orgdown", the new name for the syntax of Org-mode
@ 2021-11-28 22:25 8% ` Juan Manuel Macías
2021-11-29 5:41 6% ` Marcin Borkowski
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-28 22:25 UTC (permalink / raw)
To: orgmode
Hi,
I believe (IMHO) that it does not make much sense to separately name the
Org Mode syntax (as a markup language). That would only generate
confusion among users. Furthermore, 'Org Mode', as a whole, is already a
sufficiently recognized and popular name, even outside the GNU Emacs
community. A single name is best remembered. More than one name means
atomization. For example: there is TeX (the typographic engine) and TeX
(the programming language for that engine). And there has never been any
conflict.
On the other hand, drawing a dividing line between Org (a lightweight
markup language) and Org (a GNU Emacs major mode) as if both things
could exist separately is an illusory exercise. I mean, that the
Org's global experience is the fusion of both things.
I migrated from Markdown to Org Mode a long time ago not because I was
looking for a new and best lightweight markup language but because Org
provides me with a complete and quite sophisticated and productive work
environment. An environment that includes, yes, its own syntax, but all
within Emacs, which is where makes sense. I do not know if it is an
emergent quality, but I see Org, in many ways (and with all its
synapses) as an interface for Emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: "Orgdown", the new name for the syntax of Org-mode
@ 2021-11-29 3:25 10% ` Juan Manuel Macías
2021-11-29 7:13 5% ` Dr. Arne Babenhauserheide
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-29 3:25 UTC (permalink / raw)
To: Joost Kremers; +Cc: orgmode
Joost Kremers writes:
> Why not just use the term "Org markup"? It's descriptive and should be
> understandable to people familiar with the concept of markup languages.
This. 'Org markup language' and 'Org Syntax' are obvious and natural
terms that can easily be inferred from the Org manual. Honestly I don't
see much point in coming up with new names for a concept which is
already transparent and self-explanatory. It is something I find
unnecessary and baroque.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: "Orgdown", the new name for the syntax of Org-mode
2021-11-28 22:25 8% ` Juan Manuel Macías
@ 2021-11-29 5:41 6% ` Marcin Borkowski
2021-11-29 12:18 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Marcin Borkowski @ 2021-11-29 5:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2021-11-28, at 23:25, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> [...] For example: there is TeX (the typographic engine) and TeX
> (the programming language for that engine). And there has never been any
> conflict.
Quite the contrary. The amount of confusion between TeX (engine)/TeX
(language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
novice/casual users has always been terrible.
Just my 2 cents,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 6%]
* Re: "Orgdown", the new name for the syntax of Org-mode
2021-11-29 3:25 10% ` Juan Manuel Macías
@ 2021-11-29 7:13 5% ` Dr. Arne Babenhauserheide
0 siblings, 0 replies; 200+ results
From: Dr. Arne Babenhauserheide @ 2021-11-29 7:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Joost Kremers, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Joost Kremers writes:
>
>> Why not just use the term "Org markup"? It's descriptive and should be
>> understandable to people familiar with the concept of markup languages.
>
> This. 'Org markup language' and 'Org Syntax' are obvious and natural
> terms that can easily be inferred from the Org manual. Honestly I don't
> see much point in coming up with new names for a concept which is
> already transparent and self-explanatory. It is something I find
> unnecessary and baroque.
Org markup and Org syntax sound good, I think. I’m unsure which is
better to convey that this includes features — that org-mode is much
more than just a way to encode some information, but a way to interact
with documents and an implementation of the syntax should keep that in
mind.
One thing that is important to keep: Org Syntax or Org Markup is
implementation-defined. You cannot claim *full compatibility*, if you
are not fully compatible with org-mode. This includes a lot of Emacs
features, like linking to arbitrary files/buffers/things, extending
links, and so on.
The minimal syntax (missing a lot of features) would be outline markup
or outline syntax (from outline-mode, the ancestor of org-mode).
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [relevance 5%]
* Re: "Orgdown", the new name for the syntax of Org-mode
2021-11-29 5:41 6% ` Marcin Borkowski
@ 2021-11-29 12:18 9% ` Juan Manuel Macías
2021-11-29 12:36 6% ` Marcin Borkowski
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-29 12:18 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Marcin Borkowski writes:
> Quite the contrary. The amount of confusion between TeX (engine)/TeX
> (language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
> novice/casual users has always been terrible.
It's natural when those novice/casual users approach something that is
new to them, but nothing invincible when they want to learn. The "TeX"
ecosystem is not trivial, but I think that all, or almost all of us,
understand each other when things like 'TeX/LaTeX code', 'TeX engine',
'LaTeX format', etc. are said. If the TeX language were somewhat
self-contained and widely used outside of TeX, I would see OK that the
language had its own name. But, since the TeX language is something that
almost only TeX understands (roughly said), I think the economy wins
here (IMHO). I don't see how we could improve everything by having half
a dozen more exotic names.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: "Orgdown", the new name for the syntax of Org-mode
2021-11-29 12:18 9% ` Juan Manuel Macías
@ 2021-11-29 12:36 6% ` Marcin Borkowski
0 siblings, 0 replies; 200+ results
From: Marcin Borkowski @ 2021-11-29 12:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2021-11-29, at 13:18, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Marcin Borkowski writes:
>
>> Quite the contrary. The amount of confusion between TeX (engine)/TeX
>> (language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
>> novice/casual users has always been terrible.
>
> It's natural when those novice/casual users approach something that is
> new to them, but nothing invincible when they want to learn. The "TeX"
> ecosystem is not trivial, but I think that all, or almost all of us,
> understand each other when things like 'TeX/LaTeX code', 'TeX engine',
> 'LaTeX format', etc. are said. If the TeX language were somewhat
> self-contained and widely used outside of TeX, I would see OK that the
> language had its own name. But, since the TeX language is something that
> almost only TeX understands (roughly said), I think the economy wins
> here (IMHO). I don't see how we could improve everything by having half
> a dozen more exotic names.
Agreed, I just wanted to say that the situation with TeX is more
complicated. Especially that 92%* TeX users are novice/casual users.
* Number made up, but loosely based on anecdotal evidence;-).
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 6%]
* Re: how to export red colored TeX to latex
@ 2021-11-30 16:56 9% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-30 16:56 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode, John Kitchin
Hi,
Uwe Brauer writes:
> Hi
>
> I want to obtain a latex file that contains
>
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
>
> However when I add
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
> To an org file and export it as Latex, the construct ends up like this
>
>
> \textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}
>
> Which is wrong.
>
> Any ideas how to obtain the correctly exported expression?
Not exactly related, but if it helps, I have defined this custom link
for colored text segments:
(NB: I apply two colors for `:face', because normally I use two themes,
one clear for the day and another dark for the night hours: when my dark
theme is active, apply a background color. But you can simplify that part to
your liking):
(org-link-set-parameters "color"
;; :display 'full
:face (lambda (path) (when path
(if (string= (face-attribute 'default :background) "#282c34")
`(:foreground ,path :background "#F5f5f5")
`(:foreground ,path))))
:export (lambda (path desc format)
(cond
((eq format 'latex)
(concat
"\\textcolor{"
path
"}{" desc "}"))
((eq format 'html)
(format "<span
style=\"color:%s;\">%s</span>"
path desc)))))
The link would then look like this, adapting John's solution using a
LaTeX export snippet:
[[color:red][@@latex:$\delta \phi = \frac{2 m}{R}$@@]]
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: how to export red colored TeX to latex
@ 2021-11-30 17:43 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-30 17:43 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Thanks, right now, I don't need links but it is good to know that there is a way to use them.
It's just a way of using links to produce different strings, depending
on the export format (LaTeX, HTML...). I use them quite a bit for text
segments as \foreignlanguage{}{}, \textcolor{}{}, etc. Anyway, that
specific link does not have any associated link action.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Orgdown: negative feedback & attempt of a root-cause analysis
@ 2021-12-01 3:28 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-01 3:28 UTC (permalink / raw)
To: Tom Gillespie; +Cc: orgmode
Tom Gillespie writes:
> Karl,
> The exact naming of a thing is nearly always the most contentious
> step in trying to promulgate it. In my own field we can easily get all
> parties to agree on a definition, but they refuse to budge on a name.
> As others have said, I wouldn't worry about kibitizing over the name.
>
> I would however worry about the larger negative reaction. From my
> perspective I think the issue is that there are many efforts working
> toward a formalized specification for Org syntax and Org mode
> functionality, and some of those stakeholders who have invested
> significant effort may feel blindsided by a public declaration
> announcing Orgdown because they were not consulted and not
> made aware that you were working on it.
>
> I appreciate the amount of work that you have put in, I have devoted
> hundreds of hours to working on an alternate implementation of org
> in Racket that uses a formal ebfn in hopes that others will be able
> to use it as a guide and as a way to talk formally about how Org
> parsers and implementations should behave.
>
> It would thus be easy for me to say that your approach has put the
> cart before the horse, because there are countless nuances in the
> specification for Org syntax which must be addressed before any
> levels of org compliance can be specified, otherwise the behavior
> between levels will be inconsistent.
>
> If I were to say this, it would not be fair to you at all. The ideas
> and motivation for Orgdown are vital and important. You have put
> in enormous thought and effort, all because you care about Org
> and want to see it succeed.
>
> The issue is that any shared specification for Org syntax is
> fundamentally about how to coordinate as a community.
> The way that Orgdown was presented to the community feels
> (to me) like it is being imposed top down or coming from an
> individual source, not from an open and visible community
> process (the subject of your original email reads as a declaration
> in english, and thus can be quite off putting, though I know that
> was not the intention).
>
> I personally haven't bothered with promulgation because I think
> that we are not technically ready as a community to approach
> outreach to other developers in a way that we can succeed.
>
> The good news is that all of this can co-exist if we want it to,
> but we need to be clear about our objectives as a community.
>
> To me these objectives are as follows (and I would love
> to hear from others about additional or alternate objectives).
>
> 1. To never fracture Org syntax so as to avoid the nightmare
> of markdown flavors. (This means being able to say clearly
> as a community that a parser is out of compliance and that
> it is up to the user to fix their files. The ruby org parser used
> by Github is a major issue here.)
> 2. To provide a clear specification for what graceful degradation
> looks like when parsing Org syntax if a parser does not support
> some portion of that syntax (e.g. should property drawer lines
> be excluded or rendered as plain text?).
> 3. Provide a solid basis on which further formal specification
> can be built. (My interests in particular are around providing
> consistent semantics for org-babel blocks across languages
> so that babel implementations can clearly communicate what
> runtime features they support.)
>
> The approach for Orgdown can absolutely meet all three of
> these objectives, however in its current form Orgdown1 is not
> sufficiently well specified to avoid fracturing the syntax.
> This is because Org syntax is extremely complex (even the
> elisp implementation of Org mode is internally inconsistent)
> and there are edge cases where behavior will diverge if parsing
> of even the simplest elements is not fully specified.
>
> There are many ways to remedy this, however they require
> a more formal approach. A number of us are working to build
> technical foundations for such a formal approach, but I do not
> think that any of those projects are ready to be used to
> specify discrete levels of Org syntax parsing compliance.
>
> If I may, I would suggest that an Orgdown0 is something that
> could be well specified, but it would avoid parsing of markup
> altogether and only deal with the major element types. Parsing
> paragraphs and all the org objects is not something that can
> be done piecemeal. There are too many interactions between
> different parts of the syntax, and in some cases the existing
> specification desperately needs to be revisited due to the
> complexity that it induces or because it is underspecified.
> Of course this would make Orgdown0 fairly useless as a
> replacement for markdown, but at least it would be a start.
Everything you comment here seems very sensible to me.
Anyway I have to say that, in my case, the name 'orgdown' is not the
issue, but the underlying idea under the naming, whatever the name is.
IMHO, reduce Org to a markup language or, to put it somewhat
metaphorically, distill Org into a workable markup language outside Org
itself and GNU Emacs, is a task that seems impossible to me. Or at least
(for not being so radical), quite difficult. And, on the other hand,
what would be the point of doing that? I think Org and Markdown are the
antipodes, they are like water and oil, although they share certain
purposes. Just to make my current opinion clear.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: how to export red colored TeX to latex
@ 2021-12-01 15:00 10% ` Juan Manuel Macías
2021-12-01 15:02 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-01 15:00 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
Eric S Fraga writes:
> Very nice Juan! I would find this use of links quite useful.
Thank you. Yes, org-link-set-parameters is quite productive, and
addictive in occasions! :-): I also have link types defined for somewhat
extravagant things, such as linking videos and music from the dlna
server of my raspberry...
Anyway, for format chunks of text in export I think
org-link-set-parameters is a good alternative to macros.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: how to export red colored TeX to latex
2021-12-01 15:00 10% ` Juan Manuel Macías
@ 2021-12-01 15:02 6% ` Eric S Fraga
0 siblings, 0 replies; 200+ results
From: Eric S Fraga @ 2021-12-01 15:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Wednesday, 1 Dec 2021 at 15:00, Juan Manuel Macías wrote:
> Anyway, for format chunks of text in export I think
> org-link-set-parameters is a good alternative to macros.
I also have a few links defined (used to have one for citing but no
longer needed) but macros seem to be my first port-of-call and maybe
shouldn't be!
--
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096
^ permalink raw reply [relevance 6%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 11:30 10% ` Juan Manuel Macías
2021-12-02 11:36 7% ` Denis Maier
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-02 11:30 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Denis Maier
Hi Denis and Ihor,
Ihor Radchenko writes:
> Denis Maier <denismaier@mailbox.org> writes:
>
>> Currently, org syntax doesn't officially seem to support intra-word
>> emphasis. Am I missing something?
>
> intra-*word* works just fine for me.
>
> Best,
> Ihor
I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org-syntax: Intra-word markup
2021-12-02 11:30 10% ` Juan Manuel Macías
@ 2021-12-02 11:36 7% ` Denis Maier
2021-12-02 12:00 5% ` Ihor Radchenko
2 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-12-02 11:36 UTC (permalink / raw)
To: Juan Manuel Macías, Ihor Radchenko; +Cc: orgmode
Yes, Juan Manuel. That's it.
See for reference:
https://stackoverflow.com/questions/1218238/how-to-make-part-of-a-word-bold-in-org-mode
Best,
Denis
Am 02.12.2021 um 12:30 schrieb Juan Manuel Macías:
> Hi Denis and Ihor,
>
> Ihor Radchenko writes:
>
>> Denis Maier <denismaier@mailbox.org> writes:
>>
>>> Currently, org syntax doesn't officially seem to support intra-word
>>> emphasis. Am I missing something?
>> intra-*word* works just fine for me.
>>
>> Best,
>> Ihor
> I think what Denis is referring to is a construction of the type
> *intra*word, which, if I'm not mistaken, is not supported and can only
> be achieved by inserting a zero width space.
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Org-syntax: Intra-word markup
2021-12-02 11:30 10% ` Juan Manuel Macías
2021-12-02 11:36 7% ` Denis Maier
@ 2021-12-02 12:00 5% ` Ihor Radchenko
2021-12-02 12:28 0% ` Denis Maier
2 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-02 12:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Denis Maier
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> intra-*word* works just fine for me.
>>
> I think what Denis is referring to is a construction of the type
> *intra*word, which, if I'm not mistaken, is not supported and can only
> be achieved by inserting a zero width space.
I see. We had a discussion about emphasis issues in
https://orgmode.org/list/8735nnq73n.fsf@localhost
The conclusion from there is that supporting such scenarios will
introduce various edge cases. We would need to make the emaphsis parser
more and more complex inevitably introducing errors.
An alternative may be some kind of "forced" emphasis syntax where Org
does not have to guess about the emphasis using non-transparent rules.
But it's what zero width space is for and it is what we recommend in the
Org manual.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: Org-syntax: Intra-word markup
2021-12-02 12:00 5% ` Ihor Radchenko
@ 2021-12-02 12:28 0% ` Denis Maier
0 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-12-02 12:28 UTC (permalink / raw)
To: Ihor Radchenko, Juan Manuel Macías; +Cc: orgmode
Am 02.12.2021 um 13:00 schrieb Ihor Radchenko:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> intra-*word* works just fine for me.
>>>
>> I think what Denis is referring to is a construction of the type
>> *intra*word, which, if I'm not mistaken, is not supported and can only
>> be achieved by inserting a zero width space.
> I see. We had a discussion about emphasis issues in
> https://orgmode.org/list/8735nnq73n.fsf@localhost
>
> The conclusion from there is that supporting such scenarios will
> introduce various edge cases. We would need to make the emaphsis parser
> more and more complex inevitably introducing errors.
Thanks, I'll try to read that thread in due time.
>
> An alternative may be some kind of "forced" emphasis syntax where Org
> does not have to guess about the emphasis using non-transparent rules.
> But it's what zero width space is for and it is what we recommend in the
> Org manual.
As for the forced syntax. What do you think about the asciidoc solution?
Denis
^ permalink raw reply [relevance 0%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 13:14 9% ` Juan Manuel Macías
2021-12-02 13:28 7% ` Denis Maier
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 13:14 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, denismaier
Ihor Radchenko writes:
> Denis Maier <denismaier@mailbox.org> writes:
>
>>> Can you create an example of such scenario and post it as a bug?
>>> Probably, we just need to strip all zero-width spaces at the basic ox.el
>>> level.
>> To be clear: That's not an org bug. It's just that latex won't be able
>> such a word. If | is a zero width space, the word "hyphen|ation" is not
>> the same as "hyphenation".
>> 1. hyphenation
>> 2. hyphen|ation
>
> You are right for your example, but if we force the user to put
> *hyphen*|ation to create bold emphasis, it should not be any different
> compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the *hyphen*|ation
> gets exported as \textbf{hyphen}|ation keeping the zero width space.
--
I would say that they are very random cases, and therefore difficult to
reproduce. In the 'hyphenation' example, if we load the package
showhypehns, you see that:
/hyphen/ation (with zero width sp)
and
\emph{hyphen}ation
they are cut in the same way. But differently from
hyphenation (without emphasis)
(compiled with LuaTeX).
Anyway, I have come across some curious cases. For example, a long time
ago I had defined a macro for text in other languages:
#+MACRO: lg (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 "\u200B" "@@latex:}@@") $2))
I needed to add before and after a zero width space, but doing so, the
shape of the text was altered. That can be reproduced with this example:
#+LaTeX_Header: \usepackage{showhyphens}
#+LaTeX_Header:\usepackage{lipsum,multicol}
#+LaTeX_Header:\usepackage[spanish]{babel}
#+LaTeX_Header: \def\example{\lipsum[1]}
#+LaTeX_Header: \def\zwsp{\char"200B{}}
#+OPTIONS: toc:nil
@@latex:\begin{multicols}{2}@@
@@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@
@@latex:\foreignlanguage{italian}{\example}@@
@@latex:\end{multicols}@@
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
2021-12-02 13:14 9% ` Juan Manuel Macías
@ 2021-12-02 13:28 7% ` Denis Maier
0 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-12-02 13:28 UTC (permalink / raw)
To: Juan Manuel Macías, Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
Am 02.12.2021 um 14:14 schrieb Juan Manuel Macías:
> Ihor Radchenko writes:
>
>> Denis Maier<denismaier@mailbox.org> writes:
>>
>>>> Can you create an example of such scenario and post it as a bug?
>>>> Probably, we just need to strip all zero-width spaces at the basic ox.el
>>>> level.
>>> To be clear: That's not an org bug. It's just that latex won't be able
>>> such a word. If | is a zero width space, the word "hyphen|ation" is not
>>> the same as "hyphenation".
>>> 1. hyphenation
>>> 2. hyphen|ation
>> You are right for your example, but if we force the user to put
>> *hyphen*|ation to create bold emphasis, it should not be any different
>> compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the*hyphen*|ation
>> gets exported as \textbf{hyphen}|ation keeping the zero width space.
> -- I would say that they are very random cases, and therefore
> difficult to reproduce. In the 'hyphenation' example, if we load the
> package showhypehns, you see that: /hyphen/ation (with zero width sp)
> and \emph{hyphen}ation they are cut in the same way. But differently
> from hyphenation (without emphasis) (compiled with LuaTeX). Anyway, I
> have come across some curious cases. For example, a long time ago I
> had defined a macro for text in other languages: #+MACRO: lg (eval (if
> (org-export-derived-backend-p org-export-current-backend 'latex)
> (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2
> "\u200B" "@@latex:}@@") $2)) I needed to add before and after a zero
> width space, but doing so, the shape of the text was altered. That can
> be reproduced with this example: #+LaTeX_Header:
> \usepackage{showhyphens} #+LaTeX_Header:\usepackage{lipsum,multicol}
> #+LaTeX_Header:\usepackage[spanish]{babel} #+LaTeX_Header:
> \def\example{\lipsum[1]} #+LaTeX_Header: \def\zwsp{\char"200B{}}
> #+OPTIONS: toc:nil @@latex:\begin{multicols}{2}@@
> @@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@
> @@latex:\foreignlanguage{italian}{\example}@@
> @@latex:\end{multicols}@@ Best regards, Juan Manuel
Thanks Juan Manuel. I should have tried that first. Hyphenation is the
same for both /hyphen/ation (with zero width sp) and
\emph{hyphen}ation. (Maybe I can nudge Hans Hagen to add some low level
trickery in context that removes the groups before doing the
hyphenation... but that's a different story.) Anyway, as Juan Manuel
shows there can be cases where zero width spaces cause problems.
Denis
[-- Attachment #2: Type: text/html, Size: 3801 bytes --]
^ permalink raw reply [relevance 7%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 19:09 9% ` Juan Manuel Macías
2021-12-04 13:07 5% ` Org-syntax: emphasis and not English punctuation Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 19:09 UTC (permalink / raw)
To: Tom Gillespie; +Cc: orgmode
Tom Gillespie writes:
> I don't mean to be a wet blanket, but the edge cases for
> the current markup syntax are already hard enough to
> implement correctly, to the point where different parts of
> Org mode are inconsistent. Intra-word markup isn't viable
> because there simply isn't any sane way to parse something
> like *hello world*/hrm/oh no*. The other issue is that this will
> degrade parsing performance because almost every
> character could precede the start of a markup section.
>
> I recommend anyone suggesting solutions try to implement
> something that can parse the markup unambiguously with
> lots of nasty test cases. You will likely find that it is impossible
> to consistently tokenize markup, and that you have to hand
> write a whole bunch of heuristics, making Org syntax even
> harder to implement correctly.
>
> Any solution that suggests extending how =/*~+_ can be
> used gets a hard no from me. I could see teaching other
> exporters how to interpret \emph{hello}world, but trying for
> to have any sane behavior for something like
> why *hello*world oh no a wild askterisk*
> is not worth it.
I believe, that emphasis marks are a part of Org that can be very
shocking to new users. I mean, there is a series of behaviors that seem
obvious and trivial in the emphasized text, but that in Org are not
possible out of the box, unless you configure
`org-emphasis-regexp-components'. Three quick examples. This in Org is
not possible out of the box:
#+begin_example
[/emphasis/]
¡/emphasis/!
¿/Emphasis/?
#+end_example
Nor is it possible ---out of the box--- to extend emphasis beyond a
certain number of lines. New users who come from other forms of markup
maybe expect the obvious to be something like:
some-text begin-emphasis whatever-is-in-between end-emphasis more-text
Over time one ends up seeing these things more as a feature than as a
bug :-) But those little inconsistencies make the Org syntax a bit ugly,
IMHO. I can't think of how to improve that, though.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-02 19:34 9% ` Juan Manuel Macías
2021-12-02 23:05 6% ` Nicolas Goaziou
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 19:34 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Denis Maier, emacs-orgmode, Ihor Radchenko, Timothy
Hi Nicolas and all,
Nicolas Goaziou writes:
> I find zero-with spaces solution much more elegant. It also doesn't
> change current syntax, which is a big advantage.
I agree that zero width spaces work fine as a solution, but I think they
should not be understood as part of the syntax but as a punctual
(temporal?) remedy to certain scenarios. As mentioned before, in LaTeX
zero width spaces can produce unexpected effects and modify the final
form of the text (at least in luatex). I also don't know if it would be
useful to remove all zero width spaces in the export process, because in
some cases the user may want to keep them, as I think Maxim commented in
a previous message.
As for the solution of using complementary marks ("//...//", etc.), I
think it would undermine consistency, as those marks would only be to
fix exceptions.
It's a tricky subject...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
2021-12-02 19:34 9% ` Juan Manuel Macías
@ 2021-12-02 23:05 6% ` Nicolas Goaziou
2021-12-02 23:24 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-12-02 23:05 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Timothy, emacs-orgmode, Ihor Radchenko, Denis Maier
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I agree that zero width spaces work fine as a solution, but I think they
> should not be understood as part of the syntax but as a punctual
> (temporal?) remedy to certain scenarios. As mentioned before, in LaTeX
> zero width spaces can produce unexpected effects and modify the final
> form of the text (at least in luatex). I also don't know if it would be
> useful to remove all zero width spaces in the export process, because in
> some cases the user may want to keep them, as I think Maxim commented in
> a previous message.
We may be misunderstanding each other.
I'm suggesting to remove zero-width spaces contiguous to emphasis
markers only. Therefore LaTeX process would npot see them. Other zero
width spaces, e.g., inserted by user, are kept. AFAICT, the two last
points you mention are not relevant with my proposal.
Besides, they already part of the syntax, in some way. So that ship has
sailed long ago.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: Org-syntax: Intra-word markup
2021-12-02 23:05 6% ` Nicolas Goaziou
@ 2021-12-02 23:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-02 23:24 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Nicolas Goaziou writes:
> I'm suggesting to remove zero-width spaces contiguous to emphasis
> markers only. Therefore LaTeX process would npot see them. Other zero
> width spaces, e.g., inserted by user, are kept. AFAICT, the two last
> points you mention are not relevant with my proposal.
>
> Besides, they already part of the syntax, in some way. So that ship has
> sailed long ago.
I understand that it is too late to change certain things, but that is
not an impediment for me to continue to think that using the character
U+200B as a part (at least /de facto/) of the syntax is still shocking
and weird.
On the other hand, what was expected in Org would have been to have the
emphasis marks and at the same time have a universal escape character
for those emphasis marks. In the same way as I can write in markdown:
*foo* AND \*foo\*. In Org we have the emphasis marks but not the escape
character. That was probably the cause of many issues that are being
discussed here. But that means also entering the realm of assumptions.
Still, I wanted to leave an opinion on this question in particular.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* On zero width spaces and Org syntax
@ 2021-12-03 12:48 8% Juan Manuel Macías
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 12:48 UTC (permalink / raw)
To: orgmode
Hi all,
It is usually recommended, as you know, to insert a zero width space
character (Unicode U+200B) as a sort of delimiter mark to solve the
scenarios of emphasis within a word (for example, =/meta/literature=)
and others contexts where emphasis marks are not recognized (for example
=[/literature/]=). I believe that as a puntual workaround it is not bad;
however, I find it problematic that this character is part, more or less
de facto, of the Org syntax. For two main reasons:
1. It is an invisible character, and therefore it is difficult to
control and manage. I think it is not good practice to introduce this
type of characters implicitly in a plain text document.
2. It is more natural that this type of space characters are part of the
'output' and not of the 'input'. In the input it is better to introduce
them not implicitly but through their representation. For example, in
LaTeX (with LuaTeX) using the command '\char"200B{}' (or '^^^^200b'),
'​' in HTML, etc.
In any case, as an implicit character, I do not see it appropriate for
the syntax of a markup language. The marks should be simply ascii
characters, IMHO. So what if Org had a specific delimiter mark for the
scenarios described above? For example, something like that:
#+begin_example
/meta/''literature
*meta*''literature
[''*literature*'']
#+end_example
WDYT?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-03 15:01 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 15:01 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Hi Maxim,
Max Nikulin writes:
> More explicit markup leaves less room for ambiguities, and I like the
> idea due to this reason. On the other hand it diverges from principle
> of lightweight markup. The almost only special character in TeX is
> "\", HTML has three ones "&<>" with simple escape rules. Org uses many
> special characters to avoid verbosity and requires some tricks to
> escape them. Markers like "\{" make Org more verbose but do not make
> it more strict, a lot of things still rely on heuristics.
Excellent explanation. Thanks for the clarification.
> I have an idea what can be done when some special markup is required
> that is not fit into current syntax. Unfortunately some new constructs
> should be introduced anyway: inline objects and multiline elements
> that represent simplified result of parsed Org structures:
>
> ((italic "intra") "word")
>
> wrapped with some markup. It should satisfy any special needs (and
> even should allow to create invalid impossible constructs). Maybe idea
> of combination of lightweight markup and low-level blocks better suits
> for some other project with more expressive internal representation.
> In Org it may become the most hated feature.
I really would like a solution in this direction. In LaTeX there is a
command called \protect (which has nothing to do with this topic and is
used for other things, but I like the 'protection' concept); we could
perhaps think of a type of mark to protect the 'usual' marks when syntax
consistency is compromised in some way by the context. Maybe something
like enclosing the normal marks between two double single quotes ''...''
---or a single set of single quotes before the leading marker--- as I
proposed in another thread:
#+begin_example
''*protected emphasis*''
#+end_example
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: On zero width spaces and Org syntax
@ 2021-12-03 20:30 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 20:30 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg, thank you for your comment,
Greg Minshall writes:
> in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
> file. some sort of "visible" sequence would be great. backwards
> compatibility might be a problem.
Yes I agree. I think that in this case, a new mark would not compromise
backward compatibility, as this presumed new mark would do the same
function as zero width space: i.e. delimit to preserve emphasis. Of
course one could go on using a zero-width space, though I keep thinking
that this is rather a puntual workaround and should not form part of the
syntax.
> your last example
>
> : [''*literature*'']
>
> seems a bit of sleight-of-hand, though. iiuc, text inside square
> brackets isn't highlighted currently, and ZWNBSP doesn't (afaict) turn
> on highlighting. (maybe there's been recent discussion, modifications
> of this?)
The idea would be to use a kind of 'protection mark', to allow something
in a context where it is not allowed: a passport ;-). As the emphasis
marks are recognized before and after a single quote, I thought that
maybe a sequence of two single quotes could function here as a
protection mark (screenshot: https://i.imgur.com/cPIH9qa.png). For
example:
#+begin_example
| Some examples where emphasis marks are not allowed | Protected emphasis marks |
|----------------------------------------------------+--------------------------|
| /meta/literature | /meta/''literature |
| [/literature/] | [''/literature/''] |
| <*literature*> | <''*literature*''> |
| meta/*literature* | meta/''*literature* |
#+end_example
With the protection marks we get (in LaTeX for example):
\emph{meta}literature
[\emph{literature}]
<\textbf{literature}>
meta/\textbf{literature}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: On zero width spaces and Org syntax
2021-12-03 12:48 8% On zero width spaces and Org syntax Juan Manuel Macías
@ 2021-12-03 21:48 3% ` Tim Cross
2021-12-04 1:26 6% ` Juan Manuel Macías
2021-12-04 6:43 5% ` Marcin Borkowski
2 siblings, 1 reply; 200+ results
From: Tim Cross @ 2021-12-03 21:48 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi all,
>
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others contexts where emphasis marks are not recognized (for example
> =[/literature/]=). I believe that as a puntual workaround it is not bad;
> however, I find it problematic that this character is part, more or less
> de facto, of the Org syntax. For two main reasons:
>
> 1. It is an invisible character, and therefore it is difficult to
> control and manage. I think it is not good practice to introduce this
> type of characters implicitly in a plain text document.
>
> 2. It is more natural that this type of space characters are part of the
> 'output' and not of the 'input'. In the input it is better to introduce
> them not implicitly but through their representation. For example, in
> LaTeX (with LuaTeX) using the command '\char"200B{}' (or '^^^^200b'),
> '​' in HTML, etc.
>
> In any case, as an implicit character, I do not see it appropriate for
> the syntax of a markup language. The marks should be simply ascii
> characters, IMHO. So what if Org had a specific delimiter mark for the
> scenarios described above? For example, something like that:
>
> #+begin_example
>
> /meta/''literature
>
> *meta*''literature
>
> [''*literature*'']
>
> #+end_example
>
> WDYT?
>
> Best regards,
>
> Juan Manuel
I think I am in agreement regarding most of your points about the use of
the zero-width character. I see it as a type of escape hatch which
provides a solution in some less frequent situations. It is a somewhat
clever kludge to enable markup in some situations not supported by the
basic markup syntax I'm happy with its status as a kludge and would not
want to see it become an official part of the syntax. Where we may
differ is in whether we actually want to add inner word markup support
at all.
I'm somewhat surprised and more than a little concerned at how much
interest and focus on modifying the markup syntax of org the question of
inner word markup has generated. This seems to be a symptom of a more
general trend towards adding and extending org mode to meet the needs of
everyone and I'm concerned this is overlooking the key strength of org
mode - simplicity.
Consider how many times we have had requests for inner word markup in
the last 18 years. I've seen such requests only a very few times.
Certainly not frequently enough to consider modification of the markup
syntax to accommodate such a requirement.
A key philosophy of org mode is simplicity - it makes the easy stuff
simple and the hard stuff possible. The thing about simple solutions is
that they will inevitably have limitations. If you don't want those
limitations, then you use a more complex feature rich markup, such as
Latex, HTML, XML etc. Ideally, your system will provide some escape
hatches to allow you to do things not supported by the base markup
syntax. Those escape hatches will usually be less convenient and often
look quite ugly, but that is fine because they are an escape hatch
which is used infrequently. Better still is if the system provides some
way to make a specific escape hatch easier to use in a document (such as
via a macro). The basic org markup syntax has worked remarkably well for
18 years. Nearly all the proposed additions or alterations to support
inner word markup with complicate the syntax or introduce potential new
ambiguities and/or complexity in processing to support a feature which
has been rarely asked for and which has other, less convenient and often
ugly, solutions which work.
One of org's strengths has been the ability to export documents to
multiple formats. One way this has been made possible is by keeping the
markup syntax simple - a basic markup which is well supported by all
export back ends. Once you start adding more complex markup support, you
see a blow out of complexity in the export back ends. Worse yet, you get
results which are surprising to the end user or which simply don't work
correctly with some formats. to avoid this, it is critical to keep the
markup syntax as simple and straight-forward as possible, even if that
means some limitations on what can be done with the markup.
My vote is to simply maintain the status quo. Don't modify the syntax,
don't make the zero space character somewhat special or processed in any
special way during export. In short, accept that inner word markup has
only limited support and if that is a requirement which is critical to
your use case, accept that org mode may not be the right solution for
your requirements.
^ permalink raw reply [relevance 3%]
* Re: On zero width spaces and Org syntax
2021-12-03 21:48 3% ` Tim Cross
@ 2021-12-04 1:26 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-04 1:26 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> I think I am in agreement regarding most of your points about the use of
> the zero-width character. I see it as a type of escape hatch which
> provides a solution in some less frequent situations. It is a somewhat
> clever kludge to enable markup in some situations not supported by the
> basic markup syntax I'm happy with its status as a kludge and would not
> want to see it become an official part of the syntax. Where we may
> differ is in whether we actually want to add inner word markup support
> at all.
>
> I'm somewhat surprised and more than a little concerned at how much
> interest and focus on modifying the markup syntax of org the question of
> inner word markup has generated. This seems to be a symptom of a more
> general trend towards adding and extending org mode to meet the needs of
> everyone and I'm concerned this is overlooking the key strength of org
> mode - simplicity.
>
> Consider how many times we have had requests for inner word markup in
> the last 18 years. I've seen such requests only a very few times.
> Certainly not frequently enough to consider modification of the markup
> syntax to accommodate such a requirement.
>
> A key philosophy of org mode is simplicity - it makes the easy stuff
> simple and the hard stuff possible. The thing about simple solutions is
> that they will inevitably have limitations. If you don't want those
> limitations, then you use a more complex feature rich markup, such as
> Latex, HTML, XML etc. Ideally, your system will provide some escape
> hatches to allow you to do things not supported by the base markup
> syntax. Those escape hatches will usually be less convenient and often
> look quite ugly, but that is fine because they are an escape hatch
> which is used infrequently. Better still is if the system provides some
> way to make a specific escape hatch easier to use in a document (such as
> via a macro). The basic org markup syntax has worked remarkably well for
> 18 years. Nearly all the proposed additions or alterations to support
> inner word markup with complicate the syntax or introduce potential new
> ambiguities and/or complexity in processing to support a feature which
> has been rarely asked for and which has other, less convenient and often
> ugly, solutions which work.
>
> One of org's strengths has been the ability to export documents to
> multiple formats. One way this has been made possible is by keeping the
> markup syntax simple - a basic markup which is well supported by all
> export back ends. Once you start adding more complex markup support, you
> see a blow out of complexity in the export back ends. Worse yet, you get
> results which are surprising to the end user or which simply don't work
> correctly with some formats. to avoid this, it is critical to keep the
> markup syntax as simple and straight-forward as possible, even if that
> means some limitations on what can be done with the markup.
>
> My vote is to simply maintain the status quo. Don't modify the syntax,
> don't make the zero space character somewhat special or processed in any
> special way during export. In short, accept that inner word markup has
> only limited support and if that is a requirement which is critical to
> your use case, accept that org mode may not be the right solution for
> your requirements.
Thank you very much for the detailed and precise exposition of your
point of view. I appreciate it.
First of all, a point that I consider important and essential in this
and other debates that are generated here, is that there is no single
conception of Org that should prevail as (say) "the canon". Org is so
polyhedral and so multifaceted that there are as many conceptions of Org
as there are users of Org. Well, what I have said is in itself one more
conception of Org. But I assume that other users may think that Org is
not all the things that I say it is. At the end of the day, what matters
is only one thing, for on top of theories and doctrines: if Org is
useful to you and helps you to do your work, so great. A few months ago
(and I think I already shared it here) I finished the typesetting and
layout of a dictionary of almost 1000 pages, and I did it using a
workflow that I have developed which is a merge between Org/Org-Publish
and LuaTeX. And now, using the same method, I am working on an
ancient-Greek/Spanish bilingual critical edition. So I believe I'm not
suspicious of thinking that Org doesn't cover the needs of my workflow.
As for the matter of emphasis marks between words. I believe that this
is not the underlying problem, but rather the (little) inconsistency of
the markup on certain contexts. Think, for example, of a text where you
have to put many words in italics, enclosed between brackets. I don't
care if that type of text is 'typical' or 'non-typical', 'majority' or
'non-majority'. It is simply a kind of scenario absolutely legitimate
and feasible, and right now I could quote you more than a type of text
in that direction.
Since I have been using Org I have been running into these little
inconsistencies. Any insurmountable, of course, nor I had to abandon the
use of Org for that minor issues. Fortunately, Org is more than just a
markup language, and it offers lots of alternative resources and
extensibility. Org is GNU Emacs. Org is not Markdown.
My proposal here also does not arise from an irrepressible desire to add
more complexity to the syntax. If it's recommended that the user, in
certain contexts, enter implicitly a zero-width space (which, I insist,
is a practice that should be avoided as much as possible in a plain text
document), why not at least offer a graphical alternative, a *real* mark
whose role is *exactly* the same as that of the zero-with space? Is that
adding more complexity??? Honestly I think that's exactly the opposite.
In any case, I have suggested that new mark as a possibility, in case it
is interesting to implement it, since a thread has emerged these days
about the topic of the intra-words syntax. Discussions and threads
arised about these questions and any other are perfectly legitimate and
natural and welcome. Please: there are no issues more 'important' than
others; no two users are the same in Org. What you do not find useful,
another user may perhaps finds it indispensable. And vice versa. And I
think no one is in willingness to state what the average Org user does
or does not want, given that we do not know even 1% of Org users.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: On zero width spaces and Org syntax
@ 2021-12-04 5:29 5% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 5:29 UTC (permalink / raw)
To: Tom Gillespie; +Cc: orgmode
Tom Gillespie writes:
> I don't mean to be dismissive of the suggestion, but a lot of
> time is spent on this list walking back ideas that have not
> had sufficient time put into understanding what the
> unintended consequences would be, so I wouldn't say
> that it is irresponsible, I would say instead that it lacks
> sufficient rigor and depth to be seriously considered. If you
> can add those to this proposal (e.g. in the form of a patch)
> then I suspect it would get a much warmer reception.
I am afraid that I am explaining myself wrong, and it is not my
intention that this matter becomes entangled to infinity.
I have no intention of proposing any patch on this. I'm not strongly
requesting this feature be included, and I am not interested in starting
a crusade to defend this (and as for lack of rigor and depth, well, it's your
subjective opinion). But it's more simple. Since a thread on these
questions came up recently, it occurred to me to suggest this idea as a
*possibility*, in case anyone could find it interesting and would like
to explore it. Nothing more. In fact, I don't think I was going to use
this probable feature much, if it was implemented, because for these
scenarios I prefer to use Org macros or other resources that I have
implemented for my workflow. But maybe users would prefer this to insert
a zero-whith space character (which is a tricky and quite ugly
workaround and should not be recommended). Or maybe not. I really don't
know. I don't know all Org users in the world, do you know them?
Anyway, I want to point out one thing, again. The scenarios and contexts
that are being described here are far from "very narrow use case". And I
don't think it's very appropriate to hide the lack of something with the
excuse that no one is going to need it. Intra-word emphasis is used (for
example) a lot in linguistics books and texts, grammars, etc. That you
*ignore* this fact does not mean that does not exist.
regards,
jm
^ permalink raw reply [relevance 5%]
* Re: On zero width spaces and Org syntax
2021-12-03 12:48 8% On zero width spaces and Org syntax Juan Manuel Macías
2021-12-03 21:48 3% ` Tim Cross
@ 2021-12-04 6:43 5% ` Marcin Borkowski
2 siblings, 0 replies; 200+ results
From: Marcin Borkowski @ 2021-12-04 6:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2021-12-03, at 13:48, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi all,
>
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others contexts where emphasis marks are not recognized (for example
> =[/literature/]=). I believe that as a puntual workaround it is not bad;
> however, I find it problematic that this character is part, more or less
> de facto, of the Org syntax. For two main reasons:
>
> 1. It is an invisible character, and therefore it is difficult to
> control and manage. I think it is not good practice to introduce this
> type of characters implicitly in a plain text document.
>
> 2. It is more natural that this type of space characters are part of the
> 'output' and not of the 'input'. In the input it is better to introduce
> them not implicitly but through their representation. For example, in
> LaTeX (with LuaTeX) using the command '\char"200B{}' (or '^^^^200b'),
> '​' in HTML, etc.
>
> In any case, as an implicit character, I do not see it appropriate for
> the syntax of a markup language. The marks should be simply ascii
> characters, IMHO. So what if Org had a specific delimiter mark for the
> scenarios described above? For example, something like that:
Hi all,
I've skimmed through this discussion. FWIW, I also use zero-width
spaces in my Org files for this precise reason. However, I agree that
extending syntax is dangerous.
How about a solution (or maybe it's only a "solution"...) where:
1. We take care to modify the "official" exporters to throw out the ZWSs.
Or even better, convert them to something reasonable, e.g. with LaTeX
they can be discarded or converted to some command – possibly even one
defined in the preamble – so that nothing is lost. I'd even say that an
option deciding what to do with those could be nice.
2. We modify Emacs itself to somehow highlight the ZWS. There is (kind
of) a precedent – a no-breaking space is already fontified with
=nobreak-space= face. At the very least, make whitespace-mode somehow
show ZWSs (which it doesn't now, and I'd probably say it's a bug).
I know that my point 2. is a bit controversial, since it could lead to
alignment issues where a ZWS is displayed as something with a positive
width. OTOH, even now changing the face of a ZWS leads to a narrow
(1-pixel wide) line of a different color. Is there a way to make it
a bit stronger?
Just some random ideas,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 5%]
* Re: Org-syntax: emphasis and not English punctuation
2021-12-02 19:09 9% ` Juan Manuel Macías
@ 2021-12-04 13:07 5% ` Max Nikulin
2021-12-04 16:42 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-04 13:07 UTC (permalink / raw)
To: emacs-orgmode
On 03/12/2021 02:09, Juan Manuel Macías wrote:
>
> I believe, that emphasis marks are a part of Org that can be very
> shocking to new users. I mean, there is a series of behaviors that seem
> obvious and trivial in the emphasized text, but that in Org are not
> possible out of the box, unless you configure
> `org-emphasis-regexp-components'. Three quick examples. This in Org is
> not possible out of the box:
>
> #+begin_example
> [/emphasis/]
> ¡/emphasis/!
> ¿/Emphasis/?
> #+end_example
Maybe this issue should be considered independently of itra-word emphasis.
Second and third examples looks like they should be supported. Ihor
mentioned treating punctuation in a more general way. It requires rich
test set to estimate changes in heuristics. I suspect some problems
since start and end patterns are not symmetric and I have not found a
way to specify in regexp only punctuation marks that normally appears in
front of words. Square brackets likely should be excluded somehow as
well since they are part of Org syntax. I am unsure if it is possible to
use just regexp without additional checks of candidates.
Ihor Radchenko. [PATCH] Re: c47b535bb origin/main org-element: Remove
dependency on ‘org-emphasis-regexp-components’
Sun, 21 Nov 2021 17:28:57 +0800.
https://list.orgmode.org/87v90lzwkm.fsf@localhost
^ permalink raw reply [relevance 5%]
* Re: Org-syntax: emphasis and not English punctuation
2021-12-04 13:07 5% ` Org-syntax: emphasis and not English punctuation Max Nikulin
@ 2021-12-04 16:42 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 16:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Maybe this issue should be considered independently of itra-word emphasis.
Yes I agree. Apologies for mixing up this topic in the discussion about
intra-word emphasis...
> Second and third examples looks like they should be supported. Ihor
> mentioned treating punctuation in a more general way. It requires rich
> test set to estimate changes in heuristics. I suspect some problems
> since start and end patterns are not symmetric and I have not found a
> way to specify in regexp only punctuation marks that normally appears
> in front of words. Square brackets likely should be excluded somehow
> as well since they are part of Org syntax. I am unsure if it is
> possible to use just regexp without additional checks of candidates.
Ihor's idea seems interesting to me, although I understand the possible
problems you mention. By the way, I'm afraid of initial inverted
punctuation (¡¿) are only used in Castilian Spanish and other languages
of Spain, such as Galician or Asturian, due to the Castilian influence
(we go backwards from the rest of the world ;-):
https://en.wikipedia.org/wiki/Inverted_question_and_exclamation_marks
> Ihor Radchenko. [PATCH] Re: c47b535bb origin/main org-element: Remove
> dependency on ‘org-emphasis-regexp-components’
> Sun, 21 Nov 2021 17:28:57 +0800.
> https://list.orgmode.org/87v90lzwkm.fsf@localhost
I see. I believe it's a sensible decision to get rid of the dependency
on org-emphasis-regexp-components. I understand that now everything
related to the structure of emphases is the competence of org-element?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org-syntax: Intra-word markup
@ 2021-12-04 21:16 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 21:16 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
Hi John,
John Kitchin writes:
> Along these lines (and combining the s-exp suggestion from Max) , you
> can achieve something like this with links.
I like this idea of merging the Maxim's proposal with the power of links.
In any case, this and other workarounds provided here make it clear that
in Org we do not lack of good and useful resources. I usually use macros
(taking advantage of the fact that macros expand soon). For example
(only in this case with the LaTeX backend):
#+MACRO: emph (eval (when (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\emph{@@" $1 "@@latex:}@@")))
Defined the macro this way, it allows me also to introduce nested
emphases by both ways:
#+begin_src example
{{{emph(lorem *ipsum* /dolor/ {{{emph(sit)}}} amet)}}}
#+end_src
==> \emph{lorem \textbf{ipsum} \emph{dolor} \emph{sit} amet}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-05 9:16 9% ` Juan Manuel Macías
2021-12-05 10:24 5% ` Ihor Radchenko
2021-12-05 13:06 4% ` Tim Cross
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-05 9:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> The website title is "Org mode for Emacs", repelling users who _do
> not want_ to use Org inside Emacs. Maybe we can do better? Something
> with less accent on Emacs like "Org mode: your life in plain text"
I am not at all in favor of separating the 'Org Mode' name from 'GNU Emacs'.
In any case, regardless of my opinion, I see here two problems:
1. "Org mode: your life in plain text". The word "mode" remains orphan:
mode of what? It is clear that it is an Emacs mode, therefore it doesn't
make much sense to hide Emacs and then suggest it.
2. One possibility: "Org: your life in plain text". But here what
remains orphaned is "Org", too generic name. Unless "Org Mode" is a
lexicalized construct, without reference to any emacs mode.
(In any case, I would be extremely saddened if the reference to GNU Emacs
disappears in the title, just to please a minority).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 9:16 9% ` Juan Manuel Macías
@ 2021-12-05 10:24 5% ` Ihor Radchenko
2021-12-05 11:08 9% ` Juan Manuel Macías
2021-12-05 13:06 4% ` Tim Cross
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-05 10:24 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am not at all in favor of separating the 'Org Mode' name from 'GNU
> Emacs'.
To clarify, I do not suggest to remove the linkage between Org mode and
GNU Emacs. Just change the emphasis. I had no intention to remove the
reference to Emacs from search result. It should be still there in the
short description of orgmode.org. See the second part of my suggestion
#1.
> 1. "Org mode: your life in plain text". The word "mode" remains orphan:
> mode of what? It is clear that it is an Emacs mode, therefore it doesn't
> make much sense to hide Emacs and then suggest it.
>
> 2. One possibility: "Org: your life in plain text". But here what
> remains orphaned is "Org", too generic name. Unless "Org Mode" is a
> lexicalized construct, without reference to any emacs mode.
I view "Org Mode" as a "brand name". Something uniquely identifying Org
mode and serving as a search term.
> (In any case, I would be extremely saddened if the reference to GNU Emacs
> disappears in the title, just to please a minority).
Is it your principal position about the title specifically? Do you think
that just referring to Emacs in the website description is not
sufficient?
Note that my suggestion #1 has nothing to do with actual orgmode.org
front page. Just about how it appears in search results.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 10:24 5% ` Ihor Radchenko
@ 2021-12-05 11:08 9% ` Juan Manuel Macías
2021-12-05 11:54 6% ` Heinz Tuechler
2021-12-05 12:08 3% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-05 11:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I view "Org Mode" as a "brand name". Something uniquely identifying Org
> mode and serving as a search term.
Yes, it makes sense.
> Is it your principal position about the title specifically? Do you think
> that just referring to Emacs in the website description is not
> sufficient?
> Note that my suggestion #1 has nothing to do with actual orgmode.org
> front page. Just about how it appears in search results.
Yes, sorry for not explaining myself well: I was also referring to
search results, not the title in the web site...
But the question is: what need is there to remove the reference to Emacs
in the search result? I think the emphasis is necessary. As we say in
spanish, it's like putting the bandage on before the wound. If there are
people who think that Org Mode can 'live' in some way outside of Emacs
(a respectable opinion, but that I do not share, at least 100%), I think
the burden of the work falls on them and not on us, the users of
Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
not my intention to initiate a controversy with it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 11:08 9% ` Juan Manuel Macías
@ 2021-12-05 11:54 6% ` Heinz Tuechler
2021-12-05 12:08 3% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Heinz Tuechler @ 2021-12-05 11:54 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías wrote/hat geschrieben on/am 05.12.2021 12:08:
> Ihor Radchenko writes:
>
>> I view "Org Mode" as a "brand name". Something uniquely identifying Org
>> mode and serving as a search term.
>
> Yes, it makes sense.
>
>> Is it your principal position about the title specifically? Do you think
>> that just referring to Emacs in the website description is not
>> sufficient?
>
>> Note that my suggestion #1 has nothing to do with actual orgmode.org
>> front page. Just about how it appears in search results.
>
> Yes, sorry for not explaining myself well: I was also referring to
> search results, not the title in the web site...
>
> But the question is: what need is there to remove the reference to Emacs
> in the search result? I think the emphasis is necessary. As we say in
> spanish, it's like putting the bandage on before the wound. If there are
> people who think that Org Mode can 'live' in some way outside of Emacs
> (a respectable opinion, but that I do not share, at least 100%), I think
> the burden of the work falls on them and not on us, the users of
> Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
> not my intention to initiate a controversy with it.
>
> Best regards,
>
> Juan Manuel
>
>
As a humble emacs and org-mode user I second this "simple and subjectiv
opinion".
Therefore I would first mention org as an emacs mode and secondly as a
file format.
best regards,
Heinz
^ permalink raw reply [relevance 6%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 11:08 9% ` Juan Manuel Macías
2021-12-05 11:54 6% ` Heinz Tuechler
@ 2021-12-05 12:08 3% ` Ihor Radchenko
2021-12-05 13:32 0% ` Tim Cross
2021-12-05 18:59 6% ` Juan Manuel Macías
1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2021-12-05 12:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Yes, sorry for not explaining myself well: I was also referring to
> search results, not the title in the web site...
>
> But the question is: what need is there to remove the reference to Emacs
> in the search result? I think the emphasis is necessary. As we say in
> spanish, it's like putting the bandage on before the wound. If there are
> people who think that Org Mode can 'live' in some way outside of Emacs
> (a respectable opinion, but that I do not share, at least 100%), I think
> the burden of the work falls on them and not on us, the users of
> Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
> not my intention to initiate a controversy with it.
Ok. Let me explain my thought process.
First of all, there is no burden on users of Org mode in making edits to
orgmode.org. It is a burden on Org contributors.
One of the aims of my proposal is reducing this burden by involving
non-emacs users to provide contributions to Org (e.g. by making more
tests for Org-element parser). To do it, we need to make the
contribution process for non-emacs developers easier. Ideally, without
too much effort on our side.
The idea of involving non-emacs users does have a potential because we
do know that third-party tools are already using Org. The problem is the
disconnect between those tools and Org mode proper.
The sources of the disconnect are (1) lack of technical "blueprints" for
Org that do not require knowing Elisp; (2) lack of discovereability of
Org mode as something that can live outside narrow field of Emacs. In
this branch of our discussion, I am going to talk about the second
point.
People simply do not expect to see a markup language when they encounter
a link with "Org mode for Emacs" title. Someone looking for Org mode
markup to be used in, say, websites will think that "Org mode for Emacs"
is limited to Emacs. Someone just interested in plain text markup will
find no relevance at all.
Title is important. If we care at all about orgmode.org website
appearing in search results, we want the title and the summary to have 2
main properties: (1) Provide search keywords to make it searchable by
potentially interested people; (2) Provide a title that immediately
signal that our website contains the information people are looking for.
Now, we need to understand what kind of people may be looking to
orgmode.org website.
1. Existing emacs users
If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
is indeed recognisable. On the other hand, the word "Org mode" does
not provide much further info, except that it is a major (or maybe
minor?) mode for "Org"??
Now, consider "Org mode: your life in plain text".
For emacs users, "Org mode" is not just a strange phrase, but a very
clear indication that we are talking about Emacs.
The "your life in plain text" provides extra information about what
"Org mode" refers to. Clearly, text documents and "your life in plain
text" should resonate with every Emacs user's soul.
We can change the second variant of the title to contain "Emacs", but
will it add much value? I am not convinced. On the other hand, making
title too long or too complex _is_ bad. Long titles tend to be
skipped (there was even formal research on this!)
2. Non-emacs users interested in plain text markup
These users know nothing about Emacs and "Org mode" has no meaning
for them as is. So, we do need something more descriptive.
Adding "Emacs" may be fine, but it will serve no purpose for people
not familiar with emacs. Just another unknown term making the title
longer.
3. Non-emacs users interested in GTD/project management, etc
"Org mode: your life in plain text" is somewhat relevant when people
are looking to manage "life" (typically true for GTD enthusiasts).
Though we can probably do better for this category.
Maybe "Org mode: manage your life and notes in plain text"?
Though it makes the title less relevant to group #2.
4. Researchers looking for ipython-like environment
Not covered, except by reading my proposed site summary. I am not
sure how we can improve title for this audience.
5. ??? (Suggestions are welcome)
Of course, better suggestions for the title are welcome. I just wanted
to make it clear the reasoning I do not like the current title and how
the proposed alternative is better (though not ideal).
Finally, I want to emphasise that our aim for search engines is not
advertising Emacs (we already do it by trapping users inside Org and
making them switch to Emacs by force :evil_laughter:). The aim is
encouraging people to use and contribute to Org mode in useful ways
(even unrelated to writing Elisp or, really, any code at all).
Search result is just an entrance for users to be curious about the new
beast of "Org mode". The website front page is the means to make users
try. And the Org mode itself is the way to make users fall in love with
Org in one way or another (even unrelated to Emacs [at least
initially]).
Best,
Ihor
^ permalink raw reply [relevance 3%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 9:16 9% ` Juan Manuel Macías
2021-12-05 10:24 5% ` Ihor Radchenko
@ 2021-12-05 13:06 4% ` Tim Cross
1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2021-12-05 13:06 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> The website title is "Org mode for Emacs", repelling users who _do
>> not want_ to use Org inside Emacs. Maybe we can do better? Something
>> with less accent on Emacs like "Org mode: your life in plain text"
>
> I am not at all in favor of separating the 'Org Mode' name from 'GNU Emacs'.
> In any case, regardless of my opinion, I see here two problems:
>
> 1. "Org mode: your life in plain text". The word "mode" remains orphan:
> mode of what? It is clear that it is an Emacs mode, therefore it doesn't
> make much sense to hide Emacs and then suggest it.
>
> 2. One possibility: "Org: your life in plain text". But here what
> remains orphaned is "Org", too generic name. Unless "Org Mode" is a
> lexicalized construct, without reference to any emacs mode.
>
> (In any case, I would be extremely saddened if the reference to GNU Emacs
> disappears in the title, just to please a minority).
>
There is another big issue which people are not considering.
Org mode is a GNU project and it is part of Emacs. This actually has
some consequences, most notably -
- It is not acceptable for the project to explicitly or implicitly
recommend or appear to recommend any non-free solutions or provide
support for non-free software. Products like Github and MS Visual Code
fall squarely in the unacceptable bucket.
- It would not be possible to reference any 3rd party libraries or
programs which are not free software in the proposed list of external
tools
- The suggested org mode in a browser example is unlikely to be
acceptable to the FSF (or RMS). The FSF is very much against cloud
based computing services or any web service which uses non-free
Javascript (which is most of them and one of the many reasons Github
is discouraged by the FSF).
A number of the ideas proposed are good ideas for org mode generally -
for example, a repository of reference documents which could be used for
testing purposes would be extremely useful for org-mode development and
testing. Likewise, any effort to clarify the syntax and remove any
ambiguities is beneficial for org mode itself. However, the emphasis and
priority needs to remain focused on org mode as a mode for Emacs. The
use of org mode by other external programs is really outside (but
related) to the project.
As a consequence and to eliminate/remove potential conflicts with FSF
philosophy and goals, it may be worth considering spinning off a
separate project. which happens to use the same markup syntax, but is
not a GNU project (though it would be good to still be GPL'd).
If you want ot get a feel for the sort of issues which could come up
when trying to develop/support 3rd party tools, have a look at the
recent thread on creating an LSP server for emacs-lisp. While I
personally disagree with most of the fears raised by some contributors
to that thread and disagree with RMS's view that such a server would not
be in the best interests of Emacs, the thread does give you a sample of
the sort of issues which could come up with efforts to support or
encourage 3rd party libraries for org markup, much of which could be
avoided if the work is clearly not part of, related to or supported by
the main org-mode project.
^ permalink raw reply [relevance 4%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 12:08 3% ` Ihor Radchenko
@ 2021-12-05 13:32 0% ` Tim Cross
2021-12-05 18:59 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2021-12-05 13:32 UTC (permalink / raw)
To: emacs-orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Yes, sorry for not explaining myself well: I was also referring to
>> search results, not the title in the web site...
>>
>> But the question is: what need is there to remove the reference to Emacs
>> in the search result? I think the emphasis is necessary. As we say in
>> spanish, it's like putting the bandage on before the wound. If there are
>> people who think that Org Mode can 'live' in some way outside of Emacs
>> (a respectable opinion, but that I do not share, at least 100%), I think
>> the burden of the work falls on them and not on us, the users of
>> Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
>> not my intention to initiate a controversy with it.
>
> Ok. Let me explain my thought process.
>
> First of all, there is no burden on users of Org mode in making edits to
> orgmode.org. It is a burden on Org contributors.
>
> One of the aims of my proposal is reducing this burden by involving
> non-emacs users to provide contributions to Org (e.g. by making more
> tests for Org-element parser). To do it, we need to make the
> contribution process for non-emacs developers easier. Ideally, without
> too much effort on our side.
>
> The idea of involving non-emacs users does have a potential because we
> do know that third-party tools are already using Org. The problem is the
> disconnect between those tools and Org mode proper.
>
> The sources of the disconnect are (1) lack of technical "blueprints" for
> Org that do not require knowing Elisp; (2) lack of discovereability of
> Org mode as something that can live outside narrow field of Emacs. In
> this branch of our discussion, I am going to talk about the second
> point.
>
> People simply do not expect to see a markup language when they encounter
> a link with "Org mode for Emacs" title. Someone looking for Org mode
> markup to be used in, say, websites will think that "Org mode for Emacs"
> is limited to Emacs. Someone just interested in plain text markup will
> find no relevance at all.
>
> Title is important. If we care at all about orgmode.org website
> appearing in search results, we want the title and the summary to have 2
> main properties: (1) Provide search keywords to make it searchable by
> potentially interested people; (2) Provide a title that immediately
> signal that our website contains the information people are looking for.
>
> Now, we need to understand what kind of people may be looking to
> orgmode.org website.
>
> 1. Existing emacs users
>
> If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
> is indeed recognisable. On the other hand, the word "Org mode" does
> not provide much further info, except that it is a major (or maybe
> minor?) mode for "Org"??
>
> Now, consider "Org mode: your life in plain text".
> For emacs users, "Org mode" is not just a strange phrase, but a very
> clear indication that we are talking about Emacs.
> The "your life in plain text" provides extra information about what
> "Org mode" refers to. Clearly, text documents and "your life in plain
> text" should resonate with every Emacs user's soul.
>
> We can change the second variant of the title to contain "Emacs", but
> will it add much value? I am not convinced. On the other hand, making
> title too long or too complex _is_ bad. Long titles tend to be
> skipped (there was even formal research on this!)
>
> 2. Non-emacs users interested in plain text markup
>
> These users know nothing about Emacs and "Org mode" has no meaning
> for them as is. So, we do need something more descriptive.
> Adding "Emacs" may be fine, but it will serve no purpose for people
> not familiar with emacs. Just another unknown term making the title
> longer.
>
> 3. Non-emacs users interested in GTD/project management, etc
> "Org mode: your life in plain text" is somewhat relevant when people
> are looking to manage "life" (typically true for GTD enthusiasts).
>
> Though we can probably do better for this category.
> Maybe "Org mode: manage your life and notes in plain text"?
> Though it makes the title less relevant to group #2.
>
> 4. Researchers looking for ipython-like environment
>
> Not covered, except by reading my proposed site summary. I am not
> sure how we can improve title for this audience.
>
> 5. ??? (Suggestions are welcome)
>
> Of course, better suggestions for the title are welcome. I just wanted
> to make it clear the reasoning I do not like the current title and how
> the proposed alternative is better (though not ideal).
>
> Finally, I want to emphasise that our aim for search engines is not
> advertising Emacs (we already do it by trapping users inside Org and
> making them switch to Emacs by force :evil_laughter:). The aim is
> encouraging people to use and contribute to Org mode in useful ways
> (even unrelated to writing Elisp or, really, any code at all).
>
> Search result is just an entrance for users to be curious about the new
> beast of "Org mode". The website front page is the means to make users
> try. And the Org mode itself is the way to make users fall in love with
> Org in one way or another (even unrelated to Emacs [at least
> initially]).
>
I think your working off a false premise. Your view is that org mode
should be available in other editors/software so that others can realise
the power and benefits it provides. I can understand that position.
However, the FSF position would be exactly the opposite. They would
argue that orgmode is a powerful and flexible tool that is part of Emacs
and if you want that power and flexibility, you need to use Emacs. Org
mode has probably done more to bring new users to Emacs than any other
Emacs mode in the last 30 years. As a consequence, you will find not
only little support towards making it available in other editors, you
are likely to run into active resistance. As you say, org-mode can be
thought of as a brand name and that is a brand name owned by the FSF as
an official GNU project and a goal of the FSF is to convert people to
use GNU free software. Anything which has the potential to take the
power of org mode and make it available in non-free software (not simply
open source) is not going to be supported or welcomed.
^ permalink raw reply [relevance 0%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 12:08 3% ` Ihor Radchenko
2021-12-05 13:32 0% ` Tim Cross
@ 2021-12-05 18:59 6% ` Juan Manuel Macías
2021-12-05 23:24 4% ` Russell Adams
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-05 18:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Ok. Let me explain my thought process.
>
> First of all, there is no burden on users of Org mode in making edits to
> orgmode.org. It is a burden on Org contributors.
>
> One of the aims of my proposal is reducing this burden by involving
> non-emacs users to provide contributions to Org (e.g. by making more
> tests for Org-element parser). To do it, we need to make the
> contribution process for non-emacs developers easier. Ideally, without
> too much effort on our side.
>
> The idea of involving non-emacs users does have a potential because we
> do know that third-party tools are already using Org. The problem is the
> disconnect between those tools and Org mode proper.
>
> The sources of the disconnect are (1) lack of technical "blueprints" for
> Org that do not require knowing Elisp; (2) lack of discovereability of
> Org mode as something that can live outside narrow field of Emacs. In
> this branch of our discussion, I am going to talk about the second
> point.
>
> People simply do not expect to see a markup language when they encounter
> a link with "Org mode for Emacs" title. Someone looking for Org mode
> markup to be used in, say, websites will think that "Org mode for Emacs"
> is limited to Emacs. Someone just interested in plain text markup will
> find no relevance at all.
>
> Title is important. If we care at all about orgmode.org website
> appearing in search results, we want the title and the summary to have 2
> main properties: (1) Provide search keywords to make it searchable by
> potentially interested people; (2) Provide a title that immediately
> signal that our website contains the information people are looking for.
>
> Now, we need to understand what kind of people may be looking to
> orgmode.org website.
>
> 1. Existing emacs users
>
> If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
> is indeed recognisable. On the other hand, the word "Org mode" does
> not provide much further info, except that it is a major (or maybe
> minor?) mode for "Org"??
>
> Now, consider "Org mode: your life in plain text".
> For emacs users, "Org mode" is not just a strange phrase, but a very
> clear indication that we are talking about Emacs.
> The "your life in plain text" provides extra information about what
> "Org mode" refers to. Clearly, text documents and "your life in plain
> text" should resonate with every Emacs user's soul.
>
> We can change the second variant of the title to contain "Emacs", but
> will it add much value? I am not convinced. On the other hand, making
> title too long or too complex _is_ bad. Long titles tend to be
> skipped (there was even formal research on this!)
>
> 2. Non-emacs users interested in plain text markup
>
> These users know nothing about Emacs and "Org mode" has no meaning
> for them as is. So, we do need something more descriptive.
> Adding "Emacs" may be fine, but it will serve no purpose for people
> not familiar with emacs. Just another unknown term making the title
> longer.
>
> 3. Non-emacs users interested in GTD/project management, etc
> "Org mode: your life in plain text" is somewhat relevant when people
> are looking to manage "life" (typically true for GTD enthusiasts).
>
> Though we can probably do better for this category.
> Maybe "Org mode: manage your life and notes in plain text"?
> Though it makes the title less relevant to group #2.
>
> 4. Researchers looking for ipython-like environment
>
> Not covered, except by reading my proposed site summary. I am not
> sure how we can improve title for this audience.
>
> 5. ??? (Suggestions are welcome)
>
> Of course, better suggestions for the title are welcome. I just wanted
> to make it clear the reasoning I do not like the current title and how
> the proposed alternative is better (though not ideal).
>
> Finally, I want to emphasise that our aim for search engines is not
> advertising Emacs (we already do it by trapping users inside Org and
> making them switch to Emacs by force :evil_laughter:). The aim is
> encouraging people to use and contribute to Org mode in useful ways
> (even unrelated to writing Elisp or, really, any code at all).
>
> Search result is just an entrance for users to be curious about the new
> beast of "Org mode". The website front page is the means to make users
> try. And the Org mode itself is the way to make users fall in love with
> Org in one way or another (even unrelated to Emacs [at least
> initially]).
Ihor, thank you very much for explaining your motivation in detail. I
think I understand it and (on the important points) I share it. In my
case, as an Org Mode user I often feel a mixture of happiness and
frustration. Happiness on using Org. Frustration every time I want to
recommend Org to many of my friends and colleagues, who don't even use
Emacs. GNU Emacs is a great, labyrinthine, fascinating building. Almost
like a city. And Org is a room on one of the upper floors. In the
Org-room (including Org-Roam! :-) there is a lot of fun, great people,
great music. But whoever wants to get there must go through a series of
levels, intricate corridors that are like a kind of learning path. Emacs
is great, but you can't learn to use it in two days. It takes time to
adapt it to your needs, get to know it, even love it. Sorry to be so
metaphorical and poetic, but it is the only way I can find to explain
what is, in many ways, a personal learning process (even the init Emacs
file could be understood as a kind of autobiography...). I wish the entry
into Org was smoother and more direct, but being an Emacs mode, it is
necessary to go through Emacs. And this gets more crude for
non-technical, Humanities users, who I think could be very happy using
Org and not Word or other modern auto-torture methods :-)
I came to Org been an Emacs user already, so I was reasonably familiar
with Emacs and Elisp, although what I used most was AUCTeX (and Markdown
for my docs). I heard about Org but it never caught my attention, until
one day I read the Org compact guide and I was fascinated that such a
thing existed (and it was just the compact guide!).
TL; DR: I understand and share the maneuver of baiting new and potential
users. But I see it difficult. Users who have never used Emacs will have
to go through the Emacs learning process first, especially non-technical
users or those who come from the country of word processors, that is,
Mordor. On the other hand, Org as a lightweight markup language is only
a tiny part of Org. I don't think Org is better or worse as a markup
language than Markdown, asciidoc or other similar formats. I think the
important thing about Org here is the integration of a series of
resources: a whole that is more important than the sum of the parts
(https://en.wikipedia.org/wiki/Emergentism).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 18:59 6% ` Juan Manuel Macías
@ 2021-12-05 23:24 4% ` Russell Adams
2021-12-06 5:57 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Russell Adams @ 2021-12-05 23:24 UTC (permalink / raw)
To: emacs-orgmode
On Sun, Dec 05, 2021 at 06:59:20PM +0000, Juan Manuel Macías wrote:
> Frustration every time I want to recommend Org to many of my friends
> and colleagues, who don't even use Emacs.
I think this is the core of every interoperability argument: "Why do
we have to use Emacs to use Org?" It's called Emacs Org-mode for a
reason. Org-mode doesn't work outside of Emacs.
I've often told users that it's worth learning enough Emacs to use
Org, and have successfully moved several non-power users over to
Emacs. They know enough to consistently open their files, edit Org,
and quit. That's enough. They complain it's "ugly" compared to
"modern" GUI tools, but they can't deny the utility.
> I came to Org been an Emacs user already, so I was reasonably familiar
> with Emacs and Elisp, although what I used most was AUCTeX (and Markdown
> for my docs).
I'd have a hard time convincing users in Mordor to use a plain text
format, much less Org without Emacs.
> On the other hand, Org as a lightweight markup language is only
> a tiny part of Org. I don't think Org is better or worse as a markup
> language than Markdown, asciidoc or other similar formats.
What makes Org dramatically different is the editing experience in
Emacs. Collapsing the outline, filtering on metadata, exports, agenda,
etc. Those are Emacs features, not specific to the actual markup
format.
My impression is we already have stretched our resources thin trying
to maintain Org. Pushing to provide compatibility with non-Emacs tools
seems a poor use of their time, and rude to ask of them.
If non-Emacs users and coders want to use Org formatted files, they
are free to spend their time customizing their tools to make it
work. If the Org project owes anything to anyone, it's a consistent
experience for the users who have used Org for years. Not changes to
satisfy potential users or follow trendy fads.
My experience has been that Org's markup is so simple and could be
summarized in a few lines. Anything more complex enters the territory
of Emacs only features (ie: drawers. exports, view control, source
blocks, reporting). Those are unlikely to be portable, so we're back
to "use Emacs".
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
^ permalink raw reply [relevance 4%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
2021-12-05 23:24 4% ` Russell Adams
@ 2021-12-06 5:57 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-06 5:57 UTC (permalink / raw)
To: Russell Adams; +Cc: orgmode
Russell Adams writes:
> What makes Org dramatically different is the editing experience in
> Emacs. Collapsing the outline, filtering on metadata, exports, agenda,
> etc. Those are Emacs features, not specific to the actual markup
> format.
>
> My impression is we already have stretched our resources thin trying
> to maintain Org. Pushing to provide compatibility with non-Emacs tools
> seems a poor use of their time, and rude to ask of them.
>
> If non-Emacs users and coders want to use Org formatted files, they
> are free to spend their time customizing their tools to make it
> work. If the Org project owes anything to anyone, it's a consistent
> experience for the users who have used Org for years. Not changes to
> satisfy potential users or follow trendy fads.
>
> My experience has been that Org's markup is so simple and could be
> summarized in a few lines. Anything more complex enters the territory
> of Emacs only features (ie: drawers. exports, view control, source
> blocks, reporting). Those are unlikely to be portable, so we're back
> to "use Emacs".
I think that I cannot agree more with this. Org Mode is GNU Emacs, and
the magic of Org Mode is the magic of GNU Emacs. That's why I insist
that going to Org means going to Emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-06 7:24 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-06 7:24 UTC (permalink / raw)
To: Timothy; +Cc: emacs-orgmode
Hi Timohy,
Timothy writes:
> I don’t think Ihor is suggesting we stop indicating that org-mode is part of
> Emacs.
Of course, I am convinced that Ihor is not saying that Org is not part
of Emacs, and I have to make it clear, that I have never suggested such
a thing. What's more, I understand and applaud his conciliatory effort
on this issue, since since a series of debates and noise have arisen
here on these matters.
What worries me are the consequences of insisting here on these debates.
That is why I have underlined what Russell has commented, as I think he
is right.
On the other hand, we must not forget that Org, as part of Emacs, is
part of GNU, and this is a mailing list from the GNU project. I think
everything related to the (possible) extension of GNU Org Mode outside
of GNU Emacs (even in software incompatible with the ethics and
philosophy of the GNU project) should be considered offtopic here and be
discussed in other forums. Otherwise it would only create confusion
among users.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
@ 2021-12-06 14:59 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 14:59 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg,
Greg Minshall writes:
> i hope we don't adopt such an "official policy" regarding discussions on
> this list. i don't think we've had any problems where non-FSF/GNU
> topics have somehow swamped our discussions.
Not that I want to put on a censor hat, far from it :-). But this is
still an 'official' list. It's not reddit or anything like that. I think
it is necessary for the user to know what to expect here and what not to
expect. And I think there is a border between offtopic and explicitly
discussing extending Org beyond its natural limits or even flirting with
applications and software that do not respect user freedom and are
outside of GNU ethics and philosophy. And for the record, I am not
talking about Ihor's specific proposals in this thread --- which, as I
have already said, seems to me to be a commendable conciliatory effort,
although I do not share some points--- but rather from the previous
debate on the "new" name of the Org syntax, and other such things. I
think things like the 'orgdown' topic, which are not productive here,
should have their own place and forums outside here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Raw Org AST snippets for "impossible" markup
@ 2021-12-06 15:45 8% ` Juan Manuel Macías
2021-12-06 16:56 13% ` Juan Manuel Macías
2021-12-08 13:09 4% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 15:45 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> John, thank you for the reminding me of Juan Manuel's idea that
> everything missed in Org may be polyfilled (ab)using links.
> It is enough for proof of concept, special markers may be introduced
> later. After some time spent exercising in monkey-typing,
> I have got some code that illustrates my idea.
>
> So the goal is to mitigate demand to extend current syntax.
> While simple cases should be easy,
> special cases should not be impossible.
>
> - Raw AST snippets should be processed without ~eval~ to give
> other tools such as =pandoc= a chance to support the feature.
> If you desperately need ~eval~ then you can use source blocks.
> - The idea is to use existing backends by passing structures
> similar to ones generated by ~org-element~ parser.
> - I would prefer to avoid "@@" for link prefix since such sequences
> are already a part of Org syntax. In the following example
> export snippet is preliminary terminated by such link:
>
> #+begin_src elisp :results pp
> (org-element-parse-secondary-string
> "@@latex:[[@@:(italics \"i\")]]@@"
> (org-element-restriction 'paragraph))
> #+end_src
>
>
> #+RESULTS:
> : ((export-snippet
> : (:back-end "latex" :value "[[" :begin 1 :end 13 :post-blank 0
> :parent #0))
> : #(":(italics \"i\")]]@@" 0 18
> : (:parent #0)))
>
> Let's take some link prefix that makes it clear that the proposal
> is a draft and a sane variant will be chosen later when agreement
> concerning details of such feature is achieved. Till that moment
> it is named "orgia".
>
> #+begin_src elisp :results silent
> (defun orgia-export (path desc backend)
> (if (not (eq ?\( (aref path 0)))
> path
> (let ((tree (read path))
> (info (org-export-get-environment backend nil nil)))
> (org-no-properties
> (org-export-data-with-backend tree backend info)))))
>
> (org-link-set-parameters
> "orgia"
> :export #'orgia-export)
> #+end_src
>
>
> Either [[orgia:("inter" (bold () "word"))]]
> or <orgia:((italic () "inter") "word")>
> links may be used. Certainly plain text may be outside:
>
> #+begin_src elisp
> (org-export-string-as "A <orgia:(italic () \"inter\")>word" 'html t)
> #+end_src
>
> #+RESULTS:
> : <p>
> : A <i>inter</i>word</p>
>
> - Error handling is required.
> - Elements (blocks) should be considered as an error
> in object (inline) context.
> - Passed tree should be preprocessed to glue strings split to
> avoid interpreting them as terminating outer construct or link itself
> (=]]= =][= should be ="]" "]"= ="]" "["= inside bracket links).
> It is especially important for property values.
> - For convenience =parse= element may be added to parse a string
> accordingly to Org markup.
> - There should be a similar element (block-level markup structure).
> - Symbols and structures used by ~org-element~ becomes a part of
> public API, but they are already are since they are used
> by export backends.
> - ~org-cite~ is likely will be a problem.
Hi Maxim,
I understand that with this method the emphases could be nested, which
it seems also very productive. I like it.
I would suggest, however, not to use the term 'italics', since is a
'typographic' term, but a term that is agnostic of format and
typography, something like as 'emphasis' or 'emph'. For example, in a
format agnostic environment like Org, which is concerned only with
structure, an emphasis is always an emphasis. But in a typographic
environment that emphasis may or may not be be in italics. That is why
in LaTeX you can write constructions like:
#+begin_src latex
\emph{The Making Off of \emph{Star Wars}}
#+end_src
In this context 'Star Wars' would appear in upright font. Naturally,
these things are only possible in LaTeX, but it's nice to keep in Org a
typographic agnosticism.
Anyway, I find all this very interesting as proof of concept, although
in my workflow I prefer to use macros for these types of scenarios (yes,
a rare case where I don't use links! :-D):
#+begin_src emacs-lisp
(defun my-macro-emph (arg)
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
(concat "@@latex:\\emph{@@" arg "@@latex:}@@"))
((org-export-derived-backend-p org-export-current-backend 'html)
(concat "@@html:<em>@@" arg "@@html:</em>@@"))
((org-export-derived-backend-p org-export-current-backend 'odt)
(concat "@@odt:<text:span text:style-name=\"Emphasis\">@@" arg "@@odt:</text:span>@@"))))
(setq org-export-global-macros
'(("emph" . "(eval (my-macro-emph $1))")))
#+end_src
{{{emph(The Making Off of {{{emph(Star Wars)}}})}}}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-06 15:45 8% ` Juan Manuel Macías
@ 2021-12-06 16:56 13% ` Juan Manuel Macías
2021-12-08 13:09 4% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 16:56 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Juan Manuel Macías writes:
> I would suggest, however, not to use the term 'italics [...blah blah...]'
Sorry for the noise! I think I messed myself up...
Naturally, 'italic' (or 'bold') is required: (italic () \"inter\")
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-06 15:45 8% ` Juan Manuel Macías
2021-12-06 16:56 13% ` Juan Manuel Macías
@ 2021-12-08 13:09 4% ` Max Nikulin
2021-12-08 23:19 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-08 13:09 UTC (permalink / raw)
To: emacs-orgmode
On 06/12/2021 22:45, Juan Manuel Macías wrote:
>
> I understand that with this method the emphases could be nested, which
> it seems also very productive. I like it.
>
> I would suggest, however, not to use the term 'italics', since is a
> 'typographic' term, but a term that is agnostic of format and
> typography, something like as 'emphasis' or 'emph'. For example, in a
> format agnostic environment like Org, which is concerned only with
> structure, an emphasis is always an emphasis. But in a typographic
> environment that emphasis may or may not be be in italics. That is why
> in LaTeX you can write constructions like:
As you have guessed, It is not my choice, it is interface of ox.el and
org-element.el.
However if you strongly want to use proper terminology in markup, you
may try to trade it for +your soul+ compatibility and portability
issues. The following almost works:
#+begin_src elisp :results silent
(defun orgia-link (link-data desc info)
(let* ((backend-struct (plist-get info :back-end))
(backend-name (org-export-backend-name backend-struct)))
(or
(org-export-custom-protocol-maybe link-data desc backend-name info)
(let* ((parent (org-export-backend-parent backend-struct))
(transcoders-alist (org-export-get-all-transcoders parent))
(link-transcoder (alist-get 'link transcoders-alist)))
(if link-transcoder
(funcall link-transcoder link-data desc info)
desc)))))
(defun evilatex-emph (_emph content info)
;; I have no idea yet why newline is appended.
(format "\\textit{%s}%%" content))
(org-export-define-derived-backend 'evilatex 'latex
:translate-alist '((emph . evilatex-emph)
(link . orgia-link)))
#+end_src
#+begin_src elisp
(let ((org-export-with-broken-links 'mark))
(org-export-string-as
"An [[orgia:(italic () \"ex\")]]ample of <orgia:(emph ()
\"inter\")>word and [[http://te.st][link]] [[unknown:prefix][desc]]!"
'evilatex t))
#+end_src
#+RESULTS:
: An \emph{ex}ample of \textit{inter}%
: word and \href{http://te.st}{link} [BROKEN LINK: unknown:prefix]!
Actually, I believe that something like orgia-link code should be added
by `org-exprot-define-derived-backend' if "link" is missed in
translate-alist. I suspect that `org-export-get-all-transcoders' may be
avoided.
> (setq org-export-global-macros
> '(("emph" . "(eval (my-macro-emph $1))")))
Sorry, I have not prepared better variant to solve comma in macro
problem yet.
^ permalink raw reply [relevance 4%]
* Making a dictionary in Org
@ 2021-12-08 20:03 12% Juan Manuel Macías
2021-12-08 23:13 6% ` Thomas S. Dye
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-08 20:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
Hi,
How to create a 'dictionary style' PDF document from Org, with two
columns and with dynamic page headers[1]: here I share (attached) an Org
file, in case it is useful to someone, with the (simplified) LaTeX code
I used to define the styles of the entries and the dynamic page headers
in the typesetting of the /Hispanic Dictionary of Classical Tradition/.
I produced this dictionary (828 pp.) using Org and Org-Publish, with
output to LuaLaTeX. Some images:
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc5.png
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc3.png
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc4.png
[1] If a page contains multiple entries, the first and the last entries
are collected, both separated by an en dash; if the page contains a
single entry, or a continuation of the previous page/entry, it is
collected that entry only.
Best regards,
Juan Manuel
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
[-- Attachment #2: dictionary.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1218 bytes --]
^ permalink raw reply [relevance 12%]
* Re: Making a dictionary in Org
2021-12-08 20:03 12% Making a dictionary in Org Juan Manuel Macías
@ 2021-12-08 23:13 6% ` Thomas S. Dye
0 siblings, 0 replies; 200+ results
From: Thomas S. Dye @ 2021-12-08 23:13 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> How to create a 'dictionary style' PDF document from Org, with
> two
> columns and with dynamic page headers[1]: here I share
> (attached) an Org
> file, in case it is useful to someone, with the (simplified)
> LaTeX code
> I used to define the styles of the entries and the dynamic page
> headers
> in the typesetting of the /Hispanic Dictionary of Classical
> Tradition/.
>
> I produced this dictionary (828 pp.) using Org and Org-Publish,
> with
> output to LuaLaTeX. Some images:
> https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc5.png
> https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc3.png
> https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc4.png
>
> [1] If a page contains multiple entries, the first and the last
> entries
> are collected, both separated by an en dash; if the page
> contains a
> single entry, or a continuation of the previous page/entry, it
> is
> collected that entry only.
>
Nice work!
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 6%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-08 13:09 4% ` Max Nikulin
@ 2021-12-08 23:19 9% ` Juan Manuel Macías
2021-12-08 23:35 6% ` John Kitchin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-08 23:19 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> As you have guessed, It is not my choice, it is interface of ox.el and
> org-element.el.
Indeed. Sorry for my haste: it's the consequences of not read the code
carefully :-)
Of course, your orgia-link-procedure could be extended to more org elements.
I can't think of what kind of scenario that might fit in, but as a proof
of concept I find it really stimulating. E.g:
#+begin_src elisp
(org-export-string-as "<orgia:(verse-block () \"Lorem\\nipsum\\ndolor\")>" 'html t)
#+end_src
#+RESULTS:
: <p>
: <p class="verse">
: Lorem<br />
: ipsum<br />
: dolor</p>
: </p>
#+begin_src elisp
(org-export-string-as "<orgia:(quote-block (:attr_latex
(\":environment foreigndisplayquote :options {greek}\"))
\"Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
Ἀρταξέρξης, νεώτερος δὲ Κῦρος·\")>" 'latex t)
#+end_src
#+RESULTS:
: \begin{foreigndisplayquote}{greek}
: Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲνἈρταξέρξης, νεώτερος δὲ Κῦρος·
: \end{foreigndisplayquote}
> However if you strongly want to use proper terminology in markup, you
> may try to trade it for +your soul+ compatibility and portability
> issues. The following almost works:
Interesting, thank you.
Yes, it is strange the new line added in `evilatex-emph' ... I have no
idea why that happens.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-08 23:19 9% ` Juan Manuel Macías
@ 2021-12-08 23:35 6% ` John Kitchin
2021-12-09 7:01 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2021-12-08 23:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, orgmode
[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]
Have you seen
https://github.com/tj64/org-dp? It seems to do a lot with creating and
manipulating org elements. It might either be handy or lead to some
inspiration.
On Wed, Dec 8, 2021 at 6:20 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Max Nikulin writes:
>
> > As you have guessed, It is not my choice, it is interface of ox.el and
> > org-element.el.
>
> Indeed. Sorry for my haste: it's the consequences of not read the code
> carefully :-)
>
> Of course, your orgia-link-procedure could be extended to more org
> elements.
> I can't think of what kind of scenario that might fit in, but as a proof
> of concept I find it really stimulating. E.g:
>
> #+begin_src elisp
> (org-export-string-as "<orgia:(verse-block ()
> \"Lorem\\nipsum\\ndolor\")>" 'html t)
> #+end_src
>
> #+RESULTS:
> : <p>
> : <p class="verse">
> : Lorem<br />
> : ipsum<br />
> : dolor</p>
> : </p>
>
> #+begin_src elisp
> (org-export-string-as "<orgia:(quote-block (:attr_latex
> (\":environment foreigndisplayquote :options {greek}\"))
> \"Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
> Ἀρταξέρξης, νεώτερος δὲ Κῦρος·\")>" 'latex t)
> #+end_src
>
> #+RESULTS:
> : \begin{foreigndisplayquote}{greek}
> : Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲνἈρταξέρξης,
> νεώτερος δὲ Κῦρος·
> : \end{foreigndisplayquote}
>
>
> > However if you strongly want to use proper terminology in markup, you
> > may try to trade it for +your soul+ compatibility and portability
> > issues. The following almost works:
>
> Interesting, thank you.
>
> Yes, it is strange the new line added in `evilatex-emph' ... I have no
> idea why that happens.
>
> Best regards,
>
> Juan Manuel
>
--
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
[-- Attachment #2: Type: text/html, Size: 3121 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-08 23:35 6% ` John Kitchin
@ 2021-12-09 7:01 5% ` Juan Manuel Macías
2021-12-09 14:56 4% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-09 7:01 UTC (permalink / raw)
To: John Kitchin; +Cc: Maxim Nikulin, orgmode
John Kitchin writes:
> Have you seen
> https://github.com/tj64/org-dp? It seems to do a lot with creating and
> manipulating org elements. It might either be handy or lead to some
> inspiration.
Interesting package. Thanks for sharing.
It gave me an idea, also borrowing part of Maxim's code, but evaluating
in this case the path. To continue playing with links... The goal is
to obtain a link with this structure `[[quote-lang:lang][quote]]':
#+BEGIN_SRC emacs-lisp :results silent
(org-link-set-parameters
"quote-lang"
:display 'full
:export (lambda (path desc bck)
(let* ((bck org-export-current-backend)
(attr (list (format
":environment foreigndisplayquote :options {%s}"
path)))
(info (org-export-get-environment
bck nil nil)))
(org-no-properties
(org-export-data-with-backend
`(quote-block (:attr_latex ,attr)
,desc)
bck info)))))
#+END_SRC
#+begin_src emacs-lisp
(setq backends '(latex html odt))
(setq results nil)
(mapc (lambda (backend)
(add-to-list 'results
(org-export-string-as
"[[quote-lang:spanish][Publicamos nuestro libros
para librarnos de ellos, para no pasar el resto de nuestras vidas
corrigiendo borradores.]]" backend t) t))
backends)
(mapconcat 'identity results "\n")
#+end_src
#+RESULTS:
#+begin_example
\begin{foreigndisplayquote}{spanish}
Publicamos nuestro libros
para librarnos de ellos, para no pasar el resto de nuestras vidas
corrigiendo borradores.
\end{foreigndisplayquote}
<p>
<blockquote>
Publicamos nuestro libros
para librarnos de ellos, para no pasar el resto de nuestras vidas
corrigiendo borradores.
</blockquote>
</p>
<text:p text:style-name="Text_20_body">Publicamos nuestro libros
para librarnos de ellos, para no pasar el resto de nuestras vidas
corrigiendo borradores.</text:p>
#+end_example
^ permalink raw reply [relevance 5%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-09 7:01 5% ` Juan Manuel Macías
@ 2021-12-09 14:56 4% ` Max Nikulin
2021-12-09 16:11 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-09 14:56 UTC (permalink / raw)
To: emacs-orgmode
On 09/12/2021 14:01, Juan Manuel Macías wrote:
> John Kitchin writes:
>
>> Have you seen
>> https://github.com/tj64/org-dp? It seems to do a lot with creating and
>> manipulating org elements. It might either be handy or lead to some
>> inspiration.
>
> Interesting package. Thanks for sharing.
Either I missed something or its purpose is completely different. It
maps Org markup to Org markup. I am experimenting with fragments that
should allow to get something that is really tricky or even impossible
with established syntax, so it has to run immediately before exporters.
> It gave me an idea, also borrowing part of Maxim's code, but evaluating
> in this case the path. To continue playing with links... The goal is
> to obtain a link with this structure `[[quote-lang:lang][quote]]':
>
> #+BEGIN_SRC emacs-lisp :results silent
> (org-link-set-parameters
> "quote-lang"
> :display 'full
> :export (lambda (path desc bck)
> (let* ((bck org-export-current-backend)
> (attr (list (format
> ":environment foreigndisplayquote :options {%s}"
> path)))
> (info (org-export-get-environment
> bck nil nil)))
> (org-no-properties
> (org-export-data-with-backend
> `(quote-block (:attr_latex ,attr)
> ,desc)
> bck info)))))
> #+END_SRC
Looking into your code I have realized that it should be implemented
using filter, not through :export property of links. Maybe without
working proof of concept with link exporters, this session of
monkey-typing would not be successful.
#+begin_src elisp :results silent
(defun orgia-element-replace (current new destructive?)
(if (eq current new)
current
(let* ((lst? (and (listp new) (not (symbolp (car new)))))
(new-lst (if lst?
(if destructive? (nconc new) (reverse new))
(list new))))
(dolist (element new-lst)
(org-element-insert-before element current)))
(org-element-extract-element current)
new))
(defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
(let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
(read path)))))
(defun orgia-parse-tree-filter (data _backend info)
(org-element-map data 'link
(lambda (data)
(orgia-element-replace data (orgia--transform-link data) t))
info nil nil t)
data)
#+end_src
#+begin_src elisp :results silent
(add-to-list 'org-export-filter-parse-tree-functions
#'orgia-parse-tree-filter)
(org-link-set-parameters "orgia")
#+end_src
#+begin_src elisp
(org-export-string-as "An <orgia:(\"in\" (italic () \"ter\"))>word"
'html t)
#+end_src
#+RESULTS:
: <p>
: An in<i>ter</i>word</p>
^ permalink raw reply [relevance 4%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-09 14:56 4% ` Max Nikulin
@ 2021-12-09 16:11 6% ` Juan Manuel Macías
2021-12-09 22:27 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-09 16:11 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Looking into your code I have realized that it should be implemented
> using filter, not through :export property of links. Maybe without
> working proof of concept with link exporters, this session of
> monkey-typing would not be successful.
Jumping into the "real world", how about these two examples of nested emphasis?
#+begin_src org :results latex :results replace
[[orgia:(italic () "The English versions of the " (italic () "Iliad") " and the " (italic () "Odyssey"))]]
#+end_src
#+RESULTS:
#+begin_export latex
\emph{The English versions of the \emph{Iliad} and the \emph{Odyssey}}
#+end_export
This one more complex:
#+begin_src org :results latex :results replace
[[orgia:(italic () "The English versions of the " (bold () (italic () "Iliad")) " and the " (bold () (italic () "Odyssey")))]]
#+end_src
#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the \textbf{\emph{Odyssey}}}
#+end_export
^ permalink raw reply [relevance 6%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-09 16:11 6% ` Juan Manuel Macías
@ 2021-12-09 22:27 12% ` Juan Manuel Macías
2022-01-03 14:34 3% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-09 22:27 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Juan Manuel Macías writes:
> Jumping into the "real world", how about these two examples of nested emphasis?
By the way, what do you think about allowing the use of some kind of
aliases, so that the aspect is less verbose? Maybe something like "(i::"
instead of "(italic () ..."? I came up with this hasty sketch over your
latest code, *just* to see how it looks (I don't know if I prefer it to
stay verbose):
#+begin_src emacs-lisp :results silent
(setq orgia-alias-alist '(("i" "italic")
("b" "bold")
("u" "underline")
("s" "strike-through")))
(defun orgia-replace (before after)
(interactive)
(save-excursion
(goto-char (point-min))
(while (re-search-forward before nil t)
(replace-match after t nil))))
(defun orgia--transform-path (path)
(with-temp-buffer
(insert path)
(mapc (lambda (el)
(orgia-replace (concat "(" (car el) "::") (concat "(" (cadr el) " () ")))
orgia-alias-alist)
(buffer-string)))
(defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
(let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
(read (orgia--transform-path path)))))) ;; <====
;;;;;;;;;;;;;;;;;;
#+end_src
#+begin_src elisp
(org-export-string-as "An <orgia:(\"in\" (s:: \"ter\"))>word"
'odt t)
#+end_src
#+RESULTS:
:
: <text:p text:style-name="Text_20_body">An in<text:span text:style-name="Strikethrough">ter</text:span>word</text:p>
#+begin_src org :results latex :results replace
[[orgia:(i:: "The English versions of the " (b:: (i:: "Iliad")) " and the " (b:: (i::
"Odyssey")))]]
#+end_src
#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the \textbf{\emph{Odyssey}}}
#+end_export
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 12%]
* Re: format/fill of text in a cell in tables
@ 2021-12-17 21:25 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-17 21:25 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> This reminds me of people advocating "semantic backup" (e.g. use
> "emphasis" instead of "italics", until one realises that you just
> managed to peel off one layer of the sematic onion. The onion just got
> smaller (some literature perhaps might want to play with the ambiguity
> of italics?), and if you continue, you end up with no onion at all.
There is a lot of confusion between the terms 'emphasis' and
'italics/cursive'. The second term is strictly typographic-calligraphic.
There are entire codices that are wrote in Byzantine cursive. And you
have the Porson typeface, from the Oxford editions of Ancient Greek
texts, which is a cursive, but which is used as a normal font. In an
ancient text there is no notion for 'emphasis': how do we know when
Homer or Sappho wanted to emphasize a phrase? Typography has
historically used italics as a resource for emphasis (not in all
languages, some use the separation of letters to emphasize; there are
also writing systems where the concept of 'italics' or 'cursive' does
not make sense), but it uses the italic also for more varied purposes:
depends on the era, fashion and trends. Consider also the avant-garde
poetry of the early last century, which had a great typographical
dependency, as a sort of game. In addition, there is the maremagnum of
graphic design, which is not strictly typography (although both terms
are also confused), but use the typography for expressive purposes:
advertising, etc.
I remember that a long time ago I use to wrote in a typewriter, and
there was a common convention in typed texts, which consisted of marking
the emphases like this: _emphasis_. WYSIWYG word processors imposed a
form quite unnatural to write, by confusing format and content. And they
force authors to have typographical concerns at the most inopportune
moment, which is the creation of content (as if Hemingway used a
monotype instead of a typewriter). The proof is that hardly any of the
Word users use Word styles or apply them consistently. The normal thing,
with rare exceptions, is to degrade the documents using direct format,
which is the great plague.
I believe that a text whose main purpose is not to produce a visual
impact (advertising, ritual, magic, etc.) but to transmit a thought and
a content, it must have a structure. And then there will be time for
that structure can be translated to other supports. Typography, in its
most basic and utilitarian sense (not visual) is nothing more than a
language to translate that structure, offering the maximum possible
readability, through a series of techniques. And every type of
content, for example a 'table' (in Org terms not typographic terms), can
have many possible typographic translations, even translations that
don't consist of a 'table', in typographical terms. But typography is not
the only possible language to translate a content: think of texts
written to be heard, or texts written for absolutely personal use.
That's why I believe the least unhealthy way to put content in writing
is within a environment as agnostic as possible of the format. In that
environment is where the term 'emphasis' makes sense.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: format/fill of text in a cell in tables
@ 2021-12-18 11:09 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-18 11:09 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> I think, one attempt could be to use org-edit-special, to edit a cell,
> type the text in a temporary buffer, fill it and then return to the table.
>
> That seems so obvious that I think there might be technical problems,
> because otherwise it would have been implemented already.
I proposed that here the last time a similar discussion came up, but now
I don't think it's a good idea. I believe the root problem is that the
visual representation of the tables in Org is line oriented. Cells with
a lot of content (paragraphs, for example) should be shrunken, because
the content is a single line; when editing each cell in its special
buffer, that content would have to be converted into paragraphs, and
when saving the edition buffer, convert it back to a single line again.
I tried to write something similar for my personal use, but it is very
tricky. Maybe such an implementation would work better for AUCTeX, since
tables in LaTeX are not line oriented.
About a possible solution for Org regarding the topic of 'complex'
tables, I have ended up giving up. I think it is better to create the
complex tables in raw LaTeX. To export them to HTML you could perhaps
think of a LaTeX block that would return the results compiling with
tex4ht (https://ctan.org/pkg/tex4ht?lang=en) instead of LaTeX. But I
don't know if it would work. The point is that anything other than a
simple and clean table (visually speaking) in Org, is to enter the land
of the tricks.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: text after sub headings?
@ 2021-12-23 20:27 8% ` Juan Manuel Macías
2021-12-24 16:51 4% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-23 20:27 UTC (permalink / raw)
To: Robert Nikander; +Cc: orgmode
Hi Robert,
Robert Nikander writes:
> I see why this is not possible, given the text format of an org file.
> But I am curious if people think it would be useful. This is a bit
> off-topic maybe, but I’m imagining what I would do if I created
> something like org-mode using another underlying format.
>
> Example:
>
> * Top
> Some text under “Top”
> ** A level-2 heading
> Text under level-2 heading
> ** Another level-2 heading
> Text under the second level-2 heading
> More text under “Top”
> So if the level-2 headings were collapsed we would still see this.
> ** Could have more sub-headings here
> More top level text, etc.
It is an interesting question; however, I would say that this is not a
useful or realistic structure. Regardless of the Org trees/subtrees and
their folding ability (indicating that each thing is at a certain
level), I think that a content will be more useful and intelligible if
it is easy and obvious to extract a table of contents (with headings and
levels) from that content. Let's imagine not we are in Org but writing a
novel on a typewriter. It could be a two-voice novel, with a main
narrator and a "secondary" narrator. The first structure could be:
Part I (Narrator A)
Some text under Part I (Narrator A)
Chaper 1
Text under Chapter 1 (Narrator B)
Chapter 2
Text under Chapter 2 (Narrator B)
?? More text under Part I (Narrator A)
More chapters (Narrator B)
?? More Part I text, etc. (Narrator A)
(...)
Although we feel that our structure is very clear, our publisher will
probably force us to include some kind of division into the texts marked
with "??". I mean, it's not that easy to escape from the (graphical)
levels, parts and chapters, even if it is by editorial imposition or for
not confuse our readers. We can, for example, call Part II "Interlude",
or add the first text marked with "??" after a graphic separation (some
dashes, for example: ------). Although the literary structure is
complex, its graphical representation always has limits:
Part I (Narrator A)
Some text under Part I (Narrator A)
Chaper 1
Text under Chapter 1 (Narrator B <= Narrator A)
Chapter 2
Text under Chapter 2 (Narrator B <= Narrator A)
Division 1 (forced by the publishing house = Part II?)
More text under Part II (Narrator A)
More chapters (Narrator B)
(...)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: text after sub headings?
@ 2021-12-23 21:21 5% Robert Nikander
2021-12-23 21:47 0% ` John Kitchin
2021-12-23 22:10 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Robert Nikander @ 2021-12-23 21:21 UTC (permalink / raw)
To: emacs-orgmode
Max Nikulin wrote:
> Have you seen the following and links therein?
> https://orgmode.org/worg/org-faq.html#closing-outline-sections
No, I hadn't found that. Thanks. Those links answer my question.
Juan Manuel Macías wrote:
> It is an interesting question; however, I would say that this is not a
> useful or realistic structure. Regardless of the Org trees/subtrees and
> their folding ability (indicating that each thing is at a certain
> level), I think that a content will be more useful and intelligible if
> […]
I see your point.
Maybe it depends on how you use org-mode and how you imagine the meaning of the "*" items. I see some disagreement about this in the old threads that Max linked to. No need to rehash it deeply here again; I was just curious.
The way I'm using org-mode so far, I'm not exporting to other formats, and I can see a use for collapsible sections in the middle of a larger chunk of text. I can already kind of do it with a "-" list item, like this. (Or other things like code blocks, etc)
* Heading
Top Text
Top Text
- Sub
This can be hidden if I hit 'tab' key on "Sub".
More Top Text
More Top Text
If you view a "*" item as "book section", it's confusing. But if you view a "*" item as "collapsible thing", then it makes more sense.
^ permalink raw reply [relevance 5%]
* Re: text after sub headings?
2021-12-23 21:21 5% Robert Nikander
@ 2021-12-23 21:47 0% ` John Kitchin
2021-12-23 22:10 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: John Kitchin @ 2021-12-23 21:47 UTC (permalink / raw)
To: Robert Nikander; +Cc: org-mode-email
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
You can also use drawers (as an alternative to inline tasks) for
collapsible content.
Another potential is to use blocks. You can define your own kind of blocks,
or even just use an org block and it is collapsible.
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Thu, Dec 23, 2021 at 4:22 PM Robert Nikander <robert.nikander@icloud.com>
wrote:
> Max Nikulin wrote:
> > Have you seen the following and links therein?
> > https://orgmode.org/worg/org-faq.html#closing-outline-sections
>
> No, I hadn't found that. Thanks. Those links answer my question.
>
> Juan Manuel Macías wrote:
> > It is an interesting question; however, I would say that this is not a
> > useful or realistic structure. Regardless of the Org trees/subtrees and
> > their folding ability (indicating that each thing is at a certain
> > level), I think that a content will be more useful and intelligible if
> > […]
>
> I see your point.
>
> Maybe it depends on how you use org-mode and how you imagine the meaning
> of the "*" items. I see some disagreement about this in the old threads
> that Max linked to. No need to rehash it deeply here again; I was just
> curious.
>
> The way I'm using org-mode so far, I'm not exporting to other formats, and
> I can see a use for collapsible sections in the middle of a larger chunk of
> text. I can already kind of do it with a "-" list item, like this. (Or
> other things like code blocks, etc)
>
> * Heading
> Top Text
> Top Text
> - Sub
> This can be hidden if I hit 'tab' key on "Sub".
> More Top Text
> More Top Text
>
> If you view a "*" item as "book section", it's confusing. But if you view
> a "*" item as "collapsible thing", then it makes more sense.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2809 bytes --]
^ permalink raw reply [relevance 0%]
* Re: text after sub headings?
2021-12-23 21:21 5% Robert Nikander
2021-12-23 21:47 0% ` John Kitchin
@ 2021-12-23 22:10 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-23 22:10 UTC (permalink / raw)
To: Robert Nikander; +Cc: orgmode
Robert Nikander writes:
> If you view a "*" item as "book section", it's confusing. But if you
> view a "*" item as "collapsible thing", then it makes more sense.
I understand your use case. But I think in that context Org headings
would still be useful (at least they remind us at what level we're). For
example, some headings could be used for those parts with a tag
:not_a_heading:. I sometimes use something like that, and then I remove
those tagged headings on export or convert them to another type of
separator, it depends on the case:
* Top
Some text under “Top”
** A level-2 heading
Text under level-2 heading
** Another level-2 heading
Text under the second level-2 heading
* Some descriptive title :not_a_heading:
More text under “Top”
^ permalink raw reply [relevance 6%]
* Re: text after sub headings?
2021-12-23 20:27 8% ` Juan Manuel Macías
@ 2021-12-24 16:51 4% ` Max Nikulin
2021-12-24 20:17 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-24 16:51 UTC (permalink / raw)
To: emacs-orgmode
On 24/12/2021 03:27, Juan Manuel Macías wrote:
> Robert Nikander writes:
>
>> I see why this is not possible, given the text format of an org file.
>> But I am curious if people think it would be useful.
While considered isolated, vim feature "set foldmethod=marker" with
explicit open and closed markers ("{{{" and "}}}" by default) is more
flexible. There are at least 2 problems with Org: performance penalty
and rather reach lightweight markup, so a lot of marker variants are
busy already.
> Although we feel that our structure is very clear, our publisher will
> probably force us to include some kind of division into the texts marked
> with "??". I mean, it's not that easy to escape from the (graphical)
> levels, parts and chapters, even if it is by editorial imposition or for
> not confuse our readers. We can, for example, call Part II "Interlude",
> or add the first text marked with "??" after a graphic separation (some
> dashes, for example: ------). Although the literary structure is
> complex, its graphical representation always has limits:
Text books and magazines may contain insets (side notes), sometimes even
page-long ones. They present independent material that may be
interesting or useful in particular context or may be just skipped when
a reader is concentrated on main material. Such inset may be considered
as a heading that is inserted in the middle of another section. It may
have larger margins, smaller font, distinct font face, another
background color, box around or just rule at some side, so readers have
clear notion where it ends and main material continues.
Export filter may solve the problem by treating specially marked
headings as continuation of text.
Aside from export, it may be notes interspersed with deeper details
(debug logs, etc.) It would be nice to be able to switch between 2
reading modes: all details are collapsed to quickly skim through main
steps and conclusions or all details are open (in particular subtree).
Plain list items, #+begin_/#+end_ blocks may be folded, drawers may be
expanded but only individually. Besides list items, deeper nested
substructure may be a problem, e.g. neither of them may contain
headings. Using of such construct is not perfect but mostly bearable.
The following is not a feature request just some thoughts how to achieve
convenient reading without heading closing syntax.
In addition to current heading visibility cycle, there may be commands
increasing or decreasing "zoom level" for the whole document or for the
current subtree. Headings may have a "lense" property that may change
zoom level when such section becomes visible (absolute value or relative
adjustment in respect to parent, positive or negative). So in response
to "zoom in" command some headings are unfolded, some remains collapsed.
Visibility effect to some extent is similar to explicit end of subheading.
^ permalink raw reply [relevance 4%]
* Re: text after sub headings?
2021-12-24 16:51 4% ` Max Nikulin
@ 2021-12-24 20:17 5% ` Juan Manuel Macías
2021-12-25 13:15 4% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-24 20:17 UTC (permalink / raw)
To: orgmode
Max Nikulin writes:
> Text books and magazines may contain insets (side notes), sometimes
> even page-long ones. They present independent material that may be
> interesting or useful in particular context or may be just skipped
> when a reader is concentrated on main material. Such inset may be
> considered as a heading that is inserted in the middle of another
> section. It may have larger margins, smaller font, distinct font face,
> another background color, box around or just rule at some side, so
> readers have clear notion where it ends and main material continues.
This is complex layout, something that DTP programs (InDesign, Quark,
Scribus) do very well as they work on the concept of multiple threads of
connected text boxes. [offtopic: in LaTeX there is an attempt to emulate
that with the flowfram package, with obvious limitations. And the Sile
typesetting system is very interesting and promising, which tries to
combine the WYSIWYM style of TeX and the linked text boxes of DTP
programs: https://sile-typesetter.org/]. But --- returning to the
topic---, even so, there is always an underlying notion of hierarchy,
levels and dependency, which is what I was referring to: there is a
skeleton. I think that Org's system of trees and nodes, agnostic of any
typographic format, is enough to maintain that hierarchy. In fact, I
have some works with a very complex output starting simply from Org
(right now I'm with a trilingual edition, using flowfram: for example,
certain Org nodes are exported as flowfram boxes). Obviously, that can
also be done from XML (an example of a combination of xml and LuaTeX:
https://www.speedata.de/en/). But I think, perhaps in a somewhat
quixotic way, that Org has tremendous potential and can play very well
in that league. XML is more accurate; but Org is a great compendium of
resources.
^ permalink raw reply [relevance 5%]
* Re: text after sub headings?
2021-12-24 20:17 5% ` Juan Manuel Macías
@ 2021-12-25 13:15 4% ` Max Nikulin
2021-12-26 9:17 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-25 13:15 UTC (permalink / raw)
To: emacs-orgmode
On 25/12/2021 03:17, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> It may have larger margins, smaller font, distinct font face,
>> another background color, box around or just rule at some side, so
>> readers have clear notion where it ends and main material continues.
>
> This is complex layout, something that DTP programs (InDesign, Quark,
> Scribus) do very well as they work on the concept of multiple threads of
> connected text boxes.
It is not necessary complex layout. It is a decoration similar to
pictures in fiction books. Unlike figures such additions are not
strictly important to understand material. In printed form it is like
figures however. Insets are appropriate in particular places, but
tolerate some shift due to paging.
This particular examples has internal structure:
http://algorithmics.lsi.upc.edu/docs/Dasgupta-Papadimitriou-Vazirani.pdf#page=135
Book reader on small phone screen might require a tap to show all
additional material. On wide screen in may appear on margins and visible
by default. In Org it migh remain collapsed when heading is expanded
while text around is visible.
I have not worked with complex documents in DTP programs. In my opinion,
LaTeX deals much better with figures (plots, drawings) in scientific
papers than office software. When users complains that LaTeX puts at
their figures and table at the end of the document it usually means that
they copy-pasted markup explicitly forbidding most of usual places for
floats (e.g. page completely filled with figures).
It is possible to create insets in Org Mode document, but it is not
native support.
In a bit broader sense insets do not violates tree structure
- Branch: Section Heading
- Leaf: section text
- Branch: Inset section Heading
- Leaf: inset section text
- Branch: Inset Subsection Heading 1
- Leaf: Inset subsection 1 text
- Branch: Inset Subsection Heading 2
- Leaf: Inset subsection 2 text
- Leaf: section text continues
Another example when it is convenient to have text itermixed with
headings is notes. Tree structure is too rigid, particular note may be
appropriate to several topics. Important point that sometimes it is
better to have particular order within some topic, if ordering is not
required than all links may appear before subheadings. So not text is
put to one topic, other ones contains links. Ideally it should appear like
* Topic 2
some general notes
*** Note 2.1...
*** Note 2.2...
[[#note_from_other_topic1]]
contains some interesting details
*** Note 2.4...
[[#note_from_other_topic2]]
contains other interesting details
*** Note 2.6...
It would be nice to have links visually distinct from headings and there
is no real reason to collapse link if description text is just a couple
of line.
I do not ask to change anything. I admit that nobody has bright idea how
to properly implement it. I am just against statements that Org is ideal
in respect to sectioning and covers all use cases. My opinion that it is
limitation, there are some workarounds and trade-offs for each
particular case. Anyway there is no unambiguously better tool.
^ permalink raw reply [relevance 4%]
* Re: text after sub headings?
2021-12-25 13:15 4% ` Max Nikulin
@ 2021-12-26 9:17 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-26 9:17 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
Max Nikulin writes:
> It is not necessary complex layout. It is a decoration similar to
> pictures in fiction books. Unlike figures such additions are not
> strictly important to understand material. In printed form it is like
> figures however. Insets are appropriate in particular places, but
> tolerate some shift due to paging.
Generally, any scenario where graphic and textual content must be
distributed and managed is already complex layout. Although there are
several levels of complexity, and in many cases visual control is
necessary. In any case, TeX is not intended for (stricto sensu) layout
but for typesetting, which is where DTP programs often fail. This does
not mean that highly complex pages cannot be achieved in TeX, but the
strong point of TeX is the automation of processes and repeated
structures, while the strong point of DTP programs is visual layout
design, more focused on magazines, newspapers, posters, etc. There are
"intermediate places", and in TeX there are still unresolved issues. For
example: the possibility of working with independent text flows (for
example, create two parallel TeX processes: one for even pages and
another for odd pages) or grid typesetting (in LaTeX it is almost impossible
and in ConTeXt some advances have been made) although I am very critical
of the grid composition, which has become a plague lately.
Anyway, in order not to get too off the topic, here are a couple of
examples that I made (one of them with flowfram), exporting an inline
task to LaTeX through an ad hoc filter:
https://i.imgur.com/8ERXNWp.png
https://i.imgur.com/mpFRL9h.png
(code attached)
Best regards,
Juan Manuel
[-- Attachment #2: tests.org --]
[-- Type: application/vnd.lotus-organizer, Size: 16218 bytes --]
^ permalink raw reply [relevance 8%]
* Re: caption width in LateX export
@ 2021-12-27 7:41 10% ` Juan Manuel Macías
2021-12-27 9:09 12% ` Juan Manuel Macías
2021-12-27 12:53 6% ` Sebastian P. Luque
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27 7:41 UTC (permalink / raw)
To: Seb; +Cc: orgmode
Hi Seb
Seb writes:
> When exporting to LaTeX, is there a mechanism to make the figure
> captions as wide as the figure? In pure LaTeX, this can be easily
> accomplished by placing the figure inside a minipage environment.
> Using a special block, as in:
>
> \begin{minipage}{0.7\textwidth}
>
> #+CAPTION: looooooong caption.
> [[file_path]]
>
> \end{minipage}
>
> fails, as it seems impossible to pass arguments to the special block.
> Any tips welcome.
If you use the caption package (https://www.ctan.org/pkg/caption), you
can indicate in each figure the width of the caption. In this case, you
would have to introduce the code using raw latex via the `:caption'
property:
#+LaTeX_Header: \usepackage{caption}
#+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem ipsum dolor sit amet, consectetuer adipiscing elit}
#+ATTR_LaTeX: :width .3\linewidth
[[file_path]]
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: caption width in LateX export
2021-12-27 7:41 10% ` Juan Manuel Macías
@ 2021-12-27 9:09 12% ` Juan Manuel Macías
2021-12-27 12:53 6% ` Sebastian P. Luque
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27 9:09 UTC (permalink / raw)
To: Seb; +Cc: orgmode
P.S.: I have come up with another possibility, more automatic, on the
LaTeX side, if you compile with LuaTeX. This thread
(https://tex.stackexchange.com/questions/202046/width-of-the-caption-of-a-figure),
where someone proposes to use a \savebox for concrete images, gave me
the idea. We can automate that through a simple function in Lua, and add
it to the `process_input_buffer' callback, in order to the caption
*always* has the width of each image:
You can put this in your Org document:
#+NAME: luacode
#+begin_src latex :exports none
\usepackage{luacode}
\begin{luacode*}
function caption_width ( text )
text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
text = string.gsub ( text, "(\\caption{.+})", "\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
return text
end
\end{luacode*}
\newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}
\AtBeginDocument{\CaptionAutoWidth}
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<luacode>>
#+end_src
And then:
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit
#+ATTR_LaTeX: :width .3\linewidth
[[img]]
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case, you
> would have to introduce the code using raw latex via the `:caption'
> property:
>
> #+LaTeX_Header: \usepackage{caption}
>
> #+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem ipsum dolor sit amet, consectetuer adipiscing elit}
> #+ATTR_LaTeX: :width .3\linewidth
> [[file_path]]
^ permalink raw reply [relevance 12%]
* Re: caption width in LateX export
2021-12-27 7:41 10% ` Juan Manuel Macías
2021-12-27 9:09 12% ` Juan Manuel Macías
@ 2021-12-27 12:53 6% ` Sebastian P. Luque
2021-12-27 13:28 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Sebastian P. Luque @ 2021-12-27 12:53 UTC (permalink / raw)
To: emacs-orgmode
On Mon, 27 Dec 2021 07:41:59 +0000,
Juan Manuel Macías <maciaschain@posteo.net> wrote:
[...]
> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case,
> you would have to introduce the code using raw latex via the
> `:caption' property:
> #+LaTeX_Header: \usepackage{caption}
> #+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem
> ipsum dolor sit amet, consectetuer adipiscing elit} #+ATTR_LaTeX:
> :width .3\linewidth [[file_path]]
Thank you, Juan. Unfortunately, there is a price for this solution as
it is now impossible to name and refer to this segment as usual:
#+LATEX_HEADER: \usepackage{caption}
See [[fig1]].
#+NAME: fig1
#+ATTR_LATEX: :caption \captionsetup{width=0.5\textwidth}\caption{Lorem ipsum dolor sit amet, consectetuer adipiscing elit}
[[file_path]]
leads to this (I compile with latexmk):
Latexmk: Summary of warnings from last run of *latex:
Latex failed to resolve 1 reference(s)
--
Seb
^ permalink raw reply [relevance 6%]
* Re: caption width in LateX export
2021-12-27 12:53 6% ` Sebastian P. Luque
@ 2021-12-27 13:28 8% ` Juan Manuel Macías
2021-12-27 17:16 6% ` Sebastian P. Luque
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-27 13:28 UTC (permalink / raw)
To: Sebastian P. Luque; +Cc: orgmode
Sebastian P. Luque writes:
> Thank you, Juan. Unfortunately, there is a price for this solution as
> it is now impossible to name and refer to this segment as usual:
I see. Have you tried the option with LuaTeX that I put in my other
message? You can compile with LuaTeX also using latexmk:
(setq org-latex-pdf-process
'("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape %%S/' %f"))
In any case, since this is a simple substitution, you can use also a
function in Elisp as a final output filter[1]:
#+BIND: org-export-filter-final-output-functions (caption-auto-width)
#+begin_src emacs-lisp :exports results :results none
(defun caption-auto-width (text backend info)
(when (org-export-derived-backend-p backend 'latex)
(with-temp-buffer
(insert text)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\(\\\\includegraphics.+\\)" nil t)
(replace-match "\\\\sbox0{\\1}" t nil)))
(save-excursion
(goto-char (point-min))
(while (re-search-forward "\\(\\\\caption.+\\)" nil t)
(replace-match "\\\\begin{minipage}{\\\\wd0}\\\\usebox0\\1\\\\end{minipage}" t nil)))
(setq text (buffer-string)))))
#+end_src
Vid. [[fig:1]]
#+NAME: fig:1
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus
#+ATTR_LaTeX: :width .3\linewidth
[[my-image.jpg]]
[1] You need to set this variable as non-nil, in order to use bind
keywords: (setq org-export-allow-bind-keywords t)
Hope this works,
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: caption width in LateX export
2021-12-27 13:28 8% ` Juan Manuel Macías
@ 2021-12-27 17:16 6% ` Sebastian P. Luque
2021-12-27 19:28 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Sebastian P. Luque @ 2021-12-27 17:16 UTC (permalink / raw)
To: emacs-orgmode
On Mon, 27 Dec 2021 13:28:08 +0000,
Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Sebastian P. Luque writes:
>> Thank you, Juan. Unfortunately, there is a price for this solution
>> as it is now impossible to name and refer to this segment as usual:
> I see. Have you tried the option with LuaTeX that I put in my other
> message? You can compile with LuaTeX also using latexmk:
> (setq org-latex-pdf-process '("latexmk -lualatex -e
> '$lualatex=q/lualatex %%O -shell-escape %%S/' %f"))
I haven't tried this yet, but it's great to know latexmk can use LuaTex.
> In any case, since this is a simple substitution, you can use also a
> function in Elisp as a final output filter[1]:
> #+BIND: org-export-filter-final-output-functions (caption-auto-width)
> #+begin_src emacs-lisp :exports results :results none
> (defun caption-auto-width (text backend info) (when
> (org-export-derived-backend-p backend 'latex) (with-temp-buffer
> (insert text) (save-excursion (goto-char (point-min)) (while
> (re-search-forward "\\(\\\\includegraphics.+\\)" nil t) (replace-match
> "\\\\sbox0{\\1}" t nil))) (save-excursion (goto-char (point-min))
> (while (re-search-forward "\\(\\\\caption.+\\)" nil t) (replace-match
> "\\\\begin{minipage}{\\\\wd0}\\\\usebox0\\1\\\\end{minipage}" t nil)))
> (setq text (buffer-string))))) #+end_src
> Vid. [[fig:1]]
> #+NAME: fig:1 #+CAPTION: Lorem ipsum dolor sit amet, consectetuer
> adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere
> tellus
> #+ATTR_LaTeX: :width .3\linewidth [[my-image.jpg]]
> [1] You need to set this variable as non-nil, in order to use bind
> keywords: (setq org-export-allow-bind-keywords t)
> Hope this works,
This is great, and very interesting to learn about the BIND keyword.
Thank you,
--
Seb
^ permalink raw reply [relevance 6%]
* Re: caption width in LateX export
2021-12-27 17:16 6% ` Sebastian P. Luque
@ 2021-12-27 19:28 5% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27 19:28 UTC (permalink / raw)
To: orgmode
Sebastian P. Luque writes:
> This is great, and very interesting to learn about the BIND keyword.
>
> Thank you,
You're welcome. Of course, if you use the filter very often, it is not
necessary to include it in a document or use the bind keyword. It
would be enough to add the function to your init and the line:
(add-to-list 'org-export-filter-final-output-functions #'caption-auto-width)
In a case like this, however, I would prefer to use the other function
in Lua within LuaTeX, since two commands could be defined: one to enable
the automatic caption width and one to disable it, throughout the
document. E.g.:
#+begin_src latex
\usepackage{luacode}
\begin{luacode*}
function caption_width ( text )
text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
text = string.gsub ( text, "(\\caption.+)", "\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
return text
end
\end{luacode*}
\newcommand\CaptionAutoWidthOn{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}
\newcommand\CaptionAutoWidthOff{\directlua{luatexbase.remove_from_callback
( "process_input_buffer" , "caption_width" )}}
#+end_src
\CaptionAutoWidthOn
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus
#+ATTR_LaTeX: :width .3\linewidth
[[img.jpg]]
\CaptionAutoWidthOff
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus
#+ATTR_LaTeX: :width .1\linewidth
[[img.jpg]]
^ permalink raw reply [relevance 5%]
* [BUG] Underlined text in parentheses is not exported correctly
@ 2021-12-31 10:14 10% Juan Manuel Macías
2021-12-31 11:08 12% ` Juan Manuel Macías
2021-12-31 11:13 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-31 10:14 UTC (permalink / raw)
To: orgmode
Hi all,
I don't know if this is a known issue...
Consider the text:
(_underline_)
When exported to LaTeX we get:
(\textsubscript{underline}\_)
And to HTML:
(<sub>underline</sub>_)
The same result with:
(_underline_ text)
LaTeX:
(\textsubscript{underline}\_ text)
But this:
(this word is _underline_)
is exported correctly:
(this word is \uline{underline})
If I do M-! (occur org-match-substring-regexp)
I get:
10:(_underline_)
22:(_underline_ text)
Best regards, and happy New Year,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [BUG] Underlined text in parentheses is not exported correctly
2021-12-31 10:14 10% [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
@ 2021-12-31 11:08 12% ` Juan Manuel Macías
2021-12-31 11:13 5% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-31 11:08 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> If I do M-! (occur org-match-substring-regexp)
>
> I get:
>
> 10:(_underline_)
> 22:(_underline_ text)
Well, in my case the temporary workaround was to force super/subscripts
with braces:
#+begin_src emacs-lisp
(defun my-org-element-subscript-with-braces-parser ()
(save-excursion
(unless (bolp) (backward-char))
(when (looking-at org-match-substring-with-braces-regexp)
(let ((bracketsp (match-beginning 4))
(begin (match-beginning 2))
(contents-begin (or (match-beginning 4)
(match-beginning 3)))
(contents-end (or (match-end 4) (match-end 3)))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point)))
(list 'subscript
(list :begin begin
:end end
:use-brackets-p bracketsp
:contents-begin contents-begin
:contents-end contents-end
:post-blank post-blank))))))
(advice-add 'org-element-subscript-parser :override #'my-org-element-subscript-with-braces-parser)
#+end_src
^ permalink raw reply [relevance 12%]
* Re: [BUG] Underlined text in parentheses is not exported correctly
2021-12-31 10:14 10% [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
2021-12-31 11:08 12% ` Juan Manuel Macías
@ 2021-12-31 11:13 5% ` Ihor Radchenko
2021-12-31 11:31 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-31 11:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I don't know if this is a known issue...
>
> Consider the text:
>
> (_underline_)
I am not sure if it is an actual issue.
Note that (_u can be interpreted as a subscript.
Org prioritises subscript over underline.
Looking at the code:
(?_ (or (and (memq 'subscript restriction)
(org-element-subscript-parser))
(and (memq 'underline restriction)
(org-element-underline-parser))))
The priority appears to be intentional.
Unless Nicolas (the author of this code) sees anything wrong here, I
recommend you to use zero-width space in front of the first _ to make
sure that you obtain underline, not subscripts (see
https://orgmode.org/manual/Escape-Character.html#Escape-Character)
P.S.
Note that the fontification you observe in Org is wrong. It is not how
the actual exporter sees the text. I am sorry about this. Fixing the
fontification is a work-in-progress.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: [BUG] Underlined text in parentheses is not exported correctly
2021-12-31 11:13 5% ` Ihor Radchenko
@ 2021-12-31 11:31 10% ` Juan Manuel Macías
2021-12-31 14:43 4% ` [PATCH] " Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-31 11:31 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> I am not sure if it is an actual issue.
>
> Note that (_u can be interpreted as a subscript.
> Org prioritises subscript over underline.
>
> Looking at the code:
>
> (?_ (or (and (memq 'subscript restriction)
> (org-element-subscript-parser))
> (and (memq 'underline restriction)
> (org-element-underline-parser))))
>
> The priority appears to be intentional.
I see. But then the compatibility with the rest of the emphasis is
broken. I mean, the user would expect things like (_underline_) will be
exported as (\uline{underline}), in the same way that (/emphasis/) is
exported as (\emph{emphasis}). I would say there is a slight
inconsistency in the syntax here.
Anyway, in my case I have solved it by always forcing the
super/sub-scripts with brackets overriding `org-element-subscript-parser'
(I never use them without brackets), as I mentioned in my previous
message.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [PATCH] Re: [BUG] Underlined text in parentheses is not exported correctly
2021-12-31 11:31 10% ` Juan Manuel Macías
@ 2021-12-31 14:43 4% ` Ihor Radchenko
2022-01-01 11:28 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-31 14:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The priority appears to be intentional.
>
> I see. But then the compatibility with the rest of the emphasis is
> broken. I mean, the user would expect things like (_underline_) will be
> exported as (\uline{underline}), in the same way that (/emphasis/) is
> exported as (\emph{emphasis}). I would say there is a slight
> inconsistency in the syntax here.
I agree with you. I think that the initial intention was to avoid
parsing things like (x+y)_1+x_2 as underline.
However, thinking about it more, I feel that prioritising underline
should work better. The underline parser recently got changed into a
stricter version. Now, only underlines starting after spaces,-,(,',",
and { are recognised as an underlines.
So, the attached patch is changing the priority of the parsing.
Maybe Nicolas knows some tricky cases when the patch makes things wrong,
but those cases are certainly not covered by tests.
Best,
Ihor
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-underline-parser-inside-parenthesis.patch --]
[-- Type: text/x-diff, Size: 2454 bytes --]
From 12272f1ea89c169dcbece009c3a227e354019366 Mon Sep 17 00:00:00 2001
Message-Id: <12272f1ea89c169dcbece009c3a227e354019366.1640961654.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Fri, 31 Dec 2021 22:39:03 +0800
Subject: [PATCH] Fix underline parser inside parenthesis
* lisp/org-element.el (org-element--object-lex): prioritise underline
parser over subscript. `org-element-underline-parser' is more strict
compared to `org-element-subscript-parser'.
* testing/lisp/test-org-element.el (test-org-element/underline-parser):
Add test.
Fixes https://list.orgmode.org/87v8z52eom.fsf@posteo.net/T/#t
---
lisp/org-element.el | 8 ++++----
testing/lisp/test-org-element.el | 11 ++++++++++-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 45ddc79b7..c9d1d80bb 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4850,10 +4850,10 @@ (defun org-element--object-lex (restriction)
(pcase (char-after)
(?^ (and (memq 'superscript restriction)
(org-element-superscript-parser)))
- (?_ (or (and (memq 'subscript restriction)
- (org-element-subscript-parser))
- (and (memq 'underline restriction)
- (org-element-underline-parser))))
+ (?_ (or (and (memq 'underline restriction)
+ (org-element-underline-parser))
+ (and (memq 'subscript restriction)
+ (org-element-subscript-parser))))
(?* (and (memq 'bold restriction)
(org-element-bold-parser)))
(?/ (and (memq 'italic restriction)
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 338204eab..b58d71c8c 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2661,7 +2661,16 @@ (ert-deftest test-org-element/underline-parser ()
(org-test-with-temp-text "_first line\nsecond line_"
(org-element-map
(org-element-parse-buffer) 'underline #'identity nil t)))
- '("first line\nsecond line"))))
+ '("first line\nsecond line")))
+ ;; Starting after non-blank
+ (should
+ (eq 'underline
+ (org-test-with-temp-text "(_under<point>line_)"
+ (org-element-type (org-element-context)))))
+ (should-not
+ (eq 'underline
+ (org-test-with-temp-text "x_under<point>line_)"
+ (org-element-type (org-element-context))))))
;;;; Verbatim
--
2.32.0
^ permalink raw reply related [relevance 4%]
* Re: [PATCH] Re: [BUG] Underlined text in parentheses is not exported correctly
2021-12-31 14:43 4% ` [PATCH] " Ihor Radchenko
@ 2022-01-01 11:28 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-01 11:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> However, thinking about it more, I feel that prioritising underline
> should work better. The underline parser recently got changed into a
> stricter version. Now, only underlines starting after spaces,-,(,',",
> and { are recognised as an underlines.
>
> So, the attached patch is changing the priority of the parsing.
> Maybe Nicolas knows some tricky cases when the patch makes things wrong,
> but those cases are certainly not covered by tests.
Great! I vote for this patch, I think it is a necessary addition. In my
case I have not found any error.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Raw Org AST snippets for "impossible" markup
2021-12-09 22:27 12% ` Juan Manuel Macías
@ 2022-01-03 14:34 3% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-01-03 14:34 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]
On 10/12/2021 05:27, Juan Manuel Macías wrote:
> Juan Manuel Macías writes:
>
>> Jumping into the "real world", how about these two examples of nested emphasis?
>
> By the way, what do you think about allowing the use of some kind of
> aliases, so that the aspect is less verbose?
I have no particular opinion concerning aliases, but certainly they
should not work through string search and replace when parsed tree is
available.
> (defun orgia--transform-path (path)
> (with-temp-buffer
> (insert path)
> (mapc (lambda (el)
> (orgia-replace (concat "(" (car el) "::") (concat "(" (cadr el) " () ")))
By the way, is there any problem with `replace-regexp-in-string'?
See the attached file for definitions of some helper functions. Final setup:
#+begin_src elisp :results silent
(setq orgia-demo-alias-alist
'((b . bold)
(i . italic)
(s . strike-through)
(_ . underline)))
(defun orgia-demo-alias-post-filter (node &optional _children)
(when (listp node)
(let ((sym (and (symbolp (car node))
(assq (car node) orgia-demo-alias-alist))))
(when sym
(setcar node (cdr sym)))))
node)
(defun orgia-demo-alias (tree)
(orgia-transform-tree-deep tree nil #'orgia-demo-alias-post-filter))
#+end_src
#+begin_src elisp :results silent
(require 'ox)
(add-to-list 'org-export-filter-parse-tree-functions
#'orgia-parse-tree-filter)
(org-link-set-parameters "orgia")
(require 'ob-org)
(add-to-list 'orgia-transform-functions #'orgia-demo-alias)
#+end_src
And a bit modified your test sample:
#+begin_src org :results latex :results replace
[[orgia:(i nil "The English versions of the " (b nil (i () "Iliad"))
" and the " (b () (i ()
"Odyssey")))]]
#+end_src
#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the
\textbf{\emph{Odyssey}}}
#+end_export
[-- Attachment #2: orgia-draft.el --]
[-- Type: text/x-emacs-lisp, Size: 2080 bytes --]
(defvar orgia-transform-functions nil)
(defun orgia-default-pre-filter (node)
"Returns (node . children)"
(if (listp node)
(cons node node)
(cons node nil)))
(defun orgia-transform-tree-deep (tree &optional pre-filter post-filter)
"Deep-first walk."
;; Queue items: ((node-cell . children) . next-list)
(let* ((pre-filter (or pre-filter #'orgia-default-pre-filter))
(top (list tree))
(queue (list (cons (cons top top) top))))
(while queue
(let* ((item (pop queue))
(next-list (cdr item)))
(if (not next-list)
;; post; skip POST-FILTER for the list wrapping TREE
(when (and queue post-filter)
(let* ((node-cell-children (car item))
(children (cdr node-cell-children)))
(setcar (car node-cell-children)
(funcall post-filter
(caar node-cell-children)
children))))
;; pre
(setcdr item (cdr next-list))
(push item queue)
(let* ((node-children
(funcall pre-filter (car next-list)))
(node (car node-children))
(children (cdr node-children)))
(setcar next-list node)
(push (cons (cons next-list children) children) queue)))))
(car top)))
(defun orgia-element-replace (current new destructive?)
(if (eq current new)
current
(let* ((lst? (and (listp new) (not (symbolp (car new)))))
(new-lst (if lst?
(if destructive? (nconc new) (reverse new))
(list new))))
(dolist (element new-lst)
(org-element-insert-before element current)))
(org-element-extract-element current)
new))
(defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
(let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
(let ((tree (read path)))
(dolist (f orgia-transform-functions tree)
(setq tree (funcall f tree))))))))
(defun orgia-parse-tree-filter (data _backend info)
(org-element-map data 'link
(lambda (data)
(orgia-element-replace data (orgia--transform-link data) t))
info nil nil t)
data)
^ permalink raw reply [relevance 3%]
* A simple Lua filter for Pandoc
@ 2022-01-04 10:14 9% Juan Manuel Macías
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-04 10:14 UTC (permalink / raw)
To: orgmode
Hi,
Very often I need to convert docx documents to Org. There are a series
of characters that I prefer to be passed to Org as Org entities and not
literally, so I have written this little filter in Lua for Pandoc. I
share it here in case it could be useful to someone. Of course, the
associative table can be expanded with more replacement cases:
#+begin_src lua :tangle entities.lua
local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
[">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = "\\nbsp{}"}
function Str (elem)
x = elem.text:match 'http[^%s]'
if not x then
for i in pairs(chars) do
elem = pandoc.Str(elem.text:gsub (i, chars[i]))
end
return elem
end
end
#+end_src
And a quick test:
#+begin_src sh :results org
str="/ † * < > http://foo.es "
pandoc -f markdown -t org --lua-filter=entities.lua <<< $str
#+end_src
#+RESULTS:
#+begin_src org
\slash{} \dagger{} \lowast{} \lt{} \gt{} http://foo.es \nbsp{}
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: A simple Lua filter for Pandoc
2022-01-04 10:14 9% A simple Lua filter for Pandoc Juan Manuel Macías
@ 2022-01-04 14:05 6% ` Max Nikulin
2022-01-04 15:06 5% ` Juan Manuel Macías
2022-01-04 16:28 6% ` Thomas S. Dye
2 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-01-04 14:05 UTC (permalink / raw)
To: emacs-orgmode
On 04/01/2022 17:14, Juan Manuel Macías wrote:
>
> Very often I need to convert docx documents to Org. ...
>
> local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
> [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = "\\nbsp{}"}
> ...
> pandoc -f markdown -t org --lua-filter=entities.lua <<< $str
Ideally it should be done pandoc and only if it causes incorrect parsing
of org markup. NBSP, probably, should be replaced by some exporters, I
do not think, it is a problem e.g. in HTML files.
^ permalink raw reply [relevance 6%]
* Re: A simple Lua filter for Pandoc
@ 2022-01-04 15:11 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-04 15:11 UTC (permalink / raw)
To: orgmode
Hi Timothy:
Timothy writes:
> I’m quite interested in this, thanks for sharing. In fact, I’ll probably add
> this to <https://github.com/tecosaur/org-pandoc-import>.
Interesting package. Until now I used a number of homemade functions to
convert docx/odt files from Dired, but I think your package will be very
useful to me ;-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: A simple Lua filter for Pandoc
2022-01-04 14:05 6% ` Max Nikulin
@ 2022-01-04 15:06 5% ` Juan Manuel Macías
2022-01-05 16:29 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-04 15:06 UTC (permalink / raw)
To: orgmode
Max Nikulin writes:
> Ideally it should be done pandoc and only if it causes incorrect
> parsing of org markup. NBSP, probably, should be replaced by some
> exporters, I do not think, it is a problem e.g. in HTML files.
The reason for this filter is my own comfort. Linguistics texts contains
a lot of certain characters such as "/" or "*", and they are often
italicized or bold. So, in order not to be more confused than necessary,
I prefer that they pass as entities. In general, there are certain
characters that I am more comfortable working with as entities than as
literal characters (for example, a lot of zero-width combining
diacritics that are used a lot in linguistics or epigraphy (and there
are no fonts that include the NFC normalized version of all possible
combinations: in fact, they are not in Unicode, and would have to go to
the private use area). Summarizing, I prefer that these characters have
their actual typographic representation only with LuaTeX. A very typical
example is the character U+0323 (COMBINING DOT BELOW). It is very
uncomfortable to work /in situ/, although there are fonts that usually
render it well (with the 'mark' otf tag).
(Naturally, I have to do, inside Org, a lot of corrections in italics
later, due to the bad habit that Word users have of applying direct
formatting. Interestingly only the pandoc docx reader trims the emphasis
before exporting to Org or Markdown, so as not to produce things like
"/ foo /". But the odt reader doesn't. I don't know if I'm missing
something.
^ permalink raw reply [relevance 5%]
* Re: A simple Lua filter for Pandoc
2022-01-04 10:14 9% A simple Lua filter for Pandoc Juan Manuel Macías
2022-01-04 14:05 6% ` Max Nikulin
@ 2022-01-04 16:28 6% ` Thomas S. Dye
2 siblings, 0 replies; 200+ results
From: Thomas S. Dye @ 2022-01-04 16:28 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> Very often I need to convert docx documents to Org. There are a
> series
> of characters that I prefer to be passed to Org as Org entities
> and not
> literally, so I have written this little filter in Lua for
> Pandoc. I
> share it here in case it could be useful to someone. Of course,
> the
> associative table can be expanded with more replacement cases:
>
> #+begin_src lua :tangle entities.lua
> local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}",
> ["<"] = "\\lt{}",
> [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)]
> = "\\nbsp{}"}
>
> function Str (elem)
> x = elem.text:match 'http[^%s]'
> if not x then
> for i in pairs(chars) do
> elem = pandoc.Str(elem.text:gsub (i, chars[i]))
> end
> return elem
> end
> end
> #+end_src
Neat! Converting Word documents is no fun at all.
BTW, Babel support for Lua isn't very good AFAICT. I poked around
ob-lua.el recently and concluded that one problem is that the Lua
interpreter prints pointers for some data types instead of a
human-readable form that might be parsed.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 6%]
* Re: Tool to compare and choose fonts
@ 2022-01-05 10:16 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-05 10:16 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> Was a tool to compare fonts presented in this list some time ago?
>
> I lost it, I thought I discovered it on Reddit, but now I am thinking
> I found it here.
>
> It was a script that presented on emacs every font in the computer, in
> pairs; so the user chose one font each time, like if it were a
> "championship" between fonts.
https://github.com/alphapapa/unpackaged.el#font-compare
Outside of Emacs there are many tools for auditing fonts. In TeX live
you have the otfinfo script, for example, very useful. And recently the
Unicode Font Table package has been uploaded to CTAN, to represent
character tables in (Lua/Xe)LaTeX:
https://www.ctan.org/pkg/unicodefonttable
(an example that I have done inside Org, using LaTeX blocks:
https://i.imgur.com/eiiAUlB.png)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: A simple Lua filter for Pandoc
2022-01-04 15:06 5% ` Juan Manuel Macías
@ 2022-01-05 16:29 5% ` Max Nikulin
2022-01-05 17:08 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-01-05 16:29 UTC (permalink / raw)
To: orgmode; +Cc: Tom Gillespie
On 04/01/2022 22:06, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> Ideally it should be done pandoc and only if it causes incorrect
>> parsing of org markup. NBSP, probably, should be replaced by some
>> exporters, I do not think, it is a problem e.g. in HTML files.
>
> The reason for this filter is my own comfort. Linguistics texts contains
> a lot of certain characters such as "/" or "*", and they are often
> italicized or bold. So, in order not to be more confused than necessary,
> I prefer that they pass as entities.
It seems, lightweight markup is more annoyance than advantage for you.
Tom posted some thoughts on more rigorous syntax in the following message:
Tom Gillespie. Re: Org-syntax: Intra-word markup.
Sat, 4 Dec 2021 09:53:11 -0800.
https://list.orgmode.org/CA+G3_PNca3HY6TUDPMfHGt35Amj9a-y8dBNQo+ZvBOV6y3nHYw@mail.gmail.com
For C and C++ it is possible to tune some aspects of compiler behavior using
#pragma something
directives. In some cases it might be convenient to e.g. temporary
disable emphasis markers (or switch to more verbose alternative) through
#+some: keyword
> In general, there are certain
> characters that I am more comfortable working with as entities than as
> literal characters (for example, a lot of zero-width combining
> diacritics that are used a lot in linguistics or epigraphy (and there
> are no fonts that include the NFC normalized version of all possible
> combinations: in fact, they are not in Unicode, and would have to go to
> the private use area). Summarizing, I prefer that these characters have
> their actual typographic representation only with LuaTeX. A very typical
> example is the character U+0323 (COMBINING DOT BELOW). It is very
> uncomfortable to work /in situ/, although there are fonts that usually
> render it well (with the 'mark' otf tag).
I have seen warnings concerning complications due to variants of
character representation, but I have no experience such nuances (either
typing and editing or processing text programmatically). Dagger and
non-breaking space in your code snippet were much more simpler cases.
^ permalink raw reply [relevance 5%]
* Re: A simple Lua filter for Pandoc
2022-01-05 16:29 5% ` Max Nikulin
@ 2022-01-05 17:08 9% ` Juan Manuel Macías
2022-01-07 14:29 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-05 17:08 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> It seems, lightweight markup is more annoyance than advantage for you.
> Tom posted some thoughts on more rigorous syntax in the following message:
It's generally the opposite: working in Org is a pleasant journey for
me... except when there are dozens of "/" and "*" in a document, and
they placed in 'unhappy' positions. For example, in phonetics the
"/ ... /" notation is used a lot, and there may be cases like:
#+begin_example
/foo/ /bar/ /baz/
#+end_example
In grammar the asterisk is also used a lot, to designate that a term is
not attested or to indicate that it is ungrammatical:
#+begin_example
*foo *bar *baz
#+end_example
And we can even have the combination of both:
#+begin_example
/*foo/ /*bar/ /*baz/
#+end_example
And in certain cases, they are usually expressed in italics. With these
landscapes, it's worth having a few entities rather than working from
pure LaTeX, which is more accurate, but horribly more verbose.
This is a page from a book I typesetted a couple of years ago (when the
pandemic started), entirely from Org:
https://i.imgur.com/f6X7qLs.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Way to mark contents of an Org special block as verbatim?
@ 2022-01-06 18:27 9% ` Juan Manuel Macías
2022-01-06 19:14 5% ` Kaushal Modi
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-06 18:27 UTC (permalink / raw)
To: Kaushal Modi; +Cc: orgmode
Hi Kaushal,
Kaushal Modi writes:
> I would like to treat that block /like/ how Org treats the latex
> environment blocks, but it needs to be a special block as
> begin_katex/end_katex here is special and it could be a different
> equation rendering backend for another user.
>
> So is that a header switch or arg that can be passed on to this
> special block that enables the verbatim mode (prevent Org from
> replacing the Org entities, do the sub/superscript expansion, etc.)?
I think one possibility would be using a parse tree export filter:
#+BIND: org-export-filter-parse-tree-functions (katex-verbatim)
#+begin_src emacs-lisp :exports results :results none
(defun katex-verbatim (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'special-block
(lambda (block)
(when (equal "katex" (org-element-property :type block))
(let ((cont (org-element-interpret-data (org-element-contents block)))
(create-export-snippet ;; idea from Nicolas Goaziou
(lambda (v)
(org-element-create 'export-snippet (list :back-end "latex" :value v)))))
(apply #'org-element-set-contents
block
(list (funcall create-export-snippet cont))))))
info)
tree))
#+end_src
#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex
==>
\begin{katex}
E = -J \sum_{i=1}^N s_i s_{i+1}
\end{katex}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Way to mark contents of an Org special block as verbatim?
2022-01-06 18:27 9% ` Juan Manuel Macías
@ 2022-01-06 19:14 5% ` Kaushal Modi
2022-01-06 19:33 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Kaushal Modi @ 2022-01-06 19:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Thu, Jan 6, 2022 at 1:27 PM Juan Manuel Macías
<maciaschain@posteo.net> wrote:
> I think one possibility would be using a parse tree export filter:
>
> #+BIND: org-export-filter-parse-tree-functions (katex-verbatim)
> #+begin_src emacs-lisp :exports results :results none
> (defun katex-verbatim (tree backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (org-element-map tree 'special-block
> (lambda (block)
> (when (equal "katex" (org-element-property :type block))
> (let ((cont (org-element-interpret-data (org-element-contents block)))
> (create-export-snippet ;; idea from Nicolas Goaziou
> (lambda (v)
> (org-element-create 'export-snippet (list :back-end "latex" :value v)))))
> (apply #'org-element-set-contents
> block
> (list (funcall create-export-snippet cont))))))
> info)
> tree))
> #+end_src
>
> #+begin_katex
> E = -J \sum_{i=1}^N s_i s_{i+1}
> #+end_katex
>
> ==>
>
> \begin{katex}
> E = -J \sum_{i=1}^N s_i s_{i+1}
> \end{katex}
Wow, thanks for that complete code. I didn't know about the parse tree
functions.
I was thinking if below is possible as any user running my exporter
would need to use this feature easily.
#+begin_katex :verbatim t
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex
Is it possible to do anything inside the org-hugo-special-block
function that's defined in the exporter?
^ permalink raw reply [relevance 5%]
* Re: Way to mark contents of an Org special block as verbatim?
2022-01-06 19:14 5% ` Kaushal Modi
@ 2022-01-06 19:33 6% ` Juan Manuel Macías
2022-01-06 19:46 5% ` Kaushal Modi
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-06 19:33 UTC (permalink / raw)
To: Kaushal Modi; +Cc: orgmode
Kaushal Modi writes:
> Wow, thanks for that complete code. I didn't know about the parse tree
> functions.
>
> I was thinking if below is possible as any user running my exporter
> would need to use this feature easily.
>
> #+begin_katex :verbatim t
> E = -J \sum_{i=1}^N s_i s_{i+1}
> #+end_katex
I just realized that there is a much simpler solution for your katex
environment :-)
You can use an example block, and define your custom environment using
the attribute :environment
#+ATTR_LaTeX: :environment katex
#+begin_example
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_example
^ permalink raw reply [relevance 6%]
* Re: Way to mark contents of an Org special block as verbatim?
2022-01-06 19:33 6% ` Juan Manuel Macías
@ 2022-01-06 19:46 5% ` Kaushal Modi
2022-01-08 21:52 0% ` Berry, Charles
0 siblings, 1 reply; 200+ results
From: Kaushal Modi @ 2022-01-06 19:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Thu, Jan 6, 2022 at 2:33 PM Juan Manuel Macías
<maciaschain@posteo.net> wrote:
> I just realized that there is a much simpler solution for your katex
> environment :-)
>
> You can use an example block, and define your custom environment using
> the attribute :environment
Sorry, but this exporter is derived from md, and before exporting the
verbatim body of the special block needs to be surrounded with some
special syntax, with some optional stuff that the user specifies. Also
it could any special block name:
- katex
- tikz
- tikzjax
In any case, if user has this in Org:
#+begin_FOO
<body verbatim>
#+end_FOO
I need to export:
{{< FOO custom stuff >}}
<body verbatim>
{{< /FOO >}}
^ permalink raw reply [relevance 5%]
* Filter to put decorative initial letters
@ 2022-01-07 0:41 9% Juan Manuel Macías
2022-01-11 0:43 6% ` William Denton
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-07 0:41 UTC (permalink / raw)
To: orgmode
Hi,
These past holidays I've been experimenting with some little useful, but
fun stuff. This is an export filter to put a decorative initial letter
in the first paragraphs of the first level sections, using the LaTeX
package lettrine (https://www.ctan.org/pkg/lettrine).
A screenshot: https://i.imgur.com/mLQVHFC.png
#+BIND: org-export-filter-parse-tree-functions (lettrine)
#+begin_src emacs-lisp :exports results :results none
(defun lettrine (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'headline
(lambda (section)
(when (eq 1 (org-element-property :level section))
(let* ((contents (org-element-interpret-data (org-element-contents section)))
(lettrine-opt (org-export-get-node-property :LETTRINE_OPTIONS section t))
(contents-lettrine (with-temp-buffer
(insert contents)
(save-excursion
(goto-char (point-min))
(re-search-forward "\\(\\b.\\)\\([^\s]+\\b\\)" nil t)
(replace-match (concat "\\\\lettrine"
(if lettrine-opt (format "[%s]"
lettrine-opt) "")
"{" "\\1" "}" "{" "\\2" "}")
t nil)
(org-element-parse-buffer)))))
(apply #'org-element-set-contents
section
(list contents-lettrine)))))
info)
tree))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: A simple Lua filter for Pandoc
2022-01-05 17:08 9% ` Juan Manuel Macías
@ 2022-01-07 14:29 5% ` Max Nikulin
2022-01-07 15:14 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2022-01-07 14:29 UTC (permalink / raw)
To: emacs-orgmode
On 06/01/2022 00:08, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> It seems, lightweight markup is more annoyance than advantage for you.
>> Tom posted some thoughts on more rigorous syntax in the following message:
>
> It's generally the opposite: working in Org is a pleasant journey for
> me... except when there are dozens of "/" and "*" in a document, and
> they placed in 'unhappy' positions. For example, in phonetics the
> "/ ... /" notation is used a lot, and there may be cases like:
>
> #+begin_example
> /foo/ /bar/ /baz/
> #+end_example
Unless you were seeking for a lightweight markup I would remind you
about macro:
---- >8 ----
#+macro: ph @@x:@@/@@x:@@$1@@x:@@/@@x:@@
/{{{ph(foo)}}} {{{ph(bar)}}} {{{ph(baz)}}}/
---- 8< ----
Form my point of view it is not worse than "\slash{}" entities.
LISP can bee easily transformed to a domain specific language by means
of LISP macros (it is its strong and weak side simultaneously). I am
unaware whether a comparable framework exists for creating custom
lightweight markups. In LaTeX for your examples I expect something like
\phonetic{foo} commands to have logical markup. Certainly with some
hints /foo/ in particular part of text might be considered as "phonetic"
rather than "italic" in intermediate representation keeping source
easily readable.
> https://i.imgur.com/f6X7qLs.png
In this example there is no need to replace "<" by entity since it can
not be confused with <http://te.st/> links.
^ permalink raw reply [relevance 5%]
* Re: A simple Lua filter for Pandoc
2022-01-07 14:29 5% ` Max Nikulin
@ 2022-01-07 15:14 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-07 15:14 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Form my point of view it is not worse than "\slash{}" entities.
Yes, I also use macros a lot, especially for more complex constructions.
Macros, entities and other tricks have their pros and cons, but they
allow me to have a certain group of characters under control.
>> https://i.imgur.com/f6X7qLs.png
>
> In this example there is no need to replace "<" by entity since it can
> not be confused with <http://te.st/> links.
As I have already said, this comes from a desire to keep a series of
characters under control, because they can be confused with the Org
marks or because I can get confused when working with the text,
especially if it is an imported text. In the case of "<" and ">", many
authors usually use them for various contexts in philology (instead of
the correct characters for some of those contexts, such as
RIGHT-POINTING ANGLE BRACKET and LEFT-POINTING ANGLE BRACKET: in that
case, I have to replace with the correct symbol). In general, I am
calmer if I have, in one way or another, all those symbols conveniently
"delimited", because even if Org is not wrong, I can get confused.
Anyway, regardless of the idiosyncrasy of my workflow, the origin of
this thread (the function in Lua) was in case someone wants to adapt it
to their own workflow, and needs to substitute some strings for others
when importing from docx or odt.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [tip] Inline tasks as anonymous sections
@ 2022-01-08 11:32 9% Juan Manuel Macías
2022-01-08 13:09 6% ` Marcin Borkowski
2022-01-09 7:13 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-08 11:32 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
Hi,
I think that a very efficient way to take advantage of inline tasks (in
the framework of document authoring and exporting) is to treat them as
anonymous sections, that is, those sections that do not have a title and
are normally separated in books by some special symbol: three asterisks
(a dinkus: https://en.wikipedia.org/wiki/Dinkus), an asterism (three
asterisks forming a triangle), or any other fancy symbol. Users can
associate their own export functions with the variables
`org-latex-format-inlinetask-function',
`org-odt-format-inlinetask-function', etc. Well, you can always add the
separation symbol directly in your text, but the advantage of using
inline task is that we can conveniently have those sections delimited,
as real sections (with properties, todo states, etc).
If anyone wants to explore this possibility, I am attaching a test org
document. I have defined two LaTeX commands: \anonsectionbreak and
\anonsectionmark; and the 'anonsection' environment[1].
[1] The Memoir class includes code for these types of divisions (see
section 6.7 FANCY ANONYMOUS BREAKS in Memoir documentation).
Best regards,
Juan Manuel
[-- Attachment #2: anon-sec-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1862 bytes --]
^ permalink raw reply [relevance 9%]
* Re: [tip] Inline tasks as anonymous sections
2022-01-08 11:32 9% [tip] Inline tasks as anonymous sections Juan Manuel Macías
@ 2022-01-08 13:09 6% ` Marcin Borkowski
2022-01-09 7:13 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Marcin Borkowski @ 2022-01-08 13:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2022-01-08, at 12:32, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> I think that a very efficient way to take advantage of inline tasks (in
> the framework of document authoring and exporting) is to treat them as
> anonymous sections, that is, those sections that do not have a title and
> are normally separated in books by some special symbol: three asterisks
> (a dinkus: https://en.wikipedia.org/wiki/Dinkus), an asterism (three
> asterisks forming a triangle), or any other fancy symbol. Users can
> associate their own export functions with the variables
> `org-latex-format-inlinetask-function',
> `org-odt-format-inlinetask-function', etc. Well, you can always add the
> separation symbol directly in your text, but the advantage of using
> inline task is that we can conveniently have those sections delimited,
> as real sections (with properties, todo states, etc).
>
> If anyone wants to explore this possibility, I am attaching a test org
> document. I have defined two LaTeX commands: \anonsectionbreak and
> \anonsectionmark; and the 'anonsection' environment[1].
I don't expect this to be useful for me personally, but I love the idea!
Best,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 6%]
* Re: Way to mark contents of an Org special block as verbatim?
2022-01-06 19:46 5% ` Kaushal Modi
@ 2022-01-08 21:52 0% ` Berry, Charles
0 siblings, 0 replies; 200+ results
From: Berry, Charles @ 2022-01-08 21:52 UTC (permalink / raw)
To: Kaushal Modi; +Cc: Juan Manuel Macías, orgmode
> On Jan 6, 2022, at 11:46 AM, Kaushal Modi <kaushal.modi@gmail.com> wrote:
>
> On Thu, Jan 6, 2022 at 2:33 PM Juan Manuel Macías
> <maciaschain@posteo.net> wrote:
>> I just realized that there is a much simpler solution for your katex
>> environment :-)
>>
>> You can use an example block, and define your custom environment using
>> the attribute :environment
>
> Sorry, but this exporter is derived from md, and before exporting the
> verbatim body of the special block needs to be surrounded with some
> special syntax, with some optional stuff that the user specifies. Also
> it could any special block name:
> - katex
> - tikz
> - tikzjax
>
> In any case, if user has this in Org:
>
> #+begin_FOO
> <body verbatim>
> #+end_FOO
>
> I need to export:
>
> {{< FOO custom stuff >}}
> <body verbatim>
> {{< /FOO >}}
>
>
What am I missing?
It seems like you want your derived backend to transcode special blocks somewhat differently than the parent backend. And adding a special block export filter doesn't quite do the job.
For that purpose, you should write a special block transcoder - perhaps falling back to the parent backend for block types you do not wish to handle as described above.
Block specific customizations could rely on a backend specific attribute.
HTH,
Chuck
^ permalink raw reply [relevance 0%]
* Re: [tip] Inline tasks as anonymous sections
2022-01-08 11:32 9% [tip] Inline tasks as anonymous sections Juan Manuel Macías
2022-01-08 13:09 6% ` Marcin Borkowski
@ 2022-01-09 7:13 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-01-09 7:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think that a very efficient way to take advantage of inline tasks (in
> the framework of document authoring and exporting) is to treat them as
> anonymous sections, that is, those sections that do not have a title and
> are normally separated in books by some special symbol: three asterisks
> (a dinkus: https://en.wikipedia.org/wiki/Dinkus), an asterism (three
> asterisks forming a triangle), or any other fancy symbol. Users can
> associate their own export functions with the variables
> `org-latex-format-inlinetask-function',
Thanks! It is an interesting idea.
In Org, I also prefer to display inline tasks using "⇒⇒⇒" instead of all
the asterisks. (see the attached screenshot)
Best,
Ihor
[-- Attachment #2: 2022-01-09_15-12.png --]
[-- Type: image/png, Size: 74727 bytes --]
^ permalink raw reply [relevance 6%]
* Preview fonts from Dired with org-latex-preview (and test opentype features)
@ 2022-01-10 16:47 8% Juan Manuel Macías
2022-01-18 20:50 6% ` Ken Mankoff
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-10 16:47 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
Hi,
I have written for my personal use this code (still quite crude) that
allows me to preview with org-latex-preview small text strings in a font
marked in dired, and test open type features too. The preview is
compiled with LuaLaTeX, since LuaTeX allows to load fonts that are not
installed in the system.
When a font is selected, the list of opentype features included in the
font are extracted (using the otfinfo command), and they are arranged in
the preview buffer as buttons. By clicking on each button we can
activate in the preview the corresponding opentype feature. For example,
if the font includes the 'smcp' feature, clicking on the button 'smcp'
the text will be displayed in small caps.
We can enter the text strings literally or through Unicode code: each
character separated by a space; the separation between words is marked
with a vertical bar. For example, this code:
0063 006f 0064 0065 | 0068 0065 0072 0065
returns the string "code here".
As a third option, a complete specimen can be displayed from a file.
Here is a demo video: https://cloud.disroot.org/s/aHXKiof36fTSZGB
As I said, my function is still pretty crude, and while it works well,
it's now more of a proof of concept than a finished thing. But if anyone
wants to try it, I attach the code here in an org document.
Best regards,
Juan Manuel
[-- Attachment #2: font-preview.org --]
[-- Type: application/vnd.lotus-organizer, Size: 10258 bytes --]
^ permalink raw reply [relevance 8%]
* Re: Filter to put decorative initial letters
2022-01-07 0:41 9% Filter to put decorative initial letters Juan Manuel Macías
@ 2022-01-11 0:43 6% ` William Denton
2022-01-11 16:21 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: William Denton @ 2022-01-11 0:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On 7 January 2022, Juan Manuel Macías wrote:
> These past holidays I've been experimenting with some little useful, but
> fun stuff. This is an export filter to put a decorative initial letter
> in the first paragraphs of the first level sections, using the LaTeX
> package lettrine (https://www.ctan.org/pkg/lettrine).
>
> A screenshot: https://i.imgur.com/mLQVHFC.png
This is beautiful, and a nice Org hack. I appreciate the typographical and
design examples you send, and have learned a lot from them. Thank you.
Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
^ permalink raw reply [relevance 6%]
* Re: Filter to put decorative initial letters
2022-01-11 0:43 6% ` William Denton
@ 2022-01-11 16:21 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-11 16:21 UTC (permalink / raw)
To: William Denton; +Cc: orgmode
Hi William,
William Denton writes:
> This is beautiful, and a nice Org hack. I appreciate the
> typographical and design examples you send, and have learned a lot
> from them. Thank you.
>
> Bill
Thanks for your kind words, I'm glad you found that code useful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: puzzled about :fit for LaTeX src block
@ 2022-01-12 17:22 10% ` Juan Manuel Macías
2022-01-13 10:14 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-12 17:22 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
Eric S Fraga writes:
> I have a LaTeX src block which creates an image using tikz. In a book
> I'm writing, the image, when created as a png, does not get shrunk but
> is instead a full page (with the actual diagram in the top left corner).
> If I create a PDF, instead, it works fine.
Testing two possibilities:
What (latex) code produces that image in the output *tex file of your book?
and
C-h v RET org-format-latex-header RET: what value?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: puzzled about :fit for LaTeX src block
2022-01-12 17:22 10% ` Juan Manuel Macías
@ 2022-01-13 10:14 6% ` Eric S Fraga
2022-01-13 11:17 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Eric S Fraga @ 2022-01-13 10:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On Wednesday, 12 Jan 2022 at 17:22, Juan Manuel Macías wrote:
> Testing two possibilities:
>
> What (latex) code produces that image in the output *tex file of your book?
They both use the same LaTeX src block (as was in the attachment) which
creates an org link to the generated PDF or PNG file. It's the
generation of the image file that is the problem, not how the file is
used in the end unfortunately.
> C-h v RET org-format-latex-header RET: what value?
Both the same and the default value from org.
thank you,
eric
--
: Eric S Fraga, with org release_9.5.2-298-g1f48d2 in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: puzzled about :fit for LaTeX src block
2022-01-13 10:14 6% ` Eric S Fraga
@ 2022-01-13 11:17 10% ` Juan Manuel Macías
2022-01-13 12:05 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-13 11:17 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
Eric S Fraga writes:
> Both the same and the default value from org.
I'm not sure, but maybe the problem comes from the
\documentclass{article} in org-format-latex-header. Can you try
replacing that with "\\documentclass[varwidth]{standalone}"?
Another possibility: please try adding the header arg. :imagemagick yes
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: puzzled about :fit for LaTeX src block
2022-01-13 11:17 10% ` Juan Manuel Macías
@ 2022-01-13 12:05 6% ` Eric S Fraga
2022-01-13 15:41 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Eric S Fraga @ 2022-01-13 12:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Thursday, 13 Jan 2022 at 11:17, Juan Manuel Macías wrote:
> Another possibility: please try adding the header arg. :imagemagick yes
This did it! Thank you. I am curious now to find out what tool was
used instead... something for later today!
Thanks again,
eric
--
Professor Eric S Fraga, UCL; GnuPG: 0xc89193d8fffcf67d
^ permalink raw reply [relevance 6%]
* Re: puzzled about :fit for LaTeX src block
2022-01-13 12:05 6% ` Eric S Fraga
@ 2022-01-13 15:41 8% ` Juan Manuel Macías
2022-01-13 16:14 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-13 15:41 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga writes:
> This did it! Thank you. I am curious now to find out what tool was
> used instead... something for later today!
Well, it seems that if you use ":imagemagick yes", the image is created
with the `org-babel-latex-convert-pdf' function. I almost always use this
to create images from latex blocks, for example:
#+begin_src latex: imagemagick yes :iminoptions -density 600
\bfseries Hello world!
#+end_src
":fit" crop the image, but you can also put in your "org-format-latex-header" "\\documentclass[varwidth]{standalone}"
On the contrary, without :imagemagick, but with results to *.png file,
`org-create-formula-image' is used, which depends on
"org-preview-latex-process-alist" and
"org-preview-latex-default-process". Since I only use LuaTeX for
everything, I have this in my init, in order to preview LaTeX fragments:
(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)
Note that the -trim option for the "convert" program (last line) allows
you to crop the image from the pdf page.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: puzzled about :fit for LaTeX src block
2022-01-13 15:41 8% ` Juan Manuel Macías
@ 2022-01-13 16:14 6% ` Eric S Fraga
0 siblings, 0 replies; 200+ results
From: Eric S Fraga @ 2022-01-13 16:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Thursday, 13 Jan 2022 at 15:41, Juan Manuel Macías wrote:
> Well, it seems that if you use ":imagemagick yes", the image is created
> with the `org-babel-latex-convert-pdf' function.
Indeed. I went to the code. Thank you. Everything is working like I
want it!
--
: Eric S Fraga, with org release_9.5.2-298-g1f48d2 in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
@ 2022-01-13 18:50 10% ` Juan Manuel Macías
[not found] ` <87bl0feahc.fsf@posteo.net-MtJnHBm----2>
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 18:50 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
Hi,
fatiparty--- via "General discussions about Org-mode." writes:
> Is there anything to perform the opposite, playing down the text?
Are you referring to nested emphasis, something like in LaTeX
\emph{foo \emph{bar} baz}
= foo...baz in italic; bar in normal font?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Playing down the text in org-mode
@ 2022-01-13 19:19 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 19:19 UTC (permalink / raw)
To: John Kitchin, fatiparty; +Cc: orgmode
John Kitchin writes:
> It depends on what you mean. I can't think of a standard markup for
> de-emphasis. You could imply it with color perhaps, e.g. some shade of
> grey, or size by making it smaller. At least for LaTex/HTML, both of
> those can be done. You would either need to use something like a
> macro, or a link for something like that I think.
The problem is that the concept of nested emphasis only works in LaTeX.
I agree that a macro would be a good solution, putting the argument in
'normal' text. An approximation could be:
#+begin_src emacs-lisp
(defun macro-no-emph (arg)
(let* ((backend org-export-current-backend))
(cond ((eq org-export-current-backend 'latex)
(concat "@@latex:{\\normalfont @@" arg "@@latex:}@@"))
((eq org-export-current-backend 'html)
(concat "@@html:<span style=\"font-style:normal;\">@@" arg "@@html:</span>@@"))
((eq org-export-current-backend 'odt)
;; a character style `normal' must be definded for odt
(concat "@@odt:<text:span text:style-name=\"normal\">@@" arg "@@odt:</text:span>@@")))))
(setq org-export-global-macros
'(("noemph" . "(eval (mi-macro-emph $1))")))
#+end_src
/foo {{{noemph(bar)}}} baz/
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
@ 2022-01-13 19:42 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-13 19:42 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty--- via "General discussions about Org-mode." writes:
> _a geographical region that corresponds to present-day Israel and Palestine_
In any case, from a strictly (ortho)typographical point of view this is a
matter of nesting emphasis. If what you want to do is highlight a word
within another emphasis (an underline), the correct typographical
procedure is to italicize or bold that word:
_a /geographical/ region that corresponds to present-day Israel and
Palestine_
==>
\uline{a \emph{geographical} region that corresponds to present-day
Israel and Palestine}
What you can't do in Org is nest emphases of the same order:
#+begin_example
/The translators of the /Odyssey/ in the Hispanic tradiction/
#+end_example
It does not produce in LaTeX:
#+begin_src latex
\emph{The translators of the \emph{Odyssey} in the Hispanic tradiction}
#+end_src
It is not a matter of a passage being de-emphasized (it doesn't work
that way), but rather that it is emphasized within another emphasis
text. In the above case, the way to emphasize Odyssey in a text already
emphasized in italics is with a normal font or with an underline (the
correct thing is with a normal font).
There are two separate questions here: how that is represented in Org
and how it should be exported.
^ permalink raw reply [relevance 5%]
* Re: Playing down the text in org-mode
@ 2022-01-13 20:20 9% ` Juan Manuel Macías
[not found] ` <87iluncrr6.fsf@posteo.net-MtK5wx2----2>
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 20:20 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty@tutanota.com writes:
> I am discussing something slightly different.
>
> Here is normal text within -which there is some understated text- before continuing with normal text.
Yes, it seems that I have understood you horribly wrong, sorry for the
noise (it must be the effects of the third modern vaccine that they gave
me yesterday :-)
In short, what you want is that a part of the text is "obscured" in some
way with respect to the main body text, and you would like Org to have
some marks for it. I see an important basic problem: there are many
procedures to reduce the reading importance of a text: simply pass that
text to a footnote, use dashes, parentheses or brackets, put the text in
a smaller size (which is the usual when these passages are isolated
paragraphs). I think it is better to define all these questions in the
output formats, through post-processing, and in Org use macros, custom
links, special blocks, the procedure that John has shared here, etc. But a
"universal" no-emphasis mark doesn't seem viable to me, IMHO.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Playing down the text in org-mode
@ 2022-01-13 21:39 10% ` Juan Manuel Macías
2022-01-14 9:41 6% ` Eric S Fraga
[not found] ` <874k66irh4.fsf@ucl.ac.uk-MtMyJM6----2>
[not found] ` <878rvjco35.fsf@posteo.net-MtKOBaG----2>
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 21:39 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty@tutanota.com writes:
> If I do something in emacs-lisp I would still need some form of
> containment characters.
I think a custom link would suffice for text within the paragraph. A
quick example:
#+begin_src emacs-lisp
(defface smaller
'((t :foreground "#8D8D84" :height 0.9))
"")
(org-link-set-parameters "smaller"
:face 'smaller
:export (lambda (path desc format)
(cond
((eq format 'latex)
(format "{\\small %s}" desc)))))
#+end_src
This text is important, [[smaller:x][but this one is not so important]]
A screenshot:
https://i.imgur.com/11KbJHQ.png
if you want finer tuning and more control over the format, John's
scimax-editmarks package seems like a very interesting option (although
I think Org should remain as format-agnostic as possible...)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Playing down the text in org-mode
@ 2022-01-13 23:08 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-13 23:08 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty@tutanota.com writes:
> but with the variation that the text is also within the square brackets
You can use inline footnotes, but I'm afraid you couldn't stop using
"fn" here (unless you hack the Org code). However you can use a
convention, something like:
Lorem[fn:mg1:blah blah blah] ipsum dolor sit amet, consectetuer
adipiscing elit. Donec hendrerit tempor[fn:mg2:blah blah blah] tellus.
Donec pretium posuere tellus...
And you can also use anonymous online footnotes:
Lorem[fn::dolor ipsum lorem] ipsum dolor sit amet, consectetuer
adipiscing elit. Donec hendrerit tempor[fn::blah blah blah] tellus.
Donec pretium posuere tellus...
(and for more contrast, you can also modify the orf-footnote face to
your liking).
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
2022-01-13 21:39 10% ` Juan Manuel Macías
@ 2022-01-14 9:41 6% ` Eric S Fraga
[not found] ` <874k66irh4.fsf@ucl.ac.uk-MtMyJM6----2>
1 sibling, 0 replies; 200+ results
From: Eric S Fraga @ 2022-01-14 9:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: fatiparty, orgmode
On Thursday, 13 Jan 2022 at 21:39, Juan Manuel Macías wrote:
> I think a custom link would suffice for text within the paragraph. A
> quick example:
Very nice example. Thank you.
Custom links are excellent for this kind of behaviour tuning while being
portable if the link definition is included in the org file. I use this
approach in lieu of inline tasks for creating margin notes (in the
export), for instance.
--
: Eric S Fraga, with org release_9.5.2-298-g1f48d2 in Emacs 29.0.50
^ permalink raw reply [relevance 6%]
* Playing down the text in org-mode
[not found] ` <874k66irh4.fsf@ucl.ac.uk-MtMyJM6----2>
@ 2022-01-14 13:03 0% ` fatiparty--- via General discussions about Org-mode.
[not found] ` <87o84efnqk.fsf@ucl.ac.uk-MtNobqT----2>
0 siblings, 1 reply; 200+ results
From: fatiparty--- via General discussions about Org-mode. @ 2022-01-14 13:03 UTC (permalink / raw)
To: Eric S Fraga; +Cc: Juan Manuel Macías, orgmode
Jan 14, 2022, 21:41 by e.fraga@ucl.ac.uk:
> On Thursday, 13 Jan 2022 at 21:39, Juan Manuel Macías wrote:
>
>> I think a custom link would suffice for text within the paragraph. A
>> quick example:
>>
>
> Very nice example. Thank you.
>
> Custom links are excellent for this kind of behaviour tuning while being
> portable if the link definition is included in the org file. I use this
> approach in lieu of inline tasks for creating margin notes (in the
> export), for instance.
>
How can I remove the background and underline for footnotes, and change
foreground colour.
> --
> : Eric S Fraga, with org release_9.5.2-298-g1f48d2 in Emacs 29.0.50
>
^ permalink raw reply [relevance 0%]
* Re: Playing down the text in org-mode
@ 2022-01-14 20:00 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-14 20:00 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty--- via "General discussions about Org-mode." writes:
> What is the face name associated with inline footnotes?
M-x describe-face RET Is your friend. Place the cursor on any inline
note, run this command and you will see that the face you need to modify
is called `org-footnote'.
M-: (info "(elisp)faces") RET
With this you have at your disposal all the information about faces, how
to manipulate them, etc.
I use a lot the `set-face-attribute' function in my init, to modify some
things of the theme that I have loaded. For example, if you want to
change the color of your notes and make them a little smaller in size:
(set-face-attribute 'org-footnote nil :foreground "DimGray" :height 0.9)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Playing down the text in org-mode
@ 2022-01-14 20:41 6% ` Juan Manuel Macías
[not found] ` <87zgnydp8d.fsf@posteo.net-MtPKW6j----2>
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-14 20:41 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty@tutanota.com writes:
> But this is giving "error: Invalid face, org-footnote"
Try this (I forgot to mention this, sorry):
(with-eval-after-load 'org
(set-face-attribute 'org-footnote nil :foreground "d2691e" :height 0.8 :extend t :underline "red"))
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
@ 2022-01-14 20:57 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-14 20:57 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty--- via "General discussions about Org-mode." writes:
> Is this requirement just associated with org-footnote, as it is not usual to use "with-eval-after-load"
> to apply customisations.
It's a face defined by org, and org must be loaded before. You can also
put before, simply, (require 'org) or (require 'org-faces).
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
@ 2022-01-14 21:16 6% ` Juan Manuel Macías
[not found] ` <87r19adnm9.fsf@posteo.net-MtPRzO3----2>
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-14 21:16 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty@tutanota.com writes:
> That works well. But although I am atttempting to remove the
> background and change the foreground colour, the old colours remain.
>
> (with-eval-after-load 'org
> (set-face-attribute 'org-footnote nil
> :foreground "d2691e" :background 'nil :underline 'nil
> :weight 'normal :slant 'italic :height 0.8))
You are missing a "#" symbol in the color name:
:foreground "#d2691e"
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
@ 2022-01-14 22:23 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-14 22:23 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty--- via "General discussions about Org-mode." writes:
> It is much better now. In Emacs, footnotes have a background color. I still
> can see the footnote background colour with ":background 'nil".
What theme are you using? Usually, org-footnote does not have a defined background.
In any case, you can evaluate (describe-face default), and add the value
of background in default to org-footnote.
^ permalink raw reply [relevance 6%]
* Re: Playing down the text in org-mode
@ 2022-01-14 22:44 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-14 22:44 UTC (permalink / raw)
To: fatiparty; +Cc: orgmode
fatiparty--- via "General discussions about Org-mode." writes:
> Doing describe-face on the footnote I have "Background: unspecified"
So org-footnote does not have a defined background, which is usual. You
don't need to remove any background color. You should be seeing in your
notes the background for 'default' face in that theme.
^ permalink raw reply [relevance 6%]
* Re: org-->html text between @ should be red.
@ 2022-01-15 18:21 10% ` Juan Manuel Macías
2022-01-15 19:39 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-15 18:21 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Can I have a similar setting when exporting an org file to html via the
> «normal» html exporter?
Using a custom filter?
#+begin_src emacs-lisp
(defun foo (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "@\\([^@]*\\)@"
"<span style=\"color:red\">\\1</span>"
text)))
(add-to-list 'org-export-filter-final-output-functions 'foo)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-->html text between @ should be red.
2022-01-15 18:21 10% ` Juan Manuel Macías
@ 2022-01-15 19:39 0% ` Uwe Brauer
2022-01-15 19:59 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-01-15 19:39 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> Can I have a similar setting when exporting an org file to html via the
>> «normal» html exporter?
> Using a custom filter?
> #+begin_src emacs-lisp
> (defun foo (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "@\\([^@]*\\)@"
> "<span style=\"color:red\">\\1</span>"
> text)))
> (add-to-list 'org-export-filter-final-output-functions 'foo)
> #+end_src
Thanks very much it works as expected. However I just realized (and this is true also for the org-mime filter that the reg-exp has a flaw.
I used the text
=email:oub@mat.ucm.es=
So there is only one @, nevertheless the exporter translated that to
<code>email:oub<span style="color:red">mat.ucm.es</code><br />
But this is wrong in my view.
Any ideas how to deal with such a situation?
Thanks
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: org-->html text between @ should be red.
2022-01-15 19:39 0% ` Uwe Brauer
@ 2022-01-15 19:59 10% ` Juan Manuel Macías
2022-01-15 20:24 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-15 19:59 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Thanks very much it works as expected. However I just realized (and
> this is true also for the org-mime filter that the reg-exp has a flaw.
>
> I used the text
>
>
> =email:oub@mat.ucm.es=
>
> So there is only one @, nevertheless the exporter translated that to
> <code>email:oub<span style="color:red">mat.ucm.es</code><br />
>
> But this is wrong in my view.
>
> Any ideas how to deal with such a situation?
You can bind the function to org-export-filter-plain-text-functions
instead of ...-final-output-functions.
That way you wouldn't get false positives on lines like:
=email:oub@mat.ucm.es= some text @some text@
<code>email:oub@mat.ucm.es</code> some text <span style="color:red">some text</span>
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-->html text between @ should be red.
2022-01-15 19:59 10% ` Juan Manuel Macías
@ 2022-01-15 20:24 0% ` Uwe Brauer
2022-01-15 20:58 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2022-01-15 20:24 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> Thanks very much it works as expected. However I just realized (and
>> this is true also for the org-mime filter that the reg-exp has a flaw.
>>
>> I used the text
>>
>>
>> =email:oub@mat.ucm.es=
>>
>> So there is only one @, nevertheless the exporter translated that to
>> <code>email:oub<span style="color:red">mat.ucm.es</code><br />
>>
>> But this is wrong in my view.
>>
>> Any ideas how to deal with such a situation?
> You can bind the function to org-export-filter-plain-text-functions
> instead of ...-final-output-functions.
Perfect, thanks.
Just out of curiosity because google does not know the answer
There is
(add-hook 'some-hook 'some-function)
(remove-hook 'some-hook 'some-function)
So if I have
(add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
How could I remove something from a list?
Regards
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: org-->html text between @ should be red.
2022-01-15 20:24 0% ` Uwe Brauer
@ 2022-01-15 20:58 9% ` Juan Manuel Macías
2022-01-15 21:01 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-15 20:58 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
>
> How could I remove something from a list?
I think this would work:
(setq org-export-filter-plain-text-functions
(remove 'my-html-red org-export-filter-plain-text-functions))
Anyway, I recommend that you take a look at the documentation on filters
that Timothy pointed you to, as custom filters are tremendously useful
and versatile, and very "surgical". I use them a lot!
You can also apply a filter only in a document, by using the #+bind
keyword and including the function in a non-exportable code block:
#+begin_src emacs-lisp :exports results :results none
(defun my-html-red (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "@\\([^@]*\\)@"
"<span style=\"color:red\">\\1</span>"
text)))
#+end_src
#+bind: org-export-filter-plain-text-functions (my-html-red)
(You need to set org-export-allow-bind-keywords to non-nil)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-->html text between @ should be red.
2022-01-15 20:58 9% ` Juan Manuel Macías
@ 2022-01-15 21:01 0% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-01-15 21:01 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think this would work:
> (setq org-export-filter-plain-text-functions
> (remove 'my-html-red org-export-filter-plain-text-functions))
> Anyway, I recommend that you take a look at the documentation on filters
> that Timothy pointed you to, as custom filters are tremendously useful
> and versatile, and very "surgical". I use them a lot!
> You can also apply a filter only in a document, by using the #+bind
> keyword and including the function in a non-exportable code block:
> #+begin_src emacs-lisp :exports results :results none
> (defun my-html-red (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "@\\([^@]*\\)@"
> "<span style=\"color:red\">\\1</span>"
> text)))
> #+end_src
> #+bind: org-export-filter-plain-text-functions (my-html-red)
> (You need to set org-export-allow-bind-keywords to non-nil)
Thanks very much!!!
Regards
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Depreciating TeX-style LaTeX fragments
@ 2022-01-16 13:26 9% ` Juan Manuel Macías
2022-01-16 14:43 0% ` Colin Baxter 😺
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-16 13:26 UTC (permalink / raw)
To: Colin Baxter, Timothy, Sébastien Miquel; +Cc: orgmode
Colin Baxter writes:
> Ah, LaTeX3 - whatever happened to that?
If you're a LaTeX user, you're already using LaTeX3 to a very high
extent, even if you don't see it. The current idea is not to replace
LaTeX2e with LaTeX3 as a new version, but to gradually incorporate
elements of LaTeX3 into the LaTeX kernel, like the new syntax, xparse,
etc. LaTeX3 is already present in many aspects of LaTeX, and that is an
undeniable advance. If anyone is interested in the state of the art,
this short talk by Frank Mittelbach at TUG 2020 is very illustrative:
https://invidious.snopyta.org/watch?v=zNci4lcb8Vo
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Depreciating TeX-style LaTeX fragments
2022-01-16 13:26 9% ` Juan Manuel Macías
@ 2022-01-16 14:43 0% ` Colin Baxter 😺
0 siblings, 0 replies; 200+ results
From: Colin Baxter 😺 @ 2022-01-16 14:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Sébastien Miquel, orgmode, Timothy
>>>>> Juan Manuel Macías <maciaschain@posteo.net> writes:
> Colin Baxter writes:
>> Ah, LaTeX3 - whatever happened to that?
> If you're a LaTeX user, you're already using LaTeX3 to a very high
> extent, even if you don't see it. The current idea is not to
> replace LaTeX2e with LaTeX3 as a new version, but to gradually
> incorporate elements of LaTeX3 into the LaTeX kernel, like the new
> syntax, xparse, etc. LaTeX3 is already present in many aspects of
> LaTeX, and that is an undeniable advance. If anyone is interested
> in the state of the art, this short talk by Frank Mittelbach at
> TUG 2020 is very illustrative:
Yes, I know. My remark was tongue in cheek.
^ permalink raw reply [relevance 0%]
* [ann] org-font-spec-preview (preview fonts and test open type features)
@ 2022-01-16 16:42 9% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-16 16:42 UTC (permalink / raw)
To: orgmode
Hi,
I've polished some raw ideas that I shared here a few days ago, and I
have written this little package:
https://gitlab.com/maciaschain/org-font-spec-preview
org-font-spec-preview allows you to preview arbitrary text strings in a
chosen font (or generate a complete specimen) as well as test opentype
features in real time. The preview is done in a temporary buffer, by
executing org-latex-preview, and must be compiled with LuaTeX, since
LuaTeX allows to load fonts that are not installed in the system.
Two user commands are provided:
- ofsp-system-font: Run ido and choose the candidate font from a list of
fonts installed on the system;
- ofsp-dired-font: Preview a font file in Dired.
Feedback welcome!
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: latex block tikz to svg
@ 2022-01-17 16:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-17 16:01 UTC (permalink / raw)
To: Edouard Debry; +Cc: orgmode
Hi Edouard,
Edouard Debry writes:
> I would like to find a way to generate svg images from latex src blocks
> (using tikz) which works and is compatible with default orgmode settings
> for latex export (at least does not break it)
>
> Did you experience such issues ? do you have some workings settings and
> examples ? I googled several times "org latex block tikz svg", but it is
> difficult to guess how relevant are the elements found, some of them
> seems quiet outdated. Hence my question on this mailing list
I've done some quick tests with your example block. I don't know if I'm
wrong, but I think the problem is on line 27 of `org-babel-execute:latex':
((string= "svg" extension)
I don't know if this should be considered an Org bug, but it's clear
that if the svg extension is detected in :file, the ':imagemagick yes'
option is ignored, and a type of preamble is generated that fails in
pgfsysdriver when compiling the temp tex document:
\documentclass[preview]{standalone}
\def\pgfsysdriver{pgfsys-tex4ht.def}
If I replace the above line with this conditional:
((and (string= "svg" extension) (not imagemagick))
then the imagemagick option is taken into account: it creates correctly
the pdf and then converts it to svg with 'convert' imagemagick program.
I did have to remove this line though:
#+HEADER: :imoutoptions -geometry 400 :iminoptions -density 600
otherwise, the conversion produced a dark image.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Preview fonts from Dired with org-latex-preview (and test opentype features)
2022-01-10 16:47 8% Preview fonts from Dired with org-latex-preview (and test opentype features) Juan Manuel Macías
@ 2022-01-18 20:50 6% ` Ken Mankoff
0 siblings, 0 replies; 200+ results
From: Ken Mankoff @ 2022-01-18 20:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
Please excuse brevity. Sent from tiny pocket computer with non-haptic
feedback keyboard.
On Mon, Jan 10, 2022, 08:53 Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I have written for my personal use this code (still quite crude) that
> allows me to preview with org-latex-preview small text strings in a font
> marked in dired, and test open type features too. The preview is
> compiled with LuaLaTeX, since LuaTeX allows to load fonts that are not
> installed in the system.
>
> When a font is selected, the list of opentype features included in the
> font are extracted (using the otfinfo command), and they are arranged in
> the preview buffer as buttons. By clicking on each button we can
> activate in the preview the corresponding opentype feature. For example,
> if the font includes the 'smcp' feature, clicking on the button 'smcp'
> the text will be displayed in small caps.
>
> We can enter the text strings literally or through Unicode code: each
> character separated by a space; the separation between words is marked
> with a vertical bar. For example, this code:
>
> 0063 006f 0064 0065 | 0068 0065 0072 0065
>
> returns the string "code here".
>
> As a third option, a complete specimen can be displayed from a file.
>
> Here is a demo video: https://cloud.disroot.org/s/aHXKiof36fTSZGB
>
> As I said, my function is still pretty crude, and while it works well,
> it's now more of a proof of concept than a finished thing. But if anyone
> wants to try it, I attach the code here in an org document.
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 2133 bytes --]
^ permalink raw reply [relevance 6%]
* Re: change the fontsize when exporting to HTML, header not really changed
@ 2022-01-20 11:48 10% ` Juan Manuel Macías
2022-01-20 16:14 1% ` Uwe Brauer
2022-01-20 17:56 10% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-20 11:48 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe
Uwe Brauer writes:
> Now some text is changed as expected the text in the header not really.
>
> Any idea what would be a more appropriate setting?
Taking into account that h1 is the title, h2, h3, etc. are the classes
for the different header levels. You can put something like this:
#+HTML_HEAD: <style> h2 {font-size:108%}</style>
#+HTML_HEAD: <style> body {font-size:108%}</style>
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: change the fontsize when exporting to HTML, header not really changed
2022-01-20 11:48 10% ` Juan Manuel Macías
@ 2022-01-20 16:14 1% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-01-20 16:14 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan
> Hi Uwe
> Uwe Brauer writes:
>> Now some text is changed as expected the text in the header not really.
>>
>> Any idea what would be a more appropriate setting?
> Taking into account that h1 is the title, h2, h3, etc. are the classes
> for the different header levels. You can put something like this:
> #+HTML_HEAD: <style> h2 {font-size:108%}</style>
> #+HTML_HEAD: <style> body {font-size:108%}</style>
thanks very much but it seems not to work, I also tried
#+HTML_HEAD_EXTRA: <style>*{font-size: 108%;}</style>
#+HTML_HEAD_EXTRA: <style> h1 {font-size:108%}</style>
#+HTML_HEAD_EXTRA: <style> h2 {font-size:108%}</style>
But it did not work neither. Did you test it? I am on GNU Emacs master and git master (ok several weeks old, but still recent enough I'd say)
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: change the fontsize when exporting to HTML, header not really changed
2022-01-20 11:48 10% ` Juan Manuel Macías
@ 2022-01-20 17:56 10% ` Juan Manuel Macías
2022-01-21 17:21 0% ` Uwe Brauer
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-20 17:56 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode, Eric S Fraga
Uwe Brauer writes:
>But it did not work neither. Did you test it? I am on GNU Emacs master
>and git master (ok several weeks old, but still recent enough I'd say)
I hadn't seen Eric's message, but what he says makes a lot of sense: are
you applying a separate style sheet, perhaps with a *.setup document
that already has a header style defined? It looks like one style
overlaps another.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Exporting Org file to Html with collapsable headings
@ 2022-01-21 12:23 10% ` Juan Manuel Macías
2022-01-21 16:46 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-01-21 12:23 UTC (permalink / raw)
To: ZIPING CHEN; +Cc: orgmode
ZIPING CHEN writes:
> I am working on a large org file with exceptional number of
> subheadings. For example, I may have org headings inside headings up
> to 20 or 30 layers deep.
>
> I may have many things like this in the middle of the file.
> ************************** a new heading.
>
> When I export the file to html, I like to export in such a way that
> the org headings become collapsable headline in html (toggle switch).
> I spend some time search the web, and find a theme called bigblow
> which does something close to what I want, but not exactly. It provide
> limited layer of toggle switch only. I wish to turn all layers of
> headings in org file into collapsable headline to html.
>
> Does anybody know a way I can accomplish this?
I think that you need to add javascript and enclose the collapsible
content in a div. If you google for 'html collapsible sections' there is
quite a bit of information on how to achieve this from the html side.
Here, for example:
https://levelup.gitconnected.com/collapsible-sections-with-or-without-javascript-3fd871955a9d
On the other hand, although not exactly related to what you are looking
for, you may be interested in taking a look at 'organize'. I have not
tried it, and as far as i know, it has its limitations:
https://github.com/200ok-ch/organice
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Exporting Org file to Html with collapsable headings
2022-01-21 12:23 10% ` Juan Manuel Macías
@ 2022-01-21 16:46 6% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-01-21 16:46 UTC (permalink / raw)
To: emacs-orgmode
On 21/01/2022 19:23, Juan Manuel Macías wrote:
> ZIPING CHEN writes:
>
>> I may have many things like this in the middle of the file.
>> ************************** a new heading.
>>
>> I wish to turn all layers of
>> headings in org file into collapsable headline to html.
>>
>> Does anybody know a way I can accomplish this?
>
> I think that you need to add javascript and enclose the collapsible
> content in a div.
Have a look at info "(org) JavaScript support"
https://orgmode.org/manual/JavaScript-support.html (I have not tried
that folding view).
HTML has <details><summary>header</summary>body</details> elements that
works without JS, but it will require custom exporter.
You should ensure that deep headings can not be recognized as org inline
tasks. Check ox-html, it may has limit on number of levels that are
exported as headings with switching to lists for deeper structures.
^ permalink raw reply [relevance 6%]
* Re: change the fontsize when exporting to HTML, header not really changed
2022-01-20 17:56 10% ` Juan Manuel Macías
@ 2022-01-21 17:21 0% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2022-01-21 17:21 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer writes:
>> But it did not work neither. Did you test it? I am on GNU Emacs master
>> and git master (ok several weeks old, but still recent enough I'd say)
> I hadn't seen Eric's message, but what he says makes a lot of sense: are
> you applying a separate style sheet, perhaps with a *.setup document
> that already has a header style defined? It looks like one style
> overlaps another.
No I did not, but as I said in a different message, the problem is
solved thanks to you....
#+HTML_HEAD_EXTRA: <style> body {font-size:150%}</style>
Was the correct setting but deleting all the others I had left....
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
Results 401-600 of ~1600 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-06-03 21:11 [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
2021-06-04 11:31 ` Juan Manuel Macías
2021-06-06 22:34 ` Juan Manuel Macías
2021-06-08 0:24 ` [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.) Juan Manuel Macías
2021-09-26 6:08 ` Bastien
2021-09-26 11:35 ` Juan Manuel Macías
2021-09-26 12:49 6% ` Bastien
2021-09-02 0:42 Support for tabularray in LaTeX export Vikas Rawal
2021-09-02 8:36 ` Juan Manuel Macías
2021-09-02 10:08 ` Vikas Rawal
2021-10-25 14:04 ` Vikas Rawal
2021-10-25 14:18 10% ` Juan Manuel Macías
2021-10-25 17:25 0% ` Thomas Dye
2021-09-16 21:40 [PATCH] Fix some typos Stefan Kangas
2021-09-17 9:03 ` Timothy
2021-09-17 10:05 ` Marco Wahl
2021-09-22 16:47 ` Max Nikulin
2021-09-22 20:18 ` Juan Manuel Macías
2021-09-23 14:49 ` Max Nikulin
2021-09-24 6:03 ` Loris Bennett
2021-09-24 12:23 ` Juan Manuel Macías
2021-09-25 11:08 ` Marco Wahl
2021-09-29 10:34 7% ` Max Nikulin
2021-09-29 11:09 0% ` Marco Wahl
2021-09-29 11:11 0% ` Bastien Guerry
2021-09-29 11:14 6% ` Bastien
2021-09-26 12:24 [BUG] Conflict between org-emphasis and org-latex Léo Ackermann
2021-09-26 12:57 10% ` Juan Manuel Macías
2021-09-26 16:57 7% ` Léo Ackermann
2021-09-26 18:29 9% ` Juan Manuel Macías
2021-09-27 12:07 LaTeX export: grffile is a stub package meedstrom
2021-09-27 17:00 9% ` Juan Manuel Macías
2021-09-28 15:14 Possible bug? Combine emphasis marker faces? Protesilaos Stavrou
2021-09-28 16:54 10% ` Juan Manuel Macías
2021-09-28 16:46 how to export checkboxes to odt? Uwe Brauer
2021-09-28 20:47 10% ` Juan Manuel Macías
2021-09-29 6:29 1% ` Uwe Brauer
2021-09-29 20:18 orgmode.org setup Bastien
2021-09-30 4:00 ` Greg Minshall
2021-09-30 5:18 ` Grabbing the link to a message on the archive Timothy
2021-10-01 15:07 4% ` Max Nikulin
2021-10-01 15:59 export dispatch → change the default "Contents" string Jean-Christophe Helary
2021-10-01 16:35 9% ` Juan Manuel Macías
2021-10-01 16:45 1% ` Jean-Christophe Helary
2021-10-02 10:48 12% [Question] A single *-language-alist in ox-latex.el? Juan Manuel Macías
2021-10-02 11:08 5% ` Stefan Nobis
2021-10-02 19:20 12% ` Juan Manuel Macías
2021-10-03 15:28 5% [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Juan Manuel Macías
2021-10-03 17:39 2% [PATCH] org-manual.org: List the languages supported by smart quotes feature Juan Manuel Macías
2021-10-25 13:56 6% ` Ihor Radchenko
2021-10-04 14:27 8% [patch] ox-html.el: add html attribute (verse numbers) to verse blocks Juan Manuel Macías
2021-10-06 15:18 how to export to odt with 11 or 10 pt fonts? Default font setting Uwe Brauer
2021-10-07 11:24 9% ` Juan Manuel Macías
2021-10-07 12:28 0% ` Uwe Brauer
2021-10-07 12:58 9% ` Juan Manuel Macías
2021-10-07 12:59 0% ` Peter Neilson
2021-10-07 14:57 8% [tip] Go to the org node from the attached directory Juan Manuel Macías
2021-10-09 21:17 how to export to odt with 11 or 10 pt fonts? Default font setting copropriete27ruemoret
2021-10-10 2:52 7% ` Juan Manuel Macías
2021-10-15 16:56 7% [minor tip] "TeXify" strings "TeX" and "LaTeX" when exporting to HTML Juan Manuel Macías
2021-10-18 20:37 Unable to configure emacs 27.2 to use org 9.5 Detlef Steuer
2021-10-18 22:28 13% ` Juan Manuel Macías
2021-10-19 8:32 5% ` [mostly solved] " Detlef Steuer
2021-10-20 14:57 13% Fancy underlines in Org to LaTeX Juan Manuel Macías
2021-10-22 15:01 10% [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt) Juan Manuel Macías
2021-10-22 23:27 Sub-figures in Org Mode Jason Ross
2021-10-23 0:00 10% ` Juan Manuel Macías
2021-10-26 17:46 5% ` Jason Ross
2021-10-30 14:28 10% ` Juan Manuel Macías
2021-10-24 14:23 9% A quick LaTeX reference guide in Org Juan Manuel Macías
2021-10-24 20:18 6% ` Tim Cross
2021-10-25 11:35 10% ` Juan Manuel Macías
2021-10-25 12:30 6% ` Eric S Fraga
2021-10-25 12:58 0% ` John Hendy
2021-10-25 14:10 10% ` Juan Manuel Macías
2021-10-25 0:42 7% ` Thomas S. Dye
2021-10-26 16:05 9% [patch] ox-latex.el: add `:options' LaTeX attribute to tables Juan Manuel Macías
2021-10-27 3:44 ` Vikas Rawal
2021-10-27 15:52 7% ` Juan Manuel Macías
2021-10-28 16:10 ` Vikas Rawal
2021-10-28 18:02 6% ` Juan Manuel Macías
2021-10-28 19:39 13% ` Juan Manuel Macías
2021-11-03 16:32 6% ` Nicolas Goaziou
2021-11-03 17:38 10% ` Juan Manuel Macías
2021-11-03 18:33 6% ` Nicolas Goaziou
2021-11-04 20:59 6% ` Juan Manuel Macías
2021-11-06 13:51 6% ` Nicolas Goaziou
2021-10-30 11:51 Introducing Org-transclusion Noboru Ota
2021-10-30 12:31 10% ` Juan Manuel Macías
2021-11-01 9:17 6% ` Noboru Ota
2021-11-09 16:25 7% A function to include a PDF with LaTeX commands for specific pages Juan Manuel Macías
2021-11-12 22:35 whitespace in org source files excalamus--- via General discussions about Org-mode.
2021-11-13 12:57 10% ` Juan Manuel Macías
2021-11-14 17:08 Should be possible to export list items emphasized by default? Ypo
2021-11-17 13:33 9% ` Juan Manuel Macías
2021-11-17 7:36 insert automatically a reference to a section header and a link Uwe Brauer
2021-11-17 10:04 ` Eric S Fraga
2021-11-17 13:58 ` Uwe Brauer
2021-11-17 14:06 ` John Kitchin
2021-11-17 14:15 ` Uwe Brauer
2021-11-17 14:59 ` Stefan Nobis
2021-11-17 15:42 10% ` Juan Manuel Macías
2021-11-17 15:55 ` Uwe Brauer
2021-11-17 16:29 ` Stefan Nobis
2021-11-17 18:17 10% ` Juan Manuel Macías
2021-11-17 19:00 6% ` Stefan Nobis
2021-11-21 15:36 13% org-critical-edition (new version) Juan Manuel Macías
2021-11-23 16:52 9% Dired images in an Org buffer Juan Manuel Macías
2021-11-28 19:46 "Orgdown", the new name for the syntax of Org-mode Karl Voit
2021-11-28 22:25 8% ` Juan Manuel Macías
2021-11-28 22:57 ` Tom Gillespie
2021-11-28 23:16 ` Joost Kremers
2021-11-29 3:25 10% ` Juan Manuel Macías
2021-11-29 7:13 5% ` Dr. Arne Babenhauserheide
2021-11-29 5:41 6% ` Marcin Borkowski
2021-11-29 12:18 9% ` Juan Manuel Macías
2021-11-29 12:36 6% ` Marcin Borkowski
2021-11-28 22:42 ` Tim Cross
2021-11-29 13:19 ` Karl Voit
2021-11-29 18:27 ` M. ‘quintus’ Gülker
2021-11-30 20:44 ` Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode) Karl Voit
2021-12-01 0:41 ` Tom Gillespie
2021-12-01 3:28 9% ` Orgdown: negative feedback & attempt of a root-cause analysis Juan Manuel Macías
2021-11-30 16:28 how to export red colored TeX to latex Uwe Brauer
2021-11-30 16:56 9% ` Juan Manuel Macías
2021-11-30 17:11 ` Uwe Brauer
2021-11-30 17:43 10% ` Juan Manuel Macías
2021-12-01 6:28 ` Eric S Fraga
2021-12-01 15:00 10% ` Juan Manuel Macías
2021-12-01 15:02 6% ` Eric S Fraga
2021-12-02 10:50 Org-syntax: Intra-word markup Denis Maier
2021-12-02 11:18 ` Ihor Radchenko
2021-12-02 11:30 10% ` Juan Manuel Macías
2021-12-02 11:36 7% ` Denis Maier
2021-12-02 11:42 ` Marco Wahl
2021-12-02 11:50 ` Denis Maier
2021-12-02 12:10 ` Ihor Radchenko
2021-12-02 12:40 ` Denis Maier
2021-12-02 12:54 ` Ihor Radchenko
2021-12-02 13:14 9% ` Juan Manuel Macías
2021-12-02 13:28 7% ` Denis Maier
2021-12-02 12:00 5% ` Ihor Radchenko
2021-12-02 12:28 0% ` Denis Maier
2021-12-02 11:58 ` Timothy
2021-12-02 12:26 ` Denis Maier
2021-12-02 13:07 ` Ihor Radchenko
2021-12-02 15:51 ` Max Nikulin
2021-12-02 18:11 ` Tom Gillespie
2021-12-02 19:09 9% ` Juan Manuel Macías
2021-12-04 13:07 5% ` Org-syntax: emphasis and not English punctuation Max Nikulin
2021-12-04 16:42 9% ` Juan Manuel Macías
2021-12-02 19:03 ` Org-syntax: Intra-word markup Nicolas Goaziou
2021-12-02 19:34 9% ` Juan Manuel Macías
2021-12-02 23:05 6% ` Nicolas Goaziou
2021-12-02 23:24 9% ` Juan Manuel Macías
2021-12-03 14:24 ` Max Nikulin
2021-12-03 15:01 9% ` Juan Manuel Macías
2021-12-04 15:57 ` Denis Maier
2021-12-04 17:53 ` Tom Gillespie
2021-12-04 18:37 ` John Kitchin
2021-12-04 21:16 9% ` Juan Manuel Macías
2021-12-06 10:57 ` Raw Org AST snippets for "impossible" markup Max Nikulin
2021-12-06 15:45 8% ` Juan Manuel Macías
2021-12-06 16:56 13% ` Juan Manuel Macías
2021-12-08 13:09 4% ` Max Nikulin
2021-12-08 23:19 9% ` Juan Manuel Macías
2021-12-08 23:35 6% ` John Kitchin
2021-12-09 7:01 5% ` Juan Manuel Macías
2021-12-09 14:56 4% ` Max Nikulin
2021-12-09 16:11 6% ` Juan Manuel Macías
2021-12-09 22:27 12% ` Juan Manuel Macías
2022-01-03 14:34 3% ` Max Nikulin
2021-12-03 12:48 8% On zero width spaces and Org syntax Juan Manuel Macías
2021-12-03 19:03 ` Greg Minshall
2021-12-03 20:30 9% ` Juan Manuel Macías
2021-12-03 21:48 3% ` Tim Cross
2021-12-04 1:26 6% ` Juan Manuel Macías
2021-12-04 4:04 ` Tom Gillespie
2021-12-04 5:29 5% ` Juan Manuel Macías
2021-12-04 6:43 5% ` Marcin Borkowski
2021-12-05 7:35 Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Ihor Radchenko
2021-12-05 9:16 9% ` Juan Manuel Macías
2021-12-05 10:24 5% ` Ihor Radchenko
2021-12-05 11:08 9% ` Juan Manuel Macías
2021-12-05 11:54 6% ` Heinz Tuechler
2021-12-05 12:08 3% ` Ihor Radchenko
2021-12-05 13:32 0% ` Tim Cross
2021-12-05 18:59 6% ` Juan Manuel Macías
2021-12-05 23:24 4% ` Russell Adams
2021-12-06 5:57 10% ` Juan Manuel Macías
2021-12-06 6:02 ` Timothy
2021-12-06 7:24 9% ` Juan Manuel Macías
2021-12-06 10:04 ` Greg Minshall
2021-12-06 14:59 9% ` Juan Manuel Macías
2021-12-05 13:06 4% ` Tim Cross
2021-12-08 20:03 12% Making a dictionary in Org Juan Manuel Macías
2021-12-08 23:13 6% ` Thomas S. Dye
2021-12-16 5:16 format/fill of text in a cell in tables George Michaelson
2021-12-16 9:45 ` Ihor Radchenko
2021-12-16 21:51 ` Tim Cross
2021-12-17 8:23 ` tomas
2021-12-17 12:11 ` Tim Cross
2021-12-17 18:46 ` tomas
2021-12-17 21:25 6% ` Juan Manuel Macías
2021-12-18 7:27 ` Uwe Brauer
2021-12-18 11:09 8% ` Juan Manuel Macías
2021-12-23 16:11 text after sub headings? Robert Nikander
2021-12-23 20:27 8% ` Juan Manuel Macías
2021-12-24 16:51 4% ` Max Nikulin
2021-12-24 20:17 5% ` Juan Manuel Macías
2021-12-25 13:15 4% ` Max Nikulin
2021-12-26 9:17 8% ` Juan Manuel Macías
2021-12-23 21:21 5% Robert Nikander
2021-12-23 21:47 0% ` John Kitchin
2021-12-23 22:10 6% ` Juan Manuel Macías
2021-12-27 1:22 caption width in LateX export Seb
2021-12-27 7:41 10% ` Juan Manuel Macías
2021-12-27 9:09 12% ` Juan Manuel Macías
2021-12-27 12:53 6% ` Sebastian P. Luque
2021-12-27 13:28 8% ` Juan Manuel Macías
2021-12-27 17:16 6% ` Sebastian P. Luque
2021-12-27 19:28 5% ` Juan Manuel Macías
2021-12-31 10:14 10% [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
2021-12-31 11:08 12% ` Juan Manuel Macías
2021-12-31 11:13 5% ` Ihor Radchenko
2021-12-31 11:31 10% ` Juan Manuel Macías
2021-12-31 14:43 4% ` [PATCH] " Ihor Radchenko
2022-01-01 11:28 10% ` Juan Manuel Macías
2022-01-04 10:14 9% A simple Lua filter for Pandoc Juan Manuel Macías
2022-01-04 11:26 ` Timothy
2022-01-04 15:11 10% ` Juan Manuel Macías
2022-01-04 14:05 6% ` Max Nikulin
2022-01-04 15:06 5% ` Juan Manuel Macías
2022-01-05 16:29 5% ` Max Nikulin
2022-01-05 17:08 9% ` Juan Manuel Macías
2022-01-07 14:29 5% ` Max Nikulin
2022-01-07 15:14 8% ` Juan Manuel Macías
2022-01-04 16:28 6% ` Thomas S. Dye
2022-01-05 2:09 Tool to compare and choose fonts Ypo
2022-01-05 10:16 10% ` Juan Manuel Macías
2022-01-06 17:00 Way to mark contents of an Org special block as verbatim? Kaushal Modi
2022-01-06 18:27 9% ` Juan Manuel Macías
2022-01-06 19:14 5% ` Kaushal Modi
2022-01-06 19:33 6% ` Juan Manuel Macías
2022-01-06 19:46 5% ` Kaushal Modi
2022-01-08 21:52 0% ` Berry, Charles
2022-01-07 0:41 9% Filter to put decorative initial letters Juan Manuel Macías
2022-01-11 0:43 6% ` William Denton
2022-01-11 16:21 10% ` Juan Manuel Macías
2022-01-08 11:32 9% [tip] Inline tasks as anonymous sections Juan Manuel Macías
2022-01-08 13:09 6% ` Marcin Borkowski
2022-01-09 7:13 6% ` Ihor Radchenko
2022-01-09 18:02 Org Syntax Specification Timothy
2022-01-15 12:40 ` Sébastien Miquel
2022-01-15 16:36 ` Depreciating TeX-style LaTeX fragments (was: Org Syntax Specification) Timothy
2022-01-16 8:08 ` Sébastien Miquel
2022-01-16 9:46 ` Depreciating TeX-style LaTeX fragments Colin Baxter 😺
2022-01-16 13:26 9% ` Juan Manuel Macías
2022-01-16 14:43 0% ` Colin Baxter 😺
2022-01-10 16:47 8% Preview fonts from Dired with org-latex-preview (and test opentype features) Juan Manuel Macías
2022-01-18 20:50 6% ` Ken Mankoff
2022-01-12 13:08 puzzled about :fit for LaTeX src block Eric S Fraga
2022-01-12 17:22 10% ` Juan Manuel Macías
2022-01-13 10:14 6% ` Eric S Fraga
2022-01-13 11:17 10% ` Juan Manuel Macías
2022-01-13 12:05 6% ` Eric S Fraga
2022-01-13 15:41 8% ` Juan Manuel Macías
2022-01-13 16:14 6% ` Eric S Fraga
2022-01-13 18:27 Playing down the text in org-mode fatiparty--- via General discussions about Org-mode.
2022-01-13 18:50 10% ` Juan Manuel Macías
2022-01-13 19:04 ` John Kitchin
2022-01-13 19:19 6% ` Juan Manuel Macías
[not found] ` <87bl0feahc.fsf@posteo.net-MtJnHBm----2>
2022-01-13 19:15 ` fatiparty--- via General discussions about Org-mode.
2022-01-13 19:42 5% ` Juan Manuel Macías
2022-01-13 19:53 ` fatiparty--- via General discussions about Org-mode.
2022-01-13 20:20 9% ` Juan Manuel Macías
[not found] ` <87iluncrr6.fsf@posteo.net-MtK5wx2----2>
2022-01-13 20:53 ` fatiparty--- via General discussions about Org-mode.
2022-01-13 21:39 10% ` Juan Manuel Macías
2022-01-14 9:41 6% ` Eric S Fraga
[not found] ` <874k66irh4.fsf@ucl.ac.uk-MtMyJM6----2>
2022-01-14 13:03 0% ` fatiparty--- via General discussions about Org-mode.
[not found] ` <87o84efnqk.fsf@ucl.ac.uk-MtNobqT----2>
2022-01-14 13:44 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 14:13 ` Eric S Fraga
2022-01-14 19:27 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 20:00 9% ` Juan Manuel Macías
2022-01-14 20:25 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 20:41 6% ` Juan Manuel Macías
2022-01-14 20:45 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 20:57 6% ` Juan Manuel Macías
[not found] ` <87zgnydp8d.fsf@posteo.net-MtPKW6j----2>
2022-01-14 21:00 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 21:16 6% ` Juan Manuel Macías
[not found] ` <87r19adnm9.fsf@posteo.net-MtPRzO3----2>
2022-01-14 22:01 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 22:23 6% ` Juan Manuel Macías
2022-01-14 22:31 ` fatiparty--- via General discussions about Org-mode.
2022-01-14 22:44 6% ` Juan Manuel Macías
[not found] ` <878rvjco35.fsf@posteo.net-MtKOBaG----2>
2022-01-13 22:45 ` fatiparty--- via General discussions about Org-mode.
2022-01-13 23:08 6% ` Juan Manuel Macías
2022-01-15 18:04 org-->html text between @ should be red Uwe Brauer
2022-01-15 18:21 10% ` Juan Manuel Macías
2022-01-15 19:39 0% ` Uwe Brauer
2022-01-15 19:59 10% ` Juan Manuel Macías
2022-01-15 20:24 0% ` Uwe Brauer
2022-01-15 20:58 9% ` Juan Manuel Macías
2022-01-15 21:01 0% ` Uwe Brauer
2022-01-16 16:42 9% [ann] org-font-spec-preview (preview fonts and test open type features) Juan Manuel Macías
2022-01-17 14:14 latex block tikz to svg Edouard Debry
2022-01-17 16:01 9% ` Juan Manuel Macías
2022-01-20 8:43 change the fontsize when exporting to HTML, header not really changed Uwe Brauer
2022-01-20 11:48 10% ` Juan Manuel Macías
2022-01-20 16:14 1% ` Uwe Brauer
2022-01-20 17:56 10% ` Juan Manuel Macías
2022-01-21 17:21 0% ` Uwe Brauer
2022-01-20 14:33 Exporting Org file to Html with collapsable headings ZIPING CHEN
2022-01-21 12:23 10% ` Juan Manuel Macías
2022-01-21 16:46 6% ` Max Nikulin
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).