* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
@ 2024-02-11 11:04 12% ` Juan Manuel Macías
2024-04-15 12:21 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-11 11:04 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> I agree it does not take advantage of the AUTO facility here, but I
> nevertheless think it would
> be interesting to show people how to do this. Until we expand the AUTO
> facility to cope with
> all quirks of multi-language in pdflatex (lualatex and xetex are a
> different pair of shoes), a quick
> and dirty alternative may be helpful for people. The introductory text
> could be
Pedro, the only problem I see with that is that it is an example of
LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in
the entire section it's already made clear enough what it's used for.
Perhaps a brief reminder (the AUTO facility of the previous examples
is very limited) could be added first, and that if the users want to
obtain more complex, or more specific results (like the case you
exemplify for pdfLaTeX) they must put explicit LaTeX code, using
LaTeX_header. And then your example would come, but emphasizing that the
LaTeX documentation must be consulted. wdyt?
My point is that if we abuse examples of this type (at the expense of
"#+latex_header:something"), or "how is this done in LaTeX?", in the end
a LaTeX manual is made instead of Org.
I'm glad you enjoyed the jump to LuaTeX. :-)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [patch] Add two new header args to LaTeX block
@ 2024-02-11 14:43 5% ` Ihor Radchenko
2024-02-11 20:01 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-11 14:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Considering that 'imagemagick is one of the variants in
>> `org-preview-latex-process-alist', it might be reasonable to allow
>> :process imagemagick == :imagemagick yes
>
> I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
> Instead, «:process 'imagemagick» depends on:
>
> (imagemagick :programs
> ...
Agree.
>> Also, it feels incomplete to be able to define latex command for :file
>> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
>
> The ".png" method without ":imagemagick" does not depend on
> 'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
> depends on the value of 'org-preview-latex-default-process':
> ...
> If you put :file foo.png without :imagemagick, and want to control the
> process or change the compiler, you can do it with:
>
> :process '(foo :latex-compiler ("some LaTeX command"))
>
> since this syntax is what org-preview-latex-default-process expects.
>
> In all other cases, including :imagemagick, the compilation process
> depends on the value of org-latex-pdf-process.
Got it.
Although, it is confusing to have different formats of :process
value depending on :file extension.
It would make things easier for users if
:results file :file foo.png :process '("lualatex -interaction nonstopmode
-output-directory %o %f")
worked as expected, automatically overriding :latex-compiler value in
let-bound `org-preview-latex-process-alist'.
> Anyway, I don't understand why that feature option (convert to an image
> without :imagemagick method) is limited to .png, when other graphic files are
> possible. I can define something like this:
>
> (setq org-preview-latex-default-process
> '(my-process
> :programs ("lualatex" "convert")
> :description "pdf > jpg"
> :image-input-type "pdf"
> :image-output-type "jpg"
> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>
> But if I put :file foo.jpg nothing happens. Maybe that part should be
> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
I agree that it should be corrected.
Moreover, it would be nice to unify handling .png and imagemagick
branches of the code.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-11 14:43 5% ` Ihor Radchenko
@ 2024-02-11 20:01 9% ` Juan Manuel Macías
2024-02-13 13:42 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-11 20:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.
Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...
The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).
The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):
TeX file --> compilation --> PDF --> conversion --> image file
The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:
TeX file --> {compilation + PDF + conversion + params.} --> image file
That is, the compilation and conversion processes along with the
parameters are included in the same pack.
> It would make things easier for users if
> :results file :file foo.png :process '("lualatex -interaction nonstopmode
> -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.
I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts
":process '(luatex etc ...)"
he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.
>> Anyway, I don't understand why that feature option (convert to an image
>> without :imagemagick method) is limited to .png, when other graphic files are
>> possible. I can define something like this:
>>
>> (setq org-preview-latex-default-process
>> '(my-process
>> :programs ("lualatex" "convert")
>> :description "pdf > jpg"
>> :image-input-type "pdf"
>> :image-output-type "jpg"
>> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
>> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>>
>> But if I put :file foo.jpg nothing happens. Maybe that part should be
>> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
>
> I agree that it should be corrected.
> Moreover, it would be nice to unify handling .png and imagemagick
> branches of the code.
I agree. In any case, I still think that the coexistence of two methods
to convert to images, when one of the methods has a scheme so different
from the rest, becomes difficult: for the user as well as for
maintaining the code.
The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inconveniences. We should see
what more users think.
Another possibility is to clarify the names a little more (for the user):
:image-conv [possible values: default, imagemagick (= :imagemagick yes)]
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 9%]
* Re: "Full Block" character in example block not visible in Beamer PDF
@ 2024-02-12 11:06 12% ` Juan Manuel Macías
2024-02-12 12:40 6% ` Loris Bennett
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-12 11:06 UTC (permalink / raw)
To: Loris Bennett; +Cc: Org Mode Mailing List
Loris Bennett writes:
> The blocks of the histogram are present in the PDF, but are white, like
> the background of the slides. I can see this by marking them with the
> mouse.
>
> Does anyone know what I need to do to make the full block character
> visible in this situation?
Do you compile your document with pdfLaTeX?
It looks like you're using a Unicode character (FULL BLOCK / #2588 /
descomp: █ #2588) that pdfLaTeX doesn't recognize. You would have to use
LuaTeX or XeTeX as a TeX engine. And load the fontspec package to manage
the ttf or otf fonts. Additionally, you must define a mono font that
contains that character, for example Ubuntu Mono. An example:
#+TITLE: Some title
#+AUTHOR: author
#+Beamer_Header:\usepackage{fontspec}
#+Beamer_Header:\setsansfont{Linux Biolinum O}
#+Beamer_Header:\setmonofont{Ubuntu Mono}
#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: Boadilla
#+COLUMNS: %45ITEM %10BEAMER_ENV(Env) %10BEAMER_ACT(Act) %4BEAMER_COL(Col)
Screenshot:
https://i.imgur.com/ulYxJgr.png
Bonus: To check which fonts on your system contain a certain character,
you can use the TeX live tool Albatross. E.g.:
albatross █ --border-style 0 --detailed --show-styles --include-tex-fonts
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: "Full Block" character in example block not visible in Beamer PDF
2024-02-12 11:06 12% ` Juan Manuel Macías
@ 2024-02-12 12:40 6% ` Loris Bennett
0 siblings, 0 replies; 144+ results
From: Loris Bennett @ 2024-02-12 12:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org Mode Mailing List
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Loris Bennett writes:
>
>> The blocks of the histogram are present in the PDF, but are white, like
>> the background of the slides. I can see this by marking them with the
>> mouse.
>>
>> Does anyone know what I need to do to make the full block character
>> visible in this situation?
>
> Do you compile your document with pdfLaTeX?
Yes.
> It looks like you're using a Unicode character (FULL BLOCK / #2588 /
> descomp: █ #2588) that pdfLaTeX doesn't recognize. You would have to use
> LuaTeX or XeTeX as a TeX engine. And load the fontspec package to manage
> the ttf or otf fonts. Additionally, you must define a mono font that
> contains that character, for example Ubuntu Mono. An example:
>
> #+TITLE: Some title
> #+AUTHOR: author
>
> #+Beamer_Header:\usepackage{fontspec}
> #+Beamer_Header:\setsansfont{Linux Biolinum O}
> #+Beamer_Header:\setmonofont{Ubuntu Mono}
> #+LATEX_CLASS: beamer
> #+LATEX_CLASS_OPTIONS: [presentation]
> #+BEAMER_THEME: Boadilla
>
> #+COLUMNS: %45ITEM %10BEAMER_ENV(Env) %10BEAMER_ACT(Act) %4BEAMER_COL(Col)
>
> Screenshot:
>
> https://i.imgur.com/ulYxJgr.png
The following seems to be sufficient for me
#+LATEX_COMPILER: xelatex
#+BEAMER_HEADER: \setmonofont{Fira Code}
Fira Code being the font for the terminal in which the histograms are
generated.
> Bonus: To check which fonts on your system contain a certain character,
> you can use the TeX live tool Albatross. E.g.:
>
> albatross █ --border-style 0 --detailed --show-styles --include-tex-fonts
Good to know.
Thanks!
Loris
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
>
--
This signature is currently under constuction.
^ permalink raw reply [relevance 6%]
* Re: Link type for pdf-tools annotations
@ 2024-02-09 12:13 6% ` Irfan S
0 siblings, 0 replies; 144+ results
From: Irfan S @ 2024-02-09 12:13 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Many times I need to "save" an annotation point in the pdf-tools
> annotations buffer. So I defined a new link type and the function to
> store it. The link is stored with the structure:
> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
> The link opens the PDF and jumps to the specific annotation. A screenshot:
FYI, there is also [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which provides similar (and additional) functionality, and is on MELPA. Thanks for sharing your code.
Irfan
^ permalink raw reply [relevance 6%]
* [patch] ox.latex.el: Add missing character warnings
@ 2024-02-12 15:24 12% Juan Manuel Macías
2024-02-12 18:15 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-12 15:24 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Rationale for the attached patch: It seems that a common problem that
users have with exporting to LaTeX is unicode characters that cannot be
represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
the warning is insidious, since the missing character warning is not
preceded by a 'warning' string.
Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1247 bytes --]
From 03c4c94c22f720e38f1ffb180aaa8a23abd90406 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..80d992160 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+ ("LaTeX Error: Unicode character" . "[character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+ ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
--
2.43.1
^ permalink raw reply related [relevance 12%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 15:24 12% [patch] ox.latex.el: Add missing character warnings Juan Manuel Macías
@ 2024-02-12 18:15 12% ` Juan Manuel Macías
2024-02-12 18:26 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-12 18:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Sorry, the previous patch was incomplete. The attached patch is correct.
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Rationale for the attached patch: It seems that a common problem that
> users have with exporting to LaTeX is unicode characters that cannot be
> represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
> the warning is insidious, since the missing character warning is not
> preceded by a 'warning' string.
>
> Naturally, the added Org warnings do not solve the problem, but at least
> they give some clues on how to properly adjust the document.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1825 bytes --]
From 19fb7b81d6ce3a657c86497707f590063b27683c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..da4792c04 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+ ("LaTeX Error: Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+ ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
(save-excursion
(goto-char (point-max))
(when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
- (if (re-search-forward "^!" nil t) 'error
+ (if (and
+ (re-search-forward "^!\\(.+\\)" nil t)
+ ;; This error is passed as missing character warning
+ (not (string-match-p "Unicode character" (match-string 1))))
+ 'error
(let ((case-fold-search t)
(warnings ""))
(dolist (warning org-latex-known-warnings)
--
2.43.1
^ permalink raw reply related [relevance 12%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 18:15 12% ` Juan Manuel Macías
@ 2024-02-12 18:26 6% ` Ihor Radchenko
2024-02-12 19:17 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-12 18:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Sorry, the previous patch was incomplete. The attached patch is correct.
When I try the patch with a simple file like
Hello. 你好。
I do not see any warnings or errors indicated.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 18:26 6% ` Ihor Radchenko
@ 2024-02-12 19:17 10% ` Juan Manuel Macías
2024-02-12 19:52 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-12 19:17 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Sorry, the previous patch was incomplete. The attached patch is correct.
>
> When I try the patch with a simple file like
>
> Hello. 你好。
>
> I do not see any warnings or errors indicated.
How weird... And don't they at least appear in the *Messages* buffer?
With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
(I have used the default value of org-latex-pdf-process):
https://i.imgur.com/OPOpH5c.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 19:17 10% ` Juan Manuel Macías
@ 2024-02-12 19:52 5% ` Ihor Radchenko
2024-02-12 21:20 6% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-12 19:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> When I try the patch with a simple file like
>>
>> Hello. 你好。
>>
>> I do not see any warnings or errors indicated.
>
> How weird... And don't they at least appear in the *Messages* buffer?
> With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
> (I have used the default value of org-latex-pdf-process):
I did
1. Install your patch on top of the latest main
2. make repro
3. Open /tmp/1.org and enter
Hello. 你好.
4. C-c C-e l o
In *Messages* I see
For information about GNU Emacs and the GNU system, type C-h C-a.
Org mode version 9.7-pre (release_9.6.18-1196-g8bd0dd @ /home/yantar92/Git/org-mode/lisp/)
(New file)
Making completion list... [3 times]
Loading quail/PY (native compiled elisp)...done
Saving file /tmp/1.org...
Wrote /tmp/1.org
Wrote /tmp/1.tex
Processing LaTeX file 1.tex...
PDF file produced.
Running xdg-open /tmp/1.pdf...done
My `org-latex-pdf-process' is
("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
since I have latexmk installed.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 19:52 5% ` Ihor Radchenko
@ 2024-02-12 21:20 6% ` Juan Manuel Macías
2024-02-13 14:29 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-12 21:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> When I try the patch with a simple file like
>>>
>>> Hello. 你好。
>>>
>>> I do not see any warnings or errors indicated.
>>
>> How weird... And don't they at least appear in the *Messages* buffer?
>> With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
>> (I have used the default value of org-latex-pdf-process):
>
> I did
>
> 1. Install your patch on top of the latest main
> 2. make repro
> 3. Open /tmp/1.org and enter
> Hello. 你好.
> 4. C-c C-e l o
>
> In *Messages* I see
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Org mode version 9.7-pre (release_9.6.18-1196-g8bd0dd @ /home/yantar92/Git/org-mode/lisp/)
> (New file)
> Making completion list... [3 times]
> Loading quail/PY (native compiled elisp)...done
> Saving file /tmp/1.org...
> Wrote /tmp/1.org
> Wrote /tmp/1.tex
> Processing LaTeX file 1.tex...
> PDF file produced.
> Running xdg-open /tmp/1.pdf...done
>
> My `org-latex-pdf-process' is
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
> since I have latexmk installed.
I have done the same, on a clean Emacs init. Warning appears.
And in *Messages*:
PDF file produced with warnings: [unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]
In *Org PDF LaTeX Output*:
! LaTeX Error: Unicode character 你 (U+4F60)
not set up for use with LaTeX.
(this error is the one that passes as a warning in my patch when
compiled with pdfLaTeX).
^ permalink raw reply [relevance 6%]
* Re: Retaking AUTO for \usepackage{fontenc}
@ 2024-02-13 11:57 13% ` Juan Manuel Macías
2024-02-13 16:47 6% ` Pedro Andres Aranda Gutierrez
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-13 11:57 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> Hi,
>
> Next step, @all, please help me filling up the list of codings vs.
> languages. I currently am somehow confident of the following:
>
> greek -> LGR
> russian -> T2A
The information is in the encguide PDF (you can run texdoc fontenc or
texdoc encguide). You should look especially at section 2.3 256 glyph
encodings. I don't know if some languages require more than one
encoding. Cyrillic appears to be T2A, T2B and T2C. T4 is for
"The African Latin fonts contain in their lower half (0–127) the same
characters as the European Latin (T1-encoded) Fonts, while in their
upper half (128–255) they contain letters and symbols for African
languages that use extended Latin alphabets."
etc.
But I can't find a simpler list anywhere.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-11 20:01 9% ` Juan Manuel Macías
@ 2024-02-13 13:42 5% ` Ihor Radchenko
2024-02-13 20:25 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-13 13:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Moreover, it would be nice to unify handling .png and imagemagick
>> branches of the code.
>
> I agree. In any case, I still think that the coexistence of two methods
> to convert to images, when one of the methods has a scheme so different
> from the rest, becomes difficult: for the user as well as for
> maintaining the code.
>
> The first solution that occurs to me (I'm afraid it's too radical) is to
> leave only the :imagemagick method, and maintain the possibility of
> using the other one through a variable. Something like
> org-babel-latex-default-image-conversion-method or something similar.
> But I suppose this could cause unwanted inconveniences. We should see
> what more users think.
I am not sure.
Conceptually, .png method is more flexible than imagemagick - it uses
`org-create-formula-image' that is handling (1) preamble; (2) conversion
not only to png but to svg and other arbitrary formats.
ob-latex is duplicating org-create-formula-image code, layering custom
latex preamble and more commands on top.
So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
use of `org-create-formula-image', possibly extending it to fit ob-latex
needs.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-12 21:20 6% ` Juan Manuel Macías
@ 2024-02-13 14:29 5% ` Ihor Radchenko
2024-02-13 16:01 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-13 14:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>>> When I try the patch with a simple file like
>>>>
>>>> Hello. 你好。
>>>>
>>>> I do not see any warnings or errors indicated.
>>
>> I did
>> ...
>
> I have done the same, on a clean Emacs init. Warning appears.
>
> And in *Messages*:
>
> PDF file produced with warnings: [unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]
>
> In *Org PDF LaTeX Output*:
>
> ! LaTeX Error: Unicode character 你 (U+4F60)
> not set up for use with LaTeX.
>
> (this error is the one that passes as a warning in my patch when
> compiled with pdfLaTeX).
Probably something to do with my Texlive technically having Chinese
support.
I am getting
! Package inputenc Error: Unicode character 你 (U+4F60)
(inputenc) not set up for use with LaTeX.
See the inputenc package documentation for explanation.
Type H <return> for immediate help.
...
l.28 Hello. 你
好.
! Package inputenc Error: Unicode character 好 (U+597D)
(inputenc) not set up for use with LaTeX.
See the inputenc package documentation for explanation.
Type H <return> for immediate help.
...
l.28 Hello. 你好
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-13 14:29 5% ` Ihor Radchenko
@ 2024-02-13 16:01 11% ` Juan Manuel Macías
2024-02-14 14:37 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-13 16:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
Ihor Radchenko writes:
> Probably something to do with my Texlive technically having Chinese
> support.
>
> I am getting
>
> ! Package inputenc Error: Unicode character 你 (U+4F60)
> (inputenc) not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type H <return> for immediate help.
> ...
>
> l.28 Hello. 你
> 好.
>
> ! Package inputenc Error: Unicode character 好 (U+597D)
> (inputenc) not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type H <return> for immediate help.
> ...
>
> l.28 Hello. 你好
I have fixed the org-latex-known-warnings regexp in the attached patch.
I think it should work fine now...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1816 bytes --]
From 742d67f2e8d4f1896d89f7543948facd65687ffe Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 13 Feb 2024 16:56:23 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..2fdc2afe8 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+ ("^!.+Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+ ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
(save-excursion
(goto-char (point-max))
(when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
- (if (re-search-forward "^!" nil t) 'error
+ (if (and
+ (re-search-forward "^!\\(.+\\)" nil t)
+ ;; This error is passed as missing character warning
+ (not (string-match-p "Unicode character" (match-string 1))))
+ 'error
(let ((case-fold-search t)
(warnings ""))
(dolist (warning org-latex-known-warnings)
--
2.43.1
^ permalink raw reply related [relevance 11%]
* Re: Retaking AUTO for \usepackage{fontenc}
2024-02-13 11:57 13% ` Juan Manuel Macías
@ 2024-02-13 16:47 6% ` Pedro Andres Aranda Gutierrez
2024-02-13 17:22 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Pedro Andres Aranda Gutierrez @ 2024-02-13 16:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
Hi Juan,
neither do I, This is why I'm asking for people to tell me what they use ;-)
best, /PA
On Tue, 13 Feb 2024 at 12:57, Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Pedro Andres Aranda Gutierrez writes:
>
> > Hi,
> >
> > Next step, @all, please help me filling up the list of codings vs.
> > languages. I currently am somehow confident of the following:
> >
> > greek -> LGR
> > russian -> T2A
>
> The information is in the encguide PDF (you can run texdoc fontenc or
> texdoc encguide). You should look especially at section 2.3 256 glyph
> encodings. I don't know if some languages require more than one
> encoding. Cyrillic appears to be T2A, T2B and T2C. T4 is for
>
> "The African Latin fonts contain in their lower half (0–127) the same
> characters as the European Latin (T1-encoded) Fonts, while in their
> upper half (128–255) they contain letters and symbols for African
> languages that use extended Latin alphabets."
>
> etc.
>
> But I can't find a simpler list anywhere.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos,
> diseño editorial y ortotipografía
>
>
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
[-- Attachment #2: Type: text/html, Size: 2144 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Retaking AUTO for \usepackage{fontenc}
2024-02-13 16:47 6% ` Pedro Andres Aranda Gutierrez
@ 2024-02-13 17:22 11% ` Juan Manuel Macías
2024-02-14 14:55 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-13 17:22 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List
Pedro Andres Aranda Gutierrez writes:
> neither do I, This is why I'm asking for people to tell me what they
> use ;-)
The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:
<your-texmf-dist-root>/tex/generic/babel/locale/
There you have all the information by language. For example, in
babel-fr.ini:
8<--------------------------------------------------------------
; This file is part of babel. For further details see:
; https://www.ctan.org/pkg/babel
; Data has been collected mainly from the following sources:
; * babel language styles (license LPPL):
; https://www.ctan.org/pkg/babel-contrib
; * Common Locale Data Repository (license Unicode):
; http://cldr.unicode.org/
; http://unicode.org/copyright.html
[identification]
charset = utf8
version = 0.981
date = 2022-05-14
name.local = français
name.english = French
name.babel = french
name.polyglossia = french
tag.bcp47 = fr
language.tag.bcp47 = fr
tag.bcp47.likely = fr-Latn-FR
tag.opentype = FRA
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1 <==========================================
derivate = no
.....
-------------------------------------------------------------->8
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-13 13:42 5% ` Ihor Radchenko
@ 2024-02-13 20:25 11% ` Juan Manuel Macías
2024-02-18 14:20 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-13 20:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Moreover, it would be nice to unify handling .png and imagemagick
>>> branches of the code.
>>
>> I agree. In any case, I still think that the coexistence of two methods
>> to convert to images, when one of the methods has a scheme so different
>> from the rest, becomes difficult: for the user as well as for
>> maintaining the code.
>>
>> The first solution that occurs to me (I'm afraid it's too radical) is to
>> leave only the :imagemagick method, and maintain the possibility of
>> using the other one through a variable. Something like
>> org-babel-latex-default-image-conversion-method or something similar.
>> But I suppose this could cause unwanted inconveniences. We should see
>> what more users think.
>
> I am not sure.
> Conceptually, .png method is more flexible than imagemagick - it uses
> `org-create-formula-image' that is handling (1) preamble; (2) conversion
> not only to png but to svg and other arbitrary formats.
> ob-latex is duplicating org-create-formula-image code, layering custom
> latex preamble and more commands on top.
> So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
> use of `org-create-formula-image', possibly extending it to fit ob-latex
> needs.
It is true that the "org-create-formula-image" method is much more
complete. But, IMHO, I think it's a method focused on the buffer (rather
than the block) or previewing LaTeX code in the buffer. In the case of
the LaTeX block, I think the :imagemagick method is simpler. It depends
on two simple processes: imagemagick and org-latex-pdf-process and
parameters such as the width or height of the generated image, the
density in dpi, etc. can be easily applied, via arguments. In the case
of the other method, in addition to the value of
org-preview-latex-default-process, there is that of
org-format-latex-options. There are, in short, many parameters that are
perfect for a file or an Emacs session but for a simple block I find
overhelming.
In any case, if the org-create-formula-image method is going to stay, I
think it is fine as it is (except for extending the allowed file formats
to more extensions, and not only .png). I also believe that the :process
argument is sufficient for the user to control the value of
org-latex-pdf-process or org-preview-latex-default-process, as
appropriate.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [patch] ox.latex.el: Add missing character warnings
2024-02-13 16:01 11% ` Juan Manuel Macías
@ 2024-02-14 14:37 6% ` Ihor Radchenko
0 siblings, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-02-14 14:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have fixed the org-latex-known-warnings regexp in the attached patch.
> I think it should work fine now...
Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9eec4af62
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Retaking AUTO for \usepackage{fontenc}
2024-02-13 17:22 11% ` Juan Manuel Macías
@ 2024-02-14 14:55 6% ` Ihor Radchenko
2024-02-14 22:03 13% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-14 14:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Pedro Andres Aranda Gutierrez writes:
>
>> neither do I, This is why I'm asking for people to tell me what they
>> use ;-)
>
> The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:
May it be that babel automatically loads fontenc with appropriate parameters?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Retaking AUTO for \usepackage{fontenc}
2024-02-14 14:55 6% ` Ihor Radchenko
@ 2024-02-14 22:03 13% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-14 22:03 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> neither do I, This is why I'm asking for people to tell me what they
>>> use ;-)
>>
>> The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:
>
> May it be that babel automatically loads fontenc with appropriate parameters?
AFAIK, I'm afraid it's not possible. What is possible is to be able to
select a language in the middle of the document, without declaring it
before. But you need to load fontenc and the appropriate fontencodings.
According to the babel manual (p. 8), this functionality is only limited
to Latin, Cyrillic, Greek, Arabic, Hebrew, Cherokee, Armenian, and
Georgian.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Exporting multiple #+AUTHOR keywords
@ 2024-02-17 10:34 6% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-17 10:34 UTC (permalink / raw)
To: ypuntot; +Cc: yantar92, Org-mode
ypuntot writes:
> Is it related with AUTHOR property?
> I am starting to add these properties to every book, and chapter of
> the book, that I study. I hope this doesn't lead to a suboptimal
> workflow.
>
> Doesn't this work?
>
> :PROPERTIES:
> :AUTHOR: García-Ael, Cristina and Pérez-Garín, Daniel and Recio
> Saboya, Patricia
> :BTYPE: incollection
> :BOOKTITLE: Psicología de los Grupos
> :TITLE: Métodos y Técnicas de Investigación en Psicología de
> los Grupos.
>
> :PUBLISHER: UNED
>
> :ADDRESS: C/ Bravo Murillo, 38; 28015; Madrid
> :INSTITUTION: UNED
> :YEAR: 2017
> :CHAPTER: 2
> :PAGES: 49-83
> :END:
What we are dealing with here is the keyword #+AUTHOR or the
EXPORT_AUTHOR property (when exporting a subtree), that is, the author
of the document (see 'Export settings' in the Org Manual), not the
AUTHOR property of org-ref. Your workflow is correct.
^ permalink raw reply [relevance 6%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-13 20:25 11% ` Juan Manuel Macías
@ 2024-02-18 14:20 5% ` Ihor Radchenko
2024-02-18 13:43 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-18 14:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> It is true that the "org-create-formula-image" method is much more
> complete. But, IMHO, I think it's a method focused on the buffer (rather
> than the block) or previewing LaTeX code in the buffer.
What do you mean? `org-create-formula-image' is passed a string of LaTeX
code. Note that `org-create-formula-image' is also used in HTML export.
> ... In the case of
> the LaTeX block, I think the :imagemagick method is simpler. It depends
> on two simple processes: imagemagick and org-latex-pdf-process and
> parameters such as the width or height of the generated image, the
> density in dpi, etc. can be easily applied, via arguments.
ob-latex does not have to expose all the possible toggles
`org-latex-pdf-process' has.
> ... In the case
> of the other method, in addition to the value of
> org-preview-latex-default-process, there is that of
> org-format-latex-options. There are, in short, many parameters that are
> perfect for a file or an Emacs session but for a simple block I find
> overhelming.
We can fix the parameters we do not want to expose.
> In any case, if the org-create-formula-image method is going to stay, I
> think it is fine as it is (except for extending the allowed file formats
> to more extensions, and not only .png). I also believe that the :process
> argument is sufficient for the user to control the value of
> org-latex-pdf-process or org-preview-latex-default-process, as
> appropriate.
My concern about your patch is that it creates even more divergence
between different branches of code in `org-babel-execute:latex'.
With the new proposed features only available to some code branches,
`org-babel-execute:latex' will just become more messy and harder to
maintain.
I'd prefer to refactor `org-babel-execute:latex' first, before adding
new header arguments.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-18 14:20 5% ` Ihor Radchenko
@ 2024-02-18 13:43 10% ` Juan Manuel Macías
2024-02-19 11:15 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-18 13:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> In any case, if the org-create-formula-image method is going to stay, I
>> think it is fine as it is (except for extending the allowed file formats
>> to more extensions, and not only .png). I also believe that the :process
>> argument is sufficient for the user to control the value of
>> org-latex-pdf-process or org-preview-latex-default-process, as
>> appropriate.
>
> My concern about your patch is that it creates even more divergence
> between different branches of code in `org-babel-execute:latex'.
> With the new proposed features only available to some code branches,
> `org-babel-execute:latex' will just become more messy and harder to
> maintain.
>
> I'd prefer to refactor `org-babel-execute:latex' first, before adding
> new header arguments.
org-create-formula-image inserts LaTeX code:
...
(with-temp-file texfile
(insert latex-header)
(insert "\n\\begin{document}\n"
"\\definecolor{fg}{rgb}{" fg "}%\n"
(if bg
(concat "\\definecolor{bg}{rgb}{" bg "}%\n"
"\n\\pagecolor{bg}%\n")
"")
"\n{\\color{fg}\n"
string
"\n}\n"
"\n\\end{document}\n"))
...
that, /in principle/, would make it incompatible with the :standalone
argument (in my patch), which allows writing all LaTeX code from scratch
in the block content.
Anyway, it is true that org-babel-execute:latex has grown in a somewhat
irregular way. For example, I don't quite understand why the simple
output to PDF and the conversion to an image with :imagemagick live in
the same conditional:
(or (string= "pdf" extension) imagemagick)
I would propose three main branches in this function:
- A PDF branch, using org-format-latex-header with its valid options,
and other sub-branches with conversion from the PDF, for example, the
use of :imagemagick. Or you could even think of any possible
conversion process using a hypothetical :pdf-postprocess
- A branch for orf-create-formula-image
- a third branch to export to html, with org-babel-latex-htlatex.
Having three clearly differentiated branches would make the code easier
to maintain.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: set italian language in LaTeX export
@ 2024-02-19 11:11 13% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-19 11:11 UTC (permalink / raw)
To: Luca Ferrari; +Cc: emacs-org list
Luca Ferrari writes:
> #+language: it
>
> and I correctly got in the LaTeX buffer something like:
>
> pdflang={Italian}}
>
> but not something like:
>
> \usepackage[italian]{babel}
You must load the babel package with the AUTO option:
#+language:it
#+LaTeX_Header: \usepackage[AUTO]{babel}
(see 'LaTeX header and sectioning structure' in the Org Manual)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-18 13:43 10% ` Juan Manuel Macías
@ 2024-02-19 11:15 6% ` Ihor Radchenko
2024-02-19 13:24 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-19 11:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>> new header arguments.
>
> org-create-formula-image inserts LaTeX code:
`org-create-formula-image' will be obsoleted after Timothy merges his
latex preview branch. If the new implementation turns out to be not
flexible enough, we can always refactor it further to meet ob-latex
needs.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Add two new header args to LaTeX block
2024-02-19 11:15 6% ` Ihor Radchenko
@ 2024-02-19 13:24 12% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-19 13:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' will be obsoleted after Timothy merges his
> latex preview branch. If the new implementation turns out to be not
> flexible enough, we can always refactor it further to meet ob-latex
> needs.
In that case, I think this patch could be considered canceled.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: set italian language in LaTeX export
@ 2024-02-19 15:11 13% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-19 15:11 UTC (permalink / raw)
To: Luca Ferrari; +Cc: emacs-org list
Luca Ferrari writes:
>> #+language:it
>> #+LaTeX_Header: \usepackage[AUTO]{babel}
>>
>
> Thanks, this solved the problem. Out of curiosity, why is not org-mode
> adding it automatically whenever a #+language setting is present?
> I'm just curious because it seems that, as an example, open-office
> exporting understands the language.
Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:
https://list.orgmode.org/?t=20230830082719
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* [proof of concept] inline language blocks
@ 2024-02-20 20:35 9% Juan Manuel Macías
2024-02-21 8:42 6% ` Ihor Radchenko
2024-03-31 14:56 4% ` Daniel Clemente
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-20 20:35 UTC (permalink / raw)
To: orgmode
Hi,
I'm dedicating a local branch to developing this proof of concept and
testing it in my workflow, so far with good results. The basic idea is
to provide Org with multilingual features and various methods for
selecting languages.
The inline-language-block is intended for small segments of text in a
language other than the main language. They can span several lines but
not more than a paragraph. They can be used for in-line textual quotes,
glosses, etc. They are constructions equivalent to, for example, LaTeX
\foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
I have thought of a syntax that is as least intrusive as possible, so as
not to make reading uncomfortable. I have tried the following:
:fr{some text in French} :it{some text in Italian} :la{some text in Latin}
You can also use a literal term instead of a language code:
:klingon!{some text in Klingon}
The blocks can be nested:
:klingon!{Some text in Klingon with :it{some text in Italian}}
And they may include other elements:
:el{Some text in Greek with a {{{macro}}} and a [[link]]}
To this end, I have defined the following element:
#+begin_src emacs-lisp
(defun org-element-inline-language-block-parser ()
"Parse inline language block at point.
When at an inline language block, return a new syntax node of
`inline-language-block' type containing `:begin', `:end',
`:type', `:contents-begin', `:contents-end' and `:post-blank' as
properties. Otherwise, return nil.
Assume point is at the beginning of the block."
(save-excursion
(when (looking-at ":\\([A-Za-z!]+\\){")
(goto-char (match-end 0))
(let* ((begin (match-beginning 0))
(contents-begin (match-end 0))
(type (org-element--get-cached-string
(match-string-no-properties 1)))
(contents-end
(progn
(goto-char (- contents-begin 1))
(org-element--parse-paired-brackets ?\{)
(- (point) 1)))
(post-blank (skip-chars-forward " \t"))
(end (point)))
(when contents-end
(org-element-create
'inline-language-block
(list :type type
:contents-begin contents-begin
:contents-end contents-end
:begin begin
:end end
:post-blank post-blank)))))))
(defun org-element-inline-language-block-interpreter (inline-language-block contents)
"Interpret INLINE LANGUAGE BLOCK object as Org syntax."
(format ":%s{%s}"
(org-element-property :type inline-language-block)
contents))
#+end_src
And, for now, this function for ox-latex:
#+begin_src emacs-lisp
(defun org-latex-inline-language-block (inline-language-block contents info)
"Transcode an INLINE LANGUAGE BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
(let ((type (org-element-property :type inline-language-block)))
(if (string-match-p "!" type)
(format "\\foreignlanguage{%s}{%s}"
(replace-regexp-in-string "!" "" type)
contents)
(let* ((plist (cdr
(assoc type org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
(language-ini-alt (plist-get plist :babel-ini-alt))
(lang (or language language-ini-only language-ini-alt)))
(format "\\foreignlanguage{%s}{%s}" lang contents)))))
#+end_src
Opinions, suggestions, feedback, ideas?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 9%]
* Re: [proof of concept] inline language blocks
2024-02-21 8:42 6% ` Ihor Radchenko
@ 2024-02-21 10:57 10% ` Juan Manuel Macías
2024-02-21 12:00 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-21 10:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I'm dedicating a local branch to developing this proof of concept and
>> testing it in my workflow, so far with good results. The basic idea is
>> to provide Org with multilingual features and various methods for
>> selecting languages.
>>
>> The inline-language-block is intended for small segments of text in a
>> language other than the main language. They can span several lines but
>> not more than a paragraph. They can be used for in-line textual quotes,
>> glosses, etc. They are constructions equivalent to, for example, LaTeX
>> \foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
>>
>> I have thought of a syntax that is as least intrusive as possible, so as
>> not to make reading uncomfortable. I have tried the following:
>>
>> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>>
>> You can also use a literal term instead of a language code:
>>
>> :klingon!{some text in Klingon}
>>
>> The blocks can be nested:
>>
>> :klingon!{Some text in Klingon with :it{some text in Italian}}
>>
>> And they may include other elements:
>>
>> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
>
> This is a good idea, although it would be better to make this new markup
> element within the framework of more general inline special block we
> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
Fun fact: the local branch is called inline-special-block, because I
originally had that idea in mind when I created it. Then, halfway
through, I doubted whether it wouldn't be better to have a specific
inline language selector, whose use would be as direct as an emphasis
mark. So in the branch there is also a "proto"-inline-special-block with
similar syntax: &foo{}.
I opted for the -language-block version because, as I said, its use is
very 'direct' and covers a common need to segment multilingual text
within the paragraph.
I think at the time we also discussed whether or not it would be a good
idea to provide the inline special blocks with options and attributes,
like their older brothers. And how to do it. My biggest concern here is
the (let's say) latexification of the paragraph. I mean, one of the
great things about Org versus heavier markup like LaTeX is that when org
wants to be verbose it uses dedicated lines, but usually keeps the
paragraphs clean and readable. I think that any element inside the
paragraph should tend to be as "transparent" as simple emphasis marks.
I remember that there was also discussion about puting the options
outside the paragraph, using some type of identifier. It doesn't seem
like a bad idea to me, but I think it adds an extra complication for the
user. It would be very tedious for me to write like this (even more
tedious than writing in LaTeX).
Best regards,
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [proof of concept] inline language blocks
2024-02-21 12:53 10% ` Juan Manuel Macías
@ 2024-02-21 13:10 5% ` Ihor Radchenko
2024-02-21 14:13 12% ` Juan Manuel Macías
2024-02-21 23:33 6% ` Suhail Singh
1 sibling, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-21 13:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> We need to finalize inline special block syntax first, and then talk
>> about special cases like inline language markup you propose.
>
> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block &type{text}
>
> the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
>
> I like the syntax because it is minimalist and not verbose at all. That
> could serve as a basis (at least it is good to have a starting point,
> because otherwise everything will be diluted in discussions). Then we
> can start thinking about whether to add options and how to add them.
We do not need to design the inline special block markup fully to
introduce it. However, we do need to make sure that whatever simple
version of inline markup we introduce does not prevent further planned
extensions.
My main concern is the possibility to introduce multi-argument markup.
Like @abbrev{EA}{example abbreviation}. This will be necessary to
achieve parity with Texinfo markup.
However, it is not yet clear about the best syntax to pass multiple
arguments.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [proof of concept] inline language blocks
2024-02-21 10:57 10% ` Juan Manuel Macías
@ 2024-02-21 12:00 5% ` Ihor Radchenko
2024-02-21 12:53 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-21 12:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>> This is a good idea, although it would be better to make this new markup
>> element within the framework of more general inline special block we
>> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
>
> Fun fact: the local branch is called inline-special-block, because I
> originally had that idea in mind when I created it. Then, halfway
> through, I doubted whether it wouldn't be better to have a specific
> inline language selector, whose use would be as direct as an emphasis
> mark. So in the branch there is also a "proto"-inline-special-block with
> similar syntax: &foo{}.
>
> I opted for the -language-block version because, as I said, its use is
> very 'direct' and covers a common need to segment multilingual text
> within the paragraph.
My main point is that we should use the same syntax with inline special
blocks. Similar to how #+begin_verse uses the same syntax as special
blocks.
We need to finalize inline special block syntax first, and then talk
about special cases like inline language markup you propose.
> I think at the time we also discussed whether or not it would be a good
> idea to provide the inline special blocks with options and attributes,
> like their older brothers. And how to do it. My biggest concern here is
> the (let's say) latexification of the paragraph. I mean, one of the
> great things about Org versus heavier markup like LaTeX is that when org
> wants to be verbose it uses dedicated lines, but usually keeps the
> paragraphs clean and readable. I think that any element inside the
> paragraph should tend to be as "transparent" as simple emphasis marks.
>
> I remember that there was also discussion about puting the options
> outside the paragraph, using some type of identifier. It doesn't seem
> like a bad idea to me, but I think it adds an extra complication for the
> user. It would be very tedious for me to write like this (even more
> tedious than writing in LaTeX).
I still believe that we should /allow/ options inside inline block-type
markup. This is often necessary in practice. For example, I recommend
studying
https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
and how they had to use ugly |... extensions to provide options.
But it does not mean that users /have to/ use these options. In fact, we
might design the inline language blocks to ignore options.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [proof of concept] inline language blocks
2024-02-20 20:35 9% [proof of concept] inline language blocks Juan Manuel Macías
@ 2024-02-21 8:42 6% ` Ihor Radchenko
2024-02-21 10:57 10% ` Juan Manuel Macías
2024-03-31 14:56 4% ` Daniel Clemente
1 sibling, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-02-21 8:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I'm dedicating a local branch to developing this proof of concept and
> testing it in my workflow, so far with good results. The basic idea is
> to provide Org with multilingual features and various methods for
> selecting languages.
>
> The inline-language-block is intended for small segments of text in a
> language other than the main language. They can span several lines but
> not more than a paragraph. They can be used for in-line textual quotes,
> glosses, etc. They are constructions equivalent to, for example, LaTeX
> \foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
>
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>
> You can also use a literal term instead of a language code:
>
> :klingon!{some text in Klingon}
>
> The blocks can be nested:
>
> :klingon!{Some text in Klingon with :it{some text in Italian}}
>
> And they may include other elements:
>
> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
This is a good idea, although it would be better to make this new markup
element within the framework of more general inline special block we
discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [proof of concept] inline language blocks
2024-02-21 12:00 5% ` Ihor Radchenko
@ 2024-02-21 12:53 10% ` Juan Manuel Macías
2024-02-21 13:10 5% ` Ihor Radchenko
2024-02-21 23:33 6% ` Suhail Singh
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-21 12:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
>>
>> Fun fact: the local branch is called inline-special-block, because I
>> originally had that idea in mind when I created it. Then, halfway
>> through, I doubted whether it wouldn't be better to have a specific
>> inline language selector, whose use would be as direct as an emphasis
>> mark. So in the branch there is also a "proto"-inline-special-block with
>> similar syntax: &foo{}.
>>
>> I opted for the -language-block version because, as I said, its use is
>> very 'direct' and covers a common need to segment multilingual text
>> within the paragraph.
>
> My main point is that we should use the same syntax with inline special
> blocks. Similar to how #+begin_verse uses the same syntax as special
> blocks.
>
> We need to finalize inline special block syntax first, and then talk
> about special cases like inline language markup you propose.
As I already said, in my local branch I have both elements created,
based on the same syntax:
- language block: :lang{text}
- special block &type{text}
the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
I like the syntax because it is minimalist and not verbose at all. That
could serve as a basis (at least it is good to have a starting point,
because otherwise everything will be diluted in discussions). Then we
can start thinking about whether to add options and how to add them.
>> I think at the time we also discussed whether or not it would be a good
>> idea to provide the inline special blocks with options and attributes,
>> like their older brothers. And how to do it. My biggest concern here is
>> the (let's say) latexification of the paragraph. I mean, one of the
>> great things about Org versus heavier markup like LaTeX is that when org
>> wants to be verbose it uses dedicated lines, but usually keeps the
>> paragraphs clean and readable. I think that any element inside the
>> paragraph should tend to be as "transparent" as simple emphasis marks.
>>
>> I remember that there was also discussion about puting the options
>> outside the paragraph, using some type of identifier. It doesn't seem
>> like a bad idea to me, but I think it adds an extra complication for the
>> user. It would be very tedious for me to write like this (even more
>> tedious than writing in LaTeX).
>
> I still believe that we should /allow/ options inside inline block-type
> markup. This is often necessary in practice. For example, I recommend
> studying
> https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
> and how they had to use ugly |... extensions to provide options.
>
> But it does not mean that users /have to/ use these options. In fact, we
> might design the inline language blocks to ignore options.
The wiki language is for a specific purpose, and I wouldn't consider it
a lightweight markup language, although it is certainly less thick than
html.
Actually I'm just expressing my concerns and doubts, I'm not objecting
to anything. I remember reading in the pandoc issues, a long time ago,
similar discussions every time they talked about extending the markup. I
don't know if it's a good idea to stick to a certain point to preserve
the nature of a lightweight markup language and accept certain intrinsic
limitations instead of providing options that probably have very little
use or can be resolved by some export filter. I don't have a definite
opinion, I'm just raising my doubts. Although I really value simplicity
and minimalism.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: [proof of concept] inline language blocks
2024-02-21 13:10 5% ` Ihor Radchenko
@ 2024-02-21 14:13 12% ` Juan Manuel Macías
2024-02-21 20:32 8% ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
2024-02-21 22:11 4% ` [proof of concept] inline language blocks Samuel Wales
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-21 14:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements created,
>> based on the same syntax:
>>
>> - language block: :lang{text}
>>
>> - special block &type{text}
>>
>> the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
>>
>> I like the syntax because it is minimalist and not verbose at all. That
>> could serve as a basis (at least it is good to have a starting point,
>> because otherwise everything will be diluted in discussions). Then we
>> can start thinking about whether to add options and how to add them.
>
> We do not need to design the inline special block markup fully to
> introduce it. However, we do need to make sure that whatever simple
> version of inline markup we introduce does not prevent further planned
> extensions.
My proposed syntax could be:
&type[options]{content}
> My main concern is the possibility to introduce multi-argument markup.
> Like @abbrev{EA}{example abbreviation}. This will be necessary to
> achieve parity with Texinfo markup.
> However, it is not yet clear about the best syntax to pass multiple
> arguments.
I imagine multiple arguments would depend on each backend, right?
Because I don't quite see much sense in html, for example. However, it
occurs to me to reuse content, and add some separator character:
&type[options]{arg1::arg2::etc}
or better:
&type[options and aditional args]{content}
to maintain a certain parallelism with the large blocks.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* [proof of concept] inline-special-block (was: [proof of concept] inline language blocks)
2024-02-21 14:13 12% ` Juan Manuel Macías
@ 2024-02-21 20:32 8% ` Juan Manuel Macías
2024-02-21 23:29 12% ` [proof of concept] inline-special-block Juan Manuel Macías
2024-02-22 22:03 13% ` Juan Manuel Macías
2024-02-21 22:11 4% ` [proof of concept] inline language blocks Samuel Wales
1 sibling, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-21 20:32 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
I am attaching a patch in case anyone wants to try this proposal. A
function for ox-latex is included.
Syntax:
&[optional parameters]{contents}
With this patch, something like &foo{lorem ipsum dolor} is exported to
LaTeX as \foo{lorem ipsum dolor}.
Blocks can be nested, e.g.: &foo{lorem ipsum &bar{dolor}}.
Regarding the "optional parameters", there is nothing defined, although
I think they should be adapted to each backend. A possible use that
occurs to me:
&foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}
This should produce in LaTeX:
\foo[lorem]{blah blah}{ipsum}
and in HTML:
<span class="foo" style="color:red;">blah blah</span>
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-element.el-New-element-Inline-Special-Block-proo.patch --]
[-- Type: text/x-patch, Size: 5762 bytes --]
From 587e77feb1c4e6881d527d1fd3a6e541efb596d4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block (proof of
concept).
* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
---
lisp/org-element.el | 55 ++++++++++++++++++++++++++++++++++++++++++++-
lisp/ox-latex.el | 10 +++++++++
2 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..2f9436df2 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
"\\|"))
;; Objects starting with "@": export snippets.
"@@"
+ ;; Objects starting with "&": inline-special-blocks.
+ "&"
;; Objects starting with "{": macro.
"{{{"
;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
"List of recursive element types aka Greater Elements.")
(defconst org-element-all-objects
- '(bold citation citation-reference code entity export-snippet
+ '(bold citation citation-reference code entity export-snippet inline-special-block
footnote-reference inline-babel-call inline-src-block italic line-break
latex-fragment link macro radio-target statistics-cookie strike-through
subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
;; Ignore inline babel call and inline source block as formulas
;; are possible. Also ignore line breaks and statistics
;; cookies.
+ (inline-special-block ,@standard-set)
(table-cell citation export-snippet footnote-reference link macro
radio-target target timestamp ,@minimal-set)
(table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
(org-element-property :name entity)
(when (org-element-property :use-brackets-p entity) "{}")))
+;;;; inline special block
+
+(defun org-element-inline-special-block-parser ()
+ "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties. Otherwise, return nil.
+
+Assume point is at the beginning of the block."
+ (save-excursion
+ (when (looking-at "&\\([A-Za-z]+\\)[{[]")
+ (goto-char (- (match-end 0) 1))
+ (let* ((begin (match-beginning 0))
+ (parameters
+ (let ((p (org-element--parse-paired-brackets ?\[)))
+ (and (org-string-nw-p p)
+ (replace-regexp-in-string "\n[ \t]*" " " (org-trim p)))))
+ (contents-begin (when (looking-at-p "{") (+ (point) 1)))
+ (type (org-element--get-cached-string
+ (match-string-no-properties 1)))
+ (contents-end
+ (progn
+ (goto-char (- contents-begin 1))
+ (org-element--parse-paired-brackets ?\{)
+ (- (point) 1)))
+ (post-blank (skip-chars-forward " \t"))
+ (end (point)))
+ (when contents-end
+ (org-element-create
+ 'inline-special-block
+ (list :type type
+ :parameters parameters
+ :contents-begin contents-begin
+ :contents-end contents-end
+ :begin begin
+ :end end
+ :post-blank post-blank)))))))
+
+(defun org-element-inline-special-block-interpreter (inline-special-block contents)
+ "Interpret INLINE SPECIAL BLOCK object as Org syntax."
+ (let ((type (org-element-property :type inline-special-block))
+ (opts (org-element-property :parameters inline-special-block)))
+ (format "&%s%s{%s}"
+ type
+ (if opts (format "[%s]" opts) "")
+ contents)))
;;;; Export Snippet
@@ -5260,6 +5311,8 @@ to an appropriate container (e.g., a paragraph)."
(org-element-strike-through-parser)))
(?@ (and (memq 'export-snippet restriction)
(org-element-export-snippet-parser)))
+ (?& (and (memq 'inline-special-block restriction)
+ (org-element-inline-special-block-parser)))
(?{ (and (memq 'macro restriction)
(org-element-macro-parser)))
(?$ (and (memq 'latex-fragment restriction)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..a303d54a6 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -101,6 +101,7 @@
(underline . org-latex-underline)
(verbatim . org-latex-verbatim)
(verse-block . org-latex-verse-block)
+ (inline-special-block . org-latex-inline-special-block)
;; Pseudo objects and elements.
(latex-math-block . org-latex-math-block)
(latex-matrices . org-latex-matrices))
@@ -2095,6 +2096,15 @@ holding contextual information."
center-block (format "\\begin{center}\n%s\\end{center}" contents) info))
+;;;; Inline Special Block
+
+(defun org-latex-inline-special-block (inline-special-block contents info)
+ "Transcode an INLINE SPECIAL BLOCK element from Org to LaTeX.
+CONTENTS holds the contents of the block. INFO is a plist
+holding contextual information."
+ (let ((type (org-element-property :type inline-special-block)))
+ (format "\\%s{%s}" type contents)))
+
;;;; Clock
(defun org-latex-clock (clock _contents info)
--
2.43.1
^ permalink raw reply related [relevance 8%]
* Re: [proof of concept] inline language blocks
2024-02-21 14:13 12% ` Juan Manuel Macías
2024-02-21 20:32 8% ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
@ 2024-02-21 22:11 4% ` Samuel Wales
2024-02-21 22:28 13% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Samuel Wales @ 2024-02-21 22:11 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode
at risk of being like a broken record [over many years]: i still like
cl lambda lists e.g. $[thing arg :kw value :kw value] or %(thing ...)
for allowing generality to basically all new syntax of most types,
extensibility, user-defined major ["thing"] and minor [":kw"] features
if desired to support, reduced parsing risk, ability to control
display and export and visibility and folding and other stuff like
locale or whatever, nestability, escaping/quoting, and familiar
defined syntax, all applicable to new features without having to
change anything. also, you won't have to look up how to use it much
when you use a new feature.
i'm not expressing this as well as i have in unpublished posts or
previous posts.
i might be in the minority, and it was once said that it is too
verbose. if so, i value desiderata like the above higher.
i feel org has proliferated different syntaxes and special cases a bit
too much. it's hard to have to look up what's needed, detect errors
manually etc. some of the more basic things are good with special
syntax, such as emphasis and \\. but we contend with invisible space,
variant quoting, ....
there is a school of thought that more types of syntax are usually
good; in most cases, i do not agree with that school of thought.
it's a bit like the old conflict between lisp vs. the original perl.
i never agreed with larry wall on arguments like [paraphrased,
possibly not correctly] "english is not orthogonal; lisp is, which is
bad; perl is not orthogonal; it shouldn't be because english isn't [or
perhaps for the [unspecified] reasons english isn't]". plenty of
human languages are orthogonal in places where english isn't, and i
believe they work well in those places because of, not in spite of,
that convenient orthogonality. you can know how to get the transitive
if you have the intransitve, for example. i say this despite being a
huge fan of english.
for language feature, there are various options here which range from e.g.
:fr{some text in French}
being expressed as
$[lang :fr "bonjour"]
which i think is pretty straightforward and not much more verbose,
to a more block style like this
$[lang :fr :start]
bonjour
$[lang :fr end]
and of course that "lang" can be replaced with any other new feature
we dream up, having nothing to do with languages. all the
meta-features like parsing, quoting, invisibility, folding,
nestability, extensibility will already have been worked out, and will
apply to new features and sub-features.
On 2/21/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Ihor Radchenko writes:
>
>> Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>>>> We need to finalize inline special block syntax first, and then talk
>>>> about special cases like inline language markup you propose.
>>>
>>> As I already said, in my local branch I have both elements created,
>>> based on the same syntax:
>>>
>>> - language block: :lang{text}
>>>
>>> - special block &type{text}
>>>
>>> the latter would be exported, for example, to html as <span
>>> class="type">text</span> or to LaTeX as \type{text}
>>>
>>> I like the syntax because it is minimalist and not verbose at all. That
>>> could serve as a basis (at least it is good to have a starting point,
>>> because otherwise everything will be diluted in discussions). Then we
>>> can start thinking about whether to add options and how to add them.
>>
>> We do not need to design the inline special block markup fully to
>> introduce it. However, we do need to make sure that whatever simple
>> version of inline markup we introduce does not prevent further planned
>> extensions.
>
> My proposed syntax could be:
>
> &type[options]{content}
>
>> My main concern is the possibility to introduce multi-argument markup.
>> Like @abbrev{EA}{example abbreviation}. This will be necessary to
>> achieve parity with Texinfo markup.
>> However, it is not yet clear about the best syntax to pass multiple
>> arguments.
>
> I imagine multiple arguments would depend on each backend, right?
> Because I don't quite see much sense in html, for example. However, it
> occurs to me to reuse content, and add some separator character:
>
> &type[options]{arg1::arg2::etc}
>
> or better:
>
> &type[options and aditional args]{content}
>
> to maintain a certain parallelism with the large blocks.
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 4%]
* Re: [proof of concept] inline language blocks
2024-02-21 22:11 4% ` [proof of concept] inline language blocks Samuel Wales
@ 2024-02-21 22:28 13% ` Juan Manuel Macías
2024-02-21 22:55 6% ` Samuel Wales
2024-02-21 23:02 10% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-21 22:28 UTC (permalink / raw)
To: Samuel Wales; +Cc: Ihor Radchenko, orgmode
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
>
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
Thanks for your interesting comment. However, your example still seems
too verbose to me. There are two elements that, in my opinion, get in
the way: 'lang' and "bonjour" quotes. Imagine something like this for
emphasis (mutatis mutandis):
$[emphasis :italic "text in italic"]
instead of
/text in italic/.
That simplicity is what I intend to look for with this type of elements
inside the paragraph.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [proof of concept] inline language blocks
2024-02-21 22:28 13% ` Juan Manuel Macías
@ 2024-02-21 22:55 6% ` Samuel Wales
2024-02-21 23:02 10% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Samuel Wales @ 2024-02-21 22:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode
yes as i said emphasis is convenient.
On 2/21/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Samuel Wales writes:
>
>> for language feature, there are various options here which range from
>> e.g.
>>
>> :fr{some text in French}
>>
>> being expressed as
>>
>> $[lang :fr "bonjour"]
>
> Thanks for your interesting comment. However, your example still seems
> too verbose to me. There are two elements that, in my opinion, get in
> the way: 'lang' and "bonjour" quotes. Imagine something like this for
> emphasis (mutatis mutandis):
>
> $[emphasis :italic "text in italic"]
>
> instead of
>
> /text in italic/.
>
> That simplicity is what I intend to look for with this type of elements
> inside the paragraph.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 6%]
* Re: [proof of concept] inline language blocks
2024-02-21 22:28 13% ` Juan Manuel Macías
2024-02-21 22:55 6% ` Samuel Wales
@ 2024-02-21 23:02 10% ` Juan Manuel Macías
2024-02-28 10:29 7% ` Max Nikulin
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-21 23:02 UTC (permalink / raw)
To: Samuel Wales; +Cc: Ihor Radchenko, orgmode
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
>
To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:
:fr{text in French and :it{text in Italian}}
But I would find this difficult to read:
$[lang :fr "text in French and $[lang :it "text in italian"]"]
On the other hand, the structure that I have chosen is in part inspired
by the inline code block, which is the only case of "inline block" that
we have in Org.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [proof of concept] inline-special-block
2024-02-21 20:32 8% ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
@ 2024-02-21 23:29 12% ` Juan Manuel Macías
2024-02-22 22:03 13% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-21 23:29 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
&type[optional parameters]{contents}
^ permalink raw reply [relevance 12%]
* Re: [proof of concept] inline language blocks
2024-02-21 12:53 10% ` Juan Manuel Macías
2024-02-21 13:10 5% ` Ihor Radchenko
@ 2024-02-21 23:33 6% ` Suhail Singh
1 sibling, 0 replies; 144+ results
From: Suhail Singh @ 2024-02-21 23:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block &type{text}
Why not &:lang{text} (and/or &:lang[options]{text}) instead? In fact,
it might help (in that it may reduce the need for escaping within the
"text") if the syntax was &:type{text} with "lang" being one of the
possible type (as opposed to the type being ":lang").
--
Suhail
^ permalink raw reply [relevance 6%]
* Re: [proof of concept] inline-special-block
2024-02-21 20:32 8% ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
2024-02-21 23:29 12% ` [proof of concept] inline-special-block Juan Manuel Macías
@ 2024-02-22 22:03 13% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-22 22:03 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Regarding the "optional parameters", there is nothing defined, although
> I think they should be adapted to each backend. A possible use that
> occurs to me:
>
> &foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}
>
> This should produce in LaTeX:
>
> \foo[lorem]{blah blah}{ipsum}
>
> and in HTML:
>
> <span class="foo" style="color:red;">blah blah</span>
Just to add some more ideas about parameters, I can also think of an
"anonymous" variant that only supports "universal" arguments, independent of
the backend and previously defined (and extensible by the user). For
example:
&_[:color red :smallcaps t :lang it :size small]{Lorem ipsum dolor}
Aliases could also be defined for a set of arguments:
#+OPTIONS: inlineblocks:(("myblock" :smallcaps t :color "red" :lang "fr"))
&_[:myblock t]{Lorem ipsum dolor} etc.
==> latex: {\color{red}\scshape\foreignlanguage{french}{Lorem ipsum dolor}}
Universal arguments can also be added to a normal block along with each
backend's own arguments:
&foo[:color red :prelatex [bar]]{lorem ipsum dolor}
==> latex: {\color{red}\foo[bar]{lorem ipsum dolor}}
and, of course, aliases could be combined with single arguments:
&foo[:myblock t :prelatex [bar]]{lorem ipsum dolor}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* [testing patch] inline-special-block with full implementation for LaTeX backend
@ 2024-02-23 23:50 4% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-23 23:50 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]
This patch is for testing purposes only, although the implementation for
LaTeX backend is perfectly usable.
The basic syntax of the new element is:
&foo{lorem ipsum dolor}
=> LaTeX: \foo{lorem ipsum dolor}
Nested elements are possible, as well as the inclusion of other elements
such as macros, links or emphasis marks.
The element also supports a list of optional arguments. For the LaTeX
backend there are two specific arguments: :prelatex and :postlatex.
Example:
&foo[:prelatex [bar] :postlatex {baz}]{lorem ipsum dolor}
=> LaTeX: \foo[bar]{lorem ipsum dolor}{baz}
Additionally, there are a number of universal arguments that should be
equivalent between backends where it makes sense to use them (LaTeX,
HTML, odt...). At the moment you can use: :color, :lang and :smallcaps.
Example:
&foo[:color red :smallcaps t :lang french :prelatex [bar] :postlatex {baz}]{lorem ipsum dolor}
=> LaTeX: {\scshape{}\color{red}\foreignlanguage{french}{\foo[bar]{lorem ipsum dolor}{baz}}}
The element also has an anonymous variant that only accepts universal
arguments. If set without arguments it simply returns the content
string. Example:
&_[:color blue :lang italian]{lorem ipsum dolor}
=> LaTeX: {\color{blue}\foreignlanguage{italian}{lorem ipsum dolor}}
We can define in the document a list of aliases that group several arguments:
#+options: inline-special-block-aliases:(("myalias" :color "magenta" :lang "klingon") ("myalias2" :smallcaps t :color "blue" :prelatex "{2345}"))
&_[:alias myalias :smallcaps t]{lorem ipsum dolor}
=> LaTeX: {\scshape{}\color{magenta}\foreignlanguage{klingon}{lorem ipsum dolor}}
&foo[:alias myalias2]{lorem ipsum dolor}
=> LaTeX: {\scshape{}\color{blue}\foo{2345}{lorem ipsum dolor}}
There can only be one alias per element, but an alias can be combined
with other attributes. It is the closest thing to using styles,
and perhaps the most appropriate term would be ":style". But you can get
confused with the html "style" attribute.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-element.el-New-element-Inline-Special-Block.patch --]
[-- Type: text/x-patch, Size: 9498 bytes --]
From d211bf601db0dd5c01a3edda74cd1b37f1f9448c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block.
* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
* lisp/ox.el (org-export-read-inline-special-block-attributes): read
optional attributes.
* lisp/ox.el (org-export-inline-special-block-aliases): aliases for grouped attributes.
---
lisp/org-element.el | 55 ++++++++++++++++++++++++++++++++++++++++++++-
lisp/ox-latex.el | 36 +++++++++++++++++++++++++++++
lisp/ox.el | 30 +++++++++++++++++++++++++
3 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..c430d934b 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
"\\|"))
;; Objects starting with "@": export snippets.
"@@"
+ ;; Objects starting with "&": inline-special-blocks.
+ "&"
;; Objects starting with "{": macro.
"{{{"
;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
"List of recursive element types aka Greater Elements.")
(defconst org-element-all-objects
- '(bold citation citation-reference code entity export-snippet
+ '(bold citation citation-reference code entity export-snippet inline-special-block
footnote-reference inline-babel-call inline-src-block italic line-break
latex-fragment link macro radio-target statistics-cookie strike-through
subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
;; Ignore inline babel call and inline source block as formulas
;; are possible. Also ignore line breaks and statistics
;; cookies.
+ (inline-special-block ,@standard-set)
(table-cell citation export-snippet footnote-reference link macro
radio-target target timestamp ,@minimal-set)
(table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
(org-element-property :name entity)
(when (org-element-property :use-brackets-p entity) "{}")))
+;;;; inline special block
+
+(defun org-element-inline-special-block-parser ()
+ "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties. Otherwise, return nil.
+
+Assume point is at the beginning of the block."
+ (save-excursion
+ (when (looking-at "&\\([_A-Za-z]+\\)[{[]")
+ (goto-char (- (match-end 0) 1))
+ (let* ((begin (match-beginning 0))
+ (parameters
+ (let ((p (org-element--parse-paired-brackets ?\[)))
+ (and (org-string-nw-p p)
+ (replace-regexp-in-string "\n[ \t]*" " " (org-trim p)))))
+ (contents-begin (when (looking-at-p "{") (+ (point) 1)))
+ (type (org-element--get-cached-string
+ (match-string-no-properties 1)))
+ (contents-end
+ (progn
+ (goto-char (- contents-begin 1))
+ (org-element--parse-paired-brackets ?\{)
+ (- (point) 1)))
+ (post-blank (skip-chars-forward " \t"))
+ (end (point)))
+ (when contents-end
+ (org-element-create
+ 'inline-special-block
+ (list :type type
+ :parameters parameters
+ :contents-begin contents-begin
+ :contents-end contents-end
+ :begin begin
+ :end end
+ :post-blank post-blank)))))))
+
+(defun org-element-inline-special-block-interpreter (inline-special-block contents)
+ "Interpret INLINE SPECIAL BLOCK object as Org syntax."
+ (let ((type (org-element-property :type inline-special-block))
+ (opts (org-element-property :parameters inline-special-block)))
+ (format "&%s%s{%s}"
+ type
+ (if opts (format "[%s]" opts) "")
+ contents)))
;;;; Export Snippet
@@ -5260,6 +5311,8 @@ to an appropriate container (e.g., a paragraph)."
(org-element-strike-through-parser)))
(?@ (and (memq 'export-snippet restriction)
(org-element-export-snippet-parser)))
+ (?& (and (memq 'inline-special-block restriction)
+ (org-element-inline-special-block-parser)))
(?{ (and (memq 'macro restriction)
(org-element-macro-parser)))
(?$ (and (memq 'latex-fragment restriction)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..c0161716b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -101,6 +101,7 @@
(underline . org-latex-underline)
(verbatim . org-latex-verbatim)
(verse-block . org-latex-verse-block)
+ (inline-special-block . org-latex-inline-special-block)
;; Pseudo objects and elements.
(latex-math-block . org-latex-math-block)
(latex-matrices . org-latex-matrices))
@@ -2095,6 +2096,41 @@ holding contextual information."
center-block (format "\\begin{center}\n%s\\end{center}" contents) info))
+;;;; Inline Special Block
+
+(defun org-latex-inline-special-block (inline-special-block contents info)
+ "Transcode an INLINE SPECIAL BLOCK element from Org to LaTeX.
+CONTENTS holds the contents of the block. INFO is a plist
+holding contextual information."
+ (let* ((type (org-element-property :type inline-special-block))
+ (type-is-anon (string= "_" type))
+ (parameters (org-element-property :parameters inline-special-block))
+ (attributes (org-export-read-inline-special-block-attributes parameters))
+ (alias (plist-get attributes :alias))
+ (alias-plist (when alias (cdr (or (assoc alias (plist-get info :inline-special-block-aliases))
+ (assoc alias org-export-inline-special-block-aliases)))))
+ (basic-format (if type-is-anon
+ (format "%s" contents)
+ (format "\\%s{%s}" type contents))))
+ (if (not attributes)
+ basic-format
+ (let* ((attr-final (if alias-plist (append attributes alias-plist) attributes))
+ (prelatex (plist-get attr-final :prelatex))
+ (postlatex (plist-get attr-final :postlatex))
+ (color (plist-get attr-final :color))
+ (smallcaps (plist-get attr-final :smallcaps))
+ (lang (plist-get attr-final :lang)))
+ (concat
+ (when (or color smallcaps type-is-anon) "{")
+ (when smallcaps "\\scshape{}")
+ (when color (format "\\color{%s}" color))
+ (when lang (format "\\foreignlanguage{%s}{" lang))
+ (if (not (or prelatex postlatex))
+ basic-format
+ (concat "\\" type prelatex "{" contents "}" postlatex))
+ (when lang "}")
+ (when (or color smallcaps type-is-anon) "}"))))))
+
;;;; Clock
(defun org-latex-clock (clock _contents info)
diff --git a/lisp/ox.el b/lisp/ox.el
index 5bf55ec3b..cbb6a8dcd 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -149,6 +149,7 @@
(:with-tasks nil "tasks" org-export-with-tasks)
(:with-timestamps nil "<" org-export-with-timestamps)
(:with-title nil "title" org-export-with-title)
+ (:inline-special-block-aliases nil "inline-special-block-aliases" org-export-inline-special-block-aliases)
(:with-todo-keywords nil "todo" org-export-with-todo-keywords)
;; Citations processing.
(:cite-export "CITE_EXPORT" nil org-cite-export-processors))
@@ -528,6 +529,11 @@ This option can also be set with the LANGUAGE keyword."
:type '(string :tag "Language")
:safe #'stringp)
+(defcustom org-export-inline-special-block-aliases nil
+ "TODO"
+ :group 'org-export-general
+ :type '(alist :value-type (group plist)))
+
(defcustom org-export-preserve-breaks nil
"Non-nil means preserve all line breaks when exporting.
This option can also be set with the OPTIONS keyword,
@@ -3789,6 +3795,30 @@ will become the empty string."
(cdr (nreverse (cons (funcall prepare-value s) result))))))))
(if property (plist-get attributes property) attributes)))
+(defun org-export-read-inline-special-block-attributes (attributes)
+ "TODO"
+ (let* ((prepare-value
+ (lambda (str)
+ (save-match-data
+ (cond ((member str '(nil "" "nil")) nil)
+ ((string-match "^\"\\(\"+\\)?\"$" str)
+ (or (match-string 1 str) ""))
+ (t str)))))
+ (attributes
+ (let ((value (list attributes)))
+ (when value
+ (let ((s (mapconcat #'identity value " ")) result)
+ (while (string-match
+ "\\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ \t]+\\|$\\)"
+ s)
+ (let ((value (substring s 0 (match-beginning 0))))
+ (push (funcall prepare-value value) result))
+ (push (intern (match-string 1 s)) result)
+ (setq s (substring s (match-end 0))))
+ ;; Ignore any string before first property with `cdr'.
+ (cdr (nreverse (cons (funcall prepare-value s) result))))))))
+ attributes))
+
(defun org-export-get-caption (element &optional short)
"Return caption from ELEMENT as a secondary string.
--
2.43.2
^ permalink raw reply related [relevance 4%]
* A question about local/experimental branches
@ 2024-02-25 13:53 11% Juan Manuel Macías
2024-02-25 14:05 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-25 13:53 UTC (permalink / raw)
To: orgmode
Hi,
I've noticed that the code for my implementation of the new
'inline-special-block' experimental element is growing. In addition, I
introduce modifications and improvements daily. So I think it might be a
good idea to make my local branch public, in case someone wants to try
it or contribute to the project.
My question is if there is any set of good practices to do this, or is
it enough to publish the local branch 'as is'.
Currently I have completed, and are perfectly usable, the export to
LaTeX and HTML. I have also improved the syntax. Now, if aliases are
used for group optional attributes, it is not necessary to put :alias
foo, but @foo@. Example:
#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))
This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
This is an example of Latin text with small caps: &_[@latin@ :smallcaps t]{lorem ipsum dolor sit amet}.
LaTeX ==>
This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}.
This is an example of Latin text with small caps: {\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}
HTML ==>
This is an example of Latin text: <span style="color:blue;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.
This is an example of Latin text with small caps: <span style="color:blue;font-variant:small-caps;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.
Related: https://list.orgmode.org/87ttlyloyr.fsf@posteo.net/
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: A question about local/experimental branches
2024-02-25 13:53 11% A question about local/experimental branches Juan Manuel Macías
@ 2024-02-25 14:05 6% ` Ihor Radchenko
2024-02-25 15:10 12% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Ihor Radchenko @ 2024-02-25 14:05 UTC (permalink / raw)
To: Juan Manuel Macías, Bastien; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I've noticed that the code for my implementation of the new
> 'inline-special-block' experimental element is growing. In addition, I
> introduce modifications and improvements daily. So I think it might be a
> good idea to make my local branch public, in case someone wants to try
> it or contribute to the project.
>
> My question is if there is any set of good practices to do this, or is
> it enough to publish the local branch 'as is'.
See https://orgmode.org/worg/org-contribute.html#orgfd0d3cb
You can just share the link to your branch.
I am not sure if experimental branches can go directly to our savannah,
like what Emacs does.
Bastien, WDYT?
P.S. Juan, I will need some time to review previous discussions on
inline special blocks before I can comment on your work in depth.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: A question about local/experimental branches
2024-02-25 14:05 6% ` Ihor Radchenko
@ 2024-02-25 15:10 12% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-25 15:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Bastien, orgmode
Ihor Radchenko writes:
> P.S. Juan, I will need some time to review previous discussions on
> inline special blocks before I can comment on your work in depth.
No problem, Ihor. These days I had enough free time to develop my idea,
translate it into code and get something usable from which it could be
discussed. As I mentioned, the export to HTML and LaTeX is complete and
works fine, but I'll probably stop there for a long time. I mean, I
won't go any further and I will dedicate myself to continuing testing
the code already written and fixing possible bugs. Partly because I
don't have enough knowledge of odt to work on this backend, which would
be the next step.
Thanks for the info!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
@ 2024-02-26 10:32 13% ` Juan Manuel Macías
2024-02-26 11:03 5% ` Ihor Radchenko
2024-02-26 12:58 6% ` Bastien Guerry
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-26 10:32 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Bastien writes:
> Adding [BLOG] or [TIP] in the subject prefix allows for such messages
> to be referenced on https://tracker.orgmode.org/news (along with [ANN]
> messages).
>
> It will then be possible to include these posts in the orgmode.org
> homepage, using e.g. https://tracker.orgmode.org/news.rss.
>
> This is experimental, let's see if this helps spread the word about
> useful blogs.
Great! Just one question: can articles be shared in languages other than
English? In that case, would it be necessary to add some more
prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?
(If I shared something in Spanish, I could translate the article in the
body of the message).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
2024-02-26 10:32 13% ` Juan Manuel Macías
@ 2024-02-26 11:03 5% ` Ihor Radchenko
2024-02-26 12:58 6% ` Bastien Guerry
1 sibling, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-02-26 11:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Bastien, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Great! Just one question: can articles be shared in languages other than
> English? In that case, would it be necessary to add some more
> prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?
>
> (If I shared something in Spanish, I could translate the article in the
> body of the message).
In Sacha Chua's news non-English blog posts are just shared as is:
2023年のorg-mode活用と今後の抱負 - takeokunn's blog (@kaneuchi@mstdn.jp)
(from https://sachachua.com/blog/2024/01/2024-01-29-emacs-news/)
As long as the fraction of non-English posts is small, I do not think
that it matters too much. (Of course, having a translation would be
helpful, but we cannot demand such thing.)
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
2024-02-26 10:32 13% ` Juan Manuel Macías
2024-02-26 11:03 5% ` Ihor Radchenko
@ 2024-02-26 12:58 6% ` Bastien Guerry
1 sibling, 0 replies; 144+ results
From: Bastien Guerry @ 2024-02-26 12:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Great! Just one question: can articles be shared in languages other than
> English? In that case, would it be necessary to add some more
> prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?
Yes, you can use "[BLOG] [Spanish] ..." so that people adapt their
filters, but the second prefix won't have any effect on Woof.
But because the language for discussing on this list is english, I
believe the summary should be in english - then people can use i18n
tools to get to the contents.
How does this sound?
--
Bastien Guerry
^ permalink raw reply [relevance 6%]
* Re: A question about local/experimental branches
@ 2024-02-27 9:57 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-27 9:57 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Ihor Radchenko, orgmode
Hi, Bastien,
Bastien Guerry writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> AFAIU, Juan does not have write access to savannah.
>> Should we give it? Of course, if he is willing to use savannah. Any
>> other public repo is also fine.
>
> Juan, let me know if you need access:
> https://orgmode.org/worg/org-contribute.html#devs
Thank you! I think for the moment I will use GitLab to publish my
experimental branch, if it is not essential to do it in savannah (I am
more used to gitlab). As soon as I publish it, I'll share the
link.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [proof of concept] inline language blocks
2024-02-21 23:02 10% ` Juan Manuel Macías
@ 2024-02-28 10:29 7% ` Max Nikulin
2024-02-28 13:15 4% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-02-28 10:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 22/02/2024 06:02, Juan Manuel Macías wrote:
> Samuel Wales writes:
>> :fr{some text in French}
>>
>> being expressed as
>>
>> $[lang :fr "bonjour"]
>
> To expand a little more... Another problem I see in your example is
> nesting. In my proposal, the blocks can be nested:
>
> :fr{text in French and :it{text in Italian}}
>
> But I would find this difficult to read:
>
> $[lang :fr "text in French and $[lang :it "text in italian"]"]
Juan Manuel your ":fr{}" and similar objects is a domain-specific
language that is quite different from a generic element proposed by
Samuel. Do you think it makes sense to modify your inline special block
patch to allow creation of concise DSL?
Juan Manuel Macías. [testing patch] inline-special-block with full
implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +0000.
https://list.orgmode.org/87ttlyloyr.fsf@posteo.net
I mean &fr{bonjour} defined using "#+options:" or some new keyword or a
special block. A definition of "fr" may be (using a bit different names)
:latex_element "foreignlanguage" :latex_prefix "french"
:html_element "span" :html_attr (:lang "fr")
&fr{} is no heavier than :fr{}. The only drawback is necessity to define
elements for each language used in the document. I do not think, even a
dozen of declarations is a significant burden.
^ permalink raw reply [relevance 7%]
* Re: [proof of concept] inline language blocks
2024-02-28 10:29 7% ` Max Nikulin
@ 2024-02-28 13:15 4% ` Juan Manuel Macías
2024-02-28 17:21 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-28 13:15 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Max Nikulin writes:
> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
>
> Juan Manuel Macías. [testing patch] inline-special-block with full
> implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +0000.
> https://list.orgmode.org/87ttlyloyr.fsf@posteo.net
>
> I mean &fr{bonjour} defined using "#+options:" or some new keyword or
> a special block. A definition of "fr" may be (using a bit different
> names)
>
> :latex_element "foreignlanguage" :latex_prefix "french"
> :html_element "span" :html_attr (:lang "fr")
>
> &fr{} is no heavier than :fr{}. The only drawback is necessity to
> define elements for each language used in the document. I do not
> think, even a dozen of declarations is a significant burden.
Hi, Maxim,
In the end I abandoned the concept of inline language block to the
detriment of the more general concept of inline special block (as,
rightly, proposed Ihor). I feel that at the beginning both concepts
overlapped. The patch you mention deals exclusively with the inline
special block concept, as well as the experimental branch that I hope to
publish shortly.
The syntax of my approach, summarized, would be:
-basic form: &foo[optional attributes]{lorem ipsum dolor}
==> LaTeX \foo{lorem ipsum dolor} ; ==> HTML <span class="foo">lorem
ipsum dolor</span>
- anonymous variant: &_{lorem ipsum dolor}
Common to all backends (so far I have only implemented LaTeX and HTML)
are a series of universal attributes. At the moment I have thought about
the following: :lang, :smallcaps and :color. For example:
&foo[:lang el :color blue :smallcaps t]{contents}
==> LaTeX:
{\scshape\color{blue}\foreignlanguage{greek}{\foo{contents}}}
==> HTML
<span class="foo" lang="el" style="color:blue;font-variant:small-caps;">contents</span>
There is also the :html attribute and for LaTeX the :prelatex and
:postlatex attributes. Groups of attributes can also be defined, as if
they were styles, and combined with single attributes:
#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))
This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
This is an example of Latin text with small caps: &_[@latin@ :smallcaps t]{lorem ipsum dolor sit amet}.
==> LaTeX:
This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}.
This is an example of Latin text with small caps: {\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}
==> HTML:
This is an example of Latin text: <span style="color:blue;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.
This is an example of Latin text with small caps: <span style="color:blue;font-variant:small-caps;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.
^ permalink raw reply [relevance 4%]
* Re: [proof of concept] inline language blocks
2024-02-28 13:15 4% ` Juan Manuel Macías
@ 2024-02-28 17:21 6% ` Max Nikulin
2024-02-28 23:42 4% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-02-28 17:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 28/02/2024 20:15, Juan Manuel Macías wrote:
> #+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))
>
> This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
It is more verbose than &la{lorem ipsum dolor sit amet}. My idea is to
allow latex commands other than object type ("la" this case). Something like
#+options: custom-object(:type la :latex_element foreignlanguage
:latex_pre "{latin}")
^ permalink raw reply [relevance 6%]
* Re: [proof of concept] inline language blocks
2024-02-28 17:21 6% ` Max Nikulin
@ 2024-02-28 23:42 4% ` Juan Manuel Macías
2024-02-29 7:05 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-28 23:42 UTC (permalink / raw)
To: orgmode
Max Nikulin writes:
> #+options: custom-object(:type la :latex_element foreignlanguage
> :latex_pre "{latin}")
mmm, I see it as not very flexible and perhaps too complicated for the user.
My idea with the concept of inline-special-block is that it is like the
inline version of its older brother. If something like
#+begin_foo
...
#+end_foo
produces things like
\begin{foo}
...
\end{foo}
or
<div class="foo">
...
</div>
the user should expect something like &foo{...} to produce \foo{...} or
<span class=foo>...</span>, etc. The only difference is that there would
be an anonymous variant &_{...}.
The attributes syntax (in square brackets) adds verbosity, but I
understand that it is also very flexible and granular. It doesn't need
to be used always, but at least it's there when you need to use it.
Furthermore, the user can always define lists of attributes (styles or
aliases: I would have preferred the term "style", instead of "alias",
but I fear that it will be confused with the HTML attribute of the same
name). Furthermore, these lists of attributes can also be used in
combination with other single attributes, giving rise to a great
possibility of combinations. The fact that there are a number of
universal attributes such as :lang, :color, :smallcaps prevents the user
from having to figure out which code to use on each backend to produce
colored text, small caps or the correct language selector. ":lang ru",
for example, will always produce in LaTeX \foreignlanguage{russian}{}
(which, in addition, is a command shared by babel and polyglossia) and
in HTML lang="ru".
And ultimately you could also think about some kind of folding for the
attributes part.
I believe that this possible new element would solve the need for a
native, multipurpose inline text container with properties[1], which
until now could only be achieved through macros or links, with the
limitations of both elements.
Additionally, I think this approach is more flexible than having
specific purpose blocks (for languages, colors, etc.).
Of course, it would be best not to abuse the attributes. If in a
long document one needs to put a single sentence in red, I don't think
it is a verbosity problem to put something like &_[:color red]{lorem
ipsum dolor}. If you need to put a lot of sentences in red or any other
color, it may be a better idea to define some command in LaTeX
(\redtext), a class in HTML or a character style in odt. And then it
would be enough to use &redtext{lorem ipsum dolor}.
[1] Pandoc has the "bracketed spans". According to pandoc manual:
#+begin_quote
A bracketed sequence of inlines, as one would use to begin
a link, will be treated as a Span with attributes if it is followed
immediately by attributes:
[This is *some text*]{.class key="val"}
#+end_quote
^ permalink raw reply [relevance 4%]
* Re: [proof of concept] inline language blocks
2024-02-28 23:42 4% ` Juan Manuel Macías
@ 2024-02-29 7:05 6% ` Max Nikulin
2024-02-29 10:41 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-02-29 7:05 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel,
I am not against optional arguments. The idea is to make the feature
more flexible and convenient for domain-specific documents. I did not
use square brackets in my example to concentrate on the use case of
concise and clear markup.
On 29/02/2024 06:42, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> #+options: custom-object(:type la :latex_element foreignlanguage
>> :latex_pre "{latin}")
>
> mmm, I see it as not very flexible and perhaps too complicated for the user.
Do not concentrate on \foreignlanguage. I am using it just because the
thread was started from markup suitable for mixed-language texts.
> the user should expect something like &foo{...} to produce \foo{...} or
> <span class=foo>...</span>, etc. The only difference is that there would
> be an anonymous variant &_{...}.
I do not try to dispute \foo and class="foo" as default behavior. I
suggest to implement possibility to override default behavior of
&foo{text} to \bar{text} and <bar>text</bar>. The same is applicable for
anonymous objects
&_[:latex_command bar :html_element bar]{text}
> class in HTML
HTML has a number of elements for semantic markup, e.g. <kbd>, <var>,
<abbr>, etc. I hope, they can be supported in addition to default <span>.
^ permalink raw reply [relevance 6%]
* Re: [proof of concept] inline language blocks
2024-02-29 7:05 6% ` Max Nikulin
@ 2024-02-29 10:41 10% ` Juan Manuel Macías
2024-02-29 12:05 5% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-02-29 10:41 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
>> the user should expect something like &foo{...} to produce \foo{...} or
>> <span class=foo>...</span>, etc. The only difference is that there would
>> be an anonymous variant &_{...}.
>
> I do not try to dispute \foo and class="foo" as default behavior. I
> suggest to implement possibility to override default behavior of
> &foo{text} to \bar{text} and <bar>text</bar>. The same is applicable
> for anonymous objects
>
> &_[:latex_command bar :html_element bar]{text}
Maxim, I insist that I follow the logic of the "large" special blocks.
Anyway, I think your example only makes sense in HTML, or at least I
can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
does seem sensible to me that someone would want to change the tags.
Maybe with a :html-tag, or something like that.
As for :latex-command, if I understand it correctly, I don't quite see
how useful this could be:
&foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
when it is simpler to put:
&bar{text}
The same thing happens with the anonymous variant:
&_[:latex-command foo]{text} == LaTeX ==> \foo{text}
which is identical to putting &foo{text}
The anonymous variant would be equivalent in LaTeX to a
\begingroup...\endgroup, or rather to {...}. One could add all the
commands one wants within the group simply with :prelatex:
&_[:prelatex \foo\bar\vaz\blah{}]{text}
==> {\foo\bar\vaz\blah{}text}
I'm not opposed to your ideas, I just can't find a use case for it. In
LaTeX, I mean. In the case of HTML I find it useful, indeed, to have
more control over the tags: <foo></foo>, <bar></bar>, etc.
In any case, I think that my implementation leaves open the possibility
of extending it with everything you mentioned, or anything else.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: [proof of concept] inline language blocks
2024-02-29 10:41 10% ` Juan Manuel Macías
@ 2024-02-29 12:05 5% ` Max Nikulin
2024-02-29 12:50 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-02-29 12:05 UTC (permalink / raw)
To: emacs-orgmode
On 29/02/2024 17:41, Juan Manuel Macías wrote:
> Max Nikulin writes:
>>
>> I do not try to dispute \foo and class="foo" as default behavior. I
>> suggest to implement possibility to override default behavior of
>> &foo{text} to \bar{text} and <bar>text</bar>. The same is applicable
>> for anonymous objects
>>
>> &_[:latex_command bar :html_element bar]{text}
>
> Maxim, I insist that I follow the logic of the "large" special blocks.
Export of special blocks may be extended as well.
> Anyway, I think your example only makes sense in HTML, or at least I
> can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
> does seem sensible to me that someone would want to change the tags.
> Maybe with a :html-tag, or something like that.
Consider a document aimed to be exported to different formats. It is
unlikely that names of commands, elements, classes, etc. match for all
of them.
> As for :latex-command, if I understand it correctly, I don't quite see
> how useful this could be:
>
> &foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
>
> when it is simpler to put:
>
> &bar{text}
Command may require additional arguments and it should be convenient to
define shortcuts to the same command with different arguments:
&la{text} => \foreignlanguage{latin}{text}
&es{text} => \foreinglanguage{spanish}{text}
> The same thing happens with the anonymous variant:
>
> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
>
> which is identical to putting &foo{text}
>
> The anonymous variant would be equivalent in LaTeX to a
> \begingroup...\endgroup, or rather to {...}. One could add all the
> commands one wants within the group simply with :prelatex:
>
> &_[:prelatex \foo\bar\vaz\blah{}]{text}
>
> ==> {\foo\bar\vaz\blah{}text}
The idea is to not add \begingroup and \endgroup if LaTeX command is
specified (or to control it by a dedicated attribute). Again, consider a
document suitable for multiple export formats.
I think, flexibility in respect to underlying commands/classes/elements
allows to minimize changes in documents later. Sometimes it is necessary
to switch to another LaTeX package, CSS framework, etc. It allows usage
semantic names within Org documents despite they may be exported to the
same command.
> In any case, I think that my implementation leaves open the possibility
> of extending it with everything you mentioned, or anything else.
The question is proper balance of built-in features, flexibility,
implementation complexity. It would be unfortunate if most of users will
have to create custom backends even for basic documents.
^ permalink raw reply [relevance 5%]
* Re: [proof of concept] inline language blocks
2024-02-29 12:05 5% ` Max Nikulin
@ 2024-02-29 12:50 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-02-29 12:50 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
>> Anyway, I think your example only makes sense in HTML, or at least I
>> can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
>> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
>> does seem sensible to me that someone would want to change the tags.
>> Maybe with a :html-tag, or something like that.
>
> Consider a document aimed to be exported to different formats. It is
> unlikely that names of commands, elements, classes, etc. match for all
> of them.
It makes sense, although I have never encountered a case like this.
Usually (and returning to the example of the large special blocks), if
in org I put something like:
#+begin_foo
...
#+end_foo
I try to ensure that there is a "foo" environment in LaTeX, a "foo" class
in html or a "foo" style in odt (now I don't remember if the odt exporter
produces paragraph styles from special blocks. I don't think so).
In any case, on second thought, maybe someone wants to reuse a LaTeX
preamble, css style sheets or any odt templates. I see no problem, then,
in there being attributes like :latex-command, :html-tag, :odt-style :html-attribute,
etc., which override the default values.
>> As for :latex-command, if I understand it correctly, I don't quite see
>> how useful this could be:
>> &foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
>> when it is simpler to put:
>> &bar{text}
>
> Command may require additional arguments and it should be convenient
> to define shortcuts to the same command with different arguments:
>
> &la{text} => \foreignlanguage{latin}{text}
> &es{text} => \foreinglanguage{spanish}{text}
With the current implementation:
#+options: inline-special-block-aliases:(("bar" :prelatex [bar]) ("baz" :prelatex [baz]))
&foo[@bar@]{lorem ipsum} ==> \foo[bar]{lorem ipsum}
&foo[@baz@]{lorem ipsum} ==> \foo[baz]{lorem ipsum}
Your example is less verbose, but with this implementation you can do combinations, it's
more granular, I think:
&foo[@bar@ :smallcaps t]{lorem ipsum} ==> {\scshape\foo[bar]{lorem ipsum}}
&foo[@baz@ :lang it]{lorem ipsum} ==> \foo[baz]{\foreignlanguage{italian}{lorem ipsum}}
I think this is quite flexible and leaves a great deal of freedom to the user.
>> The same thing happens with the anonymous variant:
>> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
>> which is identical to putting &foo{text}
>> The anonymous variant would be equivalent in LaTeX to a
>> \begingroup...\endgroup, or rather to {...}. One could add all the
>> commands one wants within the group simply with :prelatex:
>> &_[:prelatex \foo\bar\vaz\blah{}]{text}
>> ==> {\foo\bar\vaz\blah{}text}
>
> The idea is to not add \begingroup and \endgroup if LaTeX command is
> specified (or to control it by a dedicated attribute). Again, consider
> a document suitable for multiple export formats.
Indeed, if the :latex-command attr is implemented should work in both
variants. In such a way, perhaps:
&_[:latex-command foo]{lorem} ==> \foo{lorem}
> I think, flexibility in respect to underlying
> commands/classes/elements allows to minimize changes in documents
> later. Sometimes it is necessary to switch to another LaTeX package,
> CSS framework, etc. It allows usage semantic names within Org
> documents despite they may be exported to the same command.
>
>> In any case, I think that my implementation leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
> implementation complexity. It would be unfortunate if most of users
> will have to create custom backends even for basic documents.
We can continue the discussion when I publish my experimental branch and
share the link. I'm a little late because I want to make some
corrections to the code first.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Experimental public branch for inline special blocks
@ 2024-03-01 20:34 9% Juan Manuel Macías
` (7 more replies)
0 siblings, 8 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-01 20:34 UTC (permalink / raw)
To: orgmode
Hi,
Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:
<https://gitlab.com/maciaschain/org-mode.git>
The code incorporates fixes and modifications and I have also added some
ideas from Maxim Nikulin. The LaTeX and HTML backends are complete,
although of course it can still be perfected. Recapitulating the
necessary information:
The new element can be nested and supports other elements such as links,
macros, emphasis marks, etc.
The basic syntax:
┌────
│ &foo{lorem ipsum dolor}
└────
produces in LaTeX:
┌────
│ \foo{lorem ipsum dolor}
└────
and in HTML:
┌────
│ <span class="foo">lorem ipsum dolor</span>
└────
There is also an anonymous variant:
┌────
│ &_{lorem ipsum dolor}
└────
Optional attributes in square brackets are supported. There are a series
of 'universal' attributes, common to each backend. At the moment:
`:lang', `:color' and `:smallcaps'. Example:
┌────
│ &foo[:color red :smallcaps t :lang it]{lorem ipsum dolor}
└────
Specific to the LaTeX backend we have the `:prelatex' and `:postlatex'
attributes (which introduce arbitrary code before and after the content)
and `:latex-command', which overrides the exported command.
`:latex-command nocommand' does not export a command flag. Examples:
┌────
│ &foo[:prelatex [bar] :postlatex {baz} :lang it :latex-command blah]{lorem ipsum dolor}
└────
==>
┌────
│ \foreignlanguage{italian}{\blah[bar]{lorem ipsum dolor}{baz}}
└────
┌────
│ &_[:prelatex \foo{bar} :color red]{lorem ipsum dolor}
└────
==>
┌────
│ {\color{red}\foo{bar}lorem ipsum dolor}
└────
Likewise, for HTML we have the `:html-tag' and `:html-class' attributes
(which override the tags and the class name) and another one, more
generic, `:html', which introduces arbitrary code, such as
`style="..."'.
We can group lists of attributes as aliases. The syntax waould be:
┌────
│ &alias!{text}
└────
and we can also combine aliases with more single attributes:
┌────
│ &alias![more-attributes]{text}
└────
An example: let's imagine that we want a specific block for short quotes
in Latin and italics (it is normative in some typographical traditions
that quotes in classical Latin are put in italics instead of quotation
marks):
┌────
│ #+options: inline-special-block-aliases:(("latin" :lang "la" :latex-command "textit" :html-tag "em"))
│
│ Caesar's famous quote: &latin!{Alea iacta est}
│
│ Caesar's famous quote: &latin![:smallcaps t :color blue]{Alea iacta est}
└────
==> LaTeX:
┌────
│ Caesar's famous quote: \foreignlanguage{latin}{\textit{Alea iacta est}}
│
│ Caesar's famous quote: {\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
└────
== HTML:
┌────
│ Caesar's famous quote: <em lang="la" class="latin">Alea iacta est</em>
│
│ Caesar's famous quote: <em style="color:blue;font-variant:small-caps;" lang="la" class="latin">Alea iacta est</em>
└────
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 9%]
* Re: Experimental public branch for inline special blocks
@ 2024-03-02 10:57 13% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-02 10:57 UTC (permalink / raw)
To: emacs-orgmode
Hi, Stefan,
Stefan Nobis writes:
> first of all: Thank you for your great work. Looks really good.
You're welcome! :-)
> Just out of curiosity: Why a special syntax for alias expansion?
>
> From a syntax and user point of view, I think I would prefer a simpler
> syntax. So
>
> &alias{text}
>
> would check if an alias is registered and if yes use it. This way it
> would be easier to change/add options later on without the need for
> changing all the inline-block commands and add a "!" (not a big deal,
> just two rather simple replace commands).
I think you're right. I have removed the need for "!" in the last
commit.
Now the syntax is:
&alias{text}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
@ 2024-03-03 20:29 9% ` Juan Manuel Macías
2024-03-10 2:08 10% ` `:export' attribute?: " Juan Manuel Macías
2024-03-04 17:13 5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
` (5 subsequent siblings)
7 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-03 20:29 UTC (permalink / raw)
To: orgmode
Hi again,
The odt backend is now complete with the `org-odt-inline-special-block'
function. Some particularities of exporting to odt:
- The only specific attribute is :odt-style, which overrides the default
style. Example:
&foo{lorem ipsum} ==> the style is "foo"
&foo[:odt-style bar]{lorem ipsum} ==> the style is "bar". Same with the
anonymous variant &_[:odt-style bar]{lorem ipsum}.
- The three global attributes supported in the LaTeX and HTML backends
are also supported in odt: `:lang', `:color' and `:smallcaps'. I have
learned that these direct format elements are in odt "automatic
styles", which must be declared before the body. I haven't thought of
any other way to do it than using a list of automatic styles that is
inserted inside `org-odt-template', with each export. Some examples with
various combinations:
&foo[:color magenta :odt-style Bold]{this is magenta and bold}
&foo[:color red :odt-style Emphasis]{this is red and emphasis}
&Underline[:color green]{this is green and underline}
&foo[:color blue]{this is blue with &_[:smallcaps t]{smallcaps}}
And a screenshot: https://i.imgur.com/KNhYQrv.png
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* naming: Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-03 20:29 9% ` Juan Manuel Macías
@ 2024-03-04 17:13 5% ` Max Nikulin
2024-03-04 18:07 6% ` Juan Manuel Macías
2024-03-05 16:47 5% ` smallcaps: " Max Nikulin
` (4 subsequent siblings)
7 siblings, 2 replies; 144+ results
From: Max Nikulin @ 2024-03-04 17:13 UTC (permalink / raw)
To: emacs-orgmode
On 02/03/2024 03:34, Juan Manuel Macías wrote:
>
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
I find the feature name confusing, however I am unsure if others share
my opinion.
In Org syntax, "elements" are paragraphs and larger parts, while parts
within paragraphs are named objects. I admit that for org-element
everything is element.
In CSS "display: inline block" makes an HTML element a rectangular block
inside a paragraph while new feature is mostly intended for normal text
flow. I admit that &parbox[...]{...} may be used to create an instance
similar to inline block and that "inline source blocks" are already
described in the manual.
Does anybody have an idea of a better name for a feature? Maybe
something like inline custom objects, snippets. "Objects" are used to
describe syntax, but not used in the manual though.
^ permalink raw reply [relevance 5%]
* Re: naming: Re: Experimental public branch for inline special blocks
@ 2024-03-04 17:49 12% ` Juan Manuel Macías
2024-03-05 10:53 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-04 17:49 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Max Nikulin <manikulin@gmail.com> writes:
>
>> Does anybody have an idea of a better name for a feature? Maybe
>> something like inline custom objects, snippets. "Objects" are used to
>> describe syntax, but not used in the manual though.
>
> Custom inline markup.
Custom span?
I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: naming: Re: Experimental public branch for inline special blocks
2024-03-04 17:13 5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
@ 2024-03-04 18:07 6% ` Juan Manuel Macías
2024-03-04 22:17 5% ` Samuel Wales
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-04 18:07 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> In Org syntax, "elements" are paragraphs and larger parts, while parts
> within paragraphs are named objects. I admit that for org-element
> everything is element.
In my initial message I used 'element' loosely. Note that
inline-special-block is included in org-element-all-objects, where
inline-src-block is also.
^ permalink raw reply [relevance 6%]
* Re: naming: Re: Experimental public branch for inline special blocks
2024-03-04 18:07 6% ` Juan Manuel Macías
@ 2024-03-04 22:17 5% ` Samuel Wales
2024-03-04 22:18 0% ` Samuel Wales
0 siblings, 1 reply; 144+ results
From: Samuel Wales @ 2024-03-04 22:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
If language is not correct, then what is said is
not what is meant; if what is said is not what is meant,
then what must be done remains undone; if this remains
undone, morals and art will deteriorate; if justice goes
astray, the people will stand about in helpless
confusion. Hence there must be no arbitrariness in what is
said. This matters above everything. --- analects
On 3/4/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Max Nikulin writes:
>
>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>> within paragraphs are named objects. I admit that for org-element
>> everything is element.
>
> In my initial message I used 'element' loosely. Note that
> inline-special-block is included in org-element-all-objects, where
> inline-src-block is also.
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 5%]
* Re: naming: Re: Experimental public branch for inline special blocks
2024-03-04 22:17 5% ` Samuel Wales
@ 2024-03-04 22:18 0% ` Samuel Wales
0 siblings, 0 replies; 144+ results
From: Samuel Wales @ 2024-03-04 22:18 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
[i did not aim that at any particular person!]
On 3/4/24, Samuel Wales <samologist@gmail.com> wrote:
> If language is not correct, then what is said is
> not what is meant; if what is said is not what is meant,
> then what must be done remains undone; if this remains
> undone, morals and art will deteriorate; if justice goes
> astray, the people will stand about in helpless
> confusion. Hence there must be no arbitrariness in what is
> said. This matters above everything. --- analects
>
> On 3/4/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>> Max Nikulin writes:
>>
>>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>>> within paragraphs are named objects. I admit that for org-element
>>> everything is element.
>>
>> In my initial message I used 'element' loosely. Note that
>> inline-special-block is included in org-element-all-objects, where
>> inline-src-block is also.
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 0%]
* [tip] Export to PDF with latexmk 'continuous preview' option
@ 2024-03-05 0:58 9% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-05 0:58 UTC (permalink / raw)
To: orgmode
A little-known (and sometimes very useful) latexmk option is the -pvc
option. According to the latexmk manual:
[...] The second previewing option is the powerful -pvc option
(mnemonic: "preview continuously"). In this case, latexmk
runs continuously, regularly monitoring all the source files
to see if any have changed. Every time a change is detected,
latexmk runs all the programs necessary to generate a new
version of the document. A good previewer will then
automatically update its display. Thus the user can simply
edit a file and, when the changes are written to disk,
latexmk completely automates the cycle of updating the .dvi
(and/or the .ps and .pdf) file, and refreshing the
previewer's display. It's not quite WYSIWYG, but usefully
close.
In order to use this option from Org, I have defined a simple minor mode
that runs latexmk with the -pvc option and creates a buffer to monitor
the process. Every time the document, or any file involved, is saved,
the PDF is updated. We can define in our `latexmkrc' our favorite
external PDF viewer (Atril, Okular, Evince, etc.). I have this line:
┌────
│ $pdf_previewer = "atril %O %S > /dev/null 2>&1 &";
└────
And here's the code (for documents that are long, complex, or take a
while to export, it may be better to use the asynchronous version of
`org-latex-export-to-latex'):
┌────
│ (defun my-org-compile-latexmk-interactive ()
│ (let* ((tex-file (org-export-output-file-name ".tex")))
│ (start-process-shell-command
│ "latexmk"
│ (format "*%s-latexmk-process*" (file-name-sans-extension tex-file))
│ (concat
│ "latexmk -f -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
│ tex-file))))
│
│ (define-minor-mode org-interactive-compile-pdf-mode
│ "TODO"
│ :lighter " OrgInteractivePDF"
│ (if org-interactive-compile-pdf-mode
│ (progn
│ (my-org-compile-latexmk-interactive)
│ (add-hook 'after-save-hook #'org-latex-export-to-latex nil t))
│ (remove-hook 'after-save-hook #'org-latex-export-to-latex t)
│ (when (equal (process-status "latexmk") 'run)
│ (kill-process "latexmk"))))
└────
And a screencast:
<https://cloud.disroot.org/s/ztFfa27kdsnNkGc>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 9%]
* Re: naming: Re: Experimental public branch for inline special blocks
2024-03-04 17:49 12% ` Juan Manuel Macías
@ 2024-03-05 10:53 6% ` Max Nikulin
2024-03-05 15:16 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-05 10:53 UTC (permalink / raw)
To: emacs-orgmode
On 05/03/2024 00:49, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>> Max Nikulin writes:
>>
>>> Does anybody have an idea of a better name for a feature? Maybe
>>> something like inline custom objects, snippets. "Objects" are used to
>>> describe syntax, but not used in the manual though.
>>
>> Custom inline markup.
>
> Custom span?
>
> I chose "inline special block" because special blocks, and because of
> the parallelism inline code block/code block.
Special blocks are really block-level elements. I see similarity,
however with a better term we could avoid "inline" specifier. I think,
the new beast may serve in some cases currently handled by macros. LaTeX
snippets are named "fragments" in the manual.
Custom fragment?
^ permalink raw reply [relevance 6%]
* Re: naming: Re: Experimental public branch for inline special blocks
2024-03-05 10:53 6% ` Max Nikulin
@ 2024-03-05 15:16 11% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-05 15:16 UTC (permalink / raw)
To: Max Nikulin; +Cc: Ihor Radchenko, orgmode
Max Nikulin writes:
> Special blocks are really block-level elements. I see similarity,
> however with a better term we could avoid "inline" specifier. I think,
> the new beast may serve in some cases currently handled by macros.
> LaTeX snippets are named "fragments" in the manual.
>
> Custom fragment?
I think "custom" is an important part of defining the new object. Unlike
other elements/objects, such as emphasis marks, this one does not add
any (let's say) "logical or semantic" information. I mean, emphasis
marks (to continue with the example) are useful when reading an Org
document as it is. But the new object is rather a segment of text that
must be exported in a certain way to LaTeX, odt, HTML, etc. Something
like "&foo{some text}" does not provide any information to the reader,
but rather to the exporters and the output format. So, how about
something like:
- Custom Export Fragment
- Custom Export Span
- Custom Export "Whatever"
- ...
?
(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* smallcaps: Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
` (2 preceding siblings ...)
2024-03-04 17:13 5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
@ 2024-03-05 16:47 5% ` Max Nikulin
2024-03-05 17:28 10% ` Juan Manuel Macías
2024-03-06 16:53 7% ` To avoid zero width space: " Max Nikulin
` (3 subsequent siblings)
7 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-05 16:47 UTC (permalink / raw)
To: emacs-orgmode
On 02/03/2024 03:34, Juan Manuel Macías wrote:
> │ Caesar's famous quote: &latin![:smallcaps t :color blue]{Alea iacta est}
> ==> LaTeX:
> │ Caesar's famous quote: {\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
> == HTML:
> │ Caesar's famous quote: <em style="color:blue;font-variant:small-caps;" lang="la" class="latin">Alea iacta est</em>
I am in doubts if smallcaps should be hardcoded. From my point of view,
current implementation is unnecessary rigid. In this particular example
:smallcaps is an ad-hoc property. I would expect its usage through an
alias definition, e.g.
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
If some type is used through the document multiple times then it is
better to avoid style="font-variant:small-caps" and use a CSS class
instead. Even for LaTeX it may be better to define a dedicated command
to be closer to semantic markup.
Moreover different decorations may be used in LaTeX and HTML. Some type
may be typed in small caps in LaTeX, but in HTML it may use regular font
and some color.
Perhaps an e.g. user-configurable and extensible alist of types with
per-backend properties should be used instead.
A portion of wisdom how to represent small caps for each export backend
may be handy, but accessing it should be more flexible.
^ permalink raw reply [relevance 5%]
* Re: smallcaps: Re: Experimental public branch for inline special blocks
2024-03-05 16:47 5% ` smallcaps: " Max Nikulin
@ 2024-03-05 17:28 10% ` Juan Manuel Macías
2024-03-06 10:55 5% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-05 17:28 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> escribió:
> If some type is used through the document multiple times then it is
> better to avoid style="font-variant:small-caps" and use a CSS class
> instead. Even for LaTeX it may be better to define a dedicated command
> to be closer to semantic markup.
>
> Moreover different decorations may be used in LaTeX and HTML. Some type
> may be typed in small caps in LaTeX, but in HTML it may use regular font
> and some color.
The "global attribute" concept implies that there should be (ideally)
the same result in all possible backends (naturally, if the output is
plain text, :color doesn't make much sense). Global attributes are a
quick and easy (for the user) way to create direct formatting, analogous
to the LaTeX commands \textcolor, \textsc, etc. Its casual use is the
most recommended, in my opinion. Let's imagine that a user wants to
color segments of text, in the same color, for LaTeX and odt, and does
not want to bother with predefined styles or macros in odt and LaTeX
respectively.
If a segment of text must have a different appearance, for example, in
LaTeX (small caps) and HTML (red color), you can put:
&_[:html style="color:red;" :prelatex \scshape{}]{text}
And if one wants to have more robust control, for example because many
text segments must have a certain treatment in HTML, odt or LaTeX,
styles, classes and macros can always be defined in the output format.
Additionally, there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 10%]
* Re: smallcaps: Re: Experimental public branch for inline special blocks
2024-03-05 17:28 10% ` Juan Manuel Macías
@ 2024-03-06 10:55 5% ` Max Nikulin
2024-03-06 15:21 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-06 10:55 UTC (permalink / raw)
To: emacs-orgmode
On 06/03/2024 00:28, Juan Manuel Macías wrote:
> Max Nikulin escribió:
> I think that the current implementation is very flexible and gives rise
> to many possible variations, and the combination of direct formatting
> and styles to suit the user.
OK, just consider it as my dissenting opinion. I believe that it should
be possible for the same Org document
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
&definition{Example} or &_[:smallcaps t]{ad-hoc}
to export it as
<span style="font-variant:small-caps;">Example</span>
or <span style="font-variant:small-caps;">ad-hoc</span>
or as
<span class="definition">Example</span>
or <span class="small-caps">ad-hoc</span>
by adjusting of global settings. The former one be suitable for a CMS
that does not allow user CSS and the latter one is preferable for a site
under full user control and having CSS
.definition, .small-capps { font-variant: small-caps; }
^ permalink raw reply [relevance 5%]
* Re: smallcaps: Re: Experimental public branch for inline special blocks
2024-03-06 10:55 5% ` Max Nikulin
@ 2024-03-06 15:21 11% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-06 15:21 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> OK, just consider it as my dissenting opinion. I believe that it should
> be possible for the same Org document
>
> #+options: inline-special-block-aliases:(("definition" :smallcaps t))
>
> &definition{Example} or &_[:smallcaps t]{ad-hoc}
>
> to export it as
>
> <span style="font-variant:small-caps;">Example</span>
> or <span style="font-variant:small-caps;">ad-hoc</span>
>
> or as
>
> <span class="definition">Example</span>
> or <span class="small-caps">ad-hoc</span>
>
> by adjusting of global settings. The former one be suitable for a CMS
> that does not allow user CSS and the latter one is preferable for a site
> under full user control and having CSS
>
> .definition, .small-capps { font-variant: small-caps; }
With the current implementation this:
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
&definition{Example}
produces:
<span style="font-variant:small-caps;" class="definition">Example</span>
:smallcaps simply adds a (say) direct formatting layer. I am not a fan
of any form of direct formatting. But, as I already said, I think that
these types of global attributes can be useful for users who do not want
to bother with predefining styles, classes or commands in
odt/html/LaTeX, or because they do not know how to do it. They simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
necessary, but perhaps other users think differently.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* To avoid zero width space: Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
` (3 preceding siblings ...)
2024-03-05 16:47 5% ` smallcaps: " Max Nikulin
@ 2024-03-06 16:53 7% ` Max Nikulin
2024-03-06 18:27 12% ` Juan Manuel Macías
2024-03-06 21:13 12% ` Juan Manuel Macías
2024-03-07 10:57 6% ` false positives: " Max Nikulin
` (2 subsequent siblings)
7 siblings, 2 replies; 144+ results
From: Max Nikulin @ 2024-03-06 16:53 UTC (permalink / raw)
To: emacs-orgmode
On 02/03/2024 03:34, Juan Manuel Macías wrote:
>
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
>
> <https://gitlab.com/maciaschain/org-mode.git>
The new feature is promising as an alternative for U+200B zero width
space as an escape character (info "(org) Escape Character"). It may
adjusted to allow really plain text markup instead of a character
invisible by default:
(org-export-string-as "Example of &_{*intra*}&_{/word/} markup"
'html
'(:export-options (body-only)))
"<p>
Example of <span><b>intra</b></span><span><i>word</i></span> markup</p>
"
However to produce clean export result <span> elements should not be
added if no attributes are specified. My expectation is
"<p>
Example of <b>intra</b><i>word</i> markup</p>
"
Earlier discussions:
- Denis Maier. Org-syntax: Intra-word markup. Thu, 2 Dec 2021 11:50:32
+0100.
https://list.orgmode.org/4897bc60-b74f-ccfd-e13e-9b89a1194fdf@mailbox.org
- Juan Manuel Macías. On zero width spaces and Org syntax. Fri, 03 Dec
2021 12:48:16 +0000. https://list.orgmode.org/87ilw5yhv3.fsf@posteo.net
- Vincent Belaïche. RE: [RFC] Creole-style / Support for
**emphasis**__within__**a word** Mon, 24 Jan 2022 10:50:10 +0000.
https://list.orgmode.org/PAXPR06MB809350C21E7C75A2A110C529845E9@PAXPR06MB8093.eurprd06.prod.outlook.com
^ permalink raw reply [relevance 7%]
* Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
2024-03-06 16:53 7% ` To avoid zero width space: " Max Nikulin
@ 2024-03-06 18:27 12% ` Juan Manuel Macías
2024-03-06 21:13 12% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-06 18:27 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> However to produce clean export result <span> elements should not be
> added if no attributes are specified. My expectation is
>
> "<p>
> Example of <b>intra</b><i>word</i> markup</p>
> "
It seems like a good idea to me. Currently, in LaTeX:
&_{lorem ipsum dolor} ==> LaTeX ==> lorem ipsum dolor
It can also be extended to html, odt and the rest of the backends.
That is, by default, the anonymous variant without attributes simply
returns the content.
Another possibility (with the current implementation):
#+options: inline-special-block-aliases:(("b" :html-tag "b")("i" :html-tag "i"))
&b{intra}&i{word}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
2024-03-06 16:53 7% ` To avoid zero width space: " Max Nikulin
2024-03-06 18:27 12% ` Juan Manuel Macías
@ 2024-03-06 21:13 12% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-06 21:13 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> However to produce clean export result <span> elements should not be
> added if no attributes are specified. My expectation is
>
> "<p>
> Example of <b>intra</b><i>word</i> markup</p>
> "
With the latest commit now the anonymous variant without attributes
simply returns the content (in LaTeX, HTML and odt). You can try:
&_{/lorem/}&_{*ipsum*}&_{_dolor_}
==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}
==> HTML <i>lorem</i><b>ipsum</b><span class="underline">dolor</span>
==> ODT <text:span text:style-name="Emphasis">lorem</text:span><text:span text:style-name="Bold">ipsum</text:span><text:span text:style-name="Underline">dolor</text:span>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* false positives: Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
` (4 preceding siblings ...)
2024-03-06 16:53 7% ` To avoid zero width space: " Max Nikulin
@ 2024-03-07 10:57 6% ` Max Nikulin
2024-03-07 11:06 12% ` Juan Manuel Macías
2024-04-09 8:52 1% ` Ihor Radchenko
2024-04-11 11:06 7% ` Max Nikulin
7 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-07 10:57 UTC (permalink / raw)
To: emacs-orgmode
On 02/03/2024 03:34, Juan Manuel Macías wrote:
>
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
>
> <https://gitlab.com/maciaschain/org-mode.git>
It seems the parser finds new objects where syntactical constructs are
incomplete:
(org-export-string-as "Alpha&Beta{"
'html
'(:export-options (body-only)))
"<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
My expectation is
"<p>\nAlpha&Beta{</p>\n"
Even worse
(org-export-string-as "Alpha&Beta["
'html
'(:export-options (body-only)))
Debugger entered--Lisp error: (wrong-type-argument
number-or-marker-p nil)
I think, this particular case deserves a unit test despite it is too
early for extensive test suite.
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 10:57 6% ` false positives: " Max Nikulin
@ 2024-03-07 11:06 12% ` Juan Manuel Macías
2024-03-07 11:18 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-07 11:06 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> It seems the parser finds new objects where syntactical constructs are
> incomplete:
>
> (org-export-string-as "Alpha&Beta{"
> 'html
> '(:export-options (body-only)))
> "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
mmm, right. And there may also be a problem with the subscripts: &_{subscript}...
Perhaps we should think about a structure less prone to ambiguities. For
example:
&:type[attrs]{text} / &:_[attrs]{text}
(I think someone had suggested something like this in a past message,
but I can't find it, apologies).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 11:06 12% ` Juan Manuel Macías
@ 2024-03-07 11:18 6% ` Ihor Radchenko
2024-03-07 11:19 6% ` Juan Manuel Macías
2024-03-07 15:53 12% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Ihor Radchenko @ 2024-03-07 11:18 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> (org-export-string-as "Alpha&Beta{"
> ...
> mmm, right. And there may also be a problem with the subscripts: &_{subscript}...
>
> Perhaps we should think about a structure less prone to ambiguities. For
> example:
>
> &:type[attrs]{text} / &:_[attrs]{text}
I suggest @type[...]{...}. Akin Texinfo constructs.
(Texinfo because of
previous RMS' request to implement better support for markup used in
software manuals - keeping things close to Texinfo syntax will make life
easier if we ever reach the point when Org mode is used as standard
documentation format.)
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 11:18 6% ` Ihor Radchenko
@ 2024-03-07 11:19 6% ` Juan Manuel Macías
2024-03-07 15:53 12% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-07 11:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> (org-export-string-as "Alpha&Beta{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts: &_{subscript}...
>>
>> Perhaps we should think about a structure less prone to ambiguities. For
>> example:
>>
>> &:type[attrs]{text} / &:_[attrs]{text}
>
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.)
+1
(one character is always better than two)
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 11:18 6% ` Ihor Radchenko
2024-03-07 11:19 6% ` Juan Manuel Macías
@ 2024-03-07 15:53 12% ` Juan Manuel Macías
2024-03-07 16:09 6% ` Ihor Radchenko
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-07 15:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.)
I have modified the syntax in the last commit. Now:
@type[...]{...} (or @_[...]{...})
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 15:53 12% ` Juan Manuel Macías
@ 2024-03-07 16:09 6% ` Ihor Radchenko
2024-03-07 16:57 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-03-07 16:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have modified the syntax in the last commit. Now:
>
> @type[...]{...} (or @_[...]{...})
I am wondering if @@[...]{...} would be better than @_...
It should be slightly easier to type.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 16:09 6% ` Ihor Radchenko
@ 2024-03-07 16:57 12% ` Juan Manuel Macías
2024-03-07 18:21 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-07 16:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko <yantar92@posteo.net> escribió:
> I am wondering if @@[...]{...} would be better than @_...
> It should be slightly easier to type.
Another possibility would be @:[...]{...}, which is somewhat shorter.
(I don't have any special preference, although @@ visually reminds me a
bit of the export snippet).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 16:57 12% ` Juan Manuel Macías
@ 2024-03-07 18:21 12% ` Juan Manuel Macías
2024-03-08 13:58 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-07 18:21 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías writes:
> Ihor Radchenko <yantar92@posteo.net> escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any special preference, although @@ visually reminds me a
> bit of the export snippet).
Anyway, in the last commit I replaced _ with @. Let's see how it goes...
Now the anonymous variant is @@[...]{...}.
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-07 18:21 12% ` Juan Manuel Macías
@ 2024-03-08 13:58 6% ` Max Nikulin
2024-03-08 15:44 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-08 13:58 UTC (permalink / raw)
To: emacs-orgmode
On 08/03/2024 01:21, Juan Manuel Macías wrote:
>> Ihor Radchenko escribió:
>>
>>> I am wondering if @@[...]{...} would be better than @_...
>>> It should be slightly easier to type.
>
> Anyway, in the last commit I replaced _ with @. Let's see how it goes...
> Now the anonymous variant is @@[...]{...}.
Unfortunately the issue, I have reported, has not fixed. I admit, the
examples have become more contrived
(org-export-string-as "Alpha@Beta{"
'html
'(:export-options (body-only)))
"<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
(org-export-string-as "Alpha@Beta["
'html
'(:export-options (body-only)))
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
nil)
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 13:58 6% ` Max Nikulin
@ 2024-03-08 15:44 12% ` Juan Manuel Macías
2024-03-08 16:04 6% ` Max Nikulin
2024-03-08 16:15 6% ` Ihor Radchenko
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-08 15:44 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> (org-export-string-as "Alpha@Beta{"
> 'html
> '(:export-options (body-only)))
> "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
>
> (org-export-string-as "Alpha@Beta["
> 'html
> '(:export-options (body-only)))
> Debugger entered--Lisp error: (wrong-type-argument
> number-or-marker-p nil)
Maybe in that case you could add a zero width space character.
In any case, if someone has reasons to write "Alpha@Beta{" they may also
have reasons to write "Alpha_Beta":
(org-export-string-as "Alpha_beta"
'html
'(:export-options (body-only)))
<p>
Alpha<sub>beta</sub></p>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 15:44 12% ` Juan Manuel Macías
@ 2024-03-08 16:04 6% ` Max Nikulin
2024-03-08 16:15 6% ` Ihor Radchenko
1 sibling, 0 replies; 144+ results
From: Max Nikulin @ 2024-03-08 16:04 UTC (permalink / raw)
To: emacs-orgmode
On 08/03/2024 22:44, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> (org-export-string-as "Alpha@Beta{"
>> 'html
>> '(:export-options (body-only)))
>> "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
>>
>> (org-export-string-as "Alpha@Beta["
>> 'html
>> '(:export-options (body-only)))
>> Debugger entered--Lisp error: (wrong-type-argument
>> number-or-marker-p nil)
>
> Maybe in that case you could add a zero width space character.
>
> In any case, if someone has reasons to write "Alpha@Beta{" they may also
> have reasons to write "Alpha_Beta":
>
> (org-export-string-as "Alpha_beta"
> 'html
> '(:export-options (body-only)))
> <p>
> Alpha<sub>beta</sub></p>
From my point of view it is a pitfall with Org syntax, but parser works
as it should.
On the other hand if there is no closing bracket then it is not an
inline special block, so this part of document should be considered as
text (unless some other objects are recognized).
Currently Org parser does not signal errors even for invalid input.
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 15:44 12% ` Juan Manuel Macías
2024-03-08 16:04 6% ` Max Nikulin
@ 2024-03-08 16:15 6% ` Ihor Radchenko
2024-03-08 18:44 12% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-03-08 16:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Debugger entered--Lisp error: (wrong-type-argument
>> number-or-marker-p nil)
>
> Maybe in that case you could add a zero width space character.
>
> In any case, if someone has reasons to write "Alpha@Beta{" they may also
> have reasons to write "Alpha_Beta":
1. Parser must not throw errors on text files. Ever. Any text file is a
valid Org file.
2. We should demand paired {...}, as we do for latex fragments,
emphasis, inline export snippets, and all other container objects.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 16:15 6% ` Ihor Radchenko
@ 2024-03-08 18:44 12% ` Juan Manuel Macías
2024-03-08 18:57 14% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-08 18:44 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Debugger entered--Lisp error: (wrong-type-argument
>>> number-or-marker-p nil)
>>
>> Maybe in that case you could add a zero width space character.
>>
>> In any case, if someone has reasons to write "Alpha@Beta{" they may also
>> have reasons to write "Alpha_Beta":
>
> 1. Parser must not throw errors on text files. Ever. Any text file is a
> valid Org file.
> 2. We should demand paired {...}, as we do for latex fragments,
> emphasis, inline export snippets, and all other container objects.
Ok, I think you and Maxim are right. This is a clear bug. I hope it
was fixed in the last commit.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 18:44 12% ` Juan Manuel Macías
@ 2024-03-08 18:57 14% ` Juan Manuel Macías
2024-03-09 11:10 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-08 18:57 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> escribió:
> Ok, I think you and Maxim are right. This is a clear bug. I hope it
> was fixed in the last commit.
Now:
(org-export-string-as "Alpha@Beta{" 'latex t))
==> Alpha@Beta\{
(org-export-string-as "Alpha@Beta{gamma}" 'latex t))
==> Alpha\Beta{gamma}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 14%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-08 18:57 14% ` Juan Manuel Macías
@ 2024-03-09 11:10 6% ` Max Nikulin
2024-03-09 11:48 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-09 11:10 UTC (permalink / raw)
To: emacs-orgmode
On 09/03/2024 01:57, Juan Manuel Macías wrote:
>
>> Ok, I think you and Maxim are right. This is a clear bug. I hope it
>> was fixed in the last commit.
>
> (org-export-string-as "Alpha@Beta{" 'latex t))
>
> ==> Alpha@Beta\{
>
> (org-export-string-as "Alpha@Beta{gamma}" 'latex t))
>
> ==> Alpha\Beta{gamma}
However it is still gives
(org-export-string-as "Alpha@Beta["
'html
'(:export-options (body-only)))
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
nil)
Moreover I am unsure if "@" should be allowed in any position of elements
(org-export-string-as "@sp@n{}"
'html
'(:export-options (body-only)))
"<p>\n<span class=\"sp@n\">nil</span></p>\n"
(org-export-string-as "@@@@{}"
'latex
'(:export-options (body-only)))
"\\@@@{nil}\n"
^ permalink raw reply [relevance 6%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-09 11:10 6% ` Max Nikulin
@ 2024-03-09 11:48 12% ` Juan Manuel Macías
2024-03-09 15:24 14% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-09 11:48 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> However it is still gives
>
> (org-export-string-as "Alpha@Beta["
> 'html
> '(:export-options (body-only)))
> Debugger entered--Lisp error: (wrong-type-argument
> number-or-marker-p nil)
I think the problem is the contents-begin variable. When it is nil it
produces that error. I will make a new commit to fix the bug.
Thanks for all the tests you're doing!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-09 11:48 12% ` Juan Manuel Macías
@ 2024-03-09 15:24 14% ` Juan Manuel Macías
2024-03-10 7:11 7% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-09 15:24 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Juan Manuel Macías writes:
> Max Nikulin writes:
>
>> However it is still gives
>>
>> (org-export-string-as "Alpha@Beta["
>> 'html
>> '(:export-options (body-only)))
>> Debugger entered--Lisp error: (wrong-type-argument
>> number-or-marker-p nil)
>
> I think the problem is the contents-begin variable. When it is nil it
> produces that error. I will make a new commit to fix the bug.
>
> Thanks for all the tests you're doing!
Well, I hope that in the last commit the two bugs that you mentioned
have been fixed. Please check:
Albha@Beta[
@sp@n{lorem ipsum}
@@@@{lorem ipsum}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 14%]
* `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-03 20:29 9% ` Juan Manuel Macías
@ 2024-03-10 2:08 10% ` Juan Manuel Macías
2024-03-10 13:54 13% ` Juan Manuel Macías
2024-03-11 10:27 5% ` Max Nikulin
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-10 2:08 UTC (permalink / raw)
To: orgmode
I'm thinking about adding a new global attribute, `:export', that
would granularly control whether or not to export the object and how to
export it.
Possible values: "noexport", "contents" (it would export only the content)
or the backends to which you want to export, separated by spaces. Each
backend should be followed by a "+" sign (= export all) or "*" (export
content only). For example:
@foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
This means that "lorem ipsum dolor" would be exported with color format
to LaTeX, but only the content would be exported to odt and html.
Wdyt?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: false positives: Re: Experimental public branch for inline special blocks
2024-03-09 15:24 14% ` Juan Manuel Macías
@ 2024-03-10 7:11 7% ` Max Nikulin
0 siblings, 0 replies; 144+ results
From: Max Nikulin @ 2024-03-10 7:11 UTC (permalink / raw)
To: emacs-orgmode
On 09/03/2024 22:24, Juan Manuel Macías wrote:
> Well, I hope that in the last commit the two bugs that you mentioned
> have been fixed. Please check:
>
> Albha@Beta[
>
> @sp@n{lorem ipsum}
>
> @@@@{lorem ipsum}
Thanks, Juan Manuel. I do not see issues any more.
I would still consider unit tests to not break these cases later.
^ permalink raw reply [relevance 7%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-10 2:08 10% ` `:export' attribute?: " Juan Manuel Macías
@ 2024-03-10 13:54 13% ` Juan Manuel Macías
2024-03-11 10:27 5% ` Max Nikulin
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-10 13:54 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the content)
> or the backends to which you want to export, separated by spaces. Each
> backend should be followed by a "+" sign (= export all) or "*" (export
> content only). For example:
>
> @foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
>
> This means that "lorem ipsum dolor" would be exported with color format
> to LaTeX, but only the content would be exported to odt and html.
I have implemented the new :export attribute in the last commit, to
experiment (in any case, it can always be reverted). The syntax and
usage are as described in the previous message. An example, where we
define an alias for inline comments and another for highlighted text: It
will only be exported as highlighted text to LaTeX (using the lua-ul
package for LuaLaTeX); only the content will be exported to HTML; and it
will not be exported to the rest of the backends.
#+options: inline-special-block-aliases:(("comment" :export "noexport")("hl" :export "latex+ html*" :latex-command "highLight"))
#+latex_header: \usepackage{xcolor,luacolor,lua-ul}
#+latex_compiler: lualatex
@hl{this is highlighted text, only in LaTeX} @comment{this is a comment}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-10 2:08 10% ` `:export' attribute?: " Juan Manuel Macías
2024-03-10 13:54 13% ` Juan Manuel Macías
@ 2024-03-11 10:27 5% ` Max Nikulin
2024-03-11 13:59 11% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-11 10:27 UTC (permalink / raw)
To: emacs-orgmode
On 10/03/2024 09:08, Juan Manuel Macías wrote:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
I have a bit different expectations in respect to export predicates. It
should be possible to express that some content should be exported by
all backend except the given list. The use case is fallback for backends
not covered by export snippets:
@@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML
formatting</strong>@@@[...]{*for other backends}
Earlier I raised this issue during discussion of @@:...@@ syntax extension:
Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022
21:52:17 +0700.
https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982fcf@gmail.com
Another case for backend predicates is whether it should be applicable
to derived backends or just to explicitly specified ones.
^ permalink raw reply [relevance 5%]
* Re: Footnotes on line and not raised
@ 2024-03-11 11:03 12% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-11 11:03 UTC (permalink / raw)
To: Colin Baxter; +Cc: emacs-orgmode
Colin Baxter writes:
> Perhaps it's not possible because I see that .footref in css support is
> always <sup>.
You can modify <sup> a little so that it does not alter the paragraph
line spacing so much. In this example, with a value of 0em, it is
positioned on the baseline:
#+HTML_HEAD: <style> sup {vertical-align: baseline;position: relative;bottom: 0em;} </style>
Another slightly dirtier way is with an export filter in your document.
The sub tag is removed and the reference number is enclosed in square
brackets, separated by a space from the previous word:
#+BIND: org-export-filter-footnote-reference-functions (footnote-sup-filter)
#+begin_src emacs-lisp :exports results :results none
(defun footnote-sup-filter (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "<a" " <a"
(replace-regexp-in-string "\\([[:digit:]]+\\)\\(</a\\)" "[\\1]\\2"
(replace-regexp-in-string "</?sup>" "" text)))))
#+end_src
screenshot:
https://i.ibb.co/CBRnfXG/pantallazo-79248380551244229p8.png
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-11 10:27 5% ` Max Nikulin
@ 2024-03-11 13:59 11% ` Juan Manuel Macías
2024-03-11 17:01 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-11 13:59 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 10/03/2024 09:08, Juan Manuel Macías wrote:
>> I'm thinking about adding a new global attribute, `:export', that
>> would granularly control whether or not to export the object and how to
>> export it.
>
> I have a bit different expectations in respect to export predicates.
> It should be possible to express that some content should be exported
> by all backend except the given list. The use case is fallback for
> backends not covered by export snippets:
>
> @@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML
> formatting</strong>@@@[...]{*for other backends}
I think that in your example (if I understand the intentions correctly)
it would not even be necessary to use export snippets:
#+options: inline-special-block-aliases:(("strong" :latex-command textbf
:html-tag strong :export "latex+ html+ odt*" ))
@strong{formatting}
or even:
@strong{@@latex:\latex{}: @@@@html:HTML: @@ formatting}
As defined, it is exported to LaTeX and HTML with all the formatting,
but only the content is exported to odt. The rest are not exported.
Maybe an "rest" option could be added, to avoid verbosity:
:export "latex+ html+ rest*"
(the complete format is exported to LaTeX and html and only the content to the rest).
However, I think that exporting this object to 'format-agnostic' backends,
such as plain text, would have to be implemented in a way that always
exports the content.
> Earlier I raised this issue during discussion of @@:...@@ syntax extension:
> Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022
> 21:52:17 +0700.
> https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982fcf@gmail.com
>
> Another case for backend predicates is whether it should be applicable
> to derived backends or just to explicitly specified ones.
I don't have a definite opinion. Maybe it would be nice to also take
into account derived backends...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-11 13:59 11% ` Juan Manuel Macías
@ 2024-03-11 17:01 6% ` Max Nikulin
2024-03-11 20:19 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-11 17:01 UTC (permalink / raw)
To: emacs-orgmode
On 11/03/2024 20:59, Juan Manuel Macías wrote:
>>
>> I have a bit different expectations in respect to export predicates.
>> It should be possible to express that some content should be exported
>> by all backend except the given list. The use case is fallback for
>> backends not covered by export snippets:
>>
>> @@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML
>> formatting</strong>@@@[...]{*for other backends}
>
> I think that in your example (if I understand the intentions correctly)
> it would not even be necessary to use export snippets:
>
> #+options: inline-special-block-aliases:(("strong" :latex-command textbf
> :html-tag strong :export "latex+ html+ odt*" ))
Your example uses a closed list of backends while "not (html or latex)"
may be applicable to ascii, rst, some wiki dialects, etc.
Backend-specific markup may be more complex and content of fallback
option may be different from text used in export snippets. Perhaps I
shouldn't give so simple example.
Side note: I expect that the new object will be more convenient than
export snippets in most cases.
> :export "latex+ html+ rest*"
"rest" might be a valid backend name.
^ permalink raw reply [relevance 6%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-11 17:01 6% ` Max Nikulin
@ 2024-03-11 20:19 11% ` Juan Manuel Macías
2024-03-12 8:32 6% ` Stefan Nobis
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-11 20:19 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> Your example uses a closed list of backends while "not (html or
> latex)" may be applicable to ascii, rst, some wiki dialects, etc.
Makes sense.
> Backend-specific markup may be more complex and content of fallback
> option may be different from text used in export snippets. Perhaps I
> shouldn't give so simple example.
I think I have understood the essentials, but perhaps it would be good
to see a slightly more complex scenario.
> Side note: I expect that the new object will be more convenient than
> export snippets in most cases.
I think so. In any case, although this object is proving pleasantly
versatile for us, I think we should not lose sight of the fact that its
main purpose is to be an inline text container with export properties.
Exports snippets are more for literal code inclusion. There can be
border uses between both objects, as there can also be with macros and
links. I suppose the ideal is to always choose the feature that best
suits a given context. One can put, for example @esindex[:export
latex+]{some word}, but in this case it would be more comfortable to put
@@latex:\esindex{some word}@@ or even use a macro.
>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.
I will try to implement the "rest" option.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-11 20:19 11% ` Juan Manuel Macías
@ 2024-03-12 8:32 6% ` Stefan Nobis
2024-03-12 13:45 11% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Stefan Nobis @ 2024-03-12 8:32 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>> :export "latex+ html+ rest*"
>> "rest" might be a valid backend name.
> I will try to implement the "rest" option.
What about "others" or even ":others" as a placeholder for any not
explicitly mentioned export backend?
Another quick thought crossing my mind: May make "+" the default (so
"latex" means "latex+" and only use a marker char like '*' for
"content only")?
--
Until the next mail...,
Stefan.
^ permalink raw reply [relevance 6%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-12 8:32 6% ` Stefan Nobis
@ 2024-03-12 13:45 11% ` Juan Manuel Macías
2024-03-12 16:20 6% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-12 13:45 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Max Nikulin, Stefan Nobis
In the last commit I have introduced some changes. Now this new feature
is no longer hardcoded in each backend but is controlled by an external
function in ox.el. I think this can simplify the implementation for
other backends.
As Stefan Nobis proposed, the "+" sign is now not necessary:
backend-name = full export
backend-name* = only contents
And the "rest" option is introduced, with the same syntax as before.
Examples:
@foo[:export noexport]{lorem ipsum dolor}
==> does not export anything
@foo[:export contents]{lorem ipsum dolor}
==> only contents
@foo[:export latex]{lorem ipsum dolor}
==> exports only to LaTeX
@foo[:export latex odt* html*]{lorem ipsum dolor}
==> exports everything to LaTeX, but to odt and HTML only the content
@foo[:export latex* rest]{lorem ipsum dolor}
==> content to LaTeX but full export to the rest of the backends
@foo[:export latex rest*]{lorem ipsum dolor}
==> the opposite of the above.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-12 13:45 11% ` Juan Manuel Macías
@ 2024-03-12 16:20 6% ` Max Nikulin
2024-03-12 17:41 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-12 16:20 UTC (permalink / raw)
To: emacs-orgmode
On 12/03/2024 20:45, Juan Manuel Macías wrote:
>
> backend-name = full export
> backend-name* = only contents
> And the "rest" option is introduced, with the same syntax as before.
>
> Examples:
It is not clear for me how to achieve the following. Add a link
[[https://youtube.com/...][Org mode in action demo (video)]]
for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because
there is an #+export_html block with player embedded using an iframe.
Instead of "noexport" and "rest" that may be confused with backend names
I would consider "+" and "*" without any name. I would consider some
characters like "-", "_", "!", "~" to express "do not export to this and
derived backends" and "do not export for specified backend only".
^ permalink raw reply [relevance 6%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-12 16:20 6% ` Max Nikulin
@ 2024-03-12 17:41 12% ` Juan Manuel Macías
2024-03-13 16:08 5% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-12 17:41 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> It is not clear for me how to achieve the following. Add a link
>
> [[https://youtube.com/...][Org mode in action demo (video)]]
>
> for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because
> there is an #+export_html block with player embedded using an iframe.
Sorry, I don't quite understand this. Could you please elaborate?
> Instead of "noexport" and "rest" that may be confused with backend
> names I would consider "+" and "*" without any name. I would consider
> some characters like "-", "_", "!", "~" to express "do not export to
> this and derived backends" and "do not export for specified backend
> only".
how about the following:
- "--" :: do not export
- "**" :: export only the content
- "==" :: rest (full)
- "=*" :: rest (only the content)
- "!backend-name+ :: export this backend (full)
- "!backend-name*" :: export this backend (only the content)
- "!backend-name- :: do not export this backend
?
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-12 17:41 12% ` Juan Manuel Macías
@ 2024-03-13 16:08 5% ` Max Nikulin
2024-03-13 16:48 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-13 16:08 UTC (permalink / raw)
To: emacs-orgmode
On 13/03/2024 00:41, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> It is not clear for me how to achieve the following. Add a link
>>
>> [[https://youtube.com/...][Org mode in action demo (video)]]
>>
>> for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because
>> there is an #+export_html block with player embedded using an iframe.
>
> Sorry, I don't quite understand this. Could you please elaborate?
--- 8< ---
&_[:exports -html]{Watch [[https://youtube.com/...][Org mode in action
demo]] video.}
#+begin_export html
<iframe src="https://youtube.com/embed/..."
title="Org mode in action demo"
width="..." height="..."></iframe>
#+end_export
--- >8 ---
should be exported to HTML without the sentence with the link
--- 8< ---
<iframe src="https://youtube.com/embed/..."
title="Org mode in action demo"
width="..." height="..."></iframe>
--- >8 ---
however only the sentence with the link is exported to LaTeX or any
other format
--- 8< ---
Watch \href{https://youtube.com/...}{Org mode in action demo} video.
--- >8 ---
>> Instead of "noexport" and "rest" that may be confused with backend
>> names I would consider "+" and "*" without any name. I would consider
>> some characters like "-", "_", "!", "~" to express "do not export to
>> this and derived backends" and "do not export for specified backend
>> only".
>
> how about the following:
> - "--" :: do not export
> - "**" :: export only the content
> - "==" :: rest (full)
> - "=*" :: rest (only the content)
> - "!backend-name+ :: export this backend (full)
> - "!backend-name*" :: export this backend (only the content)
> - "!backend-name- :: do not export this backend
I do not see why operator should be duplicated for backends that are not
specified explicitly. Single "+" (default) or "-" should be enough. I
have not got your idea with leading "!". From my point of view it is
redundant.
^ permalink raw reply [relevance 5%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-13 16:08 5% ` Max Nikulin
@ 2024-03-13 16:48 12% ` Juan Manuel Macías
2024-03-13 17:16 14% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-13 16:48 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
>> how about the following:
>> - "--" :: do not export
>> - "**" :: export only the content
>> - "==" :: rest (full)
>> - "=*" :: rest (only the content)
>> - "!backend-name+ :: export this backend (full)
>> - "!backend-name*" :: export this backend (only the content)
>> - "!backend-name- :: do not export this backend
>
> I do not see why operator should be duplicated for backends that are not
> specified explicitly. Single "+" (default) or "-" should be enough. I
> have not got your idea with leading "!". From my point of view it is
> redundant.
It was necessary with the previous implementation, which excessively
abused regexp. Not now (I want to do a few more tests and I'll make a
new commit with the changes). With the new implementation, now:
- do not export
* export only the content
= rest (full)
=* rest (contents only)
backend- do not export this backend (and the backends derived from it)
backend+ (or, perhaps, just "backend") export this backend (idem)
backend* export this backend (contents only) (idem)
I think your example with the video link would also be possible with the
new implementation.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-13 16:48 12% ` Juan Manuel Macías
@ 2024-03-13 17:16 14% ` Juan Manuel Macías
2024-03-15 2:19 5% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-13 17:16 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Juan Manuel Macías writes:
> It was necessary with the previous implementation, which excessively
> abused regexp. Not now (I want to do a few more tests and I'll make a
> new commit with the changes). With the new implementation, now:
>
> - do not export
>
> * export only the content
>
> = rest (full)
>
> =* rest (contents only)
>
> backend- do not export this backend (and the backends derived from it)
>
> backend+ (or, perhaps, just "backend") export this backend (idem)
>
> backend* export this backend (contents only) (idem)
>
> I think your example with the video link would also be possible with the
> new implementation.
Please try the latest commit:
@@[:export html-]{Watch [[https://youtube.com/...][Org mode in action demo]] video.}
#+begin_export html
<iframe src="https://youtube.com/embed/..."
title="Org mode in action demo"
width="..." height="..."></iframe>
#+end_export
It would not be exported to html or its derived backends.
(In your example you used `-html' instead of `html-'. I have no
preference for one variant or another).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 14%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-13 17:16 14% ` Juan Manuel Macías
@ 2024-03-15 2:19 5% ` Juan Manuel Macías
2024-03-15 10:52 4% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-15 2:19 UTC (permalink / raw)
To: orgmode
To summarize the latest improvements and modifications to the `:export'
attribute...
The attribute supports one or more elements separated by a space. Each
element can be any of the following signs: "*" (export only the
content), "-" (do not export), "=" (export the rest normally), "=*"
(export the rest, but only the content), "=-" (do not export the rest).
Additionally, backend names can be given explicitly, alone or
accompanied by the "*" or "-" signs, that is (where "backend" equals the
name of the backend):
backend: export normally for that backend and its derived backends;
backend-: do not export for that backend or its derived backends.
backend*: export only the content for that backend and its derived
backends.
Some examples with valid combinations:
@foo[:export *]{lorem ipsum}
==> export only the content
@foo[:export -]{lorem ipsum}
==> do not export
@foo[:export latex-]{lorem ipsum}
==> do not export to LaTeX
@foo[:export latex- html* =]{lorem ipsum}
==> do not export to LaTeX, export only the content to html and export the
rest normally.
@foo[:export latex =*]{lorem ipsum}
==> export normally to LaTeX but export only the content to the rest
@foo[:export latex =-]{lorem ipsum}
==> export normally to LaTeX and not export to the rest
And below is a complete example based on a possible use case that Max
had exposed:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
To see a demo of the Fairlight CMI, watch @@[:export html =-]{this
video} @@[:export
html-]{[[https://www.youtube.com/watch?v=am0GBuS_7cE][this video]]}
with Peter Vogel.
#+begin_export html
<iframe width="560" height="315"
src="https://www.youtube.com/embed/am0GBuS_7cE?si=X7pghJhtdfOT1hby"
title="YouTube video player"
frameborder="0"
allow="accelerometer;
autoplay; clipboard-write; encrypted-media; gyroscope;
picture-in-picture; web-share"
allowfullscreen></iframe>
#+end_export
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
^ permalink raw reply [relevance 5%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-15 2:19 5% ` Juan Manuel Macías
@ 2024-03-15 10:52 4% ` Max Nikulin
2024-03-15 13:10 5% ` Juan Manuel Macías
2024-03-15 16:26 12% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Max Nikulin @ 2024-03-15 10:52 UTC (permalink / raw)
To: emacs-orgmode
On 15/03/2024 09:19, Juan Manuel Macías wrote:
> The attribute supports one or more elements separated by a space. Each
> element can be any of the following signs: "*" (export only the
> content), "-" (do not export), "=" (export the rest normally), "=*"
> (export the rest, but only the content), "=-" (do not export the rest).
> Additionally, backend names can be given explicitly, alone or
> accompanied by the "*" or "-" signs, that is (where "backend" equals the
> name of the backend):
1. "-" is a valid backend name and valid last character of backend name
2. From the description it is not clear to me what is effect of "rest"
specified for more than one backend.
I have had into the code. I would expect something like the following
(characters may be changed, the code is not heavily tested). Two
characters from the following groups may be appended to backend name:
+ full (default)
* content
/ skip
(these ones may be used without backed name to specify fallback action)
= this and derived backends (default)
. this, but not derived backends
Perhaps it is necessary to add possibility that
these rules may coexist (use loop instead of assoc)
(ignore
(pp
(let ((rules
(org-export--inline-special-block-make-backend-alist
(org-split-string "latex/ html./ ascii+ *"))))
(mapcar (lambda (backend)
(list backend
(org-export--inline-special-block-export-decision
rules backend)))
'(odt latex beamer html md ascii)))))
Gives
((odt content)
(latex nil)
(beamer nil)
(html nil)
(md content)
(ascii full))
Function definitions:
(defun org-export--inline-special-block-make-backend-alist
(rules)
(nconc
(let (result)
(dolist (spec rules)
(if (string-match
"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
spec)
(let ((name (match-string 1 spec))
(inherit (match-string 3 spec))
(what (or (match-string 2 spec)
(match-string 4 spec))))
(push (cons
(if (string-equal "" name) '@ (intern name))
(cons (or (not inherit) (string-equal inherit "="))
(if what (string-to-char what) ?+)))
result))
(message "invalid :export specification %S" spec)))
result)))
(defun org-export--inline-special-block-export-decision
(rules-alist backend)
(when (symbolp backend)
(setq backend (org-export-get-backend backend)))
(let* ((rule (assoc (org-export-backend-name backend) rules-alist))
(decision (and rule (cddr rule))))
(while (and (not decision)
(setq backend (org-export-backend-parent backend)))
(setq backend (org-export-get-backend backend))
(when (and (setq rule (assq (org-export-backend-name backend)
rules-alist))
rule
(cadr rule))
(setq decision (cddr rule))))
(unless decision
(setq rule (assq '@ rules-alist))
(setq decision (and rule (cddr rule))))
(pcase decision
(?+ 'full)
(?* 'content)
(?/ nil)
(_ 'full))))
^ permalink raw reply [relevance 4%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-15 10:52 4% ` Max Nikulin
@ 2024-03-15 13:10 5% ` Juan Manuel Macías
2024-03-15 17:21 5% ` Max Nikulin
2024-03-15 16:26 12% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-15 13:10 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Thank you for your comments.
Max Nikulin writes:
> On 15/03/2024 09:19, Juan Manuel Macías wrote:
>> The attribute supports one or more elements separated by a space. Each
>> element can be any of the following signs: "*" (export only the
>> content), "-" (do not export), "=" (export the rest normally), "=*"
>> (export the rest, but only the content), "=-" (do not export the rest).
>> Additionally, backend names can be given explicitly, alone or
>> accompanied by the "*" or "-" signs, that is (where "backend" equals the
>> name of the backend):
>
> 1. "-" is a valid backend name and valid last character of backend name
I had not thought of it. Can + also be a valid character?
> 2. From the description it is not clear to me what is effect of "rest"
> specified for more than one backend.
'rest' (=) is equivalent to the rest of the backends that have not been
explicitly set. What happens is that, with my current approach, if you
want to export only one backend, you must enter:
:export backend =- (that is, export this backend and not the rest)
This is not ideal. It should be enough to just put:
:export backend
but I am not able to achieve it.
> I have had into the code. I would expect something like the following
> (characters may be changed, the code is not heavily tested). Two
> characters from the following groups may be appended to backend name:
>
> + full (default)
> * content
> / skip
> (these ones may be used without backed name to specify fallback action)
>
> = this and derived backends (default)
> . this, but not derived backends
> Perhaps it is necessary to add possibility that
> these rules may coexist (use loop instead of assoc)
OK. How about the following?
- Single characters (they affect everything, if backend name is not
specified, or the rest, if backend name is specified:
* content
/ skip
. never export derived backends
= full, this and derived backends (default)
- And in combination with backend names (some examples):
:export latex* > content to LaTeX, normal to the rest
:export latex/ > do not export to LaTeX
:export latex. > do not export to LaTeX derived backends
:export latex . > export normally to LaTeX but do not export the derived backends in the rest of the cases
etc.
These days I'm going to be a little short on time, due to work, and I
don't know if I'll be able to attend to the list. I want to calmly take
a look at the code you share.
^ permalink raw reply [relevance 5%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-15 10:52 4% ` Max Nikulin
2024-03-15 13:10 5% ` Juan Manuel Macías
@ 2024-03-15 16:26 12% ` Juan Manuel Macías
2024-03-16 14:07 4% ` Max Nikulin
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-15 16:26 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> (ignore
> (pp
> (let ((rules
> (org-export--inline-special-block-make-backend-alist
> (org-split-string "latex/ html./ ascii+ *"))))
> (mapcar (lambda (backend)
> (list backend
> (org-export--inline-special-block-export-decision
> rules backend)))
> '(odt latex beamer html md ascii)))))
>
> Gives
>
> ((odt content)
> (latex nil)
> (beamer nil)
> (html nil)
> (md content)
> (ascii full))
>
> Function definitions:
>
> (defun org-export--inline-special-block-make-backend-alist
> (rules)
> (nconc
> (let (result)
> (dolist (spec rules)
> (if (string-match
>
> "\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
> spec)
> (let ((name (match-string 1 spec))
> (inherit (match-string 3 spec))
> (what (or (match-string 2 spec)
> (match-string 4 spec))))
> (push (cons
> (if (string-equal "" name) '@ (intern name))
> (cons (or (not inherit) (string-equal inherit "="))
> (if what (string-to-char what) ?+)))
> result))
> (message "invalid :export specification %S" spec)))
> result)))
>
> (defun org-export--inline-special-block-export-decision
> (rules-alist backend)
> (when (symbolp backend)
> (setq backend (org-export-get-backend backend)))
> (let* ((rule (assoc (org-export-backend-name backend) rules-alist))
> (decision (and rule (cddr rule))))
> (while (and (not decision)
> (setq backend (org-export-backend-parent backend)))
> (setq backend (org-export-get-backend backend))
> (when (and (setq rule (assq (org-export-backend-name backend)
> rules-alist))
> rule
> (cadr rule))
> (setq decision (cddr rule))))
> (unless decision
> (setq rule (assq '@ rules-alist))
> (setq decision (and rule (cddr rule))))
> (pcase decision
> (?+ 'full)
> (?* 'content)
> (?/ nil)
> (_ 'full))))
I've been testing your code and it works very well. It is certainly
finer than the current approach. I think it could be implemented, and we
are testing that.
Tomorrow I will make a new commit with your code.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-15 13:10 5% ` Juan Manuel Macías
@ 2024-03-15 17:21 5% ` Max Nikulin
0 siblings, 0 replies; 144+ results
From: Max Nikulin @ 2024-03-15 17:21 UTC (permalink / raw)
To: emacs-orgmode
On 15/03/2024 20:10, Juan Manuel Macías wrote:
> Max Nikulin writes:
>>
>> 1. "-" is a valid backend name and valid last character of backend name
>
> I had not thought of it. Can + also be a valid character?
https://orgmode.org/worg/org-syntax.html#Affiliated_Keywords
BACKEND
A string consisting of alphanumeric characters, hyphens, or
underscores (-_).
>> 2. From the description it is not clear to me what is effect of "rest"
>> specified for more than one backend.
>
> 'rest' (=) is equivalent to the rest of the backends that have not been
> explicitly set. What happens is that, with my current approach, if you
> want to export only one backend, you must enter:
>
> :export backend =- (that is, export this backend and not the rest)
At first I thought it may be used as [:export backend=-] and it is the
reason why I was confused. However I still do not see difference between
[:export backend -] and [:export backend =-].
> This is not ideal. It should be enough to just put:
>
> :export backend
>
> but I am not able to achieve it.
I agree, it is intuitive, but it makes formal rules more complicated.
> = full, this and derived backends (default)
I would prefer to modify code to handle
[:export latex.+ latex=/]
to apply first declaration (content only) to latex and second one (skip)
to derived backends. Anyway the code requires optimization. Walk through
parent backends is likely inefficient.
> These days I'm going to be a little short on time, due to work, and I
> don't know if I'll be able to attend to the list.
Then I will postpone other questions (mostly unrelated to :export).
^ permalink raw reply [relevance 5%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-15 16:26 12% ` Juan Manuel Macías
@ 2024-03-16 14:07 4% ` Max Nikulin
2024-03-18 19:42 6% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-03-16 14:07 UTC (permalink / raw)
To: emacs-orgmode
On 15/03/2024 23:26, Juan Manuel Macías wrote:
> Tomorrow I will make a new commit with your code.
An update with a couple of bugs fixed. Now it is possible to specify
different export rules for a backend and all its derivatives:
(ignore
(pp
(let ((rules
(org-export--inline-special-block-make-backend-list
(org-split-string "latex/ html./ html+= ascii+ *"))))
(mapcar (lambda (backend)
(let ((hierarchy
(org-export--backend-hierarchy backend)))
(list backend
(org-export--inline-special-block-export-decision
rules hierarchy))))
'(odt latex beamer html md ascii)))))
((odt content)
(latex nil)
(beamer nil)
(html nil)
(md full)
(ascii full))
----
(defun org-export--inline-special-block-make-backend-list
(rules)
(let (result)
(dolist (spec rules)
(if (string-match
"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
spec)
(let ((name (match-string 1 spec))
(inherit (or (match-string 3 spec)
(match-string 4 spec)))
(what (or (match-string 2 spec)
(match-string 5 spec))))
(push (cons
(if (string-equal "" name) '@ (intern name))
(cons (or (not inherit) (string-equal inherit "="))
(if what (string-to-char what) ?+)))
result))
(message "invalid :export specification %S" spec)))
(nreverse result)))
(defun org-export--backend-hierarchy (backend)
"Result may be cached in INFO."
(let ((hierarchy))
(when (not (symbolp backend))
(setq backend (org-export-backend-name backend)))
(while backend
(push backend hierarchy)
(setq backend (org-export-backend-parent
(org-export-get-backend backend))))
hierarchy))
(defun org-export--inline-special-block-export-decision
(rule-list hierarchy)
(let ((hierarchy (cons '@ hierarchy))
(decision ?+))
(while (and hierarchy rule-list)
(let* ((rule (pop rule-list))
(tail (memq (car rule) hierarchy)))
(when (and tail
(or (not (cdr tail)) ; Current backend.
(cadr rule))) ; Inherits.
(setq hierarchy (cdr tail))
(setq decision (cddr rule)))))
(pcase decision
(?+ 'full)
(?* 'content)
(?/ nil)
(_ 'full))))
^ permalink raw reply [relevance 4%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-16 14:07 4% ` Max Nikulin
@ 2024-03-18 19:42 6% ` Juan Manuel Macías
2024-03-19 14:54 3% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-18 19:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> An update with a couple of bugs fixed. Now it is possible to specify
> different export rules for a backend and all its derivatives:
I have implemented your code in the last commit. I think it is a great
improvement, thanks a lot.
As I mentioned in a past email, these days I will be somewhat busy, but
I will try to keep up to date with your comments. Although it may take a
while to respond.
^ permalink raw reply [relevance 6%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-18 19:42 6% ` Juan Manuel Macías
@ 2024-03-19 14:54 3% ` Max Nikulin
2024-03-19 17:47 6% ` Juan Manuel Macías
2024-03-21 10:26 5% ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Max Nikulin @ 2024-03-19 14:54 UTC (permalink / raw)
To: emacs-orgmode
On 19/03/2024 02:42, Juan Manuel Macías wrote:
> As I mentioned in a past email, these days I will be somewhat busy, but
> I will try to keep up to date with your comments. Although it may take a
> while to respond.
Would you mind against new thread as an umbrella for next bunch of
topics? Current one becomes too large from my point of view.
For a while a couple of questions related to :export to think on.
I am afraid that :export will cause confusion with :exports for source
code blocks. Its name differs by just "s" but possible values have
nothing common.
Another issue is more general and should apply e.g. to HTML attributes
as well. Consider
--- 8< ---
#+options: inline-special-block-aliases:(("kbd" :export "html*"
:html-tag kbd))
@kbd{Default} and @kbd[:export "latex*"]{LaTeX}
--- >8 ---
It exports to
<p>\nDefault and <kbd class="kbd">LaTeX</kbd></p>
I would expect that "html*" is inherited from the parent declaration and
"latex*" does not override it, so
<p>\nDefault and LaTeX</p>
On the other hand it should be possible to specify that declared earlier
rules should be taken into consideration. E.g. "#" might stop further
processing:
--- 8< ---
#+options: inline-special-block-aliases:(("kbd" :export "html*"
:html-tag kbd))
@kbd{Default} and @kbd[:export "latex* #"]{LaTeX}
--- >8 ---
makes
<p>\nDefault and <kbd class="kbd">LaTeX</kbd></p>
result valid.
In the meanwhile I have realized that there is no point in the list of
parsed rules. You may consider code organized in a bit different way. I
hope, just a single extra line in these helpers is required to support "#".
(defun org-export--parse-export-rule
(spec)
(and (string-match
"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
spec)
(let ((name (match-string 1 spec))
(inherit (or (match-string 3 spec)
(match-string 4 spec)))
(what (or (match-string 2 spec)
(match-string 5 spec))))
(cons
(if (string-equal "" name) '@ (intern name))
(cons (or (not inherit) (string-equal inherit "="))
(pcase (and what (string-to-char what))
((or ?+ (pred null)) 'full)
(?* 'content)
(?/ nil)))))))
;; (org-export--parse-export-rule "html+=")
(defun org-export--backend-hierarchy (backend)
"Result may be cached in INFO."
(let ((hierarchy))
(when (not (symbolp backend))
(setq backend (org-export-backend-name backend)))
(while backend
(push backend hierarchy)
(setq backend (org-export-backend-parent
(org-export-get-backend backend))))
hierarchy))
;; (org-export--backend-hierarchy 'md)
(defun org-export--inline-special-block-export-decision
(spec-list hierarchy &optional default-rule)
"Returns (backend inherit . what).
so use `cddr' to get decision."
(let ((decision '(@ t . full))
(hierarchy (cons '@ hierarchy)))
(while (and hierarchy spec-list)
(let* ((rule (org-export--parse-export-rule (pop spec-list)))
(tail (and rule (memq (car rule) hierarchy))))
(if (not rule)
(message "invalid :export specification %S" (car spec-list)))
(when (and tail
(or (not (cdr tail)) ; Current backend.
(cadr rule))) ; Inherits.
(setq hierarchy (cdr tail))
(setq decision rule))))
(if (and default-rule (memq (car default-rule) hierarchy))
default-rule
decision)))
----
(ignore
(pp
(let ((rules (org-split-string "latex/ html./ html+= ascii+ *")))
(mapcar (lambda (backend)
(let ((hierarchy
(org-export--backend-hierarchy backend)))
(list backend
(cddr
(org-export--inline-special-block-export-decision
rules hierarchy)))))
'(odt latex beamer html md ascii)))))
((odt content)
(latex nil)
(beamer nil)
(html nil)
(md full)
(ascii full))
^ permalink raw reply [relevance 3%]
* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
2024-03-19 14:54 3% ` Max Nikulin
@ 2024-03-19 17:47 6% ` Juan Manuel Macías
2024-03-21 10:26 5% ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-03-19 17:47 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> Would you mind against new thread as an umbrella for next bunch of
> topics? Current one becomes too large from my point of view.
Ok, I agree. I suggest that from now any new thread related to the new
object have as subject:
"inline-special-block: specific topic to discuss".
Tomorrow I will try to answer all the latest questions related to the
export rules.
^ permalink raw reply [relevance 6%]
* inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks)
2024-03-19 14:54 3% ` Max Nikulin
2024-03-19 17:47 6% ` Juan Manuel Macías
@ 2024-03-21 10:26 5% ` Juan Manuel Macías
2024-03-26 16:56 6% ` inline-special-block: export rules Max Nikulin
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-21 10:26 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I am afraid that :export will cause confusion with :exports for source
> code blocks. Its name differs by just "s" but possible values have
> nothing common.
I agree. At the moment two alternative names come to mind: :backends or
:export-rules
> Another issue is more general and should apply e.g. to HTML attributes
> as well. Consider
>
> --- 8< ---
>
> #+options: inline-special-block-aliases:(("kbd" :export "html*"
> :html-tag kbd))
>
> @kbd{Default} and @kbd[:export "latex*"]{LaTeX}
> --- >8 ---
>
> It exports to
>
> <p>\nDefault and <kbd class="kbd">LaTeX</kbd></p>
>
> I would expect that "html*" is inherited from the parent declaration and
> "latex*" does not override it, so
>
> <p>\nDefault and LaTeX</p>
But it is the expected result in all attributes. If an attribute of the
same type as the one declared in the alias is added, the value is
overwritten.
In any case, since in this case the attribute allows cumulative values,
I think the approach should be at the level of the attribute name itself
and not the code to manage the export rules. For example:
:export [or whatever new name we give it] ==> normal behavior, overwrites the values
:export+ ==> adds the new values to the values defined in the alias
This syntax could also be extended to other cases. Perhaps we want
attributes like :prelatex, :postlatex, or :html to support accumulating
values. It could be easily solved from the functions of each backend. In
other cases, of course, it wouldn't make sense (a block can't have two
languages at the same time), but in that scenario, if someone puts
:lang+, it simply wouldn't be taken into account. Wdyt?
^ permalink raw reply [relevance 5%]
* [bug] Smart quotes: confusion of apostrophe with second level quotes
@ 2024-03-22 1:04 11% Juan Manuel Macías
2024-03-23 11:38 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-22 1:04 UTC (permalink / raw)
To: orgmode
Hi,
I don't know if this is a known issue, but I haven't been able to find
any mention of it. I think this is partly because in English it can go
perfectly unnoticed, since for English the values of secondary-closing
and apostrophe are identical:
(secondary-closing :utf-8 "’" :html "’" :latex "'" :texinfo "'")
(apostrophe :utf-8 "’" :html "’")
However, consider the following example:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
#+OPTIONS: ':t
#+language:es
"my friends' party and the students' papers"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
the above produces in LaTeX:
\guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
In Spanish, as in other similar cases, the issue is easier to reproduce
because:
(secondary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
(apostrophe :utf-8 "’" :html "’")
I don't know whether to consider this a bug or a limitation in the
current implementation, originating from how Org interprets an
apostrophe. Although I suspect it has a difficult solution: how to
differentiate an apostrophe from a second-level quote in certain
scenarios, when the approach seems to be essentially heuristic? Let us
also consider cases in which the apostrophe can be placed at the
beginning of a word, as in Greek:
"να 'ρθώ το βράδυ"
(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)
Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at least add some brief warning in the manual: in certain
contexts it is safer to use a explicit Unicode character for the
apostrophe.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
2024-03-22 1:04 11% [bug] Smart quotes: confusion of apostrophe with second level quotes Juan Manuel Macías
@ 2024-03-23 11:38 5% ` Ihor Radchenko
2024-03-23 13:41 6% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-03-23 11:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> #+OPTIONS: ':t
> #+language:es
>
> "my friends' party and the students' papers"
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> the above produces in LaTeX:
>
> \guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
> ...
> Perhaps a possible solution would be to allow the use of a specific,
> customizable character, other than an apostrophe, for second-level
> quotes. Or at least add some brief warning in the manual: in certain
> contexts it is safer to use a explicit Unicode character for the
> apostrophe.
I think that we can address examples like this simply by not replacing
unbalanced quotes. There is already some effort in the code towards such
treatment, but it is not complete.
Can you try the attached patch?
[-- Attachment #2: 0001-org-export-Do-not-treat-unpaired-and-as-smart-quotes.patch --]
[-- Type: text/x-patch, Size: 5726 bytes --]
From 4a034fbb0029ca7e635f629810a6179df4ca24d9 Mon Sep 17 00:00:00 2001
Message-ID: <4a034fbb0029ca7e635f629810a6179df4ca24d9.1711193777.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sat, 23 Mar 2024 14:34:06 +0300
Subject: [PATCH] org-export: Do not treat unpaired ' and " as smart quotes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/ox.el (org-export--smart-quote-status): When quotes are not
balanced, treat " literally and ' as apostrophes.
* testing/lisp/test-ox.el (test-org-export/activate-smart-quotes): Fix
test with unbalanced " and add new tests for unbalanced quotes.
Reported-by: Juan Manuel Macías <maciaschain@posteo.net>
Link: https://list.orgmode.org/orgmode/875xxfqdpt.fsf@posteo.net/
---
lisp/ox.el | 45 +++++++++++++++++++++++++++++++++++++++++
testing/lisp/test-ox.el | 29 ++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 929b306dc..539d31d9d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5942,6 +5942,51 @@ (defun org-export--smart-quote-status (s info)
(when current-status
(push (cons text (nreverse current-status)) full-status))))
info nil org-element-recursive-objects)
+ ;; When quotes are not balanced, threat them as apostrophes.
+ (setq full-status (nreverse full-status))
+ (let (primary-openings secondary-openings)
+ (dolist (substatus full-status)
+ (let ((status (cdr substatus)))
+ (while status
+ (pcase (car status)
+ (`apostrophe nil)
+ (`primary-opening
+ (push status primary-openings))
+ (`secondary-opening
+ (push status secondary-openings))
+ (`secondary-closing
+ (if secondary-openings
+ ;; Remove matched opening.
+ (pop secondary-openings)
+ ;; No matching openings for a given closing. Replace
+ ;; it with apostrophe.
+ (setcar status 'apostrophe)))
+ (`primary-closing
+ (when secondary-openings
+ ;; Some secondary opening quotes are not closed
+ ;; within "...". Replace them all with apostrophes.
+ (dolist (opening secondary-openings)
+ (setcar opening 'apostrophe))
+ (setq secondary-openings nil))
+ (if primary-openings
+ ;; Remove matched opening.
+ (pop primary-openings)
+ ;; No matching openings for a given closing.
+ (error "This should no happen"))))
+ (setq status (cdr status)))))
+ (when primary-openings
+ ;; Trailing unclosed "
+ (unless (= 1 (length primary-openings))
+ (error "This should not happen"))
+ ;; Mark for not replacing.
+ (setcar (car primary-openings) nil)
+ ;; Mark all the secondary openings and closings after
+ ;; trailing unclosed " as apostrophes.
+ (let ((tail (car primary-openings)))
+ (while tail
+ (when (memq (car tail) '(secondary-opening secondary-closing))
+ (setcar tail 'apostrophe))
+ (setq tail (cdr tail))))))
(puthash (cons parent (org-element-secondary-p s)) full-status cache)
(cdr (assq s full-status))))))
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 01e082c9b..16e81c64b 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -4134,9 +4134,9 @@ (ert-deftest test-org-export/activate-smart-quotes ()
;; Opening quotes: at the beginning of a paragraph.
(should
(equal
- '("“begin")
+ '("“begin”")
(let ((org-export-default-language "en"))
- (org-test-with-parsed-data "\"begin"
+ (org-test-with-parsed-data "\"begin\""
(org-element-map tree 'plain-text
(lambda (s) (org-export-activate-smart-quotes s :html info))
info)))))
@@ -4267,6 +4267,31 @@ (ert-deftest test-org-export/activate-smart-quotes ()
(org-test-with-parsed-data "*\"foo\"*"
(org-element-map tree 'plain-text
(lambda (s) (org-export-activate-smart-quotes s :html info))
+ info nil nil t)))))
+ ;; Unmatched quotes.
+ (should
+ (equal '("\\guillemotleft{}my friends' party and the students' papers\\guillemotright{} \\guillemotleft{}``mothers''\\guillemotright{}")
+ (let ((org-export-default-language "es"))
+ (org-test-with-parsed-data
+ "\"my friends' party and the students' papers\" \"'mothers'\""
+ (org-element-map tree 'plain-text
+ (lambda (s) (org-export-activate-smart-quotes s :latex info))
+ info nil nil t)))))
+ (should
+ (equal '("\"'mothers'")
+ (let ((org-export-default-language "es"))
+ (org-test-with-parsed-data
+ "\"'mothers'"
+ (org-element-map tree 'plain-text
+ (lambda (s) (org-export-activate-smart-quotes s :latex info))
+ info nil nil t)))))
+ (should
+ (equal '("\\guillemotleft{}να 'ρθώ το βράδυ\\guillemotright{}")
+ (let ((org-export-default-language "el"))
+ (org-test-with-parsed-data
+ "\"να 'ρθώ το βράδυ\""
+ (org-element-map tree 'plain-text
+ (lambda (s) (org-export-activate-smart-quotes s :latex info))
info nil nil t))))))
--
2.44.0
[-- Attachment #3: Type: text/plain, Size: 224 bytes --]
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply related [relevance 5%]
* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
2024-03-23 11:38 5% ` Ihor Radchenko
@ 2024-03-23 13:41 6% ` Juan Manuel Macías
2024-03-23 13:49 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-23 13:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>> #+OPTIONS: ':t
>> #+language:es
>>
>> "my friends' party and the students' papers"
>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>>
>> the above produces in LaTeX:
>>
>> \guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
>> ...
>> Perhaps a possible solution would be to allow the use of a specific,
>> customizable character, other than an apostrophe, for second-level
>> quotes. Or at least add some brief warning in the manual: in certain
>> contexts it is safer to use a explicit Unicode character for the
>> apostrophe.
>
> I think that we can address examples like this simply by not replacing
> unbalanced quotes. There is already some effort in the code towards such
> treatment, but it is not complete.
>
> Can you try the attached patch?
Hi, Ihor,
The patch works fine, and I think it can prevent a lot of cases. But
false positives can still appear. Consider (second level quotes open
after the colon):
"two articles: 'my friends' party' and 'the students' papers'"
"A Greek folk song says: 'να 'ρθώ το βράδυ'"
==>
\guillemotleft{}two articles: ``my friends'' party' and ``the students'' papers'\guillemotright{}
\guillemotleft{}A Greek folk song says: 'να ``ρθώ το βράδυ''\guillemotright{}
I think the only solution here would be to introduce a Unicode
apostrophe (’). Or allow an optional, alternative character for
second-level quotes:
"... `my friends' party` ..."
^ permalink raw reply [relevance 6%]
* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
2024-03-23 13:41 6% ` Juan Manuel Macías
@ 2024-03-23 13:49 6% ` Ihor Radchenko
2024-03-23 15:42 6% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-03-23 13:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The patch works fine, and I think it can prevent a lot of cases. But
> false positives can still appear. Consider (second level quotes open
> after the colon):
>
> "two articles: 'my friends' party' and 'the students' papers'"
>
> "A Greek folk song says: 'να 'ρθώ το βράδυ'"
>
> ==>
>
> \guillemotleft{}two articles: ``my friends'' party' and ``the students'' papers'\guillemotright{}
>
> \guillemotleft{}A Greek folk song says: 'να ``ρθώ το βράδυ''\guillemotright{}
These are not false-positives, but ambiguity. There is no deterministic
way in this scenario to distinguish between apostrophe and smart quotes.
> I think the only solution here would be to introduce a Unicode
> apostrophe (’). Or allow an optional, alternative character for
> second-level quotes:
>
> "... `my friends' party` ..."
We may introduce \apostrophe entity.
"two articles: 'my friends\apostrophe party' and 'the students\apostrophe papers'"
"A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
2024-03-23 13:49 6% ` Ihor Radchenko
@ 2024-03-23 15:42 6% ` Juan Manuel Macías
2024-03-24 9:55 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-03-23 15:42 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> We may introduce \apostrophe entity.
>
> "two articles: 'my friends\apostrophe party' and 'the students\apostrophe papers'"
>
> "A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"
It's not a bad idea to use entities. I just discovered that an \rsquo
entity already exists. Right single quotation mark is the Unicode
recommended character for the apostrophe, and it is also the character
used in org-export-smart-quotes-alist[1].
Anyway, I think a) your patch could be a major improvement; b) perhaps a
brief note in the manual (I can send a tiny patch) should be added to
warn of possible ambiguities, and possible solutions.
[1] Although there are arguments against this Unicode recommendation,
see: https://en.wikipedia.org/wiki/Right_single_quotation_mark
^ permalink raw reply [relevance 6%]
* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
2024-03-23 15:42 6% ` Juan Manuel Macías
@ 2024-03-24 9:55 6% ` Ihor Radchenko
0 siblings, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-03-24 9:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Anyway, I think a) your patch could be a major improvement;
Applied, onto main, after fixing another edge case with quotes spanning
across multiple markup objects.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=33503445e
> ... b) perhaps a
> brief note in the manual (I can send a tiny patch) should be added to
> warn of possible ambiguities, and possible solutions.
Yes, a patch clarifying what to do to force apostrophe would be welcome.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: inline-special-block: export rules
2024-03-21 10:26 5% ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
@ 2024-03-26 16:56 6% ` Max Nikulin
0 siblings, 0 replies; 144+ results
From: Max Nikulin @ 2024-03-26 16:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
On 21/03/2024 17:26, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> I am afraid that :export will cause confusion with :exports for source
>> code blocks. Its name differs by just "s" but possible values have
>> nothing common.
>
> I agree. At the moment two alternative names come to mind: :backends or
> :export-rules
I find :export-rules too abstract. Unless a better name is proposed, I
prefer :backends.
> :export [or whatever new name we give it] ==> normal behavior, overwrites the values
> :export+ ==> adds the new values to the values defined in the alias
Vim for options allowing list of values has several options
:set opt=value1,value2 " assign new value
:set opt+=value " add to list
:set opt-=value " remove from list if it is there
:set opt& " reset to default value
I am unsure whether all variants should be implemented.
> This syntax could also be extended to other cases. Perhaps we want
> attributes like :prelatex, :postlatex, or :html to support accumulating
> values.
Certainly :export (:backends) is not the only property that should
accumulate values.
^ permalink raw reply [relevance 6%]
* Re: [proof of concept] inline language blocks
2024-02-20 20:35 9% [proof of concept] inline language blocks Juan Manuel Macías
2024-02-21 8:42 6% ` Ihor Radchenko
@ 2024-03-31 14:56 4% ` Daniel Clemente
1 sibling, 0 replies; 144+ results
From: Daniel Clemente @ 2024-03-31 14:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 6362 bytes --]
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
Sorry for joining the discussion a bit late. A long time ago I created a
syntax to be able to mix languages in that way, and a program to separate
each version into a different file.
Info: https://www.danielclemente.com/dislines/
Sample: https://www.danielclemente.com/dislines/perl.txt
Syntax: https://www.danielclemente.com/dislines/syntax.en.html
Syntax in practice: https://www.danielclemente.com/dislines/quick.en.txt
It's format-agnostic, and unrelated to org. I have used it in plain HTML
and other file types.
Many times I tried to use it for org-mode, and while it works, the
challenges are more. For instance I'd like to integrate it into the export
process (so that a single command produces many files), I want to use it to
translate headers (but where do you keep the translations of the header
name? in the header itself? in a property?), I want the TOC to use the
translated headers, and I want to keep links working (and making sure each
language only links to files in the same language). More difficult yet:
what if a particular language requires another header structure (more
headers, fewer headers, or headers arranged in another way).
I tried several approaches (inline tasks, SRC blocks, my own syntax, tags
in headers, one sub-header per language, selective export of tags,
properties in headers, post-processing, exporting all and making language
selection in JS, one manual TOC per language, …). But I didn't have time to
think or discover a good system. Multi-language hypertext systems are hard.
Maybe you can get some ideas from this, if you're still working on mixing
human languages in org paragraphs/headers/lines/files. I see the discussion
may have shifted from multilingual texts (i.e. human languages) to
multi-backend texts (e.g. export HTML/LaTeX/… differently); multi-backend
variations might be an easier goal than dealing with multilingual texts and
translations.
Thanks for implementing code for your ideas.
On Tue, 20 Feb 2024 at 20:36, Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I'm dedicating a local branch to developing this proof of concept and
> testing it in my workflow, so far with good results. The basic idea is
> to provide Org with multilingual features and various methods for
> selecting languages.
>
> The inline-language-block is intended for small segments of text in a
> language other than the main language. They can span several lines but
> not more than a paragraph. They can be used for in-line textual quotes,
> glosses, etc. They are constructions equivalent to, for example, LaTeX
> \foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
>
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>
> You can also use a literal term instead of a language code:
>
> :klingon!{some text in Klingon}
>
> The blocks can be nested:
>
> :klingon!{Some text in Klingon with :it{some text in Italian}}
>
> And they may include other elements:
>
> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
>
> To this end, I have defined the following element:
>
> #+begin_src emacs-lisp
> (defun org-element-inline-language-block-parser ()
> "Parse inline language block at point.
>
> When at an inline language block, return a new syntax node of
> `inline-language-block' type containing `:begin', `:end',
> `:type', `:contents-begin', `:contents-end' and `:post-blank' as
> properties. Otherwise, return nil.
>
> Assume point is at the beginning of the block."
> (save-excursion
> (when (looking-at ":\\([A-Za-z!]+\\){")
> (goto-char (match-end 0))
> (let* ((begin (match-beginning 0))
> (contents-begin (match-end 0))
> (type (org-element--get-cached-string
> (match-string-no-properties 1)))
> (contents-end
> (progn
> (goto-char (- contents-begin 1))
> (org-element--parse-paired-brackets ?\{)
> (- (point) 1)))
> (post-blank (skip-chars-forward " \t"))
> (end (point)))
> (when contents-end
> (org-element-create
> 'inline-language-block
> (list :type type
> :contents-begin contents-begin
> :contents-end contents-end
> :begin begin
> :end end
> :post-blank post-blank)))))))
>
> (defun org-element-inline-language-block-interpreter
> (inline-language-block contents)
> "Interpret INLINE LANGUAGE BLOCK object as Org syntax."
> (format ":%s{%s}"
> (org-element-property :type inline-language-block)
> contents))
> #+end_src
>
> And, for now, this function for ox-latex:
>
> #+begin_src emacs-lisp
> (defun org-latex-inline-language-block (inline-language-block contents
> info)
> "Transcode an INLINE LANGUAGE BLOCK element from Org to LaTeX.
> CONTENTS holds the contents of the block. INFO is a plist
> holding contextual information."
> (let ((type (org-element-property :type inline-language-block)))
> (if (string-match-p "!" type)
> (format "\\foreignlanguage{%s}{%s}"
> (replace-regexp-in-string "!" "" type)
> contents)
> (let* ((plist (cdr
> (assoc type org-latex-language-alist)))
> (language (plist-get plist :babel))
> (language-ini-only (plist-get plist :babel-ini-only))
> (language-ini-alt (plist-get plist :babel-ini-alt))
> (lang (or language language-ini-only language-ini-alt)))
> (format "\\foreignlanguage{%s}{%s}" lang contents)))))
> #+end_src
>
> Opinions, suggestions, feedback, ideas?
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos,
> diseño editorial y ortotipografía
>
>
[-- Attachment #2: Type: text/html, Size: 7707 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
` (5 preceding siblings ...)
2024-03-07 10:57 6% ` false positives: " Max Nikulin
@ 2024-04-09 8:52 1% ` Ihor Radchenko
2024-04-09 10:51 8% ` Max Nikulin
2024-04-11 11:06 7% ` Max Nikulin
7 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-04-09 8:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
>
> <https://gitlab.com/maciaschain/org-mode.git>
I have finally finished my review of the previous related discussions.
See my comments and proposals below.
[ Aside: It looks like your public branch is not up-to-date as the time
of writing this email - I do not see commits changing the syntax to
@foo{...} and @@{...} yet, as discussed in
https://list.orgmode.org/orgmode/87sf121e9t.fsf@localhost/)
I have edited your original message in the quotes to reflect upon the
newly agreed syntax. ]
---------------------
> The basic syntax:
> @foo{lorem ipsum dolor}
> There is also an anonymous variant:
> @@{lorem ipsum dolor}
> Optional attributes in square brackets are supported
> @foo[:key1 value1 :key2 value2 ...]{lorem ipsum dolor}
Let me list the main goals of the new inline markup within the scope of
overall Org markup and discuss whether the proposed syntax can work to
achieve them.
1. Introduce user-configurable ad-hoc syntax where exporting and
fontification are fully configurable on Elisp level, per-document
level, and maybe even per-markup level. Something combining
flexibility of links and special blocks, but without their
limitations:
- In contrast to links, we should be able to nest inline markup
without restrictions:
@foo{@bar{text}} ([[foo:a][[[bar:b]]]] is not possible)
***This goal is covered by the branch***
- We should be able to have arbitrary text inside inline markup.
No sequence of symbols should be prohibited:
@foo{ can contain leading and trailing spaces }
@foo{can contain "}" inside, especially inside =verbatim }= text} <-- **ambiguous**
@foo{can even have "}" at the end boundary}} <-- **ambiguous**
This is unlike links that prohibit closing "]".
***For the above examples, the proposed syntax is ambiguous***
- We should be able to define special markup for code, where the
contents is not parsed. Something like
@code{ unlike =code=, we can have leading and trailing spaces }
@code{ @foo{is not interpreted inside}}
***This goal is not addressed by the experimental branch for now***
2. Allow attaching auxiliary attributes to the on object level, as an
equivalent of affiliated keywords on element level
- For example, we should allow assigning height per-link without the
awkward kludge we have with special handling of
#+attr_html: :height 300
[[file:image.png]] has a height of 300, but what if we want a
different height in [[file:another-image.png]]?
We can thus do
#+attr_html: :height 300
[[file:image.png]] has a height of 300, but what if we want a
different height in @@[:html-height 300]{[[file:another-image.png]]}?
Note how @@{...} markup assigns attributes to objects inside - the
attributes should be somehow inherited.
Another example is the proposed @@[:lang "en"]{...} attribute - we
may want to assign it even beyond current paragraph; for example
for the whole subtree (aka mark subtree language to be "English").
***This is not covered by the branch***
- We should also be able to assign attributes that contain Org markup
themselves:
@@[:alt This image shows a _cat_ climbing a /wall/]{<file:cat.png>}
***This is not covered by the branch***
3. The new syntax should allow us to do anything Texinfo markup can do
(as per RMS request https://list.orgmode.org/orgmode/87bkqx4jyg.fsf@localhost/)
- Multi-argument markup in Texinfo like for abbreviations
@abbr{abbreviation[,meaning]}
Example: @abbr{Comput. J., Computer Journal}
(https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040abbr)
We can equivalently (if markup inside attributes is supported) do
@abbr[:meaning Computer Journal]{Comput. J.}
or even
@abbr[Computer Journal]{Comput. J.}
In theory, we may need even more than 2 arguments.
***This is partially covered***
4. The new syntax should allow working around ambiguities of the *DWIM*
markup without using the awkward zero-width space kludge
- Intra-word markup
foo@bold{bar}baz
***This is covered already***
- Simultaneous markup
@bold{foo}@italic{bar}
@@{*foo*}@@{/bar/}
***This is covered already***
- Solving the undesired first-fit-wins parser behaviour:
/italics stops [[early/?here]], but not later/
need to *escape stars* like that one*
你好。*我*不会些这个
@italic{italics stops [[early/?here]], but not later}
need to @bold{escape stars* like that one}
你好。@bold{我}不会些这个
***This is covered already***
--------
Proposed modifications to the inline markup syntax
-------
1. @foo{basic form remains the same}
2. @foo{{but we allow arbitrary number of "{{..." to open the markup.
Then, } inside does not end the @foo markup; we only end it at the
matching number of }s; "{" and "}" inside do not have to be balanced.}}
3. @foo[alternative brackets]
In an edge case, when the contents itself is {...}, allow alternative
brackets
@foo[{contents surrounded by curly braces}]
4. We also have a special form of syntax where the contents is not at all
parsed
@code{this is *verbatim* code; it may contain = or even have
whitespace at the boundaries }
This is equivalent to #+begin_example example blocks vs.
#+begin_<arbitrary> special blocks.
@code{{can also contain "}" inside, using multiple bracket
alternative}}
@code[{or be like this}]
5. Change the @foo[:key1 value1 :key2 value2 ...]{lorem ipsum dolor}
syntax:
@foo[can have][multiple][arguments]{the last argument is considered object contents}
Every argument is parsed
@title[This is an image title, with *markup*]{<file:image.png>}
@@[:lang cn :alt Hello]{你好}
@@[:lang cn][:alt Hello]{你好}
The exporters are responsible to interpret the arguments as needed,
if keyword arguments are passed.
We should also not layer additional rules for escaping delimiters
apart from the existing Org mode markup:
@@[:lang cn :alt @@{can have :keyword-like inside, insulated inside =@@{...}=}]{...}
@@[:lang cn][:attr_latex @@{:color blue}]{...}
This is akin affiliated keywords that are never split into
keyword/value pairs by org-element, leaving this job downstream to
specific commands and libraries.
(The difference is that affiliated keywords are mostly not parsed,
but parsing is necessary here to address multi-argument markup syntax
like @abbrev)
-------
Attribute inheritance
-------
As I described in @@[:html-height 300]{[[file:another-image.png]]}
example, we should have some form of attribute inheritance, so that we
are able to assign attributes to arbitrary Org markup, not just to
inline markup objects.
Furthermore, attributes like @@[:lang cn][好工作] may need to be
assigned to the text spanning across multiple paragraphs or even
headings.
I suggest following what we already do for source blocks:
1. org-babel-default-header-args sets global attributes applicable to
everything globally
2. org-babel-default-header-args:<lang> sets global attributes
per-language
3. #+PROPERTY: header-args <attributes> sets global attributes per-file
4. #+PROPERTY: header-args:<lang> <attributes> sets language-specific
attributes
5. :HEADER-ARGS: or :HEADER-ARGS:<lang>: set attributes per-subtree
6. #+HEADERS: <attributes> sets src block attributes
7. Attribute values are merged together:
org-babel-default-header-args = :cache yes :export none
#+HEADERS: :cache no :var x=1
combines into
:export none :cache no :var x=1
I propose the following naming for inline markup:
org-default-inline-attributes
org-default-inline-attributes:<foo>
#+PROPERTY: inline_attr
#+PROPERTY: inline_attr:<foo>
#+INLINE_ATTR: affiliated
#+INLINE_ATTR:<foo>:
In addition, attributes from @@[:alt Text]{<file:image.png>} are applied
to all the markup inside, including normal non-inline markup objects.
Further, we may allow a special attribute :inherit that will allow more
fine-grained control on where to inherit the attributes from:
#+inline_attr:var: :inherit example
@example[:color gray]{(defvar @var{variable-name} nil)}
As an option, I am not yet sure about, we may also allow per-keyword
control like
@bold[:export latex rest*]{and some more @bold[:export+ html]{inside}}
so that :export and :export+ are combined.
(Despite me using :export example here, what I am proposing is not
limited to :export keyword that have been discussed in-depth in
https://list.orgmode.org/orgmode/87bk7k7tuf.fsf@posteo.net/)
> Optional attributes in square brackets are supported. There are a series
> of 'universal' attributes, common to each backend. At the moment:
> `:lang', `:color' and `:smallcaps'. Example:
-------
On :lang attribute
-------
This attribute is special - language of a text is actually _not_ a
markup. It is more global, and it does not quite fit within the framework
of per-markup type inheritance.
In contrast to something like
@foo[:export latex rest*]{@bar{should be exported everywhere}}
:lang attribute applies to all types of markup inside
@foo{:lang cn}{@bar{公共汽车}}
Moreover, we may want to apply it per-paragraph or per-subtree.
So, we may want to
1. Combine all the nested inline :lang attributes regardless of the
inline markup types nesting
2. Introduce a new affiliated keyword #+LANGUAGE
3. Introduce a new subtree property :LANGUAGE:
4. Re-use #+LANGUAGE: per-document keyword
5. Use the previous 4 rules to :lang attributes as a special case.
Then, export backends should implement :lang attribute support and ox.el
should provide the means to query it, performing all the necessary
inheritance calculations.
-------
Configurable inline markup export
-------
Given that the discussed inline markup is supposed to improve on the
link export flexibility, and also add more ad-hoc export setting
options, I have the following necessary features in mind:
1. We should have an equivalent of :export link parameter
This will be Elisp level interface for inline markup, allowing to
write Org mode syntax extensions (like the one necessary for Texinfo
feature-parity)
***This is not covered by the branch***
2. We should expose per-document ad-hoc markup customization that does
not require Elisp. Something similar to link abbreviations or macros.
However, I do not want the inline markup to turn into another variant
of macros. So, I do like the proposal to define only attributes:
> ┌────
> │ #+options: inline-special-block-aliases:(("latin" :lang "la" :latex-command "textit" :html-tag "em"))
> │
> │ Caesar's famous quote: @latin{Alea iacta est}
> │
> │ Caesar's famous quote: @latin[:smallcaps t :color blue]{Alea iacta est}
> └────
However, I am not a big fan of the way it is implemented - Elisp syntax
with the need to layer all the (...) and "...".
We may instead re-use my attribute inheritance idea:
#+PROPERTY: inline_attr:latin :lang la :latex-command textit :html-tag em
-------
On :color and :smallcaps attributes or user-customized markup
-------
These proposed attributes are nothing but additional markups that will
become a part of Org mode syntax. I see them as nothing different from
@smallcals{...} and @color{blue}{...} inline markups.
I am not in favour of adding such extra markup to Org mode syntax.
Instead, we can make it a part of inline markup extensions, in parallel
with what we need to support Texinfo-specific markup like @var, @defun,
etc.
I also do not see any clear benefit of adding :color and :smallcaps as
_attributes_. Just markup will do. If one needs to combine
smallcaps/color with other markup, it is a job for ad-hoc markup
definitions.
-------
pre/post-latex (aka templates)
-------
> Specific to the LaTeX backend we have the `:prelatex' and `:postlatex'
> attributes (which introduce arbitrary code before and after the content)
> and `:latex-command', which overrides the exported command.
> `:latex-command nocommand' does not export a command flag. Examples:
>
> ┌────
> │ @foo[:prelatex [bar] :postlatex {baz} :lang it :latex-command blah]{lorem ipsum dolor}
> └────
I do not like the idea of pre/post-<exporter> attributes.
I think that we discussed this particular idea in the past, when talking
about prepending/appending commands like \newpage to headings during
LaTeX export
(https://list.orgmode.org/orgmode/87czbna4e4.fsf@localhost/)
There, I proposed to use a more generalized approach, allowing custom
export templates:
* headline
:PROPERTIES:
:ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
:ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
:ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " *this*)
:ATTR_BACKEND+: babel_block_name(exported=*this*)
:ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
:ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
:END:
We can apply the same approach when defining ad-hoc markup, extending it
a little. Rather than using %s, we introduce more placeholders:
- %contents :: like CONTENTS argument in the export transcoders
- %transcoded :: the result of what the export backend returns normally
- %:<number> :: reference to last Nth optional argument. For example
in @abbrev{Computer Science}{CS} %contents == CS and %:1 =
Computer Science
- %:attribute :: the value of attribute
This way,
@@[:prelatex \foo{bar} :color red]{lorem ipsum dolor}
will become
@foo[:latex-template @code[{\color{red}\foo{bar}%contents}]]{lorem ipsum dolor}
-------
On :export attribute
-------
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the content)
> or the backends to which you want to export, separated by spaces. Each
> backend should be followed by a "+" sign (= export all) or "*" (export
> content only). For example:
>
> @foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
Similar to :lang attribute, I see this idea to be more general than
inline markup scope. It does not have to be applicable only to inline
markup. We can extend selective export further - to paragraph-level
elements and to headings.
Recently, we even got a feature request to
exclude/include certain subtrees from export for specific backends:
https://list.orgmode.org/orgmode/1008678740.100388.1708624390334@fidget.co-bxl/
So, we can approach this just like for :lang attribute, except that we
do not need special handling with unconditional inheritance for all the
inline markup
1. Allow :lang attributes and make them follow standard inheritance
rules
2. Introduce a new affiliated keyword #+EXPORT
3. Introduce a new subtree property :EXPORT:
4. Introduce #+EXPORT: per-document keyword
5. (optional) Introduce new #+SELECT_TAGS:BACKEND:
#+EXCLUDE_TAGS:BACKEND to allow excluding/selecting subtrees by tag
(more visible compared to properties)
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 1%]
* Re: Experimental public branch for inline special blocks
2024-04-09 8:52 1% ` Ihor Radchenko
@ 2024-04-09 10:51 8% ` Max Nikulin
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-04-09 10:51 UTC (permalink / raw)
To: emacs-orgmode
On 09/04/2024 15:52, Ihor Radchenko wrote:
> Aside: It looks like your public branch is not up-to-date as the time
> of writing this email - I do not see commits changing the syntax to
> @foo{...} and @@{...} yet,
Do you have in your local copy the following?
latest commit
ba2fc870c 2024-03-18 20:28:19 +0100 Juan Manuel Macías Chaín: *
lisp/ox.el: More sensible export rules.
and
97a26a30d 2024-03-07 19:16:01 +0100 Juan Manuel Macías Chaín: *
lisp/org-element.el: `@' instead of `_' for the anonymous variant.
b2b4d0177 2024-03-07 16:42:58 +0100 Juan Manuel Macías Chaín: *
lisp/org-element.el: New syntax: `@' instead of `&'.
P.S. In your message I see most of my questions I have not asked.
^ permalink raw reply [relevance 8%]
* Re: Experimental public branch for inline special blocks
@ 2024-04-10 23:00 10% ` Juan Manuel Macías
2024-04-11 12:26 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-04-10 23:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 09/04/2024 15:52, Ihor Radchenko wrote:
>>> Aside: It looks like your public branch is not up-to-date as the time
>>> of writing this email - I do not see commits changing the syntax to
>>> @foo{...} and @@{...} yet,
>>
>> Do you have in your local copy the following?
>> ...
>
> I do now. Apparently, I somehow reviewed an earlier local copy of the
> branch.
Hi, Ihor. Thanks for all your comments. I will try to answer each of the
questions you have raised. Let's see if I can find a space next week...
The latest added to the branch are Maxim's proposals (and code) for
backend control. See this thread:
https://list.orgmode.org/?t=20240321102752
And this other thread, continuation of the previous one:
https://list.orgmode.org/877ciavnwo.fsf_-_@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* inline-special-block: part2
@ 2024-04-11 10:49 7% Max Nikulin
2024-04-11 11:08 6% ` Link to the repository (Re: inline-special-block: part2) Max Nikulin
0 siblings, 1 reply; 144+ results
From: Max Nikulin @ 2024-04-11 10:49 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Juan Manuel Macías
I think, it is better to create a new thread to discuss next bunch of
questions related to the inline special block feature.
Previous thread is rather huge:
Juan Manuel Macías. Experimental public branch for inline special
blocks. Fri, 01 Mar 2024 20:34:35 +0000.
https:list.orgmode.org/87wmql6690.fsf@posteo.net
In particular it contains detailed overview
Ihor Radchenko. Re: Experimental public branch for inline special
blocks. Tue, 09 Apr 2024 08:52:38 +0000.
https://list.orgmode.org/875xwqj4tl.fsf@localhost
An earlier closely related thread:
Juan Manuel Macías. [proof of concept] inline language blocks. Tue, 20
Feb 2024 20:35:04 +0000.
https://list.orgmode.org/87msrudgcn.fsf@posteo.net
^ permalink raw reply [relevance 7%]
* Re: Experimental public branch for inline special blocks
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
` (6 preceding siblings ...)
2024-04-09 8:52 1% ` Ihor Radchenko
@ 2024-04-11 11:06 7% ` Max Nikulin
7 siblings, 0 replies; 144+ results
From: Max Nikulin @ 2024-04-11 11:06 UTC (permalink / raw)
To: emacs-orgmode
On 02/03/2024 03:34, Juan Manuel Macías wrote:
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
>
> <https://gitlab.com/maciaschain/org-mode.git>
Next part of this thread:
Max Nikulin. inline-special-block: part2. Thu, 11 Apr 2024 17:49:40 +0700.
https://list.orgmode.org/0f1351e2-cb5e-4b65-9faf-c6e78f15c975@gmail.com
Previous discussion:
Juan Manuel Macías. [proof of concept] inline language blocks. Tue, 20
Feb 2024 20:35:04 +0000.
https://list.orgmode.org/87msrudgcn.fsf@posteo.net
^ permalink raw reply [relevance 7%]
* Link to the repository (Re: inline-special-block: part2)
2024-04-11 10:49 7% inline-special-block: part2 Max Nikulin
@ 2024-04-11 11:08 6% ` Max Nikulin
0 siblings, 0 replies; 144+ results
From: Max Nikulin @ 2024-04-11 11:08 UTC (permalink / raw)
To: emacs-orgmode
On 11/04/2024 17:49, Max Nikulin wrote:
> I think, it is better to create a new thread to discuss next bunch of
> questions related to the inline special block feature.
I have realized that I forgot to add the link for those who wish to try
the new feature in action:
Juan Manuel Macías. Experimental public branch for inline special
blocks. Fri, 01 Mar 2024 20:34:35 +0000.
https:list.orgmode.org/87wmql6690.fsf@posteo.net
>
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
>
> <https://gitlab.com/maciaschain/org-mode.git>
^ permalink raw reply [relevance 6%]
* Re: Experimental public branch for inline special blocks
2024-04-10 23:00 10% ` Juan Manuel Macías
@ 2024-04-11 12:26 6% ` Ihor Radchenko
2024-04-11 13:47 5% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-04-11 12:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The latest added to the branch are Maxim's proposals (and code) for
> backend control. See this thread:
>
> https://list.orgmode.org/?t=20240321102752
>
> And this other thread, continuation of the previous one:
>
> https://list.orgmode.org/877ciavnwo.fsf_-_@posteo.net/
I have seen these two branches and my comments account for them.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Experimental public branch for inline special blocks
2024-04-11 12:26 6% ` Ihor Radchenko
@ 2024-04-11 13:47 5% ` Juan Manuel Macías
2024-07-18 6:55 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-04-11 13:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> The latest added to the branch are Maxim's proposals (and code) for
>> backend control. See this thread:
>>
>> https://list.orgmode.org/?t=20240321102752
>>
>> And this other thread, continuation of the previous one:
>>
>> https://list.orgmode.org/877ciavnwo.fsf_-_@posteo.net/
>
> I have seen these two branches and my comments account for them.
Ok. Although I will try to answer all your comments in detail [if it's
okay, I can start a new thread called "inline-special-block: general
discussion"] I can anticipate that I would be in favor of removing
global attributes (:smallcaps, :lang, :color). At first I didn't think
it was a bad idea to have certain «pre-cooked» attributes. But later I
realized that the implementation of each backend where it makes sense to
apply these attributes is unnecessarily complicated. Furthermore, the
very flexibility of the new object allows the same goal to be achieved.
Well, next week I will continue commenting. I will try to stay up to
date with everything that is being discussed here. By the way, if
someone wants to collaborate on the branch, I can add them as a
contributor (I'm afraid it is necessary to have a GitLab account, if
I'm not mistaken).
^ permalink raw reply [relevance 5%]
* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
2024-02-11 11:04 12% ` Juan Manuel Macías
@ 2024-04-15 12:21 6% ` Ihor Radchenko
0 siblings, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-04-15 12:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Pedro Andres Aranda Gutierrez writes:
>
>> I agree it does not take advantage of the AUTO facility here, but I
>> nevertheless think it would
>> be interesting to show people how to do this. Until we expand the AUTO
>> facility to cope with
>> all quirks of multi-language in pdflatex (lualatex and xetex are a
>> different pair of shoes), a quick
>> and dirty alternative may be helpful for people. The introductory text
>> could be
>
> Pedro, the only problem I see with that is that it is an example of
> LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in
> the entire section it's already made clear enough what it's used for.
>
> Perhaps a brief reminder (the AUTO facility of the previous examples
> is very limited) could be added first, and that if the users want to
> obtain more complex, or more specific results (like the case you
> exemplify for pdfLaTeX) they must put explicit LaTeX code, using
> LaTeX_header. And then your example would come, but emphasizing that the
> LaTeX documentation must be consulted. wdyt?
>
> My point is that if we abuse examples of this type (at the expense of
> "#+latex_header:something"), or "how is this done in LaTeX?", in the end
> a LaTeX manual is made instead of Org.
A gentle ping. This patch is still hanging in the air.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Experimental public branch for inline special blocks
2024-04-11 13:47 5% ` Juan Manuel Macías
@ 2024-07-18 6:55 6% ` Ihor Radchenko
2024-07-18 21:04 12% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2024-07-18 6:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Well, next week I will continue commenting. I will try to stay up to
> date with everything that is being discussed here. By the way, if
> someone wants to collaborate on the branch, I can add them as a
> contributor (I'm afraid it is necessary to have a GitLab account, if
> I'm not mistaken).
It has been quite a while since the last activity in this thread.
Juan, may I know if you had a chance to work on the branch?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Experimental public branch for inline special blocks
2024-07-18 6:55 6% ` Ihor Radchenko
@ 2024-07-18 21:04 12% ` Juan Manuel Macías
2024-07-19 13:06 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2024-07-18 21:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Well, next week I will continue commenting. I will try to stay up to
>> date with everything that is being discussed here. By the way, if
>> someone wants to collaborate on the branch, I can add them as a
>> contributor (I'm afraid it is necessary to have a GitLab account, if
>> I'm not mistaken).
>
> It has been quite a while since the last activity in this thread.
> Juan, may I know if you had a chance to work on the branch?
Hi, Ihor,
Thanks for your reminder. I'm sorry for all this long time that I've
been inactive and unresponsive, but the last few months I have had a lot
of work, in addition to other personal circumstances that have kept me
busy. I haven't had time to follow the list or deal with the branch. I
had planned to respond to your comments now in the summer (and I will
probably do so in the next few days), but I am afraid that until
September I will not be able to participate actively or continuously on
the list.
Of course, if someone wants to actively collaborate in the development
of this branch, I have no problem. If necessary, I also have no
objection to moving the repository to another more ‘open’ place (in Gitlab
it is necessary to have an account to collaborate).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* Re: Experimental public branch for inline special blocks
2024-07-18 21:04 12% ` Juan Manuel Macías
@ 2024-07-19 13:06 6% ` Ihor Radchenko
0 siblings, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-07-19 13:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ... until
> September I will not be able to participate actively or continuously on
> the list.
No problem.
I just wanted to make sure that this is not forgotten.
> Of course, if someone wants to actively collaborate in the development
> of this branch, I have no problem. If necessary, I also have no
> objection to moving the repository to another more ‘open’ place (in Gitlab
> it is necessary to have an account to collaborate).
+1
This is an important feature that should be added sooner or later to
address numerous edge cases in the Org markup.
On my side, it is not on the very top of the priorities, so I am happy
that Juan is working on it. If anyone else wants to help, it will be
very welcome as well.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Customize list of blocks that use "\footnotemark" in `org-latex-footnote-reference'
@ 2024-09-12 10:18 12% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-09-12 10:18 UTC (permalink / raw)
To: 8dcc; +Cc: emacs-orgmode
8dcc writes:
> I am exporting an Org file that contains a large verse block to
> LaTeX. This verse block contains footnotes, but they appear in the page
> where the LaTeX verse environment ends. I looked at the exported .tex
> file and I noticed that it was using "\footnotemark" and
> "\footnotetext[N]{...}", instead of "\footnote{...}".
Hello,
I seem to remember that the problem you describe goes back to how Org
understood the footnote text. When exporting to LaTeX, each line of a
footnote was understood as if it were a verse, and Org added \\ at the
end. Hence the use of \footnotemark and the
‘org-latex--delayed-footnotes-definitions’ function.
I agree that using \footnotemark can cause problems, especially on long
runs of verses. I think the solution here would be to use a function
similar to org-latex--delayed-footnotes-definitions, which would
preserve the content of the notes in a list, and format them as a
\footnote at the end, when the block has already been built in Latex.
The case of tables is different. In the longtable environment you can
use footnote without problems, except in the row-header. In other
environments it usually gives unexpected results, especially when tables
are used as float. In a float table, however, I would not use normal
footnotes via \footnotemark but the solution from the threeparttable package.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 12%]
* [BLOG] #12 [[bbb:OrgMeetup]] on Wed, Oct 9, 19:00 UTC+3
@ 2024-10-26 9:50 1% ` Ihor Radchenko
0 siblings, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-10-26 9:50 UTC (permalink / raw)
To: emacs-orgmode
[ This time, I will try to use Org mailing list tracker and its
functionality for "blog posts". Let's see if I can make this post into
RSS feeds that are automatically posted in #org-mode Matrix room. ]
Back to the meeting notes.
- As usual, we started from Sacha's News
https://sachachua.com/blog/2024/10/2024-10-07-emacs-news/
- For a bit of a twist, before the official start of the stream, I did
a bit of a screencast working on an Org mode bug report
- https://list.orgmode.org/orgmode/878qvbstna.fsf@gmail.com/
- The bug is about Texinfo export of variable definition:
: - Variable: my-name ::
- When variable "my-name" is exactly =nil=, Org mode errs
- The problem lies in the implementation detail of ox-texinfo and
in Org handling of attribute values
- ~org-texinfo--split-definition~ replaces "variable"
description lists with special blocks
#+begin_src emacs-lisp
(apply #'org-element-create 'special-block
(list :type cmd
:attr_texinfo (list (format ":options %s" args))
:post-blank (if contents 1 0))
(mapc #'org-element-extract contents))
#+end_src
- later, ~org-texinfo-special-block~ uses
~org-export-read-attribute~ to parse the =:options variable-name=
- The problem is that ~org-export-read-attribute~ treats ~nil~
specially, making =nil= value indistinguishable from the
absence of attribute
- It is not fully clear how to address the problem. There are multiple options
1. ~org-texinfo--split-definition~ to not use ~:attr_texinfo~
and instead store the value directly + add special handling
in ~org-texinfo-special-block~. This will avoid invoking
~org-export-read-attribute~ altogether
2. Or I may try to address the limitation of
~org-export-read-attribute~, so that it becomes possible to
specify =nil= as a value of export attribute.
- This seems better overall (in a more global scope outside
of the bug report), but it is not clear what can be done
(removing special handling of nil will likely cause
regression and is thus not an option)
- [2024-10-26 Sat] I went with option (1)
- Chinmay saw the 33 stashes lying around in my local Org git repository
- Those are not all actual work though
- My workflow often involves jumping between different Org branches
and carrying over WIP changes. For example, I sometimes start to
write code on main, but then realize that it is more suitable for
bugfix (or vice versa)
- To carry the code around I often just use stashes:
1. stash current changes
2. switch branch
3. unstash
- I also tend to work on a number of small fixes in parallel,
sometimes leaving the changes to "cook" for a few days to avoid
overlooking obvious flaws (another day - another fresh look on my code)
- If I do see a flaw, I do not immediately delete a stash, but may
start changes afresh, so the stash is kept around in case if I
change my mind about the approach to handle one or another fix
- So, many stashes in my git repo are not really meaningful. I clean
them up from time to time
- While I was doing the bug fixing screencast, someone asked (by
voice, so I do not recall who it was) a bit of
an off-topic question - how I configure parenthesis to be
highlighted in different colors depending on the relative depth wrt
point
- I use =highlight-parentheses= package
- See https://github.com/yantar92/emacs-config/blob/master/config.org#highlight-parentheses-in-code
- visuwesh asked karhink (co-author of the new latex preview branch)
about the new proposal to generalize the previews to work outside
Org mode - in any arbitrary major mode buffer
- https://list.orgmode.org/87edbhljr7.fsf@hyperspace
- Recently, Karthik shared a new prototype on the list
https://list.orgmode.org/orgmode/87a5fffmuc.fsf@gmail.com/
- Here is a video demo from the recent email
https://www.youtube.com/watch?v=u44X_th6_oY (watch from 9 minute mark)
- I did some initial feedback during and after the video and later
followed up with an actual reply on the list
https://list.orgmode.org/orgmode/87o73rkgja.fsf@localhost/
- Also, maybe it would be a nice talk for EmacsConf :)
- Chinmay asked about Emacs APAC meetup (suitable for Asia-Pacific/Europe time zones)
- It is monthly, every forth Saturday, 1400 IST
- See https://emacs-apac.gitlab.io/
- karthink asked about the performance of org-persist writing caches
to disk and how to debug it
- It can take time when there is a large number of caches
- For example, with my 20-30+Mbs of Org files loaded into Emacs,
it does take a few seconds to quit Emacs (not that I frequently
do it)
- One can use a profiler to check how long it takes for org-persist
to write things
- But you need a trick to prevent Emacs from actually exiting and
not showing the profiler data: make ~kill-emacs-hook~ throw an
error at the very end
: (add-hook 'kill-emacs-hook #'error 100)
- Then, M-x profiler-report after attempting to quit will work
- Later, the hook can be removed
: (remove-hook 'kill-emacs-hook #'error)
- In case of karthink, the possible problem is a sheer number of cache
entries as he is actively using latex previews that heavily make
use of the cache
- However, we need the actual profiler data to (1) confirm that
the problem is there; (2) figure out which part of org-persist
is slowing things down
- Chinmay asked about link previews in Org mode (similar to what many
instant messengers do)
- visuwesh suggested that creates previews for youtube links:
https://github.com/TobiasZawada/org-yt
- Of course, it is only specific to youtube links (special yt: link type)
- kathink's patch that adds an API to create arbitrary link previews
is a step towards having web (and other, like, say, pdf) link
previews
https://list.orgmode.org/orgmode/875xrqg6cb.fsf@gmail.com/
- The patch introduces :preview link parameter that will be used
by ~org-toggle-inline-images~
- The patch itself does not produce web link previews, but such
previews can be implemented using the proposed API
- There is even a demo previewing youtube links from unpublished
kathink's code
https://share.karthinks.com/org-link-preview-demo-2.mp4
- We then went on discussing how to generalize the previews to be
not tied to a specific website
- Chinmay suggested https://oembed.com/ API. It might be used to
retrieve previews from arbitrary websites
- I was not so optimistic about the idea because of my
experience using OpenGraph protocol to retrieve website
metadata in my Org capture scrambler package:
https://github.com/yantar92/org-capture-ref
- Even though there are standards to provide
website metadata (previews, authors, titles, dates, etc), they
are simply not followed equally by different websites
- ... and you are lucky if the protocol is simply not
supported. Sometimes, it is kind of supported, but the
returned data is a complete garbage
- So, to have some kind of generic previewer, there might be no
universal solution. We might have to go the route I took in
org-capture-ref: (1) push our luck with "standard" protocol;
(2) fall back to website-specific scramblers otherwise.
- It is actually doable, except some especially bad websites
that do not even provide metadata without running JS
- As long as we can download HTML to Emacs, it can be parsed
using built-in libxml parser and searched for website-specific
info
- John Wiegley shared his feature idea
- He wants to have a way to define multiple variants of the same
paragraph/block/heading/etc
#+begin_quote
The idea I was proposing earlier, org-layers, would give you
markup for specifying multiple versions of a region of text, and
both Org-mode and the HTML export would give you a simple
interface for changing the view both locally and globally.
#+end_quote
- The inspiration is from https://en.wikipedia.org/wiki/Project_Xanadu#History
- [2024-10-20 Sun] I did not look into that link during the
meetup, but now I am a bit confused. According to the wiki, the
major idea is transclusion, and some people (who probably looked
into the same wiki page), immediately mentioned
https://github.com/nobiot/org-transclusion and
https://elpa.gnu.org/packages/lentic.html
- daniel german shared his extension to org-transclusion:
including parts of code in other files (not Org) into Org
document:
https://github.com/dmgerman/org-transclude-fn
- The idea is slightly different from org-babel in a way that
babel is mostly from Org source to code, while
org-transclude-fn is opposite
- [2024-10-20 Sun] On the other hand, we have
~org-babel-detangle~ that can ingest code back into Org
files
- As deniel later replied, another difference is that
org-transclude-fn does not include actual text into Org
document. It is just to be displayed and read; not edited.
- org-transclusion, in contrast, allows editing the
"transcluded" text, so that edits are reflected in the
original buffer
- Then, we went further into the old discussion about Emacs
allowing to combine parts of multiple buffers, ideally with
per-region major modes
- One of the past discussions of the idea on emacs-devel:
https://yhetil.org/emacs-devel/87h8kou1c0.fsf@telefonica.net/
- And the most recent one (now active):
https://yhetil.org/emacs-devel/86ttdau8hj.fsf@gmx.net/T/#t
- ... similar discussions keep popping up on emacs-devel from
time to time (maybe every 1-2 years or so, AFAIR)
- Another analogy that immediately stroke my mind is the problem of
translations (of manuals or normal user documents)
- Past discussion on emacs-devel: https://yhetil.org/emacs-devel/835y0b29rk.fsf@gnu.org/
- When creating a translation of slowly changing document like
manual, we cannot simply translate it all at once
- Parts of the document may be changed over time, often by
people who are not capable to keep all the available
translations up to date
- So, some system is necessary that keeps track of which parts
of the translated document are obsolete and which parts are
still up-to-date
- The classical solution for this task is https://po4a.org/index.php.en
- ... and it has no Emacs major mode
- So, I have been long playing around with the idea that Org mode
may be up to the task of maintaining the translations (of
manuals or just normal multi-lingual documents/books; inspired by
Juan Manuel Macías sharing a bilingual book written in Org mode:
https://list.orgmode.org/orgmode/87h70tyyiz.fsf@posteo.net/)
- What if we make use of affiliated keywords to mark some
paragraphs/drawers/blocks/headings as "translation"
- Such mark will also contain a link and hash of the "original"
paragraph/.../heading
- Then, depending on the #+LANGUAGE: keyword, we may choose to
export different variants of the text
- If the original source texts change, but the translations do
not, it should then be easily tracked, and we can provide
various ways to handle this, like: throw an error; mark the
exported obsolete translation somehow; put the original
instead of the translation; both; etc.
- We can go even further, and link the "translation" to, for
example, Elisp function docstring (or even body). Then, if the
docstring changes, we can automatically flag the related
portion of the manual obsolete. Think about all the extended
explanations about various Org mode commands - it is often
hard to remember keeping them in sync with changes in the
function code.
- karthink asked about an update on my big Org codebase refactoring
project
- There no progress since I started my new job in September (so I
have less time for Org mode now)
- I also need to sort out my copyright paperwork with the new
employer, which is taking some time. I am being cautious about
patches (especially non-trivial) until things are settled
- We had a moment of awkward silence and I decided to look into some
recent feature requests
- https://list.orgmode.org/orgmode/87frq13w48.fsf@localhost/
proposes to extend Org timers (M-x org-timer; [[info:org#Timers]])
- The idea is to allow chaining multiple timers one after another,
akin what people do with work/rest cycles in Pomodoro
- If anyone is interested in such features, please chime in on the
mailing list. Unless there are replies, I will have to refute
the proposal. (Mostly because it might be non-trivial code-wise
and I do not want to complicate code without popular demand for
this new feature.)
- Chinmay raised a topic of using transient in more places (including
Org mode)
- My stance of transient is that we should eventually switch all the
Org menus to use it.
- We generally want to rely more on the existing Emacs features and
get rid of Org mode parts that are re-implementing the existing
functionality (or predate the time when relevant generic
functionality, like transient, have been added to Emacs)
- Similarly, we want to move parts of Org mode that are generic
enough into Emacs itself
- Several users raised concerns about using transient though
- Mostly along the lines that is still has problems like not
supporting what Emacs users are used to
- For example, ~C-h k~ does not work inside transients
- Transient menus are also hard to create dynamically: a critical
feature required for many Org mode menus
- visuwesh also linked to not-yet-closed bug report for transient
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52058
- I myself faced a few (unreproducible) situations when transient
left my Emacs in unusable shape with key bindings completely
broken
- Having said the above, transient is still going to be an
improvement as Org menus are even worse in terms of supporting
~C-h k~ or even simply switching to the menu buffer (which, in
contrast, transient allows). After we solve the dynamic menu
building that is. [2024-10-25 Fri] But there is a hope:
https://list.orgmode.org/orgmode/8734m28l9a.fsf@gmail.com/
- As karthink pointed, a better documentation (user: and
discoverability!) would greatly benefit developing more
transient uses
- There is a good attempt to improve the docs in
https://github.com/psionic-k/transient-showcase; would be nice
if it were incorporated into upstream manual
- Also, karthink suggested that "The transient manual made sense
only after I read the EIEIO manual"
- Every instance of transient menu item is an instance of
EIEIO class
- Right after we discussed problems with transient, kickingvegas, a
big transient fan, joined
- Although, this time he did not talk about transient :)
- He presented his recent blog post on a small helper for writing Org table formulas
http://yummymelon.com/devnull/referencing-org-table-cells-with-text-regions.html
- The problem post is trying to solve is inputting cell references into the formulas
- Currently, one has to write the references manually, like =@13$7=
- This sometimes involves annoying counting of rows/columns
- Org does allow named rows/columns, which simplifies things,
but naming rows and columns require dedicated effort, which is
only worth it for really large and complex formulas
https://orgmode.org/manual/Advanced-features.html
- =C-c '= (~M-x org-table-edit-formulas~) helps somewhat by
highlighting the referenced table cell and by providing
=S-arrow= keys to modify reference at point interactively: move
reference up/down/left/right; but entering the reference
_initially_ still remains awkward
- kickingvegas used context menu approach to solve the problem
- He introduced a new context menu item, which copies cell
reference at point into the kill ring
- I suggested integrating the idea of getting cell reference via
mouse with ~org-table-edit-formulas~
- When inside edit buffer, mouse may automatically insert
cell/cell range reference at mouse into the formula editor
- More details in the followup discussion on the mailing list
https://list.orgmode.org/95CE1447-FC08-431A-9CA1-83B4C3F77BA7@gmail.com/T/#t
- visuwesh raised the topic for recent Org mode's support for M-x yank-media
- Our support revived interest in better implementations of M-x
yank-media on all the Emacs platforms
- Emacs does not support M-x yank-media on Windows well
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71909 discusses how
to implement it considering Windows quirks (Windows clipboard is
not directly compatible with the notion of mime type used in
yank-media support for GNU/Linux)
- Beginning of the thread:
https://yhetil.org/emacs-bugs/tencent_7FA4E415A96083033C6BED7C7354AEE02505@qq.com/
- As a reminder, I now post links to meetup summaries and dates for
the upcoming meetups at https://orgmode.org/worg/orgmeetup.html
- This is in addition to Mastodon and the mailing list
- My new Mastodon server is https://fosstodon.org/@yantar92
:chat:
[17:31] Welcome to <b>[[bbb:OrgMeetup]]</b>!<br /><br />For help on using BigBlueButton see these (short) <a href="https://www.bigbluebutton.org/html5" target="_blank"><u>tutorial videos</u></a>.<br /><br />To join the audio bridge click the phone button. Use a headset to avoid causing background noise for others.<br /><br />This server is running <a href="https://docs.bigbluebutton.org/" target="_blank"><u>BigBlueButton</u></a>.
[17:38] Ihor Radchenko : Hi
[17:38] Chinmay : Hi!
[17:38] Ihor Radchenko : We are starting in 20 minutes
[17:38] Chinmay : ye no problem
[17:39] Ihor Radchenko : Meanwhile, the latest Emacs News: https://sachachua.com/blog/2024/10/2024-10-07-emacs-news/
[17:41] Chinmay : omg so many stashes - i need to start naming my stashes to use them more
[17:49] Ihor Radchenko : highlight-parentheses
[17:59] visuwesh : actually, can you have a variable named nil?
[18:00] visuwesh : ahhhh i see
[18:01] visuwesh : i see, i thought the report was about actually setting a variable named nil
[18:02] visuwesh : ahhh okay
[18:04] visuwesh : a question for karthik: did the thread in emacs-orgmode about adapting the new latex-preview code for auctex ever work out? https://bbb.emacsverse.org/b/iho-h7r-qg8-led or will it have to be changed compeltely now with the new wip emacs-wide intergration?
[18:04] visuwesh : https://list.orgmode.org/87edbhljr7.fsf@hyperspace
[18:05] visuwesh : got the link wrong, sry
[18:05] visuwesh : yep
[18:06] visuwesh : yes
[18:06] Dave Marquardt : yes
[18:06] karthink : The demo of latex is at around the 9 minute mmrk
[18:07] karthink : *demo of latex-mode
[18:07] Dave Marquardt : hehe
[18:08] karthink : @visuwesh the demo is based on prototype code that's not very robust
[18:09] visuwesh : hmm, okay. i was modelling latex preview for my goldbook interface after that thread but it just never worked and i never could work out why
[18:09] visuwesh : i wanted to ask you via mail but i left it for later TM and you released this video :)
[18:09] karthink : The changes required in org-latex-preview are not yet in the dev branch
[18:10] visuwesh : was it ever expected to work before these changes though?
[18:10] karthink : Yes, the code provided by Tony Zorman should work with the dev branch as is
[18:10] visuwesh : i used org-latex-preview-place with (BEG END VALUE) passed to it
[18:10] visuwesh : hmm i see
[18:12] karthink : No I just made it to demo the possibility of latex previews across Emacs
[18:13] Corwin Brust : gm :)
[18:13] karthink : Yeah it could be played at Emacsconf, I guess. In any case, I need feedback on the API for plugging it into other major modes
[18:16] karthink : It will still `(require 'ox)` for the preamble, but yeah, independent of Org-mode would be great.
[18:17] karthink : The other issue is that I want to avoid runtime dispatch on the major-mode, because we run code in after-change-functions that needs to be very fast
[18:17] Ihor Radchenko : 1. use thingatpt for boundaries
[18:17] Ihor Radchenko : 2. use custom variable/function for preamble
[18:18] karthink : I mean code like (funcall (plist-get major-mode ...))
[18:18] karthink : Yeah, the current prototype is using buffer-local variables
[18:19] karthink : Noted your point about providing defaults.
Okay, we can discuss this further in the thread? I think it's not relevant to most people in the meetup
[18:20] karthink : No worries, please take your time
[18:24] Chinmay : is the emacs apac meetup every saturday?
[18:25] visuwesh : I believe it is monthly?
[18:25] Chinmay : ah
[18:25] visuwesh : happens around 2 pm or 2:30 pm IST iirc
[18:25] Chinmay : ye
[18:25] Chinmay : 2
[18:26] karthink : @Ihor that reminds me -- is it expected for Emacs to take 4-5 seconds to exit because of org-persist in kill-emacs-hook?
[18:27] karthink : It happens every time to me, I think it's because of the large volume of latex previews that are cached
[18:28] karthink : How do you profile kill-emacs-hook?
[18:28] visuwesh : Can you not simplyprofile org-persist-write-all?
[18:30] Ihor Radchenko : (add-hook 'kill-emacs-hook #'error 100)
[18:30] Ihor Radchenko : This way, can profile killing emacs
[18:30] karthink : @Ihor, yeah, my experience is similar to yours just now
[18:31] Ihor Radchenko : error will prevent actual killing
[18:32] karthink : Okay, I'll find out what's happening
[18:33] karthink : Yeah, I'm reminded of the problem only when I quit Emacs, which isn't very often
[18:39] Chinmay : has someone tried to add link previews to org mode?
[18:39] Chinmay : this thing https://imgur.com/ZqPjZtE
[18:43] visuwesh : https://github.com/TobiasZawada/org-yt this thing maybe?
[18:44] Chinmay : i'll check this out, thanks
[18:44] visuwesh : but is there a general solution for this problem? im sort of interested in this too
[18:45] Chinmay : iinw there's some sort of standard for this too?
[18:45] visuwesh : only thing i can remember is a PR for ement.el to add link previews but i think that simply queries the matrix homeserver
[18:45] Chinmay : like on the web
[18:45] Chinmay : not emacs
[18:45] visuwesh : i see
[18:46] visuwesh : yes
[18:46] daniel german : There is a package called (require 'org-yt) that allows to have previews of an youtube snapshot.
[18:46] visuwesh : we can't see your screen though
[18:46] karthink : @visuwesh what do you mean by a general solution?
[18:47] Chinmay : general links, not just yt i believe
[18:47] visuwesh : i presume the package works by querying youtube for the thumbnail. i was thinking if there was a gen solution because matrix, discord, etc. show a nice preview of links regardless of the website
[18:48] daniel german : yes, thi s is only for youtube. it creates a special type of link and caches it
[18:48] daniel german : yt:video-url
[18:48] Chinmay : i see
[18:49] karthink : @Ihor there's the org-link-preview patch
[18:49] Ihor Radchenko : https://github.com/TobiasZawada/org-yt
[18:50] Chinmay : this is the standard https://oembed.com/
[18:50] karthink : https://list.orgmode.org/875xrqg6cb.fsf@gmail.com
[18:50] karthink : It's the :preview link parameter
[18:51] John Wiegley : Good morning (from California timezone)
[18:51] karthink : I think org-yt is advising org-display-inline-images (or whatever it's called)
[18:53] karthink : https://share.karthinks.com/org-link-preview-demo-2.mp4
[18:54] karthink : It's just an image placed over the link with C-c C-x C-v
[18:55] Chinmay : ye
[18:56] karthink : It looks like oembed can also be used for inline link previews in Org mode
[18:57] Chinmay : yes
[18:57] Chinmay : lmao
[18:58] Chinmay : i think twitter does its own thing
[18:59] Chinmay : og:image has a png link
[19:01] Chinmay : no idea
[19:02] Chinmay : nice nice
[19:03] visuwesh : Emacs can use libxml for parsing html and xml
[19:03] Chinmay : very cool
[19:03] visuwesh : there's an elisp library for parsing xml too iirc
[19:05] John Wiegley : I just had a feature idea I wanted to brainstorm
[19:06] John Wiegley : Project Xanadu
[19:06] Chinmay : ihor your voice is echoing
[19:06] daniel german : Ted Nelsons' hypertex
[19:06] daniel german : t
[19:07] daniel german : It might be an interesting additjion to org-transclude:
[19:07] daniel german : to have a parameter that indicates isi only the title or the content of the transclusion are transcluded
[19:08] John Wiegley : I hadn't thought of tying it in with transclusion, but I love that idea!
[19:08] John Wiegley : Both!
[19:08] John Wiegley : Translation of multiple languages, and transclusion of title/content/etc
[19:08] karthink : What is org translation?
[19:09] John Wiegley : Yes, my microphone on these websites often produces echo, my apologies.
[19:09] daniel german : org-transclude not org translation
[19:09] John Wiegley : https://github.com/nobiot/org-transclusion
[19:10] John Wiegley : I use Org transclusion so that I can give my employees feedback in a meeting file, and then transclude that feedback into their personnel file for the yearly review.
[19:10] daniel german : I am adding transclusion of a function, still in beta, and it will be moved to Nobiot's repo as an module: https://github.com/dmgerman/org-transclude-fn
[19:11] John Wiegley : Saves me from having to either centralize the feedback in a single file, or having to chase links to read them all in one go.
[19:12] visuwesh : hmm how does this different from org-babel?
[19:12] Ihor Radchenko : https://elpa.gnu.org/packages/lentic.html
[19:13] daniel german : I'll respond:
[19:13] daniel german : it executes a function, and dynamically inserts the result, but the result is not part of the actual buffer and it is read only.
[19:13] karthink : It would be great if Emacs provided C-level support for including a part of one buffer in another. Would solve various issues, including Org babel fontification, LSP support, "native" transclusion etc
[19:14] John Wiegley : @daniel It sounds like you could build a webserver on that idea
[19:14] daniel german : :) once you can execute a function, the sky is the limit :)
[19:15] visuwesh : if it is never going to clog up the result, that would be nice yes
[19:15] visuwesh : it can be a bit inconvenient to switch to *Async Shell Command Output* or the sync ersion of that
[19:16] John Wiegley : The idea I was proposing earlier, org-layers, would give you markup for specifying multiple versions of a region of text, and both Org-mode and the HTML export would give you a simple interface for changing the view both locally and globally.
[19:17] Ihor Radchenko : https://yhetil.org/emacs-devel/87h8kou1c0.fsf@telefonica.net/
Discussion about having text from multiple buffers in one buffer
[19:17] daniel german : One nice thing of org-transclude is that you can edit the source text in the transcluding buffer. I highly recommend it.
[19:18] karthink : @John Would all versions be written to the file?
[19:18] John Wiegley : AYes
[19:19] John Wiegley : #+begin_layered
Version one (full text)
,#+next_layered
Version two (summary)
,#+next layered
Version three (translation?)
,#+end_layered
[19:21] John Wiegley : That hashing idea is really nice, Ihor, I could see this being applicable to code comments in a source file too...
[19:21] John Wiegley : Like, the PR would not pass CI unless the comment had been updated with the new hash, which requires revision of that text.
[19:25] karthink : @Ihor any update on your big Org refactoring effort?
[19:25] Ihor Radchenko : https://yhetil.org/emacs-devel/835y0b29rk.fsf@gnu.org/
Discussion about translations on Emacs devel
[19:25] Jeff Trull : Karthik claims to not be a programmer too ;)
[19:29] Ihor Radchenko : https://list.orgmode.org/orgmode/87frq13w48.fsf@localhost/
[19:29] Ihor Radchenko : feature request: Chaining multiple org timers
[19:30] Chinmay : i love the transientification of everything
[19:30] John Wiegley : transient does seem like a great UI modality for many things
[19:31] user : I wish transient played more nicely with "C-h k" etc. I don't know if things have improved in that regard, but I recall going from transient menu-item to function behind it was not easily discoverable
[19:31] karthink : It's hard to modify a transient menu though
[19:32] karthink : Compared to keymaps
[19:32] user : Fair, it may be better than Org menus
[19:32] visuwesh : I really hope the issues raised in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52058 will be resolved
[19:32] kickingvegas : hi folks - sorry to jump in late
[19:33] Jeff Trull : Perfect timing
[19:36] Ihor Radchenko : https://list.orgmode.org/orgmode/877cbamq2q.fsf@gmail.com/
[19:36] Ihor Radchenko : feature: transient menu for opening citations
[19:37] karthink : Oh yeah, I've broken transient several times
[19:38] visuwesh : it i mostly a request for better documentation
[19:38] user : s/documentation/discoverability/
[19:38] visuwesh : and in-transient text that tries to help the user when trying a transient for the first time
[19:38] visuwesh : documentation too, honestly
[19:39] Ihor Radchenko : https://github.com/psionic-k/transient-showcase
some extra docs
[19:39] Chinmay : gtg, bye!
[19:39] visuwesh : i find the documentation very opaque as a user
[19:39] user : You don't get the same thing
[19:40] karthink : The transient manual made sense only after I read the EIEIO manual
[19:40] visuwesh : oh i didn't realise that repo contained user documentation. i thought it was only s bunch of examples so never bothered to open it
[19:42] Jeff Trull : Karthink that's interesting what is the connection between an OO library and a menu library
[19:43] karthink : I think the prefix and suffix distinction made sense when transient was a smaller library -- since a transient-prefix is a generalization of a prefix argument to an interactive elisp command
[19:43] karthink : @Jeff every transient menu item is an instance of an EIEIO class
[19:44] Jeff Trull : Ahhh
[19:44] John Wiegley : Where was it posted?
[19:45] user : Every now and again I wish there was a primer for EIEIO and cl-defstruct. Mostly because I don't use them often enough to ever remember their conventions
[19:45] kickingvegas : http://yummymelon.com/devnull/referencing-org-table-cells-with-text-regions.html
[19:45] user : primer as in cheatsheet as opposed to manual
[19:45] John Wiegley : Thank you! And nice to hear you as well.
[19:45] karthink : @Jeff This also means if you want a menu item with bespoke behavior you have to define a new EIEIO class that implements it, just for one item
[19:48] Ihor Radchenko : 3.5.10 Advanced features describes how to create named rows/columns
[19:50] karthink : Not seeing KickingVegas' screen yet
[19:51] Dave Marquardt : Unless your screen is the "Welcome to BigBlueButton" page
[19:53] karthink : @Ihor, what was the command you invoked to edit the tblfm interactively?
[19:53] karthink : C-c '
[19:53] karthink : Got it, did you call it with the cursor in the #+TBLFM line?
[19:53] Ihor Radchenko : M-x org-table-edit-formulas
[19:54] karthink : Cool thank you
[19:55] Dave Marquardt : yes, I see Ihor's screen
[20:00] Ihor Radchenko : 42.9.2 Overlay Properties
[20:00] Ihor Radchenko : when in org-table-edit-formulas mode, you can create overlay over the table and add 'keymap property to that overlay
[20:00] karthink : (info "(elisp) Overlay Properties")
[20:02] Ihor Radchenko : 22.7.5 Drag Events
[20:02] Ihor Radchenko : 22.7 Input Events
[20:03] John Wiegley : I agree, there's inertia for me too in naming cells properly
[20:04] visuwesh : yank-media will be properly supported in Windows soon enough: https://yhetil.org/emacs-bugs/bafcfc5c-e9d5-402c-a6de-321d49229386@imayhem.com/ it would be nice to provide feedback on what file types will be useful for handlers (currently images, text/html, filenames, audio and video are mentioned)
[20:05] visuwesh : it is about yank-media
[20:05] visuwesh : yea that was another bug report, with a proepr subject line
[20:05] visuwesh : yeah but they are trying to gather user feedback on useful clipbaord items right now
[20:06] visuwesh : https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71909
[20:07] visuwesh : what clipboard items would be useful for future yank-media usage
[20:09] Ihor Radchenko : bug#71909: 30.0.60; Can not use yank-media for pasting image from clipboad in org-mode on Windows platform
[20:09] Ihor Radchenko : actual thread title
[20:09] visuwesh : https://yhetil.org/emacs-bugs/tencent_7FA4E415A96083033C6BED7C7354AEE02505@qq.com/
[20:11] visuwesh : i think in windows yo uhave to translate the clipboard data so that it matches the mimetype string that is followed in linux
[20:11] visuwesh : so they will probably end up having a specific bunch of supported types so it would be nice to alert the devs on what clipboard items would be useful
[20:12] visuwesh : yea, it is the same on mac too. i think they have a very limited num of supported clipboard items if im not wrong
[20:12] visuwesh : (at least on the ns port)
[20:12] visuwesh : yea, the pushed needed to be given c:
[20:13] daniel german : thank you.
[20:13] oylenshpeegul : Thanks, Ihor! Thanks, everybody!
[20:14] visuwesh : thank you all
[20:14] Ihor Radchenko : Meetup page and annoucements: https://orgmode.org/worg/orgmeetup.html
Also, on Org mailing list and https://fosstodon.org/@yantar92
[20:14] kickingvegas : thanks all
[20:14] karthink : Thanks for the meetup
[20:15] John Wiegley : Good bye!
:end:
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 1%]
* News about TeX engines and the latest release of LaTeX
@ 2024-11-06 17:43 13% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2024-11-06 17:43 UTC (permalink / raw)
To: orgmode
Hi,
Although I still have a significant lack of time to actively collaborate
on the list, I share here this news that Joseph Wright, member of the
LaTeX project, collects on his website. I think this may be of interest
for org-mode support for LaTeX. I make a small summary (copy the first
and last paragraph) and put the link below:
> The latest release of LaTeX went to CTAN on Friday, and moves us forward in
> truly automatic tagging for PDFs, particularly for mathematics. As part of the
> work, we have been looking at the capabilities of different engines. Here, I
> want to summarise what users should take from that for existing and for new
> documents.
> [...]
> The time to move to LuaTeX for new LaTeX documents is here. For existing pdfTeX
> sources, tagging will be available, although it may be more limited than for
> LuaTeX. pdfTeX users can keep their existing sources and will see tagging
> available. XeTeX users really do need to re-work their sources for
> LuaTeX.
Source:
https://www.texdev.net/2024/11/05/engine-news-from-the-latex-project
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 13%]
* Re: [ANN] Tomorrow at EmacsConf 2024: The Future of Org
@ 2024-12-09 19:09 1% ` Ihor Radchenko
0 siblings, 0 replies; 144+ results
From: Ihor Radchenko @ 2024-12-09 19:09 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Ihor Radchenko <yantar92@posteo.net> writes:
> Tomorrow, at EmacsConf 2024, I will talk about the future of Org mode.
>
> My talk: https://emacsconf.org/2024/talks/org-update/
Attaching the talk slides, as an Org and pdf files, for your reference.
Also, tomorrow we will have OrgMeetup where you can ask me anything,
including about the talk, without tight time limits.
Announcement: https://list.orgmode.org/8734iwel1o.fsf@localhost/T/#u
URL: https://meet.jit.si/OrgMeetup
Time & Date: <2024-12-11 Wed 19:00-21:00 @+03,Europe/Istanbul>
[-- Attachment #2: org-update.pdf --]
[-- Type: application/pdf, Size: 715047 bytes --]
[-- Attachment #3: presentation.org --]
[-- Type: application/vnd.lotus-organizer, Size: 30532 bytes --]
:PROPERTIES:
:DIR: ~/.data/73/7e5c8f-1f73-417b-894a-9aceea5e4a69/
:END:
#+TITLE: The Future of Org
#+AUTHOR: Ihor Radchenko (yantar92)
#+OPTIONS: H:2 toc:t num:t
#+date: EmacsConf 2024
#+BEAMER_THEME: Madrid
#+beamer_header: \definecolor{OrgUnicornBody}{HTML}{77AA99}
#+beamer_header: \definecolor{OrgUnicornHair}{HTML}{50362B}
#+beamer_header: \setbeamercolor*{structure}{fg=OrgUnicornBody}
#+latex_header: \usepackage{svg}
#+beamer_header: \title[org-update]{The Future of Org}
#+beamer_header: \author[Ihor Radchenko (yantar92)]
#+beamer_header: {
#+beamer_header: \textbf{Ihor Radchenko}, Bastien Guerry \\ \footnotesize \vspace{1em}
#+beamer_header: Email: \texttt{yantar92@posteo.net} \\
#+beamer_header: Matrix: \texttt{@yantar92:matrix.org} \\
#+beamer_header: Mastodon: \texttt{fosstodon.org/@yantar92} \\
#+beamer_header: \vspace{1.5em}\includesvg[height=5em]{org-mode-unicorn.svg}\\\vspace{-1.5em}
#+beamer_header: }
#+beamer_header: \date[EmacsConf 2024]{Dec 7, 2024 \\ EmacsConf 2024}
#+beamer_header: \setbeamertemplate{navigation symbols}{} %remove navigation symbols
#+beamer_header: \AtBeginSection[]{
#+beamer_header: \begin{frame}[noframenumbering]{Outline}
#+beamer_header: \small \tableofcontents[currentsection]
#+beamer_header: \end{frame}
#+beamer_header: }
#+macro: contd @@beamer:{\scriptsize@@(contd.)@@beamer:}@@
#+macro: tiny @@beamer:{\tiny{}@@$1 @@beamer:}@@
#+macro: script @@beamer:{\scriptsize{}@@$1 @@beamer:}@@
* A word from Bastien Guerry
** A word from Bastien Guerry :ATTACH:
#+beamer: \centering
[[attachment:org-bye-bzg.ogg][file:clipboard-20241203T193207.png]]
* The new maintainer
** My step-by-step journey to Org maintenance
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- Background :: Material scientist
- 2015 :: Use Org to tame my PhD and research work (no idea about Elisp)
- 2017 :: Joined the mailing list to report a bug\\
@@beamer:{\tiny@@https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00502.html
@@beamer:}@@
- 2018 :: Actively participating (and learning Elisp)
- 2019 :: My Org files grew enough to lag (first Emacs bug report)\\
@@beamer:{\tiny@@https://debbugs.gnu.org/35453
@@beamer:}@@
#+beamer: \vfill
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
I had no prior experience with Elisp, but\\
using Emacs and reading forums gave enough training
** My step-by-step journey to Org maintenance {{{contd}}}
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- 2020 :: Annoyed enough by lags (and COVID lockdown) to contribute a fix myself\\
@@beamer:{\tiny@@https://list.orgmode.org/87h7x9e5jo.fsf@localhost/
@@beamer:}@@
- \approx{}2021 :: Got write access to savannah; decided to help with bug fixes in some areas
- Sep 2021 :: Offer from Bastien to become a maintainer
- 2022 :: Helping with all the bug reports and list discussions
- end of 2022 :: Second offer from Bastien (and unstable job situation)
- 2023 - Aug 2024 :: Working on Org full time
- Sep 2024 :: Third maintenance offer (accepted)
#+beamer: \vfill
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Helping to fix bugs made me learn various parts of Org\\
*Anyone interested in Org may repeat my journey regardless of experience*
** Priorities for Org maintenance
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
1. Codebase stability: fewer bugs, better APIs, long-term stability
2. Growing the Org community: new contributors, Org forums and chats
3. Support Org-related third-party packages, mobile apps, parsers
4. Org markup development
5. Strategically important new features
#+beamer: \vfill
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Active Org community and contributors are the key to get new features\\
A sole maintainer cannot do all the above even working full time
* Codebase: towards better APIs and Emacs integration
** Modular Org :ATTACH:
#+attr_latex: :height 0.8\textheight
[[attachment:clipboard-20241111T181313.png]]
#+beamer: \centering
#+beamer: \vspace{-1em}
{{{tiny(https://list.orgmode.org/orgmode/E1kIPh1-0001Lu-Rg@fencepost.gnu.org/)}}}
** Slim down large Org libraries
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Too large and complex libraries often discourage contributions\\
{{{script(example: alphapapa's alternative to org-agenda (part of org-ql))}}}
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
#+beamer: \vfill
- Way too many Org libs are way too large
- I plan to split large libs into smaller
- The monsters like =org.el=, =org-agenda.el=, =org-table.el=,
=org-list.el=, =ob-core.el=, =org-clock.el=, and =org-compat.el=
should slim down
- The existing 127 Org libraries will be turned into 263 (WIP!)
smaller libraries
#+beamer: \vfill
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
{{{script(WIP: https://git.sr.ht/~yantar92/org-mode/log/feature/refactor-deeps-v2 )}}}
** Upstream generic Org libraries [tentative list]
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Upstreamed libs will benefit from Emacs dev's oversight
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- =org-capture=: \dots is originally forked from remember.el\\
{{{script(https://lists.gnu.org/archive/html/emacs-orgmode/2023-12/msg00412.html)}}}
- =org-protocol=: Processing external input into Emacs\\
from command line, from clicked URLs as URL handler, etc.\\
Unlike running commands directly (which is unsafe), =org-protocol=
can be used for safe interaction with external processes
- =org-persist=: generic cache API
- =org-fold-core=: Generic folding API
- =org-read-date=: Interactive date/time selection
** Upstream generic Org libraries [tentative list] {{{contd}}}
- =org-preview-image= and =org-preview-latex=: Image preview\\
Does not have to be limited to Org mode buffers\\
{{{script(https://youtu.be/u44X_th6_oY?t=199 (credit: Karthik Chikmagalur))}}}\\
{{{script(https://list.orgmode.org/orgmode/87edbhljr7.fsf@hyperspace/)}}}
- =org-diary-lib=: Org extensions for diary-lib.el
- =org-clock-notify=: System notifications
- =org-idle=: Advanced idle time tracking\\
not just for Emacs idleness, but for system idle time as well
- =org-duration=: Manipulate durations like 1d 3h 5min
** Upstream generic Org libraries [tentative list] {{{contd}}}
- =org-agenda-undo=: undoing changes in multiple buffers at once\\
This is the way undo works in agenda buffers, undoing changes in
multiple headlines changed from agenda, even when they live in
different Org files.
- =org-time=: Extra functions to work with Emacs time data\\
- =org-timer=: (almost) generic timer for Emacs
- =org-track-markers=: Keeping relative positions of markers
when cutting/pasting text in buffers\\
This is the way agenda does not get broken by
cutting/pasting/refiling the underlying headings around.
** Upstream generic Org libraries [tentative list] {{{contd}}}
- =org-macs=: many small helper functions
- (maybe) =ox=, =org-element-ast=: Org exporter can be generalized\\
The core idea of Org export does not rely upon the details of Org
syntax. It might use arbitrary parse trees (say, from tree-sitter)
as input\\
{{{tiny(https://yhetil.org/emacs-devel/87frngx4fx.fsf@localhost/)}}}
- (maybe) =ol=: Org links can already be used outside Org mode\\
Can we do better?
- (maybe) =org-table-formula=: Org spreadsheets\\
Org spreadsheets are not inherently tied to Org markup and might be
used more generally
** Use modern Emacs APIs and libraries
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Org covers many built-in Emacs features, but not always the newer ones
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
Recently added:
- =yank-media=, =dnd=: Drag and drop + pasting from system clipboard
Credit: Visuwesh\\
{{{tiny(https://list.orgmode.org/orgmode/87jzsintv0.fsf@gmail.com/)}}}
To be added:
- =transient.el=: better replacement for Org menus (export, agenda, tempo, etc.)\\
Org has an old, ad-hoc, limited, self-written menu system. And it
has nothing to do with Org itself.\\
Initial WIP: Tor-björn Claesson\\
{{{tiny(https://list.orgmode.org/orgmode/8734m28l9a.fsf@gmail.com/)}}}
** Use modern Emacs APIs and libraries {{{contd}}}
To be added {{{contd}}}:
- =compat.el=: Backwards compatibility library for Emacs\\
Org has self-written =org-compat.el=. =compat.el= is strictly
better when we need compatibility wrappers for older Emacs versions.\\
{{{tiny(https://list.orgmode.org/orgmode/87v8ks6rhf.fsf@localhost/)}}}
- =track-changes.el=: New library to track edits in buffer\\
Now, Org uses a self-written implementation
Wish list:
- =context-menu-mode=: Context menu support\\
This is a relatively new addition to Emacs. Should be supported by
all the major modes.
- =touch-screen=: Touch screen support\\
This is very important feature for Android.
- =thingatpt=: Generic parser/syntax queries
** Improve Org parser APIs
Org uses two approaches to parsing simultaneously:
1. Proper parser (=org-element=)
2. Ad-hoc approximate regexp-based parser
#+beamer: \vfill
We need to modify the parser to support all the internal use cases:
1. Generalize Org AST to be used in =ox.el= and =org-element.el= consistently\\
{{{script(done in =org-element-ast.el=)}}}
2. The parser should work in real time (fast)\\
- =org-element-cache= is enabled by default since Org 9.6
- =org-element-cache= is yet to support caching objects\\
(markup vs. paragraphs and above)
** Improve Org parser APIs {{{contd}}}
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
We need to modify the parser to support all the internal use cases {{{contd}}}:
3. [@3] Fontification should use the parser\\
{{{tiny(https://list.orgmode.org/orgmode/87ee7c9quk.fsf@localhost/)}}}
4. Wish: Editing Org files should use parser\\
We may need something akin =org-ml=\\
{{{tiny(https://github.com/ndwarshuis/org-ml)}}}
*** :B_hblock
:PROPERTIES:
:BEAMER_env: hblock
:ID: 1e0ed6ca-79b1-49ba-870a-dafe9c089752
:END:
#+beamer: \centering
=org-element= APIs should eventually be used everywhere
** Improve Org babel APIs
- Org babel backends currently use ad-hoc, sometimes undocumented API
- Backends have to use specific function names
- Header arg conventions are often undocumented
- Some APIs are not always reliable (async evaluation)
- Babel backend documentation lives on WORG (Org wiki)\\
{{{tiny(https://orgmode.org/worg/org-contrib/babel/languages/index.html)}}}
- =ob-core= should use more =ox.el=-like backend definition style
- WORG documentation must eventually move to the manual
- Async API should be generalized and fixed\\
Credit: Bruno Barbier\\
{{{tiny(https://list.orgmode.org/orgmode/65df0895.df0a0220.a68c8.0966@mx.google.com/)}}}
* Beyond Org code and Emacs: third-party packages, apps, parsers
** =org-contrib=
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Org mode is large. Some specialized parts are hard to maintain and
require knowing very specialized specs/languages.
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- Since Org 9.5, =org-contrib= is no longer a part of Org mode\\
{{{tiny(https://list.orgmode.org/orgmode/87a6qnixnr.fsf@gnu.org/)}}}
- We moved a number of specialized Org libraries to =org-contrib=\\
{{{tiny(https://list.orgmode.org/orgmode/87bl9rq29m.fsf@gnu.org/)}}}
- =ob-vala=, =ob-shen=, =ob-ledger=, =ob-picolisp=, =ob-mscgen=,
=ob-[h]ledger=, =ob-io=, =ob-ebnf=, =ob-coq=, =ob-asymptote=,
=ob-abc=, =ob-J=
- Org itself has a fair bit of specialized libs:
=org-feed=, =org-mobile=, various =ob-*= languages, various =ox-*=
exporters
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
If you know and use specialized libs\\
from =org-contrib= or Org itself, *please do volunteer*
** Org orphanage
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- =org-contrib=, as for now, is a collection of mostly abandoned libraries
- *Org core team is still maintaining them, but on the minimal level*
- In addition, we are open to provide help to third-party packages
that can no longer be maintained
- https://orgmode.org/worg/org-orphanage.html has a list of
libraries in a search for new maintainers
- We are also a part of Jonas Bernoulli's (tarsuis) Emacs orphanage
https://github.com/emacsorphanage/
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
If you are an author/maintainer of an Org-related library and unable
to provide continuous maintenance, feel free to write to Org mailing
list.
** Mobile apps and parsers
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
Org markup is understood by a number of mobile and web apps (https://orgmode.org/tools.html):
- Orgzly revived (Android): https://www.orgzlyrevived.com/
- MobileOrg (iOS): https://mobileorg.github.io/features/
- Orgro (Android, iOS): https://orgro.org/
- Organice (Web): https://organice.200ok.ch/
- Org Note (Android, Web): https://github.com/Artawower/orgnote
- Logseq (Android, Web, Desktop): https://logseq.com/
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
We cannot directly contribute to non-Elisp development,\\
but we do want to unify the Org markup and avoid Markdown fate with
multiple syntax flavors
** Mobile apps and parsers {{{contd}}}
- There are existing Org parsers for Pico Lisp, Common Lisp, NodeJS,
Python, Perl, Rust, JavaScript, Dart, Go, Julia, Clojure,
Tree-sitter, OCaml, Haskell, and Typescript\\
{{{tiny(https://orgmode.org/tools.html)}}}
- They often implement a subset of Org syntax
- *We provide reference Org syntax spec in https://orgmode.org/worg/org-syntax.html*
- Eventually, our spec will be submitted as IETF RFC\\
{{{tiny(https://list.orgmode.org/orgmode/871rjhha8t.fsf@gmail.com/)}}}
- I also hope to implement a reference set of tests as a benchmark and parser development aid\\
{{{tiny(https://list.orgmode.org/orgmode/87fsqzi4tw.fsf@localhost/)}}}
* Org syntax development
** Long-standing syntax problems
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Before we fix Org syntax blueprint (IETF), we should resolve the major
inconsistencies and problems.
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
1. Org mode does not always parse Org syntax consistently
- Some parts of Org use a slightly different parser (regexp-based)
- For example, numeric priorities in headings are not treated consistently\\
{{{tiny(https://list.orgmode.org/orgmode/CANDZv_N394TYMy30-KuEQV+eZ0FEkm4GSjTrkUtDViK_-DkX-Q@mail.gmail.com/)}}}
2. Org syntax has a number of edge cases that should better be addressed
- Intra-word markup is awkward in Org\\
{{{tiny(https://list.orgmode.org/orgmode/4897bc60-b74f-ccfd-e13e-9b89a1194fdf@mailbox.org/)}}}\\
{{{tiny(https://list.orgmode.org/orgmode/87fw46rwd6.fsf@selune.samsung.net/)}}}
- We often recommend zero-width space as a kind of escape character, but many people dislike it\\
{{{tiny(https://list.orgmode.org/orgmode/87ilw5yhv3.fsf@posteo.net/)}}}
** Long-standing syntax problems {{{contd}}}
2. [@2] Org syntax a number of edge cases that should better be addressed {{{contd}}}
- ==/+_= are tricky when used inside verbatim markup beside spaces\\
{{{tiny(https://list.orgmode.org/orgmode/87v8vng70x.fsf@web.de/)}}}
- Edge cases with double blank lines inside verbatim blocks\\
{{{tiny(https://list.orgmode.org/orgmode/87mtbilzhm.fsf@localhost/)}}}
3. Inlinetask syntax is not great both from human and technical point
of view. It should be re-designed\\
{{{tiny(https://list.orgmode.org/orgmode/87fs47h2x4.fsf@localhost/)}}}
** New syntax features
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Some features have been requested many times\\
or can solve the existing problems
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- Time zone support in timestamps\\
*the syntax has been decided; we need patches*\\
{{{tiny(https://list.orgmode.org/87tu063ox2.fsf@localhost/)}}}
- Better repeater specifications in timestamps\\
{{{tiny(https://list.orgmode.org/877cxp1fbx.fsf@localhost/)}}}
- Custom syntax elements (aka inline special blocks)\\
Credit: Juan Manuel Macías\\
{{{tiny(https://list.orgmode.org/875xwqj4tl.fsf@localhost/)}}}
- Multi-line cells in tables (we have no good ideas here; *please help*)\\
{{{tiny(https://list.orgmode.org/orgmode/877d0ia7vd.fsf@mat.ucm.es/)}}}
* Strategic new features
** New features I hope to see in Org
1. Asynchronous LaTeX (and non-LaTeX) previews (WIP)\\
Credit: Timothy Chapman (tecosaur/TEC), Karthik Chikmagalur (karthink)\\
{{{tiny(https://list.orgmode.org/orgmode/87lek2up0w.fsf@tec.tecosaur.net)}}}
2. Make =org-ql= part of Org core (WIP)\\
Credit: Adam Porter (alphapapa)\\
{{{tiny(https://github.com/alphapapa/org-ql/issues/409)}}}
3. Multipage export (WIP)\\
Credit: Orm Finnendahl\\
{{{tiny(https://list.orgmode.org/orgmode/ZoUdiTfbYqzPwTiX@orm-t14s/)}}}
** New features I hope to see in Org {{{contd}}}
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
4. [@4] Wish: Multi-language support
- exporting multi-language documents
- translation workflows
5. Wish: Collaborative editing
- tracking changes
- foreign comments
- import from non-Org formats (with comments)
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
*If you also want to see these features, please consider contributing*
* Org community
** Org community forums \rightarrow Org mailing list
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- *All the new features and ideas are not coming from nowhere*
- Most of the ideas are first proposed and discussed on various forums/chats
- Mailing list: https://list.orgmode.org/
- Reddit: https://reddit.com/r/orgmode/
- Mastodon: https://fosstodon.org/tags/orgmode
- IRC/Matrix: https://web.libera.chat/#org-mode, https://matrix.to/#/%23org-mode:matrix.org
- Meetups: https://emacslife.com/calendar/
- ... and non-English, like
- https://emacs-china.org/
- https://t.me/emacs_ru
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
*Eventually, we want all the serious discussions to happen on the mailing list*
see https://orgmode.org/worg/org-mailing-list.html
*... and all the non-trivial write-ups to end up in WORG (Org wiki)*
see https://orgmode.org/worg/
** Org mailing list \rightarrow world
- *Not everyone is interested reading the _whole_ Org mailing list*
- There are news feeds exposing important topics discussed on the list
- via Woof! (news feeds in HTML, RSS, ORG, JSON, and MD)
- https://tracker.orgmode.org/news\\
announcements, blog-like posts
- https://tracker.orgmode.org/requests\\
feature requests, important discussions
- weekly https://sachachua.com/blog/category/emacs-news/\\
{{{script(Credit: Sacha Chua)}}}
- Woof! RSS \rightarrow chatbots
- there is experimental bot posting news and discussions in #org-mode Matrix room
- wish: similar bots for reddit, mastodon, maybe IRC
- *We are also looking for ideas to improve CSS styles* in
https://list.orgmode.org/ and https://orgmode.org/worg/
- wish: mailing list archives could have forum-like look&feel
** Contribute ideas!
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
Unlike emacs-devel, Org mailing list is not restricted\\
to Org development. It is more like forum.
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- Anyone can post on the mailing list, without registration
- *If you have any ideas, questions, or just rant about Org mode, feel free to post*
- We'd also love to add new interesting blog posts to WORG topic collections
* The call for contributions
** How much can a single person do?
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
#+begin_src gnuplot :var data=clock-data :file clocked.png
@PNG
set title 'Hours spent weekly working on Org mode'
set xdata time
set timefmt "%Y/%m/%d"
set format x "%U"
set xrange ['2024/02/25':'2024/12/07']
set grid
set xlabel "Week#, in 2024"
set ylabel "Clocked hours"
set arrow from '2024/08/30', 31.89 to '2024/08/30', 8 lw 2 lc rgb 'red'
set label "job to pay bills" at '2024/08/30', 31.89 offset character 1.5, character -7 rotate 90
plot data u 1:2 with impulses lw 5 not, [:'2024/08/30'] 31.89 w l lw 2 lc rgb 'red' t'recorded \~32 hours/week', ['2024/08/30':] 8 w l lw 2 lc rgb 'red' t'target 8 hours/week (w job)'
#+end_src
#+attr_latex: :width 0.7\linewidth
#+RESULTS:
[[attachment:clocked.png]]
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
There is no way I can handle everything myself,\\
even if I work full time on Org
** Contribute code!
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
We *badly* need regular contributors
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- In addition to all the listed plans&ideas, I myself now have 422 bug-related
tasks, 859 feature ideas, and 894 ideas about Org improvements
- Too many ideas, too little man-hours
- We need help fixing bugs and maintaining specialized libraries
- We need help implementing new features
- If anything, I need people who can help me if life makes unexpected
turns (who knows what happens in 1, 2, 5 years from now)
- Among all types of contributions we prefer code
** Why contribute?
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- The absolute majority of new features are added by people who need
them
- Even the commonly requested features!
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
*Got a feature you wish existed? Do not wait for others to contribute it!*\\
Write to mailing list, and we can help to get started.
** Why contribute? {{{contd}}}
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- My job as a maintainer is guiding people through the Org code, if
needed
- I will also check the code, point out mistakes, and suggest
improvements
- Even Elisp beginners can contribute simple things under guidance\\
All we need is:
1. Your interest in specific new feature or area of Org
2. Your free time spent contributing
3. Readiness to learn
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
*You should not be afraid to be wrong*
** Why contribute? {{{contd}}}
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- Not comfortable with patches?
- git repos with changes are ok
- even modified versions of files are ok
- We will help as needed
- Not comfortable with emails?
- there is #org-mode IRC and Matrix chats where you can first
discuss rough ideas. You can ping me (yantar92) there\\
{{{tiny(https://web.libera.chat/#org-mode)}}}\\
{{{tiny(https://matrix.to/#/%23org-mode:matrix.org)}}}
- We have monthly meetup where you can ask by voice\\
{{{tiny(https://orgmode.org/worg/orgmeetup.html)}}}
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
*If you have any doubts, just ask. We always welcome new contributors*
** Benefits for code contributors
- *Contributing to Libre software can help with CV*
- Personally written pet projects are a known good proof of skills
- Contributing to community package can add more
1. It is a proof of an ability to work in a team
2. It is a proof of an ability to understand large codebases
3. It is a proof of an ability to follow project standards
#+beamer: \vfill
#+beamer: \scriptsize
#+begin_quote
Imagine you are the main programmer on the team, and you are hiring a
colleague. You have a bunch of resumes on your desk. Most of them
contain puffy words and perhaps basic portfolios, half-finished simple
programs that nobody uses, if anything. The last resume, unlike the
others, shows contributions to well-established, real-world production
code-bases. What is more, you can readily check both the patches and
the discussions, in one click, to see how the person talks, to machines
and to people. Which CV would you, as the expert, prefer?
People are struggling to differentiate their offering, and this is how
they can do it. The fact it is not seen much in the wild is a plus!
And it is understandable why, as it is not easy to contribute to, say, a
complex C++ code base. Emacs is unique in this regard, and Org inherits
the advantage.
\tiny
\hfill by Rudolf Adamkovič,\\
\hfill the author of MathJax 3+ support in HTML export
#+end_quote
** Benefits for code contributors {{{contd}}} :ATTACH:
- Thanks to many kind users, Org mode receives a noticeable amount of donations\\
{{{tiny(https://liberapay.com/org-mode/)}}}
- We share these donations among the interested regular contributors\\
{{{tiny(https://liberapay.com/org-mode/income/)}}}
- *If you become a regular Org contributor, you can also claim the share*
[[attachment:income-history.png]]
** Contributing as non-programmer
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- WORG needs more love
- a number of articles is outdated
- CSS styles can be improved
- table of contents popup is not ideal on small screens
- it would be nice to have dark/light themes and ability to switch
- it would be nice to have some kind of "modern" theme as an option
- more tutorials or links to good tutorials will be welcome\\
{{{tiny(https://orgmode.org/worg/org-tutorials/index.html)}}}
- Would be nice to have more screencasts like in
https://orgmode.org/features.html
- Org manual is sometimes too technical (it is written by devs who are
a bit too familiar with the code)
- This is where input from ordinary users is invaluable
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
{{{script(https://list.orgmode.org/orgmode/87y1rat98w.fsf@localhost/)}}}
** Got no free time, but still want to help?
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
- If you cannot help by code, text, or ideas, consider donating
- *Donations do help a lot*
1. It increases motivation to do mundane tasks, like fixing bugs and
writing tests
2. It affects the amount of free time spent working on Org
3. For a while, it was even the only source of income for me
personally
#+begin_quote
\scriptsize
Donations (both the group setup, and what people donate to me
individually) have increased my motivation to work on Org, even as my
time is split in more directions. It's a clear signal that the hours
that are put in are valued, and ultimately that makes me feel more
upbeat about the work, particularly when it's in the "bug squashing
slog" phase as the LaTeX preview revamp is.
Aside from the direct impact, there are a bunch of indirect/secondary
but positive aspects to it too: it also makes me feel that the
community really values the work put into open-source projects like
this.
\tiny
\hfill by Timothy Chapman (tecosaur/TEC),\\
\hfill co-author of async LaTeX preview feature,\\
\hfill the maintainer of ox-html and org-plot
#+end_quote
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
We use libre website to get donations:
https://liberapay.com/org-mode/
** Thank you! :B_fullframe:
:PROPERTIES:
:ID: 3129cc25-159b-4fa0-8cf4-d2474e6afd34
:BEAMER_env: fullframe
:END:
#+attr_latex: :height 5em
<attachment:org-mode-unicorn.svg>
*** :B_hblock:
:PROPERTIES:
:BEAMER_env: hblock
:END:
#+beamer: \centering
@@beamer:\Huge@@ Thank you!@@beamer:\small@@
*** :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:
#+beamer: \vfill
- EmacsConf page of this talk: https://emacsconf.org/2024/talks/org-update/
- How to contribute: https://orgmode.org/worg/org-contribute.html
- Support Org mode: <https://liberapay.com/org-mode/>
* Clocking data for me working on Org :NOEXPORT:
#+name: clock-data
| 2024/03/08 | 13:58 | 13.966666666666667 |
| 2024/03/15 | 14:00 | 14.0 |
| 2024/03/22 | 26:26 | 26.433333333333334 |
| 2024/03/29 | 32:40 | 32.666666666666664 |
| 2024/04/05 | 34:17 | 34.28333333333333 |
| 2024/04/12 | 36:48 | 36.8 |
| 2024/04/19 | 21:27 | 21.45 |
| 2024/04/26 | 36:08 | 36.13333333333333 |
| 2024/05/03 | 46:32 | 46.53333333333333 |
| 2024/05/10 | 25:36 | 25.6 |
| 2024/05/17 | 23:06 | 23.1 |
| 2024/05/24 | 23:34 | 23.566666666666666 |
| 2024/05/31 | 22:39 | 22.65 |
| 2024/06/07 | 40:24 | 40.4 |
| 2024/06/14 | 42:37 | 42.61666666666667 |
| 2024/06/22 | 40:00 | 40.0 |
| 2024/06/28 | 33:21 | 33.35 |
| 2024/07/05 | 36:36 | 36.6 |
| 2024/07/12 | 34:41 | 34.68333333333333 |
| 2024/07/19 | 25:49 | 25.816666666666666 |
| 2024/07/26 | 18:35 | 18.583333333333332 |
| 2024/08/02 | 48:32 | 48.53333333333333 |
| 2024/08/09 | 53:02 | 53.03333333333333 |
| 2024/08/16 | 40:15 | 40.25 |
| 2024/08/23 | 26:13 | 26.216666666666665 |
| 2024/08/30 | 1:07 | 1.1166666666666667 |
| 2024/09/06 | 6:53 | 6.883333333333334 |
| 2024/09/13 | 3:29 | 3.4833333333333334 |
| 2024/09/20 | 0:06 | 0.1 |
| 2024/09/27 | 1:08 | 1.1333333333333333 |
| 2024/10/04 | 4:27 | 4.45 |
| 2024/10/11 | 8:46 | 8.766666666666667 |
| 2024/10/18 | 13:00 | 13.0 |
| 2024/10/25 | 8:47 | 8.783333333333333 |
| 2024/11/01 | 8:17 | 8.283333333333333 |
| 2024/11/08 | 2:46 | 2.7666666666666666 |
| 2024/11/15 | 10:50 | 10.833333333333334 |
| 2024/11/22 | 4:34 | 4.566666666666666 |
| 2024/12/01 | 5:24 | 5.4 |
#+tblfm: $3='(/ (org-duration-to-minutes $2) 60)
#+begin_src python :var data=clock-data :results output
import pandas as pd
pd_data = pd.DataFrame(data)
print(pd_data[[2]].describe())
#+end_src
#+RESULTS:
: 2
: count 25.000000
: mean 31.890667
: std 10.487820
: min 13.966667
: 25% 23.566667
: 50% 33.350000
: 75% 40.000000
: max 53.033333
[-- Attachment #4: Type: text/plain, Size: 223 bytes --]
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 1%]
Results 1401-1544 of 1544 prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2024-01-21 8:44 New try at multi-lingual export to latex/pdf using pdflatex and babel Pedro Andres Aranda Gutierrez
2024-01-21 13:02 ` Ihor Radchenko
2024-01-21 17:11 ` Pedro Andres Aranda Gutierrez
2024-02-09 23:10 ` Ihor Radchenko
2024-02-10 6:13 ` Pedro Andres Aranda Gutierrez
2024-02-10 14:39 ` Ihor Radchenko
2024-02-11 6:22 ` Pedro Andres Aranda Gutierrez
2024-02-11 11:04 12% ` Juan Manuel Macías
2024-04-15 12:21 6% ` Ihor Radchenko
2024-02-08 22:13 Link type for pdf-tools annotations Juan Manuel Macías
2024-02-09 12:13 6% ` Irfan S
2024-02-10 1:58 [patch] Add two new header args to LaTeX block Juan Manuel Macías
2024-02-10 14:37 ` Ihor Radchenko
2024-02-10 15:20 ` Juan Manuel Macías
2024-02-10 16:35 ` Ihor Radchenko
2024-02-10 17:48 ` Juan Manuel Macías
2024-02-10 19:35 ` Juan Manuel Macías
2024-02-10 21:07 ` Ihor Radchenko
2024-02-10 23:34 ` Juan Manuel Macías
2024-02-11 14:43 5% ` Ihor Radchenko
2024-02-11 20:01 9% ` Juan Manuel Macías
2024-02-13 13:42 5% ` Ihor Radchenko
2024-02-13 20:25 11% ` Juan Manuel Macías
2024-02-18 14:20 5% ` Ihor Radchenko
2024-02-18 13:43 10% ` Juan Manuel Macías
2024-02-19 11:15 6% ` Ihor Radchenko
2024-02-19 13:24 12% ` Juan Manuel Macías
2024-02-12 6:36 Retaking AUTO for \usepackage{fontenc} Pedro Andres Aranda Gutierrez
2024-02-12 14:01 ` Ihor Radchenko
2024-02-13 7:51 ` Pedro Andres Aranda Gutierrez
2024-02-13 11:57 13% ` Juan Manuel Macías
2024-02-13 16:47 6% ` Pedro Andres Aranda Gutierrez
2024-02-13 17:22 11% ` Juan Manuel Macías
2024-02-14 14:55 6% ` Ihor Radchenko
2024-02-14 22:03 13% ` Juan Manuel Macías
2024-02-12 10:05 "Full Block" character in example block not visible in Beamer PDF Loris Bennett
2024-02-12 11:06 12% ` Juan Manuel Macías
2024-02-12 12:40 6% ` Loris Bennett
2024-02-12 15:24 12% [patch] ox.latex.el: Add missing character warnings Juan Manuel Macías
2024-02-12 18:15 12% ` Juan Manuel Macías
2024-02-12 18:26 6% ` Ihor Radchenko
2024-02-12 19:17 10% ` Juan Manuel Macías
2024-02-12 19:52 5% ` Ihor Radchenko
2024-02-12 21:20 6% ` Juan Manuel Macías
2024-02-13 14:29 5% ` Ihor Radchenko
2024-02-13 16:01 11% ` Juan Manuel Macías
2024-02-14 14:37 6% ` Ihor Radchenko
2024-02-17 0:36 Exporting multiple #+AUTHOR keywords ypuntot
2024-02-17 10:34 6% ` Juan Manuel Macías
2024-02-19 10:08 set italian language in LaTeX export Luca Ferrari
2024-02-19 11:11 13% ` Juan Manuel Macías
2024-02-19 14:06 ` Luca Ferrari
2024-02-19 15:11 13% ` Juan Manuel Macías
2024-02-20 20:35 9% [proof of concept] inline language blocks Juan Manuel Macías
2024-02-21 8:42 6% ` Ihor Radchenko
2024-02-21 10:57 10% ` Juan Manuel Macías
2024-02-21 12:00 5% ` Ihor Radchenko
2024-02-21 12:53 10% ` Juan Manuel Macías
2024-02-21 13:10 5% ` Ihor Radchenko
2024-02-21 14:13 12% ` Juan Manuel Macías
2024-02-21 20:32 8% ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
2024-02-21 23:29 12% ` [proof of concept] inline-special-block Juan Manuel Macías
2024-02-22 22:03 13% ` Juan Manuel Macías
2024-02-21 22:11 4% ` [proof of concept] inline language blocks Samuel Wales
2024-02-21 22:28 13% ` Juan Manuel Macías
2024-02-21 22:55 6% ` Samuel Wales
2024-02-21 23:02 10% ` Juan Manuel Macías
2024-02-28 10:29 7% ` Max Nikulin
2024-02-28 13:15 4% ` Juan Manuel Macías
2024-02-28 17:21 6% ` Max Nikulin
2024-02-28 23:42 4% ` Juan Manuel Macías
2024-02-29 7:05 6% ` Max Nikulin
2024-02-29 10:41 10% ` Juan Manuel Macías
2024-02-29 12:05 5% ` Max Nikulin
2024-02-29 12:50 10% ` Juan Manuel Macías
2024-02-21 23:33 6% ` Suhail Singh
2024-03-31 14:56 4% ` Daniel Clemente
2024-02-23 23:50 4% [testing patch] inline-special-block with full implementation for LaTeX backend Juan Manuel Macías
2024-02-25 13:53 11% A question about local/experimental branches Juan Manuel Macías
2024-02-25 14:05 6% ` Ihor Radchenko
2024-02-25 15:10 12% ` Juan Manuel Macías
2024-02-26 8:43 ` Bastien Guerry
2024-02-26 11:06 ` Ihor Radchenko
2024-02-26 13:03 ` Bastien Guerry
2024-02-27 9:57 10% ` Juan Manuel Macías
2024-02-26 8:55 [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix Bastien
2024-02-26 10:32 13% ` Juan Manuel Macías
2024-02-26 11:03 5% ` Ihor Radchenko
2024-02-26 12:58 6% ` Bastien Guerry
2024-03-01 20:34 9% Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-02 8:29 ` Stefan Nobis
2024-03-02 10:57 13% ` Juan Manuel Macías
2024-03-03 20:29 9% ` Juan Manuel Macías
2024-03-10 2:08 10% ` `:export' attribute?: " Juan Manuel Macías
2024-03-10 13:54 13% ` Juan Manuel Macías
2024-03-11 10:27 5% ` Max Nikulin
2024-03-11 13:59 11% ` Juan Manuel Macías
2024-03-11 17:01 6% ` Max Nikulin
2024-03-11 20:19 11% ` Juan Manuel Macías
2024-03-12 8:32 6% ` Stefan Nobis
2024-03-12 13:45 11% ` Juan Manuel Macías
2024-03-12 16:20 6% ` Max Nikulin
2024-03-12 17:41 12% ` Juan Manuel Macías
2024-03-13 16:08 5% ` Max Nikulin
2024-03-13 16:48 12% ` Juan Manuel Macías
2024-03-13 17:16 14% ` Juan Manuel Macías
2024-03-15 2:19 5% ` Juan Manuel Macías
2024-03-15 10:52 4% ` Max Nikulin
2024-03-15 13:10 5% ` Juan Manuel Macías
2024-03-15 17:21 5% ` Max Nikulin
2024-03-15 16:26 12% ` Juan Manuel Macías
2024-03-16 14:07 4% ` Max Nikulin
2024-03-18 19:42 6% ` Juan Manuel Macías
2024-03-19 14:54 3% ` Max Nikulin
2024-03-19 17:47 6% ` Juan Manuel Macías
2024-03-21 10:26 5% ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
2024-03-26 16:56 6% ` inline-special-block: export rules Max Nikulin
2024-03-04 17:13 5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
2024-03-04 17:29 ` Ihor Radchenko
2024-03-04 17:49 12% ` Juan Manuel Macías
2024-03-05 10:53 6% ` Max Nikulin
2024-03-05 15:16 11% ` Juan Manuel Macías
2024-03-04 18:07 6% ` Juan Manuel Macías
2024-03-04 22:17 5% ` Samuel Wales
2024-03-04 22:18 0% ` Samuel Wales
2024-03-05 16:47 5% ` smallcaps: " Max Nikulin
2024-03-05 17:28 10% ` Juan Manuel Macías
2024-03-06 10:55 5% ` Max Nikulin
2024-03-06 15:21 11% ` Juan Manuel Macías
2024-03-06 16:53 7% ` To avoid zero width space: " Max Nikulin
2024-03-06 18:27 12% ` Juan Manuel Macías
2024-03-06 21:13 12% ` Juan Manuel Macías
2024-03-07 10:57 6% ` false positives: " Max Nikulin
2024-03-07 11:06 12% ` Juan Manuel Macías
2024-03-07 11:18 6% ` Ihor Radchenko
2024-03-07 11:19 6% ` Juan Manuel Macías
2024-03-07 15:53 12% ` Juan Manuel Macías
2024-03-07 16:09 6% ` Ihor Radchenko
2024-03-07 16:57 12% ` Juan Manuel Macías
2024-03-07 18:21 12% ` Juan Manuel Macías
2024-03-08 13:58 6% ` Max Nikulin
2024-03-08 15:44 12% ` Juan Manuel Macías
2024-03-08 16:04 6% ` Max Nikulin
2024-03-08 16:15 6% ` Ihor Radchenko
2024-03-08 18:44 12% ` Juan Manuel Macías
2024-03-08 18:57 14% ` Juan Manuel Macías
2024-03-09 11:10 6% ` Max Nikulin
2024-03-09 11:48 12% ` Juan Manuel Macías
2024-03-09 15:24 14% ` Juan Manuel Macías
2024-03-10 7:11 7% ` Max Nikulin
2024-04-09 8:52 1% ` Ihor Radchenko
2024-04-09 10:51 8% ` Max Nikulin
2024-04-09 14:05 ` Ihor Radchenko
2024-04-10 23:00 10% ` Juan Manuel Macías
2024-04-11 12:26 6% ` Ihor Radchenko
2024-04-11 13:47 5% ` Juan Manuel Macías
2024-07-18 6:55 6% ` Ihor Radchenko
2024-07-18 21:04 12% ` Juan Manuel Macías
2024-07-19 13:06 6% ` Ihor Radchenko
2024-04-11 11:06 7% ` Max Nikulin
2024-03-05 0:58 9% [tip] Export to PDF with latexmk 'continuous preview' option Juan Manuel Macías
2024-03-11 9:56 Footnotes on line and not raised Colin Baxter
2024-03-11 10:12 ` Colin Baxter
2024-03-11 11:03 12% ` Juan Manuel Macías
2024-03-22 1:04 11% [bug] Smart quotes: confusion of apostrophe with second level quotes Juan Manuel Macías
2024-03-23 11:38 5% ` Ihor Radchenko
2024-03-23 13:41 6% ` Juan Manuel Macías
2024-03-23 13:49 6% ` Ihor Radchenko
2024-03-23 15:42 6% ` Juan Manuel Macías
2024-03-24 9:55 6% ` Ihor Radchenko
2024-04-11 10:49 7% inline-special-block: part2 Max Nikulin
2024-04-11 11:08 6% ` Link to the repository (Re: inline-special-block: part2) Max Nikulin
2024-09-11 17:25 Customize list of blocks that use "\footnotemark" in `org-latex-footnote-reference' 8dcc
2024-09-12 10:18 12% ` Juan Manuel Macías
2024-10-06 10:39 #12 [[bbb:OrgMeetup]] on Wed, Oct 9, 19:00 UTC+3 Ihor Radchenko
2024-10-26 9:50 1% ` [BLOG] " Ihor Radchenko
2024-11-06 17:43 13% News about TeX engines and the latest release of LaTeX Juan Manuel Macías
2024-12-06 19:25 [ANN] Tomorrow at EmacsConf 2024: The Future of Org Ihor Radchenko
2024-12-09 19:09 1% ` Ihor Radchenko
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).