* Re: org-mode export to (latex) PDF
2021-07-16 16:56 5% ` Maxim Nikulin
@ 2021-07-16 18:34 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-16 18:34 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Maxim Nikulin writes:
> I think that low level implementation in browser or in some underlying
> library is much faster
>
> <dl>
> <dt>LM Roman 12</dt>
> <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
> <dt>LM Roman 12, CMU Serif</dt>
> <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
> </dl>
They are two different scenarios: web publishing and book typesetting
(Donald Knuth in the TexBook refers to TeX as: "...a new typesetting
system intended for the creation of beautiful books [...] you will be
telling a computer exactly how the manuscript is to be transformed into
pages whose typographic quality is comparable to that of the world's
finest printers"). LuaTeX, like the rest of TeX engines, is a highly
refined typesetting system, the digital evolution of the mechanical
printing press and the art of typographers. Its goal is printing press
instead of web browsers. All decisions regarding the chosen typefaces
should be taken before. When I prepare a book design, all those
decisions I take them before, and it takes time to test and calibrate
typefaces: choose the font family, or font family groups for certain
languages. Mixing fonts is not trivial for professional typography. This
is not the scenario you describe, nor is it necessary to ensure
readability in multiple browsers with "fallback fonts" for missed
glyphs. In TeX ecosystem it makes no sense (it can be done, anyway[1])
to add fallback fonts to ensure all characters are rendered by their
corresponding glyphs. I insist: they are two orthogonal scenarios and
two diametrically opposed design concepts.
If the font I want to use lacks certain glyphs, I can take various
decisions, depending on the glyphs I need. If I lack only certain
diacritics, often with some Lua code it is enough for me (some Lua is
also usually useful to adjust the position of combining diacritical
marks without editing the font with fontforge and add a 'mark' or
'marktomark' tag). But, generally, if a font doesn't have the glyphs I
need, I just don't use it. The same is true in the case of small caps.
If a font does not have small caps, you should never use those horrible
and illegible synthesized small caps from DTP programs ...
In LuaTeX and XeTeX you can define at high level, for example, your own
hybrid font families. If I want to use the GFS Porson as italics from
another font, a Didot typeface for example, I can do this:
\newfontfamily\mygreek{GFS Didot Classic}
[Script=Greek,ItalicFont=GFS Porson,ItalicFeatures={Scale=.90}]
\emfontdeclare{\itshape,\upshape}
\mygreek
γίγνονται παῖδες δύο, \emph{πρεσβύτερος} μὲν Ἀρταξέρξης
[1] If you want to have fallback fonts, you can also do it in
LuaTeX by adding some Lua code:
https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
(anyway, I insist that combining glyphs is something you must
be done with care)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: org-mode export to (latex) PDF
2021-07-15 19:40 9% ` Juan Manuel Macías
@ 2021-07-16 16:56 5% ` Maxim Nikulin
2021-07-16 18:34 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-16 16:56 UTC (permalink / raw)
To: emacs-orgmode
On 16/07/2021 02:40, Juan Manuel Macías wrote:
> Maxim Nikulin writes:
>
>> In CSS it is possible to specify a list of fonts and a glyph is taken
>> from the first font where it is present. Despite particular fonts have
>> limited coverage, I see wide range of Unicode characters on web pages,
>> that is why I am almost sure that system font libraries combine fonts.
>
> In LuaTeX you can associate a font family to a range or a group of
> characters.
>
> texto = unicode.utf8.gsub ( text, "([\u{e000}-\u{f8ff}])", "\\puatext{%1}" )
I expect it is terribly inefficient for long spans of text in particular
language. Command should not be per-character, preferably per-paragraph
or at least per-word
"([\u{e000}-\u{f8ff}]+)"
However maybe you just do not use sequences of symbols from private use
area.
I think that low level implementation in browser or in some underlying
library is much faster
<dl>
<dt>LM Roman 12</dt>
<dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
<dt>LM Roman 12, CMU Serif</dt>
<dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
</dl>
^ permalink raw reply [relevance 5%]
* Re: org-mode export to (latex) PDF
@ 2021-07-15 19:40 9% ` Juan Manuel Macías
2021-07-16 16:56 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-15 19:40 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Maxim Nikulin writes:
> In CSS it is possible to specify a list of fonts and a glyph is taken
> from the first font where it is present. Despite particular fonts have
> limited coverage, I see wide range of Unicode characters on web pages,
> that is why I am almost sure that system font libraries combine fonts.
In LuaTeX you can associate a font family to a range or a group of
characters. In a book I typesetted some time ago I used the Cardo font
to represent the characters for Private Use Area.
\newfontfamily\cardo{Cardo} % a fontspec command
\def\puatext#1{{\cardo #1}}
\begin{luacode*}
function my_pua (text)
texto = unicode.utf8.gsub ( text, "([\u{e000}-\u{f8ff}])", "\\puatext{%1}" )
return text
end
\end{luacode*}
\newcommand\activatepuatext{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , my_pua , "my_pua" )}}
\AtBeginDocument{\activatepuatext}
(I add a simple substitution to the callback `process_imput_buffer'
[see: http://wiki.luatex.org/index.php/Callbacks], but these kinds of
overrides can also be do from Org using a custom filter).
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-mode export to (latex) PDF
@ 2021-07-15 12:06 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-15 12:06 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> Stefan Nobis <stefan-ml@snobis.de> writes:
>> But maybe we could assemble a list of good (enough) fonts for
>> different languages/scripts and provide a default setup in Org for
>> LaTeX export, that sets a proper font for the chosen document
>> language?
> I think such a list would be a really good addition to worg.
I think it's a great idea. Some resources on fonts and languages that
may be useful:
- The LaTeX Font Catalogue (https://tug.org/FontCatalogue/) is pretty
complete and includes a lot of high quality fonts, with coverage for
many languages. The fonts are from diverse origins, for example the
excellent fonts for Greek and Latin alphabets from the Greek Font
Society, the TeX Gyre project fonts, etc.
- To get quick information from an otf font (otf features, Unicode
ranges, scripts, glyphs, etc.) otfinfo is very useful
(https://man.archlinux.org/man/otfinfo.1.en). But the more powerful
tool in this regard is fontforge (https://fontforge.org/en-US/), which
is not only a complete professional font editor (and free as in
freedom) but can also be used by everyone to audit all aspects from a
font: glyphs, metadata, otf features, languages, scripts, ranges, etc.
- There are specialized fonts in a wide coverage of ranges and scripts,
but many are low-quality or proprietary. Google's Noto Fonts ensure at
least a reasonably complete coverage: I use them only for experiments
(or for ensure certain "rare" scripts in Emacs buffers, as Linear B or
Gothic), but they can also be used within a document.
- Finally, in case anyone is interested, I also wrote for my personal
use a Helm source to list all system font families and insert the
family name into a LaTeX document with the syntax of fontspec or Babel
("\babelfont", which is a frontend for fontspec).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
2021-07-14 17:30 3% ` Maxim Nikulin
@ 2021-07-14 19:29 9% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-14 19:29 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Maxim Nikulin writes:
> It perfectly suits for e.g. a book when camera ready variant is
> required. For routine notes it is better to keep from defaults as
> minimal as possible to minimize problems that may arise a decade
> later. I would prefer to avoid Linux Libertine if I am going to send
> source file to a colleague having another OS.
Linux Libertine (otf version) is included in TeX live. Indeed TeX live
includes a extensive catalog of otf and ttf fonts to be used in LuaTeX
or XeTeX:
https://tug.org/FontCatalogue/opentypefonts.html
As for the original topic of this thread, I am not aware of Japanese
nor of its typographic norms, but it may be interesting to take a look
at the luatexja package: https://ctan.org/pkg/luatexja?lang=en
As for LuaTeX, I think this engine has been a great revolution within
the TeX ecosystem, to the point that it is setting the standard of
everything that is coming new and what is to come. I guess that LuaTeX
will be the natural replacement for pdfTeX (in fact, LuaTeX evolved from
pdfTeX and also took elements from another lesser known, experimental
TeX engine, Omega, which was the first attempt, quite avant-garde, to
create a TeX engine totally Unicode based:
https://en.wikipedia.org/wiki/Omega_(TeX).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-mode export to (latex) PDF
@ 2021-07-14 17:30 3% ` Maxim Nikulin
2021-07-14 19:29 9% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Maxim Nikulin @ 2021-07-14 17:30 UTC (permalink / raw)
To: emacs-orgmode
On 14/07/2021 13:44, Stefan Nobis wrote:
>
> The main point: utf8x and the associated package ucs are not
> maintained for quite some time (utf8x seems to be last changed in
> 2004) and as far as I understand have always been more of a workaround
> than a solution. But I'm not an expert in this regard.
>
> Nowadays the LaTeX kernel and input encodings like (plain) utf8 are
> much more powerful and extensible and do play much better with other
> packages.
I was unlucky to notice the utf8x option when ≠ character was discussed
on this mail list in the context of pseudocode listings. I am afraid,
year 2004 is impressive in other sense than you expected. "Better"
solution still unable to handle ≠ (unlike deprecated one). Actually
necessity to explicitly specify several fonts reminds me end of previous
century when Cyrillic fonts was not in default package set and required
manual adjustment of config files (not to mention missed support in
babel and inputenc, so several partially incompatible variants were used
at that time).
> You need to specify all fonts that you want to use and that deviate
> from the default (Latin Modern in the case of lualatex). How else
> should the system now that you want something else?
There are cm-super fonts for at least of 15 years. OK, they are Type1,
not otf or ttf and conversion from metafont was not lossless. (Actually
the only real problem I noticed is that some rare printers ignore
hairlines.) Why is the Latin Modern family used if CMU is available?
Nowadays most of applications have no problem with wide range of Unicode
characters. However it is a kind of trade-off to preserve traditional
Computer Modern font (a kind of feature of TeX) or to pick a system font
with more characters.
> The package "unicode-math" should always be used with lualatex and
> xelatex, in order to support unicode math input.
Thank you for the hint. Do you think Org should use it by default? Are
there any caveats?
> In your minimal example neither polyglossia nor babel are required
They are almost unavoidable in any real document unless it is preview of
e.g. particular equation.
On 14/07/2021 00:53, Juan Manuel Macías wrote:> And here I add that
feature to Linux Libertine font:
>
> \setmainfont{Linux Libertine O}[RawFeature=+mysub]
It is wonderful that custom font can be chosen so easily. I was never
brave enough and I did not have strong enough reason to follow lengthy
guides how to use ttf font in latex+dvips+ps2pdf workflow. However
custom fonts are for special documents. It perfectly suits for e.g. a
book when camera ready variant is required. For routine notes it is
better to keep from defaults as minimal as possible to minimize problems
that may arise a decade later. I would prefer to avoid Linux Libertine
if I am going to send source file to a colleague having another OS. I
prefer to do fine tuning at the last stages of preparation of a
document. It is sad that default fonts are often unusable for me.
> For multilingual management I recommend using Babel instead of
> Polyglossia.
I have no experience with polyglossia yet. I added it just because most
of examples for LuaLaTeX or XeLaTeX use it.
TeX takes responsibility for a lot of things and it allows to get rather
pleasant results with minimal efforts due to reasonable defaults. Unlike
Apache FO processor for general formatting. Equations were looking
disgusting in MS Word till ~2010.
This topic started from question concerning multilingual support out of
the box. I can not help with Japanese quotes. However some problems can
be noticed with e.g. (sorry for some raw LaTeX):
---- >8 ----
Test¹ of superscript and ½ fraction.
*«Теорема».* /Пусть/ $α → ∞$ и $\beta \to \infty$.
=Катет= и \textsf{гипотенуза}.
Åå. Text Greek α. µm.
Text utf8x ≠ utf8 and math $8 ≠ x$.
---- 8< -----
Current default in Org is pdflatex. It requires at least adjusting of
fontspec by adding T2A option.
If LuaTeX and XeLaTeX handles Unicode better, is it possible to make any
of them the default option and to leave pdflatex as a fallback? Is it
possible to detect lualatex and xelatex in runtime? I have noticed that
/usr/bin/lualatex belongs to texlive-latex-base package. Originally I
did not have texlive-luatex package installed, so likely lualatex was
rather broken despite presence of the binary in the system.
Should some packages for lualatex and xelatex be added to default list
to minimize user problems and at the same time keeping configuration
safe? (unicode-math, etc.)
Is it possible to provide reasonable defaults for fonts? Since lmodern
is hardcoded in luatex and xetex, it may be done either by some usually
available latex package or by org code and custom variables.
If some defaults can not be determined (e.g. \setmainfont) likely they
should be explicitly mentioned in the org manual.
^ permalink raw reply [relevance 3%]
* Re: org-mode export to (latex) PDF
@ 2021-07-13 17:53 8% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-13 17:53 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Maxim Nikulin writes:
> I do not know if new engines allows to get list of available fonts and
> to choose a set of fonts with better coverage than lmodern.
LuaTeX and XeTeX use harfbuzz as OpenType rendering engine. On
LuaLaTeX and XeLaTeX you must use the fontspec package
(https://www.ctan.org/pkg/fontspec) to load otf or ttf fonts and add
opentype features. It is very powerful and its interface is very simple
to use. XeTeX has access to system fonts. LuaTeX has access to both
system fonts and any font you want to declare, simply by adding the
path.
For example:
\setmainfont{Palatino Linotype}[Ligatures=NoCommon,Numbers=Lowercase]
With LuaTeX you can also define new opentype features on the fly using
scripts in Lua, via the function fonts.handlers.otf.addfeature
For example, here I define a character substitution:
\directlua{
fonts.handlers.otf.addfeature{
name = "mysub",
type = "substitution",
data = {
periodcentered = "anoteleia",
},
}
}
And here I add that feature to Linux Libertine font:
\setmainfont{Linux Libertine O}[RawFeature=+mysub]
For multilingual management I recommend using Babel instead of
Polyglossia. You can, for example, assign with Babel families from fonts
and language definitions to non-Latin scripts (Cyrillic, Greek,
Devanagari, Arabic, etc.). For example
\babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
\babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
\babelfont[russian]{rm}[%
Numbers=Lowercase]{Linux Libertine O}
\babelfont[greek]{rm}[%
Numbers=Lowercase]{Old Standard}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
2021-07-10 17:40 8% ` Juan Manuel Macías
@ 2021-07-12 3:09 4% ` Tim Cross
0 siblings, 0 replies; 200+ results
From: Tim Cross @ 2021-07-12 3:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Tim Cross writes:
>
>> Just FYI for those who don't know, you can use the org-latex-classes
>> variable to define your own pseudo document classes, possibly using the
>> DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
>> settings. So for example, you can add the babel or other packages you
>> want and either make that the 'default' class or specify which class you
>> want with the #+LATEX_CLASS header. I use this quite a bit because then
>> I don't have to remember which LATEX_HEADER lines to include in the
>> document, the specific option settings etc. I don't need support for
>> multilingual documents, but I do have a number of 'special' documents
>> (such as one with colours, logos and specific fonts for an employer to
>> match their 'style guide'. I also have ones for generating project
>> documents, letters, meeting minutes etc. They all use various different
>> Latex extensions (particularly ones which don't mix well and cannot be
>> included with other packages).
>
> I agree. `Org-latex-classes' is a very good option for create LaTeX
> templates, and I have a few classes defined as well. The problem is when
> you need really long and complex preambles (it is not a problem that
> most users may have, though). In a recent project (a book) my preamble
> had about 2000 lines (including macros and environments defined by me,
> some functions in Lua for LuaTeX, etc.). With long or complex preambles
> it's a bit awkward to do it in Elisp and org-latex-classes. In that
> case, I usually write the preamble to an Org document and generate a
> *.tex file using org-babel-tangle. Then I include that file at the very
> beginning of my document with an \input macro. On the LaTeX side, there
> is also the option to create your own sty file:
> https://tex.stackexchange.com/questions/77/how-to-make-a-standard-preamble-into-a-package
>
> As an alternative to #+LaTeX_Header you can also include the
> preamble in the Org document itself using a LaTeX block:
>
> #+NAME: preamble
> #+begin_src latex :exports none
>
> ... a lot of latex code
> #+end_src
>
> and then, in another block with the keyword `:noweb':
>
> #+begin_src latex :noweb yes :results raw
> ,#+LaTeX_Header: <<preamble>>
> #+end_src
>
> (This useful trick came from Charles Berry in this thread:
> https://orgmode.org/list/225A3D45-0F47-4FFE-8BBA-F023CB8C9A6C@health.ucsd.edu/#r)
>
Yes, I do pretty much the same. I have a number of personal *.sty files
which contain a lot of additional setup information which would be
difficult to include directly in org-latex-classes.
I have also used the idea of latex blocks and tangling, especially when
working out the details for a specific latex configuration. Once I have
it working, unless this is strictly a 'one off', I will typically move
that information into a *.sty file or similar. I also use a couple of
templates via either company or yasnipet which I use for some org
documents which have a 'standard' outline and header setup.
I find the combination of these techniques makes it easy to create new
documents and maintain existing ones. I have a terrible memory for the
low level configuration stuff, so the more I can rely on pre-defined
configurations, the better. The nice thing about how I have things setup
now is that it seems pretty robust. I rarely encounter any problems when
updating org and am able to get 'up and running' on a new system fairly
quickly. The biggest challenge I've had lately has been my move from my
own standard configuration to using spacemacs. It has taken a bit of
work to get spacemacs to work the way I want, but I have grown to love
the modal editing of evil mode (probably because VI was my first
editor). I'm now very happy with my configuration and workflow.
--
Tim Cross
^ permalink raw reply [relevance 4%]
* Re: org-mode export to (latex) PDF
@ 2021-07-10 19:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 19:24 UTC (permalink / raw)
To: Jonathan McHugh; +Cc: orgmode, Jason Ross
Hi Jonathan,
Jonathan McHugh writes:
> I recall there was momentum re exporting to Context from Orgmode, hopefully a solid implementation is available.
It seems that a member of this mailing list, Jason Ross, is working on a
ConTeXt backend for org: https://github.com/Jason-S-Ross/ox-context/
ConTeXt is a TeX format that uses the LuaTeX engine, but the same
results can be achieved using LaTeX format with the LuaLaTeX version.
Of course, LuaTeX, the TeX engine that runs behind ConTeXt and LuaLaTeX,
was born with a clear multilingual "vocation", and it is the natural
evolution of pdfTeX.
Another option for multilingual documents is to use xeTeX engine and
xeLaTeX format.
ConTeXt is very interesting (a more modular approach, and it is not extended by
macro packages like LaTeX, so that the user already has everything inside
almost out of the box). The problem is that it's not as documented as LaTeX.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:59 4% ` Tim Cross
@ 2021-07-10 17:40 8% ` Juan Manuel Macías
2021-07-12 3:09 4% ` Tim Cross
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-10 17:40 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> Just FYI for those who don't know, you can use the org-latex-classes
> variable to define your own pseudo document classes, possibly using the
> DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
> settings. So for example, you can add the babel or other packages you
> want and either make that the 'default' class or specify which class you
> want with the #+LATEX_CLASS header. I use this quite a bit because then
> I don't have to remember which LATEX_HEADER lines to include in the
> document, the specific option settings etc. I don't need support for
> multilingual documents, but I do have a number of 'special' documents
> (such as one with colours, logos and specific fonts for an employer to
> match their 'style guide'. I also have ones for generating project
> documents, letters, meeting minutes etc. They all use various different
> Latex extensions (particularly ones which don't mix well and cannot be
> included with other packages).
I agree. `Org-latex-classes' is a very good option for create LaTeX
templates, and I have a few classes defined as well. The problem is when
you need really long and complex preambles (it is not a problem that
most users may have, though). In a recent project (a book) my preamble
had about 2000 lines (including macros and environments defined by me,
some functions in Lua for LuaTeX, etc.). With long or complex preambles
it's a bit awkward to do it in Elisp and org-latex-classes. In that
case, I usually write the preamble to an Org document and generate a
*.tex file using org-babel-tangle. Then I include that file at the very
beginning of my document with an \input macro. On the LaTeX side, there
is also the option to create your own sty file:
https://tex.stackexchange.com/questions/77/how-to-make-a-standard-preamble-into-a-package
As an alternative to #+LaTeX_Header you can also include the
preamble in the Org document itself using a LaTeX block:
#+NAME: preamble
#+begin_src latex :exports none
... a lot of latex code
#+end_src
and then, in another block with the keyword `:noweb':
#+begin_src latex :noweb yes :results raw
,#+LaTeX_Header: <<preamble>>
#+end_src
(This useful trick came from Charles Berry in this thread:
https://orgmode.org/list/225A3D45-0F47-4FFE-8BBA-F023CB8C9A6C@health.ucsd.edu/#r)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
2021-07-10 13:52 10% ` Juan Manuel Macías
2021-07-10 14:13 2% ` Jean-Christophe Helary
@ 2021-07-10 16:13 6% ` Maxim Nikulin
1 sibling, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-10 16:13 UTC (permalink / raw)
To: emacs-orgmode
On 10/07/2021 20:52, Juan Manuel Macías wrote:
>
> I agree with you that Org should have multilingual support. A few months
> ago I started this thread here, with some proposals:
> https://orgmode.org/list/87o8d95pvo.fsf@posteo.net/
I tried to draw more attention to support of locale-aware formatting of
numbers on emacs-devel mail list. Certainly a question concerning
mixed-language buffers were raised. Result of attempts to discuss text
properties to mark regions having alternative languages was just "Which
property will help here? we don't have such properties" from Eli Zaretskii.
> > Jean-Christophe Helary writes:
>
>> I guess it is an issue with the Latex backend and could have been
>> solved with the proper Latex settings, but it seems weird that the
>> default settings do not allow for out-of-the-box multilingual
>> support.
(add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))
might help. I am not an active LaTeX user last years, so I am unaware
whether \usepackage[utf8x]{inputenc} has any drawbacks.
^ permalink raw reply [relevance 6%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:38 8% ` Juan Manuel Macías
@ 2021-07-10 14:59 4% ` Tim Cross
2021-07-10 17:40 8% ` Juan Manuel Macías
2021-07-10 15:01 1% ` Jean-Christophe Helary
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-07-10 14:59 UTC (permalink / raw)
To: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
>
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
>
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
>
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
>
> #+LaTeX_Header: \usepackage[several langs]{babel}
>
> @@latex:\begin{otherlanguage*}{german}@@
>
> ... some text in german ...
>
> @@latex:\end{otherlanguage*}@@
>
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
>
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}
Just FYI for those who don't know, you can use the org-latex-classes
variable to define your own pseudo document classes, possibly using the
DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
settings. So for example, you can add the babel or other packages you
want and either make that the 'default' class or specify which class you
want with the #+LATEX_CLASS header. I use this quite a bit because then
I don't have to remember which LATEX_HEADER lines to include in the
document, the specific option settings etc. I don't need support for
multilingual documents, but I do have a number of 'special' documents
(such as one with colours, logos and specific fonts for an employer to
match their 'style guide'. I also have ones for generating project
documents, letters, meeting minutes etc. They all use various different
Latex extensions (particularly ones which don't mix well and cannot be
included with other packages).
The LATEX_HEADER: options are useful for 'one off' documents, but become
a real pain to include all the time. however, I see this quite a lot and
just wanted to highlight that when you need to customise the latex
process, you do have these other options which can be very useful and I
suspect would be good for things like setting up support for
multilingual environments. I also use luatex rather than the default
plain 'latex' (mainly because of better/more flexible font support).
I could be wrong as I've not looked at this in a long time, but one of
the problems with multilingual support in Latex was that it was somewhat
'fragile'. There were a number of packages which did not work well when
combined with certain fonts required for multilingual support and (from
memory) issues with hyphenation and packages which extended some
environments. While it was generally possible to tweak things to get
them to work, it was somewhat challenging to get them to work 'across
the board'. I don't know if this is still the case as it has been some
years incde I've needed to dig into Latex (mainly because now I do
almost everything just in org mode and don't need to!). This, combined
with a smaller user base for multilingual documents, may partly explain
the difficulty in gaining traction in this area. I do recall that
getting a stable general latex environment working for org exports was
somewhat challenging originally.
^ permalink raw reply [relevance 4%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 14:59 4% ` Tim Cross
@ 2021-07-10 15:01 1% ` Jean-Christophe Helary
1 sibling, 0 replies; 200+ results
From: Jean-Christophe Helary @ 2021-07-10 15:01 UTC (permalink / raw)
To: orgmode
> On Jul 10, 2021, at 23:38, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
>
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
Thank you very much Juan.
I understand that Latex has excellent support for multilingual files. I use it sometimes for very complex multilingual texts (ancient Japanese and French for ex).
But with UTF-8 being ubiquitous on computers nowadays, I really can't be bothered to have to type all those sequences to have org-mode properly export to PDF something that it exports perfectly well to ODT without requiring anything extra.
Which is the reason why I was wondering about a "generic" default setting where the conversion engine behind org could just use a default multilingual package and a default "wide enough" generic font. I really mean a "good enough" export where all the characters are visible, nothing fancy.
Jean-Christophe
>
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
>
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
>
> #+LaTeX_Header: \usepackage[several langs]{babel}
>
> @@latex:\begin{otherlanguage*}{german}@@
>
> ... some text in german ...
>
> @@latex:\end{otherlanguage*}@@
>
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
>
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}
>
> #+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
> #+begin_quote
> Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
> Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
> sich in ihr vorgesetzt, sowie über die Veranlassungen und das
> Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
> Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
> einer philosophischen Schrift nicht nur überflüssig, sondern um der
> Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
> #+end_quote
>
> Best regards,
>
> Juan Manuel
>
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
^ permalink raw reply [relevance 1%]
* Re: org-mode export to (latex) PDF
2021-07-10 14:13 2% ` Jean-Christophe Helary
@ 2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 14:59 4% ` Tim Cross
2021-07-10 15:01 1% ` Jean-Christophe Helary
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 14:38 UTC (permalink / raw)
To: Jean-Christophe Helary; +Cc: orgmode
Hi Jean-Christophe,
Jean-Christophe Helary writes:
> I had given up on Latex because mixing languages sounded like a huge
> pain in the butt but I see that without some org-level infrastructure
> it is not possible to achieve much when exporting to Latex/PDF (unless
> I missed something).
Well, LaTeX has excellent (typographic and orthotypographic)
multilingual support, using the babel or polyglossia packages. I
especially recommend babel:
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
And LaTeX also has very good support for oriental languages or languages
with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
also use opentype fonts and opentype features.
The problem is how to translate that from Org --in an org-centric way--
to LaTeX. Currently, you can apply LaTeX commands for multilingual
management directly in your Org document. For example:
#+LaTeX_Header: \usepackage[several langs]{babel}
@@latex:\begin{otherlanguage*}{german}@@
... some text in german ...
@@latex:\end{otherlanguage*}@@
Recently, I submitted a patch here that allows adding LaTeX attributes
to `quote' blocks. Then, you could do something like this:
#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}
#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
sich in ihr vorgesetzt, sowie über die Veranlassungen und das
Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
einer philosophischen Schrift nicht nur überflüssig, sondern um der
Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
#+end_quote
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: org-mode export to (latex) PDF
2021-07-10 13:52 10% ` Juan Manuel Macías
@ 2021-07-10 14:13 2% ` Jean-Christophe Helary
2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 16:13 6% ` Maxim Nikulin
1 sibling, 1 reply; 200+ results
From: Jean-Christophe Helary @ 2021-07-10 14:13 UTC (permalink / raw)
To: orgmode
> On Jul 10, 2021, at 22:52, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I guess it is an issue with the Latex backend and could have been solved with the proper Latex settings, but it seems weird that the default settings do not allow for out-of-the-box multilingual support.
>
> I agree with you that Org should have multilingual support. A few months
> ago I started this thread here, with some proposals:
> https://orgmode.org/list/87o8d95pvo.fsf@posteo.net/
Juan,
That's a very interesting proposal. Thank you for the reference.
I had given up on Latex because mixing languages sounded like a huge pain in the butt but I see that without some org-level infrastructure it is not possible to achieve much when exporting to Latex/PDF (unless I missed something).
So I guess I'll just keep my current workflow for now, with ODT as my "pivot" format.
Thank you again, Juan.
--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
^ permalink raw reply [relevance 2%]
* Re: org-mode export to (latex) PDF
@ 2021-07-10 13:52 10% ` Juan Manuel Macías
2021-07-10 14:13 2% ` Jean-Christophe Helary
2021-07-10 16:13 6% ` Maxim Nikulin
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 13:52 UTC (permalink / raw)
To: Jean-Christophe Helary; +Cc: orgmode
Hi Jean-Christophe,
Jean-Christophe Helary writes:
> I guess it is an issue with the Latex backend and could have been solved with the proper Latex settings, but it seems weird that the default settings do not allow for out-of-the-box multilingual support.
I agree with you that Org should have multilingual support. A few months
ago I started this thread here, with some proposals:
https://orgmode.org/list/87o8d95pvo.fsf@posteo.net/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] [BUG] Bad fontification in full displayed links
2021-07-10 1:50 6% ` Ihor Radchenko
@ 2021-07-10 12:12 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-10 12:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Hi Ihor,
Ihor Radchenko writes:
> Why not just (add-face-text-property start end face-property)?
You are right, I think that solution is much simpler. I attach a
new patch and I have included your name in the commit message, for the
suggestion. Thanks!
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-prevent-partial-fontification-when-a-link-is-.patch --]
[-- Type: text/x-patch, Size: 1114 bytes --]
From 0e31ba4ce76e436712285b163b8595b0a973da94 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Jul 2021 13:53:44 +0200
Subject: [PATCH] org.el: prevent partial fontification when a link is
displayed full
* lisp/org.el (org-activate-links): apply `face-property' variable in
other cases when handle invisible parts in bracket
links: `(add-face-text-property start end face-property)' suggestion
from Ihor Radchenko
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..eca12a5e7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5228,7 +5228,7 @@ This includes angle, plain, and bracket links."
'org-link))
properties)))
(add-text-properties start visible-start hidden)
- (add-face-text-property visible-start visible-end face-property)
+ (add-face-text-property start end face-property)
(add-text-properties visible-start visible-end properties)
(add-text-properties visible-end end hidden)
(org-rear-nonsticky-at visible-start)
--
2.32.0
^ permalink raw reply related [relevance 10%]
* Re: [PATCH] [BUG] Bad fontification in full displayed links
2021-07-09 9:15 10% [PATCH] [BUG] Bad fontification in full displayed links Juan Manuel Macías
@ 2021-07-10 1:50 6% ` Ihor Radchenko
2021-07-10 12:12 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-07-10 1:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> As a possible fix I'm attaching this patch.
> + (add-face-text-property start visible-start face-property)
> + (add-face-text-property visible-start visible-end face-property)
> + (add-face-text-property visible-end end face-property)
Why not just (add-face-text-property start end face-property)?
Best,
Ihor
^ permalink raw reply [relevance 6%]
* [PATCH] [BUG] Bad fontification in full displayed links
@ 2021-07-09 9:15 10% Juan Manuel Macías
2021-07-10 1:50 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-09 9:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
Hi,
To reproduce the bug:
1. Put some link: [[target][description]]
2. Run `org-toggle-link-display'
As a possible fix I'm attaching this patch.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-prevent-partial-fontification-link-display-full.patch --]
[-- Type: text/x-patch, Size: 1252 bytes --]
From caf32a7e1fb1b4bddfa011520f5403d5b6b19ddd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 8 Jun 2021 01:55:02 +0200
Subject: [PATCH] org.el: prevent partial fontification when a link is
displayed full
* lisp/org.el (org-activate-links): apply `face-property' variable in
other cases when handle invisible parts in bracket links
---
lisp/org.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..b55d8798a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5224,9 +5224,11 @@ This includes angle, plain, and bracket links."
,(or (org-link-get-parameter type :display)
'org-link))
properties)))
+ (add-face-text-property start visible-start face-property)
(add-text-properties start visible-start hidden)
- (add-face-text-property visible-start visible-end face-property)
+ (add-face-text-property visible-start visible-end face-property)
(add-text-properties visible-start visible-end properties)
+ (add-face-text-property visible-end end face-property)
(add-text-properties visible-end end hidden)
(org-rear-nonsticky-at visible-start)
(org-rear-nonsticky-at visible-end)))
--
2.31.1
^ permalink raw reply related [relevance 10%]
* Re: convert subtree or nested list to table
2021-07-06 12:56 8% ` Juan Manuel Macías
2021-07-07 6:18 0% ` Uwe Brauer
@ 2021-07-07 21:16 6% ` Matt Price
1 sibling, 0 replies; 200+ results
From: Matt Price @ 2021-07-07 21:16 UTC (permalink / raw)
To: Juan Manuel Macías, Org Mode
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
thank you Juan Mnauel. I'm testing it out, but I do wonder if I would
really rather work with lists and some CSS!
On Tue, Jul 6, 2021 at 8:56 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi Matt, sorry for the slow reply...
>
> Matt Price writes:
>
> > I'd love to try that, thanks. I think it would be really helpful.
> > Much appreciated!
>
> Some previous caveats:
>
> - *The code is very raw*. I wrote it almost as a "proof of concept" for
> my personal use, therefore it is quite improvable. In any case, it
> works (but i don't know if it will help you get what you want...).
>
> - The attached example is optimized to export to LaTeX. Use the tabularx
> environment, which is ideal for tables with a lot of textual content.
>
> - As for the code, there are two basic functions:
> `my-org/edit-table-cell' and
> `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
> you have to write something in that cell first.
>
> - The basic idea is that within each cell, the content is a single line
> (unfilled). In the edit buffer, the content is filled. There are two
> macros to indicate a line break and a paragraph end: {{{nl}}} and
> {{{par}}}. In the edit buffer you can put line breaks and white lines,
> but all of that is lost inside the cell once saved (all is a single
> line), so those macros are needed to indicate line or paragraph breaks
> (in LaTeX).
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 1901 bytes --]
^ permalink raw reply [relevance 6%]
* Re: convert subtree or nested list to table
2021-07-07 18:27 10% ` Juan Manuel Macías
@ 2021-07-07 18:44 0% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-07-07 18:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Uwe, thanks for testing the code.
> Uwe Brauer writes:
>> I am running (a couple of week old) GNU emacs master and org-mode git
>> master. I even restarted my emacs session
>>
>> What do I miss?
> I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
> case everything works as expected (taking into account that with this
> code of mine the expectations have to be modest :-).
Could also be some of my pkg file. I might check it
starting emacs -q
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: convert subtree or nested list to table
2021-07-07 6:18 0% ` Uwe Brauer
@ 2021-07-07 18:27 10% ` Juan Manuel Macías
2021-07-07 18:44 0% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-07 18:27 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe, thanks for testing the code.
Uwe Brauer writes:
> I am running (a couple of week old) GNU emacs master and org-mode git
> master. I even restarted my emacs session
>
> What do I miss?
I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
case everything works as expected (taking into account that with this
code of mine the expectations have to be modest :-).
I will do a test on Emacs master...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: convert subtree or nested list to table
2021-07-06 12:56 8% ` Juan Manuel Macías
@ 2021-07-07 6:18 0% ` Uwe Brauer
2021-07-07 18:27 10% ` Juan Manuel Macías
2021-07-07 21:16 6% ` Matt Price
1 sibling, 1 reply; 200+ results
From: Uwe Brauer @ 2021-07-07 6:18 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Matt, sorry for the slow reply...
> Matt Price writes:
>> I'd love to try that, thanks. I think it would be really helpful.
>> Much appreciated!
> Some previous caveats:
> - *The code is very raw*. I wrote it almost as a "proof of concept" for
> my personal use, therefore it is quite improvable. In any case, it
> works (but i don't know if it will help you get what you want...).
> - The attached example is optimized to export to LaTeX. Use the tabularx
> environment, which is ideal for tables with a lot of textual content.
Sorry for jumping into that thread. I could not resist downloading your
code and trying it out.
> - As for the code, there are two basic functions:
> `my-org/edit-table-cell' and
that worked.
> `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
> you have to write something in that cell first.
When I changed the text in a cell and called that function I obtained
and error
,----
|
| Debugger entered--Lisp error: (wrong-number-of-arguments #f(compiled-function (arg) (interactive "*P") #<bytecode 0x8df3ba5756afab4>) 2)
| fill-paragraph(nil t)
| (let ((fill-column (point-max)) (emacs-lisp-docstring-fill-column t)) (fill-paragraph nil region))
| unfill-paragraph(t)
| funcall-interactively(unfill-paragraph t)
| call-interactively(unfill-paragraph)
| my-org/kill-edit-table-cell-buffer-and-save()
| funcall-interactively(my-org/kill-edit-table-cell-buffer-and-save)
| call-interactively(my-org/kill-edit-table-cell-buffer-and-save record nil)
| command-execute(my-org/kill-edit-table-cell-buffer-and-save record)
| execute-extended-command(nil "my-org/kill-edit-table-cell-buffer-and-save" "my-org/k")
| funcall-interactively(execute-extended-command nil "my-org/kill-edit-table-cell-buffer-and-save" "my-org/k")
| call-interactively(execute-extended-command nil nil)
| command-execute(execute-extended-command)
|
`----
I am running (a couple of week old) GNU emacs master and org-mode git
master. I even restarted my emacs session
What do I miss?
Regards
Uwe Brauer
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: convert subtree or nested list to table
[not found] ` <CAN_Dec8iqKS+3qvjkYvQxovegnEzqR_rra0Q-ZA9baPz1mXDAA@mail.gmail.com>
@ 2021-07-06 12:56 8% ` Juan Manuel Macías
2021-07-07 6:18 0% ` Uwe Brauer
2021-07-07 21:16 6% ` Matt Price
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-06 12:56 UTC (permalink / raw)
To: Matt Price; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
Hi Matt, sorry for the slow reply...
Matt Price writes:
> I'd love to try that, thanks. I think it would be really helpful.
> Much appreciated!
Some previous caveats:
- *The code is very raw*. I wrote it almost as a "proof of concept" for
my personal use, therefore it is quite improvable. In any case, it
works (but i don't know if it will help you get what you want...).
- The attached example is optimized to export to LaTeX. Use the tabularx
environment, which is ideal for tables with a lot of textual content.
- As for the code, there are two basic functions:
`my-org/edit-table-cell' and
`my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
you have to write something in that cell first.
- The basic idea is that within each cell, the content is a single line
(unfilled). In the edit buffer, the content is filled. There are two
macros to indicate a line break and a paragraph end: {{{nl}}} and
{{{par}}}. In the edit buffer you can put line breaks and white lines,
but all of that is lost inside the cell once saved (all is a single
line), so those macros are needed to indicate line or paragraph breaks
(in LaTeX).
Best regards,
Juan Manuel
[-- Attachment #2: test-tables.org --]
[-- Type: application/vnd.lotus-organizer, Size: 20363 bytes --]
^ permalink raw reply [relevance 8%]
* Re: convert subtree or nested list to table
@ 2021-07-05 20:01 10% ` Juan Manuel Macías
[not found] ` <CAN_Dec8iqKS+3qvjkYvQxovegnEzqR_rra0Q-ZA9baPz1mXDAA@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-05 20:01 UTC (permalink / raw)
To: Matt Price; +Cc: orgmode
Hi Matt,
Matt Price writes:
> I have to write a number of text-heavy documents which need to be
> delivered as tables with wrapped paragraphs in most cells. Working
> directly in table format is pretty arduous and uncomfortable. Has
> anyone ever written a function to accept a list or subtree as input
> and process it into a table?
>
> If anyone has done something similar, I'd love some tips!
Some time ago I wrote some functions for my personal use that allow edit
table cells (with a lot of text and/or paragraphs) in a dedicated
buffer. I don't know if something like that is what you are looking for,
but if you are interested, I can clean up the code a bit and upload it
here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Virtually prefix headlines according to content
2021-06-29 13:53 5% ` John Kitchin
@ 2021-06-29 20:44 0% ` Samuel Wales
0 siblings, 0 replies; 200+ results
From: Samuel Wales @ 2021-06-29 20:44 UTC (permalink / raw)
To: John Kitchin; +Cc: Juan Manuel Macías, Rodrigo Morales, orgmode
along similar lines one possibility is to stick a symbol into the
stars. similar code could also indicate that scheduled and deadline.
On 6/29/21, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> you could use this alternative to just change the display without adding
> the tag:
>
> (org-map-entries (lambda ()
> (looking-at org-heading-regexp)
> (put-text-property (match-beginning 2) (match-end 2) 'display (concat "GH
> " (match-string 2))))
> "+GITHUB={.+}")
>
> There might be some clever way to tie that onto fontlock, or some kind of
> hook to make it also work for entries as you create them.
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Tue, Jun 29, 2021 at 9:35 AM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Rodrigo Morales writes:
>>
>> > What I would like to know is whether it is possible to format a
>> > headline
>> > by taking into consideration the properties it has. For example, in
>> > this
>> > specific scenario, I would like to make all headlines that have a
>> > "GITHUB" to show "GH" before the actual headline (the content would
>> > look
>> > like this).
>>
>> You can define a function with `org-map-entries' that adds (for example)
>> a
>> tag :github: to all headers with the property GITHUB:
>>
>> #+begin_src emacs-lisp
>> (defun add-github-tag ()
>> (interactive)
>> (org-map-entries (lambda ()
>> (save-restriction
>> (save-excursion
>> (org-narrow-to-subtree)
>> (goto-char (point-min))
>> (end-of-line)
>> (insert " :github:"))))
>> "+GITHUB={.+}"))
>>
>> (add-hook 'org-mode-hook #'add-github-tag)
>> #+end_src
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [relevance 0%]
* Re: Virtually prefix headlines according to content
2021-06-29 13:34 10% ` Juan Manuel Macías
@ 2021-06-29 13:53 5% ` John Kitchin
2021-06-29 20:44 0% ` Samuel Wales
0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2021-06-29 13:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Rodrigo Morales
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]
you could use this alternative to just change the display without adding
the tag:
(org-map-entries (lambda ()
(looking-at org-heading-regexp)
(put-text-property (match-beginning 2) (match-end 2) 'display (concat "GH
" (match-string 2))))
"+GITHUB={.+}")
There might be some clever way to tie that onto fontlock, or some kind of
hook to make it also work for entries as you create them.
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Tue, Jun 29, 2021 at 9:35 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Rodrigo Morales writes:
>
> > What I would like to know is whether it is possible to format a headline
> > by taking into consideration the properties it has. For example, in this
> > specific scenario, I would like to make all headlines that have a
> > "GITHUB" to show "GH" before the actual headline (the content would look
> > like this).
>
> You can define a function with `org-map-entries' that adds (for example) a
> tag :github: to all headers with the property GITHUB:
>
> #+begin_src emacs-lisp
> (defun add-github-tag ()
> (interactive)
> (org-map-entries (lambda ()
> (save-restriction
> (save-excursion
> (org-narrow-to-subtree)
> (goto-char (point-min))
> (end-of-line)
> (insert " :github:"))))
> "+GITHUB={.+}"))
>
> (add-hook 'org-mode-hook #'add-github-tag)
> #+end_src
>
> Best regards,
>
> Juan Manuel
>
>
>
[-- Attachment #2: Type: text/html, Size: 2679 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Virtually prefix headlines according to content
@ 2021-06-29 13:34 10% ` Juan Manuel Macías
2021-06-29 13:53 5% ` John Kitchin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-29 13:34 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Rodrigo Morales writes:
> What I would like to know is whether it is possible to format a headline
> by taking into consideration the properties it has. For example, in this
> specific scenario, I would like to make all headlines that have a
> "GITHUB" to show "GH" before the actual headline (the content would look
> like this).
You can define a function with `org-map-entries' that adds (for example) a
tag :github: to all headers with the property GITHUB:
#+begin_src emacs-lisp
(defun add-github-tag ()
(interactive)
(org-map-entries (lambda ()
(save-restriction
(save-excursion
(org-narrow-to-subtree)
(goto-char (point-min))
(end-of-line)
(insert " :github:"))))
"+GITHUB={.+}"))
(add-hook 'org-mode-hook #'add-github-tag)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Export Org mode files to (gag, barf) MS Office?
@ 2021-06-26 15:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-26 15:15 UTC (permalink / raw)
To: Brandon Taylor; +Cc: orgmode
Hello,
Brandon Taylor writes:
> I know we’re not supposed to really even TALK about proprietary
> software in FOSS communities like this one, but I can’t help but
> wonder if someone might consider making (an) Emacs plugin(s) that
> allow(s) a user to export Org mode files to Microsoft Office file
> formats such as .docx, .xlsx and the like? Or is/are there already (a)
> plugin(s) in the MELPA that can do this?
You may be interested in the variable `org-odt-preferred-output-format'.
According to the docstring:
"[...] Automatically post-process to this format after exporting to
"odt". Command ‘org-odt-export-to-odt’ exports first to "odt" format and
then uses ‘org-odt-convert-process’ to convert the resulting document to
this format. During customization of this variable, the list of valid
values are populated based on ‘org-odt-convert-capabilities’.[...]"
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: publishing: no default publishing function, or symbol is not defined
2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
@ 2021-06-25 8:38 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-25 8:38 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher, sorry for the slow reply
Christopher W. Ryan writes:
> Any advice for how to get *both* theindex.html and my main document in
> html? So far I can only get one or the other, depending on whether I
> include a non-nil value for a :makeindex option.
I don't understand the question. With the option `:makeindex t' a
document `theindex.inc' is created/updated every time you call
`org-publish-project', and also a document `theindex.org', which
contains the directive `#+INCLUDE: theindex.inc'. This is the document
which is exported to html as an index, along with the rest of the org
documents that you have inside the folder specified in the
`:base-directory' option.
For more info, you can evaluate (info (org) Generating an index)
What is your org-publish configuration?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: An attempt to convert Elfeed entries (with parameters) to Org trees
2021-06-23 14:56 6% ` Ihor Radchenko
@ 2021-06-24 8:02 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-24 8:02 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko writes:
> What about duplicates? If you insert all the feeds from the last few
> months and then update the same headline weeks later, there will overlap
> between elfeed entries.
When I update a headline, all previous feeds are removed, so there is no
possibility of duplicates. As I said, I find this system very useful to
have an overview within Org of the latest updates to certain feeds, such
as new packages uploaded to CTAN. I also have an org-capture template
only for new CTAN packages, in case I see any interesting packages.
I also have a section on CTAN news in my blog about typography and TeX
(in Spanish), and I update it using that method.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: appearance of list as results from evaluating code blocks
2021-06-23 19:43 10% ` Juan Manuel Macías
@ 2021-06-23 20:03 3% ` Johannes Brauer
0 siblings, 0 replies; 200+ results
From: Johannes Brauer @ 2021-06-23 20:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan Manuel,
thanks, that works
Best regards
Johannes
> Am 23.06.2021 um 21:43 schrieb Juan Manuel Macías <maciaschain@posteo.net>:
>
> Hi Johannes,
>
> Johannes Brauer writes:
>
>> Hi!
>> Evaluating a code block containing a list expression using org-babel for elisp or Clojure, for example
>> (list 1 2 3)
>> I get
>> #+RESULTS:
>> | 1 | 2 | 3 |
>> I would prefer
>> #+RESULTS:
>> ( 1 2 3 )
>>
>> Is it possible to get this.
>
> Try
>
> #+begin_src emacs-lisp :results raw
> (list 1 2 3)
> #+end_src
>
> #+RESULTS:
> (1 2 3)
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 3%]
* Re: appearance of list as results from evaluating code blocks
@ 2021-06-23 19:43 10% ` Juan Manuel Macías
2021-06-23 20:03 3% ` Johannes Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-23 19:43 UTC (permalink / raw)
To: Johannes Brauer; +Cc: orgmode
Hi Johannes,
Johannes Brauer writes:
> Hi!
> Evaluating a code block containing a list expression using org-babel for elisp or Clojure, for example
> (list 1 2 3)
> I get
> #+RESULTS:
> | 1 | 2 | 3 |
> I would prefer
> #+RESULTS:
> ( 1 2 3 )
>
> Is it possible to get this.
Try
#+begin_src emacs-lisp :results raw
(list 1 2 3)
#+end_src
#+RESULTS:
(1 2 3)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: An attempt to convert Elfeed entries (with parameters) to Org trees
2021-05-31 10:40 9% An attempt to convert Elfeed entries (with parameters) to Org trees Juan Manuel Macías
@ 2021-06-23 14:56 6% ` Ihor Radchenko
2021-06-24 8:02 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-06-23 14:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi all,
>
> I like to keep up to date with new LaTeX packages that are being
> uploaded to CTAN and I'm subscribed to the CTAN news feed. I always use
> Elfeed to check my subscriptions, but it occurred to me to write a
> function (with org-map-entries) to be able to pass Elfeed entries (with
> certain parameters) to Org trees.
> ...
> If anyone wants to try it, I attach an Org document with the code, which
> is very preliminary, not too fancy and quite improvable. Feedback
> welcome! :-)
What about duplicates? If you insert all the feeds from the last few
months and then update the same headline weeks later, there will overlap
between elfeed entries.
Also, there is built-in org-feed.el.
Finally, I personally save feed entries selectively using
org-capture-ref [1].
[1] https://github.com/yantar92/org-capture-ref
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 19:32 9% ` Juan Manuel Macías
@ 2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-25 8:38 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Christopher W. Ryan via General discussions about Org-mode. @ 2021-06-22 20:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel--
Thanks. I understand no pages in a web document; I thought (hoped?) that
section/subsection numbers, perhaps multiple, would appear next to the
entries in the index. I will try to be more specific with the ! syntax
Any advice for how to get *both* theindex.html and my main document in
html? So far I can only get one or the other, depending on whether I
include a non-nil value for a :makeindex option.
Thanks.
--Chris
Juan Manuel Macías wrote:
> Hi Christopher,
>
> Christopher W. Ryan" via "General discussions about Org-mode. writes:
>
>> I would expect each named entry in an index to appear once, with, if
>> necessary, multiple links next to it for all the places that index tag
>> occurs in the main document. At least, that's how the indices in books
>> work. Can the same be done in org mode?
>
> I'm afraid that in HTML that is not possible. Page numbers are used in
> books to refer to an index entry, but on a web site we don't have page
> numbers: Where would we apply the links? What I usually do with my web
> index is: use first-level entries for the general concept and second or
> third level entries for concepts more concrete.
>
> P.ej:
>
> In document A:
>
> #+INDEX: GNU Emacs!external packages!projectile
>
> In document B:
>
> #+INDEX: GNU Emacs!external packages!helm
>
> Links to document A and B go to projectile and Helm
>
> Anyway, I think in this scenario it's better to use tags, but
> org-publish doesn't provide tags out of the box. You need to do some
> elisp hacking to get something like blog tags in your web site.
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 7%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-18 22:18 0% ` Tim Cross
@ 2021-06-20 15:01 0% ` Tim Visher
0 siblings, 0 replies; 200+ results
From: Tim Visher @ 2021-06-20 15:01 UTC (permalink / raw)
To: Tim Cross; +Cc: Emacs Org Mode mailing list
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
On Fri, Jun 18, 2021 at 6:22 PM Tim Cross <theophilusx@gmail.com> wrote:
>
> Tim Visher <tim.visher@gmail.com> writes:
>
> > Hi Juan Manuel,
> >
> > On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías <
> maciaschain@posteo.net> wrote:
> >
> > Try setting this variable to non-nil:
> >
> > (setq org-export-with-broken-links t)
> >
> > Thanks for the tip here! This is definitely close to what I want. I
> think I'm going to need to code up something additional though in that none
> of the
> > default options (mark or ignore) are really the behavior that I want.
> >
> > - mark: I don't like the way the text comes out here. I don't want to
> have BROKEN LINK in the exported text at all.
> > - ignore: I don't like how the text of the link simply disappears in
> this case.
> >
> > What I really want is something that keeps the link text but drops the
> link, essentially converting it into plain text (or stylized text if the
> link text is in
> > markup).
> >
> > I'll have to play around with how to do that.
>
> Although I've never used them, I think export filters sound like they
> might be what you want. Have a look at the Advanced Export configuration
> section of the manual and how to define export filters. You should be
> able to define an org-export-filter-link-function that will tranform
> links into just the title text from the original link.
>
Thanks, Tim! I'll check them out. I hadn't heard of them before.
[-- Attachment #2: Type: text/html, Size: 2005 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Remove all Org metadata with header argument `:comments org'
2021-06-03 14:54 10% Remove all Org metadata with header argument `:comments org' Juan Manuel Macías
@ 2021-06-20 13:58 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2021-06-20 13:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am writing an *.el file from an *.org file (and then I run
> org-babel-tangle). With the header argument `:comments org' not only the
> text in my org file is converted to comments (my desired goal) but also
> the drawers, keywords and other Org metadata. Since I don't see that all
> that stuff is necessary in a source file, wouldn't it be better to get
> rid of it during the tangle process, leaving only pure content as
> comment strings? Maybe converting the Org file content to plain text
> with ox-ascii, or something like that?
>
> What do you think?
You can customise org-babel-process-comment-text to something like
(lambda (string) (org-export-string-as string 'ascii t)). Untested
though.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* Re: [External Email] Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
@ 2021-06-19 19:32 9% ` Juan Manuel Macías
2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-19 19:32 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher,
Christopher W. Ryan" via "General discussions about Org-mode. writes:
> I would expect each named entry in an index to appear once, with, if
> necessary, multiple links next to it for all the places that index tag
> occurs in the main document. At least, that's how the indices in books
> work. Can the same be done in org mode?
I'm afraid that in HTML that is not possible. Page numbers are used in
books to refer to an index entry, but on a web site we don't have page
numbers: Where would we apply the links? What I usually do with my web
index is: use first-level entries for the general concept and second or
third level entries for concepts more concrete.
P.ej:
In document A:
#+INDEX: GNU Emacs!external packages!projectile
In document B:
#+INDEX: GNU Emacs!external packages!helm
Links to document A and B go to projectile and Helm
Anyway, I think in this scenario it's better to use tags, but
org-publish doesn't provide tags out of the box. You need to do some
elisp hacking to get something like blog tags in your web site.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [External Email] Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 12:48 11% ` Juan Manuel Macías
2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
@ 2021-06-19 18:28 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 19:32 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Christopher W. Ryan via General discussions about Org-mode. @ 2021-06-19 18:28 UTC (permalink / raw)
To: orgmode
Oops, spoke to soon about the structure of the index. Here is a section
of theindex.html
I
Incarceration
Incarceration
Interview
Interview
Interview
Interview
Interview
Isolation
Isolation
Isolation
I would expect each named entry in an index to appear once, with, if
necessary, multiple links next to it for all the places that index tag
occurs in the main document. At least, that's how the indices in books
work. Can the same be done in org mode?
Thanks.
--Chris
Juan Manuel Macías wrote:
> Hi Christopher,
>
> Christopher W. Ryan" via "General discussions about Org-mode. writes:
>
>> I'm making my first foray into publishing a project. I'm running GNU
>> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>>
>> I've defined a single project, just to try it out and learn.
>
> As Christian Moe said, the function you need is
> `org-html-publish-to-html'.
>
> In case it helps, I keep this blog about typography and TeX (in spanish),
> made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
>
> The blog's public repository is at:
> https://gitlab.com/maciaschain/lunotipia
>
> And this is the org-publish configuration for the blog:
>
> ;; lunotipia
> ("lunotipia-notes"
> ;; Org files
> :base-directory "~/Git/lunotipia/org/"
> :base-extension "org"
> ;; HTML files
> :publishing-directory "~/Git/lunotipia/public/"
> :publishing-function org-html-publish-to-html
> :recursive t
> :auto-sitemap t
> :sitemap-title "Textos publicados"
> :sitemap-function my-sitemap-function-lunotipia
> :sitemap-filename "entradas.org"
> :sitemap-style list
> :sitemap-sort-files anti-chronologically
> :exclude "org-rss\\|theindex\\|acerca-de\.org"
> :makeindex t
> :html-postamble mi-postamble)
>
> ;; static files
> ("lunotipia-static"
> :base-directory "~/Git/lunotipia/org/images/"
> :base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
> :publishing-directory "~/Git/lunotipia/public/images/"
> :recursive t
> :publishing-function org-publish-attachment)
>
> And my custom sitemap function:
>
> (defun my-sitemap-function-lunotipia (title list)
> "Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
> (concat "#+TITLE: " title "\n\n"
> "#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
> "\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
> "\n#+AUTHOR:" "Juan Manuel Macías"
> "\n#+LANGUAGE:" "es"
> "\n#+begin_archive\n"
> (mapconcat (lambda (li)
> (format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
> (seq-filter #'car (cdr list))
> "\n")
> "\n#+end_archive\n"
> "\n#+begin_export html"
> "\n<div>"
> "\n<hr />"
> "\n<p>"
> "\n<a href=\"acerca-de.html\">Acerca de...</a>"
> "\n</p></div>"
> "\n<p>"
> "\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
> "\n</p></div>"
> "\n#+end_export\n"))
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 5%]
* Re: publishing: no default publishing function, or symbol is not defined
2021-06-19 12:48 11% ` Juan Manuel Macías
@ 2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
1 sibling, 0 replies; 200+ results
From: Christopher W. Ryan via General discussions about Org-mode. @ 2021-06-19 18:23 UTC (permalink / raw)
To: orgmode
Ah, I see I wrote the :publishing-function statement incorrectly. Thanks
to both of you.
But is there not a default publishing action, that requires no explicit
:publishing-function statement? This part of the documentation says
there is:
https://orgmode.org/manual/Publishing-action.html#Publishing-action
But I gave this a try:
(setq org-publish-project-alist
'(("CaseInvestigationTrainingAndReferenceManual"
:base-directory
"E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/"
:publishing-directory
"E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea"
:publishing-function org-html-publish-to-html)))
and I got the expected output in the expected place: a file called
"E:/DATA/BCHD/CD/ChinaCoronavirus2019/CommCare/Sandbox/StagingArea/WorkAreaForIndexingTrainingAndReferenceManual-7-June.html
However, when I add this line:
:makeindex 1
so with a non-null value of :makeindex
The output consists *only* of the index: a file called theindex.html.
It looks like the expected index to the document, but the document
itself is not generated. How do I get both?
Thanks.
--Chris
Juan Manuel Macías wrote:
> Hi Christopher,
>
> Christopher W. Ryan" via "General discussions about Org-mode. writes:
>
>> I'm making my first foray into publishing a project. I'm running GNU
>> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>>
>> I've defined a single project, just to try it out and learn.
>
> As Christian Moe said, the function you need is
> `org-html-publish-to-html'.
>
> In case it helps, I keep this blog about typography and TeX (in spanish),
> made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
>
> The blog's public repository is at:
> https://gitlab.com/maciaschain/lunotipia
>
> And this is the org-publish configuration for the blog:
>
> ;; lunotipia
> ("lunotipia-notes"
> ;; Org files
> :base-directory "~/Git/lunotipia/org/"
> :base-extension "org"
> ;; HTML files
> :publishing-directory "~/Git/lunotipia/public/"
> :publishing-function org-html-publish-to-html
> :recursive t
> :auto-sitemap t
> :sitemap-title "Textos publicados"
> :sitemap-function my-sitemap-function-lunotipia
> :sitemap-filename "entradas.org"
> :sitemap-style list
> :sitemap-sort-files anti-chronologically
> :exclude "org-rss\\|theindex\\|acerca-de\.org"
> :makeindex t
> :html-postamble mi-postamble)
>
> ;; static files
> ("lunotipia-static"
> :base-directory "~/Git/lunotipia/org/images/"
> :base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
> :publishing-directory "~/Git/lunotipia/public/images/"
> :recursive t
> :publishing-function org-publish-attachment)
>
> And my custom sitemap function:
>
> (defun my-sitemap-function-lunotipia (title list)
> "Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
> (concat "#+TITLE: " title "\n\n"
> "#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
> "\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
> "\n#+AUTHOR:" "Juan Manuel Macías"
> "\n#+LANGUAGE:" "es"
> "\n#+begin_archive\n"
> (mapconcat (lambda (li)
> (format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
> (seq-filter #'car (cdr list))
> "\n")
> "\n#+end_archive\n"
> "\n#+begin_export html"
> "\n<div>"
> "\n<hr />"
> "\n<p>"
> "\n<a href=\"acerca-de.html\">Acerca de...</a>"
> "\n</p></div>"
> "\n<p>"
> "\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
> "\n</p></div>"
> "\n#+end_export\n"))
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 5%]
* Re: publishing: no default publishing function, or symbol is not defined
@ 2021-06-19 12:48 11% ` Juan Manuel Macías
2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-19 12:48 UTC (permalink / raw)
To: Christopher W. Ryan; +Cc: orgmode
Hi Christopher,
Christopher W. Ryan" via "General discussions about Org-mode. writes:
> I'm making my first foray into publishing a project. I'm running GNU
> Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13, on Windows 10.
>
> I've defined a single project, just to try it out and learn.
As Christian Moe said, the function you need is
`org-html-publish-to-html'.
In case it helps, I keep this blog about typography and TeX (in spanish),
made with org-publish: https://lunotipia.juanmanuelmacias.com/index.html
The blog's public repository is at:
https://gitlab.com/maciaschain/lunotipia
And this is the org-publish configuration for the blog:
;; lunotipia
("lunotipia-notes"
;; Org files
:base-directory "~/Git/lunotipia/org/"
:base-extension "org"
;; HTML files
:publishing-directory "~/Git/lunotipia/public/"
:publishing-function org-html-publish-to-html
:recursive t
:auto-sitemap t
:sitemap-title "Textos publicados"
:sitemap-function my-sitemap-function-lunotipia
:sitemap-filename "entradas.org"
:sitemap-style list
:sitemap-sort-files anti-chronologically
:exclude "org-rss\\|theindex\\|acerca-de\.org"
:makeindex t
:html-postamble mi-postamble)
;; static files
("lunotipia-static"
:base-directory "~/Git/lunotipia/org/images/"
:base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf"
:publishing-directory "~/Git/lunotipia/public/images/"
:recursive t
:publishing-function org-publish-attachment)
And my custom sitemap function:
(defun my-sitemap-function-lunotipia (title list)
"Return sitemap using TITLE and LIST returned by `org-blog-sitemap-format-entry'."
(concat "#+TITLE: " title "\n\n"
"#+SETUPFILE:" "~/Git/lunotipia/html-lunotipia.setup"
"\n#+SETUPFILE:" "~/Git/gnutas/macros-gnutas.setup"
"\n#+AUTHOR:" "Juan Manuel Macías"
"\n#+LANGUAGE:" "es"
"\n#+begin_archive\n"
(mapconcat (lambda (li)
(format "@@html:<li>@@ %s @@html:</li>@@" (car li)))
(seq-filter #'car (cdr list))
"\n")
"\n#+end_archive\n"
"\n#+begin_export html"
"\n<div>"
"\n<hr />"
"\n<p>"
"\n<a href=\"acerca-de.html\">Acerca de...</a>"
"\n</p></div>"
"\n<p>"
"\n<a href=\"https://maciaschain.gitlab.io/lunotipia/rss.xml\">RSS</a>"
"\n</p></div>"
"\n#+end_export\n"))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 11%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-18 19:47 6% ` Tim Visher
2021-06-18 20:37 10% ` Juan Manuel Macías
@ 2021-06-18 22:18 0% ` Tim Cross
2021-06-20 15:01 0% ` Tim Visher
1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-06-18 22:18 UTC (permalink / raw)
To: emacs-orgmode
Tim Visher <tim.visher@gmail.com> writes:
> Hi Juan Manuel,
>
> On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Try setting this variable to non-nil:
>
> (setq org-export-with-broken-links t)
>
> Thanks for the tip here! This is definitely close to what I want. I think I'm going to need to code up something additional though in that none of the
> default options (mark or ignore) are really the behavior that I want.
>
> - mark: I don't like the way the text comes out here. I don't want to have BROKEN LINK in the exported text at all.
> - ignore: I don't like how the text of the link simply disappears in this case.
>
> What I really want is something that keeps the link text but drops the link, essentially converting it into plain text (or stylized text if the link text is in
> markup).
>
> I'll have to play around with how to do that.
Although I've never used them, I think export filters sound like they
might be what you want. Have a look at the Advanced Export configuration
section of the manual and how to define export filters. You should be
able to define an org-export-filter-link-function that will tranform
links into just the title text from the original link.
--
Tim Cross
^ permalink raw reply [relevance 0%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-18 19:47 6% ` Tim Visher
@ 2021-06-18 20:37 10% ` Juan Manuel Macías
2021-06-18 22:18 0% ` Tim Cross
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-18 20:37 UTC (permalink / raw)
To: Tim Visher; +Cc: orgmode
Hi Tim,
Tim Visher writes:
> What I really want is something that keeps the link text but drops the
> link, essentially converting it into plain text (or stylized text if
> the link text is in markup).
According to the `org-export-with-broken-links' docstring:
-----------------------------------
[...] If it is set to ‘mark’, broken links are marked as such in the
output, with a string like
[BROKEN LINK: path]
where PATH is the un-resolvable reference.
This option can also be set with the OPTIONS keyword, e.g.,
"broken-links:mark".
-----------------------------------
It's not exactly what you're looking for, but it can help you find a
solution.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Failure to resolve internal links on ox-html export?
2021-06-11 18:31 10% ` Juan Manuel Macías
@ 2021-06-18 19:47 6% ` Tim Visher
2021-06-18 20:37 10% ` Juan Manuel Macías
2021-06-18 22:18 0% ` Tim Cross
0 siblings, 2 replies; 200+ results
From: Tim Visher @ 2021-06-18 19:47 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
Hi Juan Manuel,
On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Try setting this variable to non-nil:
>
> (setq org-export-with-broken-links t)
>
Thanks for the tip here! This is definitely close to what I want. I think
I'm going to need to code up something additional though in that none of
the default options (mark or ignore) are really the behavior that I want.
- mark: I don't like the way the text comes out here. I don't want to have
BROKEN LINK in the exported text at all.
- ignore: I don't like how the text of the link simply disappears in this
case.
What I really want is something that keeps the link text but drops the
link, essentially converting it into plain text (or stylized text if the
link text is in markup).
I'll have to play around with how to do that.
--
In Christ,
Timmy V.
https://blog.twonegatives.com
http://five.sentenc.es
[-- Attachment #2: Type: text/html, Size: 1479 bytes --]
^ permalink raw reply [relevance 6%]
* Re: A dictionary made in Org Mode
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
2021-06-18 12:27 6% ` Detlef Steuer
@ 2021-06-18 13:51 6% ` Samuel Banya
2 siblings, 0 replies; 200+ results
From: Samuel Banya @ 2021-06-18 13:51 UTC (permalink / raw)
To: Charles Berry
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
Wow, that publication looks pro!
Absolutely beautiful!
On Fri, Jun 18, 2021, at 8:11 AM, Juan Manuel Macías wrote:
> Hi,
>
> I would like to share here my latest work. It has recently been
> published in Spain and I think it's the first dictionary made entirely
> using Org Mode ;-) I have taken care of its production and its editorial
> design:
>
> Diccionario Hispánico de la Tradición Clásica
> (Hispanic Dictionary of Classical Tradition)
>
> ISBN: 978-84-18093-93-7
>
> 828 pages
>
> Org-publish has been especially useful for its production. Soon I will
> write a detailed article in Spanish about the making off. If anyone here
> was interested I can try to translate the article into English.
>
> A few samples of the content:
>
> https://cloud.disroot.org/s/tBpMQP6afssY37p
>
> And this short video shows a quick overview of the files involved and
> the final compilation, before printing all the work:
>
> https://vimeo.com/538137630
>
> Best regards,
>
> Juan Manuel
>
>
>
[-- Attachment #2: Type: text/html, Size: 1782 bytes --]
^ permalink raw reply [relevance 6%]
* Re: A dictionary made in Org Mode
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
@ 2021-06-18 12:27 6% ` Detlef Steuer
2021-06-18 13:51 6% ` Samuel Banya
2 siblings, 0 replies; 200+ results
From: Detlef Steuer @ 2021-06-18 12:27 UTC (permalink / raw)
To: emacs-orgmode
Congratulations! Looks just beautyful!
Detlef
Am Fri, 18 Jun 2021 12:11:19 +0000
schrieb Juan Manuel Macías <maciaschain@posteo.net>:
> Hi,
>
> I would like to share here my latest work. It has recently been
> published in Spain and I think it's the first dictionary made entirely
> using Org Mode ;-) I have taken care of its production and its
> editorial design:
>
> Diccionario Hispánico de la Tradición Clásica
> (Hispanic Dictionary of Classical Tradition)
>
> ISBN: 978-84-18093-93-7
>
> 828 pages
>
> Org-publish has been especially useful for its production. Soon I will
> write a detailed article in Spanish about the making off. If anyone
> here was interested I can try to translate the article into English.
>
> A few samples of the content:
>
> https://cloud.disroot.org/s/tBpMQP6afssY37p
>
> And this short video shows a quick overview of the files involved and
> the final compilation, before printing all the work:
>
> https://vimeo.com/538137630
>
> Best regards,
>
> Juan Manuel
>
>
^ permalink raw reply [relevance 6%]
* Re: A dictionary made in Org Mode
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
@ 2021-06-18 12:19 6% ` John Kitchin
2021-06-18 12:27 6% ` Detlef Steuer
2021-06-18 13:51 6% ` Samuel Banya
2 siblings, 0 replies; 200+ results
From: John Kitchin @ 2021-06-18 12:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Congratulations! That looks like an amazing project.
On Fri, Jun 18, 2021 at 8:11 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I would like to share here my latest work. It has recently been
> published in Spain and I think it's the first dictionary made entirely
> using Org Mode ;-) I have taken care of its production and its editorial
> design:
>
> Diccionario Hispánico de la Tradición Clásica
> (Hispanic Dictionary of Classical Tradition)
>
> ISBN: 978-84-18093-93-7
>
> 828 pages
>
> Org-publish has been especially useful for its production. Soon I will
> write a detailed article in Spanish about the making off. If anyone here
> was interested I can try to translate the article into English.
>
> A few samples of the content:
>
> https://cloud.disroot.org/s/tBpMQP6afssY37p
>
> And this short video shows a quick overview of the files involved and
> the final compilation, before printing all the work:
>
> https://vimeo.com/538137630
>
> Best regards,
>
> Juan Manuel
>
>
> --
John
-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
[-- Attachment #2: Type: text/html, Size: 2124 bytes --]
^ permalink raw reply [relevance 6%]
* A dictionary made in Org Mode
@ 2021-06-18 12:11 9% Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-18 12:11 UTC (permalink / raw)
To: orgmode
Hi,
I would like to share here my latest work. It has recently been
published in Spain and I think it's the first dictionary made entirely
using Org Mode ;-) I have taken care of its production and its editorial
design:
Diccionario Hispánico de la Tradición Clásica
(Hispanic Dictionary of Classical Tradition)
ISBN: 978-84-18093-93-7
828 pages
Org-publish has been especially useful for its production. Soon I will
write a detailed article in Spanish about the making off. If anyone here
was interested I can try to translate the article into English.
A few samples of the content:
https://cloud.disroot.org/s/tBpMQP6afssY37p
And this short video shows a quick overview of the files involved and
the final compilation, before printing all the work:
https://vimeo.com/538137630
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: example paper written in org completely
@ 2021-06-17 12:51 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-17 12:51 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hi Eric,
Eric S Fraga writes:
> Dear all,
>
> for those that may be interested, my latest paper (well, preprint at
> this stage) is available if you are looking for an example of a
> numerical work where the paper is completely written in org, including
> data analysis and visualisation. See signature for link.
>
> The arxiv deposit includes the complete org file as an ancillary file.
Congratulations. Thanks for sharing your work.
By the way, I think it would be nice to create on the Worg website a
section called "Org Showcase" or similar, just like there is a "Tex
Showcase" on the Tex User Group website: http://tug.org/texshowcase/,
with samples of published books, articles or web pages, all written in
Org, to demonstrate the productivity of Org Mode.
What do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: no inline images anymore after reinstall
@ 2021-06-16 12:51 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-16 12:51 UTC (permalink / raw)
To: Prof. Dr. Johanna May; +Cc: orgmode
Hi Johanna,
I don't have much knowledge of Python, but I have done this, in case it
helps you locate the problem:
- I have tried to evaluate your block (previously I have installed in my
Arch system python-matplotlib). Output:
#+RESULTS: fig-zeitverlaufspgendrehstrom
[[file:]]
but
- I have noticed that if you comment on these two lines:
# plt.rcParams.update({'font.size':fontsize})
# rcParams.update({'figure.autolayout': True})
output:
#+RESULTS: fig-zeitverlaufspgendrehstrom
[[file:/tmp/babel-yXFqLG/figurepLRhLV.png]]
(Python console was returning these two errors before commenting
the lines:
NameError: name 'fontsize' is not defined
NameError: name 'rcParams' is not defined)
Best regards,
Juan Manuel
Prof. Dr. Johanna May writes:
> Hi guys,
>
> I've been trying on the web and in "known as good" config files to solve
> this but cannot seem to find the solution:
>
> After reinstalling linux (openSuse leap 15.3) and finding out that
> unfortunately the distro is too new, so 27.1 does not yet get offered
> and switching back to 25.3 most of the stuff that I need works again.
>
> Except for including python output diagrams in org-babel. I put the
> diagram code at the very bottom since it takes up some space. At the very end
> you also see the output: it is not a file, it is just a link called
> [[file:]]. That cannot be right and then, of course, there are no inline
> images displayed and not exported either. It is remarkable though, that
> latex gets the link to the file, but just does not seem to show it
> right. This might point to a latex problem, but the inline images aren't
> shown in org-babel. Therefore I'm trying to find a solution here.
>
> In my dotemacs I included what I thought relevant to get it working, but
> it doesn't (below).
>
> I would be very glad about a hint where to look for a solution. Maybe
> some package-install (but which). Or some other configuration ... Or
> maybe I'm still lacking an important distro package that just does not
> get output on any error buffer?
>
> Thank you very much, any help is appreciated
>
> Johanna May
>
> --- some of my dotemacs lines ---
> ;; === org-babel - Code einbinden ===
> ;; ### Darstellung ###
> (setq org-startup-with-inline-images t)
> (setq org-confirm-babel-evaluate nil)
> (setq org-src-fontify-natively t)
> (setq org-src-tab-acts-natively t)
> (setq org-hide-emphasis-markers t)
>
> ;; ### Statistik mit R ESS ###
> (require 'ess-site)
>
> ;; ### org-babel Sprachen ###
> (require 'ob-python)
> (setq org-babel-python-command "python3")
> ;;(setq python-shell-interpreter "python3")
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((emacs-lisp . t)
> (python . t)
> (ipython . t)
> (shell . t)
> (js . t)
> (latex . t)
> (org . t)
> (octave . t)
> (R . t)
> (plantuml . t)
> (dot . t)
> (gnuplot . t)
> (ruby . t)
> (screen . nil)
> (ledger . t)
> (C . t)
> (sql . t)
> (ditaa . t)))
>
> ;; ### Einrückungen beachten (z. B. python) ###
> (setq org-edit-src-content-indentation 0)
> (setq org-src-tab-acts-natively t)
> (setq org-src-preserve-indentation t)
>
> ;; ### python-Coding ###
> (require 'epc)
> (require 'company)
> (add-hook 'after-init-hook 'global-company-mode)
> (global-font-lock-mode t)
> (setq font-lock-maximum-decoration t)
> (setq-default indent-tabs-mode nil) ;; nicht Tabs sondern 4 Leerzeichen
> (setq default-tab-width 4)
> (add-hook 'python-mode-hook 'anaconda-mode)
> (add-hook 'python-mode-hook 'eldoc-mode)
> (eval-after-load "company"
> '(progn
> (add-to-list 'company-backends 'company-anaconda)))
> (add-hook 'python-mode-hook 'anaconda-mode)
>
> ;; ### Bilder aus python inline anzeigen ###
> (add-hook 'org-babel-after-execute-hook 'org-display-inline-images 'append)
> (add-hook 'org-mode-hook 'org-display-inline-images)
> --- snip ---
>
>
> ---diagram code in org---
>
> #+name: fig-zeitverlaufspgendrehstrom
> #+begin_src python :results file :session :var matplot_lib_filename=(org-babel-temp-file "figure" ".png"),fontsize=fs :exports results
>
> import matplotlib.pyplot as plt
> plt.style.use('classic')
> import numpy as np
> from matplotlib.ticker import FuncFormatter, MultipleLocator
> plt.style.use('classic')
>
> plt.rcParams.update({'font.size':fontsize})
> rcParams.update({'figure.autolayout': True})
>
> fig=plt.figure(figsize=(6,3))
>
> x=np.linspace(0,5*np.pi,1000)
> udach=230*np.sqrt(2)
> phi1=0
> phi2=-np.pi*2/3
> phi3=-np.pi*4/3
> u1=udach*np.cos(x+phi1)
> u2=udach*np.cos(x+phi2)
> u3=udach*np.cos(x+phi3)
>
> plt.plot(x,u1,label='$u_1(t)$')
> plt.plot(x,u2,label='$u_2(t)$')
> plt.plot(x,u3,label='$u_3(t)$')
> plt.xlabel('$t$')
> plt.ylabel('$u$')
> plt.xticks([])
> plt.yticks([])
> plt.legend(fontsize='small',bbox_to_anchor=(0,1.02,1.02,0),loc=3,ncol=3,mode="expand",borderaxespad=0.)
> plt.grid(True)
> plt.axhline(0,color='black',lw=1)
>
> #plt.tight_layout()
> plt.savefig(matplot_lib_filename,bbox_inches='tight')
> matplot_lib_filename
> #+end_src
>
> #+CAPTION: Zeitverlauf symmetrischer Spannungen
> #+LABEL: fig-zeitverlaufspgendrehstrom
>
> #+ATTR_LATEX: :width \textwidth :height \textheight :options angle=0,keepaspectratio :float nil
>
> #+RESULTS: fig-zeitverlaufspgendrehstrom
> [[file:]]
>
> ---snip ---
>
^ permalink raw reply [relevance 9%]
* Re: org-critical-edition (a package for philologists and classicists)
2021-06-14 8:50 6% ` Christian Moe
@ 2021-06-15 12:44 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-15 12:44 UTC (permalink / raw)
To: Christian Moe; +Cc: orgmode
Hi Christian, thank you very much for your comments.
Christian Moe writes:
> Very neat!
>
> Curious about a design choice: If I understand correctly,
> org-critical-edition puts the hidden notes in the description and the
> visible annotated text in the target of an org link. This is the reverse
> of the out-of-the-box link appearance (description visible, target
> hidden if description present). Why take the extra trouble to do it this
> way?
>
Indeed, the decision to reverse the order of the link appearance may
seem somewhat shocking :-) I did it like this to keep a syntactic
structure similar to the reledmac command \edtext, when the user (the
reledmac user) views the links full displayed. In LaTeX/reledmac the
structure is:
...some text... \edtext{annotated passage}{critical notes} ...some text...
The annotated passage is part of the text and is also the "lemma" in the
critical note.
In org-critical-edition I define a new link type called `edtext', using
`org-link-set-parameters', and the identifying string (`edtext:') must be
placed in the target part.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-critical-edition (a package for philologists and classicists)
2021-06-07 13:09 10% org-critical-edition (a package for philologists and classicists) Juan Manuel Macías
@ 2021-06-14 8:50 6% ` Christian Moe
2021-06-15 12:44 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Christian Moe @ 2021-06-14 8:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Very neat!
Curious about a design choice: If I understand correctly,
org-critical-edition puts the hidden notes in the description and the
visible annotated text in the target of an org link. This is the reverse
of the out-of-the-box link appearance (description visible, target
hidden if description present). Why take the extra trouble to do it this
way?
Yours,
Christian
Juan Manuel Macías writes:
> Hi all,
>
> I have uploaded the (very) initial version of my package
> org-critical-edition:
>
> https://gitlab.com/maciaschain/org-critical-edition
>
> This package lets you prepare a philological critical edition in Org
> Mode. The natural output is LaTeX with the reledmac package
> (https://www.ctan.org/pkg/reledmac).
>
> (For those who are not philologists, this is an example of critical
> edition that I typesetted recently: https://imgur.com/a/drqCib5)
>
> Feedback welcome!
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 6%]
* [tip] LaTeX preview of a region
@ 2021-06-12 23:51 7% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-12 23:51 UTC (permalink / raw)
To: orgmode
Hi all,
When typesetting a long book, I often need to fine tune many paragraphs
(typographically speaking). So I've write this code to avoid compiling
the whole document every time. The idea is activate a preview of any
region of the document, compiled with all the local configuration
(export filters, setup file, export options, etc.). In other words, the
preview *must be identical* to the compiled/exported pdf. Although it is
for a particular use case, I share it here in case it is useful to
someone.
My intention is to give these four variables a local value for each
document or major project. But this would be the default value:
#+begin_src emacs-lisp
(setq my-prev/preamble "preamble.tex"
my-prev/env-begin "@@latex:\\begin{dummy}@@"
my-prev/env-end "@@latex:\\end{dummy}@@"
my-prev/conf "#+OPTIONS: ':t\n
#+LANGUAGE: es\n"
#+SETUPFILE: normal.setup\n
#+INCLUDE: export-filters\n")
#+end_src
The first variable makes sense because I always use a separate file as a
preamble for large projects. The second and third variables correspond
to the environment to enclose the preview (by default, a `dummmy'
environment: `\newenvironment*{dummy}{}{}'). And the fourth is the
configuration to export the preview.
And these two functions enable or disable the preview on a region (here
a sample video:
https://lunotipia.juanmanuelmacias.com/images/latex-preview.mp4):
#+begin_src emacs-lisp
(defun my-org-latex-prev-region ()
(interactive)
(let* ((frag (save-restriction
(narrow-to-region (region-beginning) (region-end))
(buffer-string)))
(my-prev/preamble-l (buffer-local-value 'my-prev/preamble (current-buffer)))
(my-prev/env-begin-l (buffer-local-value 'my-prev/env-begin (current-buffer)))
(my-prev/env-end-l (buffer-local-value 'my-prev/env-end (current-buffer)))
(my-prev/conf-l (buffer-local-value 'my-prev/conf (current-buffer)))
(org-preview-latex-default-process 'luamagick)
(org-format-latex-header (concat (with-temp-buffer
(insert-file-contents my-prev/preamble-l)
(buffer-string)) "\n"
"\\pagestyle{empty}"))
(prev (with-temp-buffer
(insert (concat my-prev/conf-l "\n\n" my-prev/env-begin-l "\n\n" frag "\n\n" my-prev/env-end-l))
(mark-whole-buffer)
(org-latex-convert-region-to-latex)
(org-latex-preview)
(goto-char (point-min))
(overlay-get (car (overlays-at (point))) 'display))))
(let*
((ov (make-overlay (region-beginning) (region-end))))
(overlay-put ov 'overlay-latex-prev t)
(overlay-put ov 'display prev))))
(defun my-org-latex-remove-prev-region ()
(interactive)
(remove-overlays nil nil 'overlay-latex-prev t))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Write Markdown in Org mode
2021-06-12 15:14 6% ` leo
@ 2021-06-12 15:51 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-12 15:51 UTC (permalink / raw)
To: leo; +Cc: orgmode
Hi Leo,
leo writes:
> Good to know. I’m not too keen to learn yet another text markup language, but I might give org mode a try…
It's worth a try! Org markup language is very similar to Markdown. My
advice is that you take from Org only what you need, because Org has so
many features that at first it can saturate you. A Recommended initial
reading may be the compact guide, which gives you a pretty global vision
without going too deep in each aspect: https://orgmode.org/guide/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Write Markdown in Org mode
2021-06-12 12:35 9% ` Juan Manuel Macías
@ 2021-06-12 15:14 6% ` leo
2021-06-12 15:51 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: leo @ 2021-06-12 15:14 UTC (permalink / raw)
To: orgmode
Gi Juan
On 12 Jun 2021, at 22:35, Juan Manuel Macías wrote:
> Hi Leo,
>
> leo writes:
>
>> Hi there
>>
>> I write a lot of Markdown notes. At the moment I use Melpa’s markdown-mode, but I am considering switching to Org mode.
>>
>> But I’m not sure whether Org mode supports this. In the manual I found an option to *export* to Markdown, but I planning to *write* the notes directly as Markdown.
>>
>> Is this possible with Org mode?
>>
>> Many thanks!
>>
>
> I do not know the characteristics or the contexts of your workflow, but
> seen the case from the outside, from what you comment I would say that
> it would not have a lot of sense for you to write your Org docs in
> Markdown, since Org is also a lightweight markup language, but much more
> powerful than Markdown. Org mode is intended to write in Org syntax.
>
> I started writing my notes in Markdown, and when I migrated to Org, I
> converted all my old Markdown notes to Org via pandoc.
>
> Anyway, inside an Org document you can write Markdown using a source
> block:
>
> #+begin_src markdown
> your text in markdown...
> #+end_src
>
> If you do C-c ' inside the block, you can edit it in another buffer with
> the markdown mode activated[1].
>
> You can also generate a * .md file from that block (see
> https://orgmode.org/manual/Extracting-Source-Code.html):
>
> #+begin_src markdown :tangle my-file.md
> your text in markdown...
> #+end_src
>
> Best regards,
>
> Juan Manuel
Good to know. I’m not too keen to learn yet another text markup language, but I might give org mode a try…
Leo
^ permalink raw reply [relevance 6%]
* Re: Write Markdown in Org mode
@ 2021-06-12 12:35 9% ` Juan Manuel Macías
2021-06-12 15:14 6% ` leo
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-12 12:35 UTC (permalink / raw)
To: leo; +Cc: orgmode
Hi Leo,
leo writes:
> Hi there
>
> I write a lot of Markdown notes. At the moment I use Melpa’s markdown-mode, but I am considering switching to Org mode.
>
> But I’m not sure whether Org mode supports this. In the manual I found an option to *export* to Markdown, but I planning to *write* the notes directly as Markdown.
>
> Is this possible with Org mode?
>
> Many thanks!
>
I do not know the characteristics or the contexts of your workflow, but
seen the case from the outside, from what you comment I would say that
it would not have a lot of sense for you to write your Org docs in
Markdown, since Org is also a lightweight markup language, but much more
powerful than Markdown. Org mode is intended to write in Org syntax.
I started writing my notes in Markdown, and when I migrated to Org, I
converted all my old Markdown notes to Org via pandoc.
Anyway, inside an Org document you can write Markdown using a source
block:
#+begin_src markdown
your text in markdown...
#+end_src
If you do C-c ' inside the block, you can edit it in another buffer with
the markdown mode activated[1].
You can also generate a * .md file from that block (see
https://orgmode.org/manual/Extracting-Source-Code.html):
#+begin_src markdown :tangle my-file.md
your text in markdown...
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Failure to resolve internal links on ox-html export?
@ 2021-06-11 18:31 10% ` Juan Manuel Macías
2021-06-18 19:47 6% ` Tim Visher
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-11 18:31 UTC (permalink / raw)
To: Tim Visher; +Cc: orgmode
Hi Tim,
Try setting this variable to non-nil:
(setq org-export-with-broken-links t)
Best regards,
Juan Manuel
Tim Visher writes:
> Hi Everyone,
>
> I'd like to be able to link to various areas of a large wiki file I
> maintain for when I'm looking at an entry in emacs. However, I will
> often email exported subtrees and when I do that if I have a link to a
> heading that's outside the current subtree it fails with a
> `user-error: Unable to resolve link: …`, I assume because the export
> tree doesn't contain that heading.
>
> Is there any way to tell the exporter to simply make those into plain
> text _or_ to simply ignore the error?
>
> Thanks in advance!
>
> --
>
> In Christ,
>
> Timmy V.
>
> https://blog.twonegatives.com
> http://five.sentenc.es
>
^ permalink raw reply [relevance 10%]
* Re: org-attach a directory?
@ 2021-06-11 17:10 4% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-11 17:10 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
I have put the Ihor's snippet in my init file. I find it very useful,
and everything is done from a simple Helm session. The only case it
doesn't work is when I just want to copy a directory --not a file--
(instead of moving or giving it a symbolic link). So I have done this
little modification (just added a conditional to the old function when
the method attach is 'cp: if attachment is a file, run `copy-file'. If
it is a directory, run `copy-directory'. Then just call the org-attach
dispatcher as always: C-c C-a and select an attach method:
(define-advice org-attach-attach (:around (oldfun files &rest args) start-from-default-directory)
"Code shared by Ihor Radchenko, slightly modified and adapted to my use."
(interactive
(list
(mapcar #'directory-file-name (helm-read-file-name "File to keep as an attachment:"
:initial-input (or (progn
(require 'dired-aux)
(dired-dwim-target-directory))
default-directory)
:marked-candidates t))
current-prefix-arg
nil))
;; my addition starts here
(setq oldfun (lambda (file &optional visit-dir method)
(interactive)
(setq method (or method org-attach-method))
(let ((basename (file-name-nondirectory file)))
(let* ((attach-dir (org-attach-dir 'get-create))
(attach-file (expand-file-name basename attach-dir)))
(cond
((eq method 'mv) (rename-file file attach-file))
((eq method 'cp) (if (file-directory-p file) (ref:lin-attach)
(copy-directory file attach-file)
(copy-file file attach-file)))
((eq method 'ln) (add-name-to-file file attach-file))
((eq method 'lns) (make-symbolic-link file attach-file))
((eq method 'url) (url-copy-file file attach-file)))
(run-hook-with-args 'org-attach-after-change-hook attach-dir)
(org-attach-tag)
(cond ((eq org-attach-store-link-p 'attached)
(push (list (concat "attachment:" (file-name-nondirectory attach-file))
(file-name-nondirectory attach-file))
org-stored-links))
((eq org-attach-store-link-p t)
(push (list (concat "file:" file)
(file-name-nondirectory file))
org-stored-links))
((eq org-attach-store-link-p 'file)
(push (list (concat "file:" attach-file)
(file-name-nondirectory attach-file))
org-stored-links)))
(if visit-dir
(dired attach-dir)
(message "File or directory %S is now an
attachment" basename))))))
;; my addition ends here
(unless (listp files) (setq files (list files)))
(mapc (lambda (file) (apply oldfun file args)) files))
John Kitchin writes:
> I discovered another way to do this that is already built in with
> `org-attach-dired-to-subtree` that would help sometimes.
>
> You split your window, open dired in one of them, mark some files, and
> then run that command in the dired window.
>
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
> On Thu, Jun 10, 2021 at 10:04 PM stardiviner <numbchild@gmail.com>
> wrote:
>
> I want this feature patch too. Hope Org Mode can add this. I
> remember old version org-mode can do this. But later delete this
> feature? I forget what version is.
>
> I suggest to add this feature.
>
> On Jun 8, 2021, at 11:49 PM, John Kitchin
> <jkitchin@andrew.cmu.edu> wrote:
>
> Is it possible to attach a directory to an org heading?
>
> I have only seen how to attach a file so far.
>
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
--
^ permalink raw reply [relevance 4%]
* Re: literate programming, development log -- ideas? (ominbus reply)
2021-06-11 14:30 10% ` Juan Manuel Macías
@ 2021-06-11 15:02 6% ` Samuel Banya
0 siblings, 0 replies; 200+ results
From: Samuel Banya @ 2021-06-11 15:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Charles Berry
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
Now this idea I like!
Thanks for this, I didn't think about using the Git repo as a SECONDARY backup source.
Also, using Nextcloud sounds like a neat idea.
I'm into Self-Hosting stuff myself nowadays but am starting out small (ex: Just bought an old Dell Optiplex from eBay, put 2 HDDs into it, planning on using it for HDD backups, and as a Git server).
However, this sounds like an awesome workflow, as I did not consider to host Nextcloud. Awesome idea, thank you for this, Juan!
On Fri, Jun 11, 2021, at 10:30 AM, Juan Manuel Macías wrote:
> Samuel Banya writes:
>
> > I'm okay with git repos for dot files or some kind of programming
> > project but yeah, I've been debating something else for an org based
> > repo cause I too have almost had my 'life.org' be completely destroyed
> > with a merge event.
>
> I have all my everyday Org documents in a Nextcloud folder, but only
> because I work between the desktop PC and the laptop. I sync using a
> script with nextcloud-cmd, not via the Nextcloud app, which I find it
> somewhat intrusive. And with another script I do every week a backup of
> that folder to a git repo. But this repo is secondary and is only for
> keep some backups (I also keep a weekly backup of Elpa folders ---last
> versions--- there, in case some update breaks something).
>
> Best regards,
>
> Juan Manuel
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2003 bytes --]
^ permalink raw reply [relevance 6%]
* Re: literate programming, development log -- ideas? (ominbus reply)
@ 2021-06-11 14:30 10% ` Juan Manuel Macías
2021-06-11 15:02 6% ` Samuel Banya
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-11 14:30 UTC (permalink / raw)
To: Samuel Banya; +Cc: orgmode
Samuel Banya writes:
> I'm okay with git repos for dot files or some kind of programming
> project but yeah, I've been debating something else for an org based
> repo cause I too have almost had my 'life.org' be completely destroyed
> with a merge event.
I have all my everyday Org documents in a Nextcloud folder, but only
because I work between the desktop PC and the laptop. I sync using a
script with nextcloud-cmd, not via the Nextcloud app, which I find it
somewhat intrusive. And with another script I do every week a backup of
that folder to a git repo. But this repo is secondary and is only for
keep some backups (I also keep a weekly backup of Elpa folders ---last
versions--- there, in case some update breaks something).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach a directory?
2021-06-10 14:01 10% ` Juan Manuel Macías
@ 2021-06-10 16:13 13% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-10 16:13 UTC (permalink / raw)
To: orgmode
You could also modify some line in org-attach-attach, for example:
...
((eq method 'cp) (if (file-directory-p file)
(copy-directory file attach-file)
(copy-file file attach-file)))
...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> If I have to stay with a workaround that covers many scenarios, I would
> stay with Ihor's snippet, which seems to me simpler than the patch that
> I suggested before, and you don't need to define new attach
> commands/methods. I would vote for a patch in that direction (Ihor's
> code).
^ permalink raw reply [relevance 13%]
* Re: org-attach a directory?
@ 2021-06-10 14:01 10% ` Juan Manuel Macías
2021-06-10 16:13 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-10 14:01 UTC (permalink / raw)
To: Christian Barthel, John Kitchin, Ihor Radchenko; +Cc: orgmode
This only works when you create the attach folder manually, but not when
you want org-attach to generate the attach directory for the current
node.
If I have to stay with a workaround that covers many scenarios, I would
stay with Ihor's snippet, which seems to me simpler than the patch that
I suggested before, and you don't need to define new attach
commands/methods. I would vote for a patch in that direction (Ihor's
code).
Best regards,
Juan Manuel
Christian Barthel writes:
> On Thu, Jun 10 2021, Ypo wrote:
>
>> C-c C-a
>>
>> s
>>
>> (not "S" like in the video, but "s")
>
> Thanks, that is an interesting workaround:
> Setting the directory twice and using the copy/delete action
> accordingly.
>
> Does anyone know if there is a workaround to attach a file and
> delete the old one (or move the file) or do I need to write a
> small elisp function for that?
^ permalink raw reply [relevance 10%]
* [patch] Re: org-attach a directory?
@ 2021-06-09 1:38 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-09 1:38 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Hi John,
John Kitchin writes:
> I want to attach all the files in a directory on my desktop to the
> attachment directory, something that is more like
> org-attach-attach-mv-directory (that is not an existing command, but
> what I was thinking of doing). Did I misunderstand what
> org-attach-set-directory does?
As far as I know, that option is not possible. And it's something that
I've always missed in org-attach. I've written this possible patch, with
two new attach methods/commands to copy or move a directory ("C" and
"M"). I guess it would be better to use `read-file-name' and
`read-directory-name' according to each case, but I can't think of how
to solve that. Anyway, `read-file-name' may also apply here for
directories.
(Little tested).
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Org-attach.el-Add-two-new-methods-for-cp-or-mv-directories.patch --]
[-- Type: text/x-patch, Size: 4462 bytes --]
From 5a2f59a74c9b3f8ff1cf25777067780400f9043f Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 9 Jun 2021 03:03:50 +0200
Subject: [PATCH] Org-attach.el: Add two new methods for copying or moving
directories
* lisp/org-attach.el (org-attach-commands): add two new attachments
commands
(org-attach-attach): add two new attachment methods, argument `file'
is ranamed as `target'
(org-attach-attach-cp-dir): copy a directory
(org-attach-attach-mv-dir): move (rename) a directory
---
lisp/org-attach.el | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 715fe3e93..50b1dca3b 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -199,6 +199,10 @@ git-functionality from this file.")
"Attach a file using copy method.")
((?m ?\C-m) org-attach-attach-mv
"Attach a file using move method.")
+ ((?C ?\C-C) org-attach-attach-cp-dir
+ "Attach a directory using copy dir method.")
+ ((?M ?\C-M) org-attach-attach-mv-dir
+ "Attach a directory using move dir method.")
((?l ?\C-l) org-attach-attach-ln
"Attach a file using link method.")
((?y ?\C-y) org-attach-attach-lns
@@ -489,8 +493,8 @@ if it would overwrite an existing filename."
(with-temp-file output
(insert-buffer-substring buffer-name))))
-(defun org-attach-attach (file &optional visit-dir method)
- "Move/copy/link FILE into the attachment directory of the current outline node.
+(defun org-attach-attach (target &optional visit-dir method)
+ "Move/copy/link TARGET into the attachment directory of the current outline node.
If VISIT-DIR is non-nil, visit the directory with dired.
METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
`org-attach-method'."
@@ -504,15 +508,20 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
current-prefix-arg
nil))
(setq method (or method org-attach-method))
- (let ((basename (file-name-nondirectory file)))
+ (let ((basename (if (or (eq method 'mv-dir)
+ (eq method 'cp-dir))
+ target
+ (file-name-nondirectory target))))
(let* ((attach-dir (org-attach-dir 'get-create))
(attach-file (expand-file-name basename attach-dir)))
(cond
- ((eq method 'mv) (rename-file file attach-file))
- ((eq method 'cp) (copy-file file attach-file))
- ((eq method 'ln) (add-name-to-file file attach-file))
- ((eq method 'lns) (make-symbolic-link file attach-file))
- ((eq method 'url) (url-copy-file file attach-file)))
+ ((eq method 'mv) (rename-file target attach-file))
+ ((eq method 'cp) (copy-file target attach-file))
+ ((eq method 'mv-dir) (rename-file target (concat attach-dir "/")))
+ ((eq method 'cp-dir) (copy-directory target (concat attach-dir "/")))
+ ((eq method 'ln) (add-name-to-file target attach-file))
+ ((eq method 'lns) (make-symbolic-link target attach-file))
+ ((eq method 'url) (url-copy-file target attach-file)))
(run-hook-with-args 'org-attach-after-change-hook attach-dir)
(org-attach-tag)
(cond ((eq org-attach-store-link-p 'attached)
@@ -520,8 +529,8 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
(file-name-nondirectory attach-file))
org-stored-links))
((eq org-attach-store-link-p t)
- (push (list (concat "file:" file)
- (file-name-nondirectory file))
+ (push (list (concat "file:" target)
+ (file-name-nondirectory target))
org-stored-links))
((eq org-attach-store-link-p 'file)
(push (list (concat "file:" attach-file)
@@ -539,6 +548,14 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
"Attach a file by moving (renaming) it."
(interactive)
(let ((org-attach-method 'mv)) (call-interactively 'org-attach-attach)))
+(defun org-attach-attach-cp-dir ()
+ "Attach a directory by copying it."
+ (interactive)
+ (let ((org-attach-method 'cp-dir)) (call-interactively 'org-attach-attach)))
+(defun org-attach-attach-mv-dir ()
+ "Attach a directory by moving (renaming) it."
+ (interactive)
+ (let ((org-attach-method 'mv-dir)) (call-interactively 'org-attach-attach)))
(defun org-attach-attach-ln ()
"Attach a file by creating a hard link to it.
Beware that this does not work on systems that do not support hard links.
--
2.31.1
^ permalink raw reply related [relevance 6%]
* [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
2021-06-06 22:34 13% ` Juan Manuel Macías
@ 2021-06-08 0:24 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-08 0:24 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
As I commented in a previous post of this thread, to reproduce the
bug, just run `org-toggle-link-display'.
As a possible solution I'm attaching this patch (little tested).
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-prevent-partial-fontification-link-display-full.patch --]
[-- Type: text/x-patch, Size: 1252 bytes --]
From caf32a7e1fb1b4bddfa011520f5403d5b6b19ddd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 8 Jun 2021 01:55:02 +0200
Subject: [PATCH] org.el: prevent partial fontification when a link is
displayed full
* lisp/org.el (org-activate-links): apply `face-property' variable in
other cases when handle invisible parts in bracket links
---
lisp/org.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..b55d8798a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5224,9 +5224,11 @@ This includes angle, plain, and bracket links."
,(or (org-link-get-parameter type :display)
'org-link))
properties)))
+ (add-face-text-property start visible-start face-property)
(add-text-properties start visible-start hidden)
- (add-face-text-property visible-start visible-end face-property)
+ (add-face-text-property visible-start visible-end face-property)
(add-text-properties visible-start visible-end properties)
+ (add-face-text-property visible-end end face-property)
(add-text-properties visible-end end hidden)
(org-rear-nonsticky-at visible-start)
(org-rear-nonsticky-at visible-end)))
--
2.31.1
^ permalink raw reply related [relevance 9%]
* org-critical-edition (a package for philologists and classicists)
@ 2021-06-07 13:09 10% Juan Manuel Macías
2021-06-14 8:50 6% ` Christian Moe
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-07 13:09 UTC (permalink / raw)
To: orgmode
Hi all,
I have uploaded the (very) initial version of my package
org-critical-edition:
https://gitlab.com/maciaschain/org-critical-edition
This package lets you prepare a philological critical edition in Org
Mode. The natural output is LaTeX with the reledmac package
(https://www.ctan.org/pkg/reledmac).
(For those who are not philologists, this is an example of critical
edition that I typesetted recently: https://imgur.com/a/drqCib5)
Feedback welcome!
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: literate programming, development log -- ideas?
@ 2021-06-07 12:00 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-07 12:00 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg,
Greg Minshall writes:
> but i also feel a need for something that might be called a lab
> notebook, a development log, of ideas, including dead ends, i pursue
> during the development process, with links, etc.. but, i'm not really
> sure how to structure this bit, how to integrate it in the rest of the
> .org file -- i.e., as a separate heading, or related to the code section
> that (originally) was under development when the notes were created.
> or...? etc.
I use `org-add-note' a lot, in a wide variety of scenarios. According to their
docstring:
"Add a note to the current entry.
This is done in the same way as adding a state change note."
And I've set (setq org-log-into-drawer t)
On the other hand, maybe you can find interesting the org-marginalia package:
(https://github.com/nobiot/org-marginalia).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
2021-06-04 11:31 13% ` Juan Manuel Macías
@ 2021-06-06 22:34 13% ` Juan Manuel Macías
2021-06-08 0:24 9% ` [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.) Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-06 22:34 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> To simplify what I mentioned in my previous message, the bug is simply
> reproducible with any link, when running `org-toggle-link-display'.
>
> I'm not sure, but I would say it was introduced in the commit:
>
> 8bdcf51ac lisp/org.el: Update previews correctly when color chnages
I correct myself. I think the commit where this problem was introduced is:
979e82fc3 Make sure that headline faces take precedence
Best regards,
Juan Manuel
^ permalink raw reply [relevance 13%]
* Re: [PATCH] Allow LaTeX reference command (\ref) to be customised
@ 2021-06-06 18:29 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-06 18:29 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> I've started doing some more cross-referencing in documents exported to
> LaTeX, and a hardcoded use of \ref has begun to stand out to me as a
> rather annoying thing. Hypperef provides \autoref for adding helpful
> prefixes (section, figure, etc.), and there are other packages which one
> may want to use to generate 'clever' references (like cleveref with
> \cref).
>
> As such, I think that the hardcoded \ref should actually be turned into
> a customisable format string, which is what the attached patch does.
I think it's a great idea. There are many options in LaTeX to manage
cross references, beyond the standar \ref. I use the varioref package a
lot (https://www.ctan.org/pkg/varioref).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
2021-06-03 21:11 10% [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
@ 2021-06-04 11:31 13% ` Juan Manuel Macías
2021-06-06 22:34 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-04 11:31 UTC (permalink / raw)
To: orgmode
Hello again,
To simplify what I mentioned in my previous message, the bug is simply
reproducible with any link, when running `org-toggle-link-display'.
I'm not sure, but I would say it was introduced in the commit:
8bdcf51ac lisp/org.el: Update previews correctly when color chnages
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi all,
>
> In master:
>
> if I do:
>
> (org-link-set-parameters "foo"
> :display 'full
> :face '(:foreground "chocolate" :weight bold :underline t))
>
> and then:
>
> [[foo:target][description]]
>
> the face parameter is only applied in the description part.
>
> Expected result: shouldn't the face be applied to the entire link?
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 13%]
* [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part
@ 2021-06-03 21:11 10% Juan Manuel Macías
2021-06-04 11:31 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-03 21:11 UTC (permalink / raw)
To: orgmode
Hi all,
In master:
if I do:
(org-link-set-parameters "foo"
:display 'full
:face '(:foreground "chocolate" :weight bold :underline t))
and then:
[[foo:target][description]]
the face parameter is only applied in the description part.
Expected result: shouldn't the face be applied to the entire link?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Remove all Org metadata with header argument `:comments org'
@ 2021-06-03 14:54 10% Juan Manuel Macías
2021-06-20 13:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-06-03 14:54 UTC (permalink / raw)
To: orgmode
I am writing an *.el file from an *.org file (and then I run
org-babel-tangle). With the header argument `:comments org' not only the
text in my org file is converted to comments (my desired goal) but also
the drawers, keywords and other Org metadata. Since I don't see that all
that stuff is necessary in a source file, wouldn't it be better to get
rid of it during the tangle process, leaving only pure content as
comment strings? Maybe converting the Org file content to plain text
with ox-ascii, or something like that?
What do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Format babel code block for export?
@ 2021-06-02 9:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-02 9:42 UTC (permalink / raw)
To: Galaxy Being; +Cc: orgmode
Hi Lawrence,
You can use multiple blocks and noweb reference syntax
(https://orgmode.org/manual/Noweb-Reference-Syntax.html):
#+NAME:block1
#+begin_src haskell :results silent :exports none
:{
#+end_src
#+NAME:block2
#+begin_src haskell :results silent :exports none
maximum'' :: (Ord a) => [a] -> a
maximum'' = foldl1 (\x acc -> if x > acc then x else acc)
#+end_src
#+NAME:block3
#+begin_src haskell :results silent :exports none
:}
#+end_src
# for export
#+begin_src haskell :noweb yes :exports code
<<block2>>
#+end_src
# for evaluation
#+begin_src haskell :noweb yes :results silent :exports none
<<block1>>
<<block2>>
<<block3>>
#+end_src
Best regards,
Juan Manuel
Galaxy Being <borgauf@gmail.com> writes:
> I have this
>
> #+begin_src haskell :results silent :exports code
> :{
> maximum'' :: (Ord a) => [a] -> a
> maximum'' = foldl1 (\x acc -> if x > acc then x else acc)
> :}
> #+end_src
>
> but on export to HTML (or LaTex) I'd like to suppress the :{ and :} to
> just show the code
>
> maximum'' :: (Ord a) => [a] -> a
> maximum'' = foldl1 (\x acc -> if x > acc then x else acc)
>
> Also, this
>
> #+begin_src haskell :results verbatim :exports both
> maximum'' [1,3,5,2,4]
> #+end_src
>
> I'd like to export the code part with a > REPL prompt included, e.g.,
>
>> maximum'' [1,3,5,2,4]
>
> I once saw some similar tricks, but I've searched and searched and
> can't find them again. There's probably other html export formatting
> I'd like too, but if anyone can point me to that mystery doc I'd
> appreciate it.
>
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf@gmail.com
>
^ permalink raw reply [relevance 10%]
* Re: suggestion to change default org-latex-pdf-process to latexmk
@ 2021-06-02 8:40 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-02 8:40 UTC (permalink / raw)
To: Stefan Nobis; +Cc: orgmode
Stefan Nobis writes:
> An alternative may be to use latexmk only if citations are found (new
> feature, new dependencies). Or a wrapper that checks whether latexmk
> is available and works (e.g. trying to call "latexmk --version") and
> falls back to the old routine of manually running the engine and
> bibtex/biber if necessary.
Another possibility would be to add to the documentation all the
instructions needed on how to properly configure `org-latex-pdf-process'
with latexmk, for those users who wish to use bibtex or biblatex.
Although latexmk is also useful for many packages that need multiple
compilations, indexes, etc.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: suggestion to change default org-latex-pdf-process to latexmk
@ 2021-06-01 15:52 10% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-06-01 15:52 UTC (permalink / raw)
To: Bruce D'Arcus; +Cc: orgmode
Hi Bruce,
Bruce D'Arcus writes:
> So what do LaTeX users think about changing the default for
> "org-latex-pdf-process" to "latexmk"?
It sounds like a good idea to me. In fact I have `org-latex-pdf-process'
set to latexmk in my ~ /.emacs (with the option to always compile with
LuaTeX).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* An attempt to convert Elfeed entries (with parameters) to Org trees
@ 2021-05-31 10:40 9% Juan Manuel Macías
2021-06-23 14:56 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-31 10:40 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
Hi all,
I like to keep up to date with new LaTeX packages that are being
uploaded to CTAN and I'm subscribed to the CTAN news feed. I always use
Elfeed to check my subscriptions, but it occurred to me to write a
function (with org-map-entries) to be able to pass Elfeed entries (with
certain parameters) to Org trees.
For example, something like:
* New on CTAN
:PROPERTIES:
:ELFEED: @6-months-ago +TeX New on CTAN
:END:
Or, for /This Month in Org/:
* /This Month in Org/
:PROPERTIES:
:ELFEED: @3-months-ago +tmio
:END:
And then run `my-org/insert-entries-elfeed'.
If anyone wants to try it, I attach an Org document with the code, which
is very preliminary, not too fancy and quite improvable. Feedback
welcome! :-)
Best regards,
Juan Manuel
[-- Attachment #2: elfeed-to-org.org --]
[-- Type: application/vnd.lotus-organizer, Size: 3719 bytes --]
^ permalink raw reply [relevance 9%]
* Re: TMIO Pre-release, request for feedback
@ 2021-05-30 19:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-30 19:42 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
Timothy writes:
> Hi Everyone,
>
> As we arrive at the end of May, I'm about to publish the 3rd issue of
> /This Month in Org/. I thought I'd share the current draft with the list
> the day before I publish to so that those of you who are interested have
> the chance to point out any errors, let me know if there's anything I
> haven't covered that you'd like to see, along with any other feedback
> you may have.
>
> For the next day, you can find the draft at:
> https://blog.tecosaur.com/tmio/DRAFT-2021-05-31.html
> and then once published it will live at:
> https://blog.tecosaur.com/tmio/2021-05-31.html
Thank you very much for your excellent work, and for all the effort and
time you put in it. I think your /This Month in Org/ conveys, above all,
something very valuable that all Org users share: an immense and
uncompromising enthusiasm for Org and Emacs :-D
I like the design of the site: very clear and readable.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-26 23:02 6% ` Juan Manuel Macías
@ 2021-05-29 20:22 6% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-05-29 20:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I'm sorry, it's my fault. It's already fixed. I think the patch attached
> here should apply well...
Applied. Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 20:37 10% ` Juan Manuel Macías
@ 2021-05-29 2:42 6% ` Andreas Gösele
0 siblings, 0 replies; 200+ results
From: Andreas Gösele @ 2021-05-29 2:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Andreas Gösele writes:
>
>> I tried it, but it doesn't work. It leaves the simple quotes
>> untouched. Did you test it and did it work then?
>
> I forgot to tell you (sorry!) that you should set the variable
> `org-export-allow-bind-keywords' as non-nil:
>
> (setq org-export-allow-bind-keywords t)
With this the filter works. Thanks a lot.
Andreas
^ permalink raw reply [relevance 6%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 20:27 7% ` Andreas Gösele
@ 2021-05-28 20:37 10% ` Juan Manuel Macías
2021-05-29 2:42 6% ` Andreas Gösele
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-28 20:37 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
Hi Andreas,
Andreas Gösele writes:
> I tried it, but it doesn't work. It leaves the simple quotes
> untouched. Did you test it and did it work then?
I forgot to tell you (sorry!) that you should set the variable
`org-export-allow-bind-keywords' as non-nil:
(setq org-export-allow-bind-keywords t)
If you are going to use that filter in many documents, you can better add to your
~ /.emacs:
(add-to-list 'org-export-filter-final-output-functions 'single-quote-filter)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 17:02 9% ` Juan Manuel Macías
@ 2021-05-28 20:27 7% ` Andreas Gösele
2021-05-28 20:37 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Andreas Gösele @ 2021-05-28 20:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Thanks Juan Manuel!
I tried it, but it doesn't work. It leaves the simple quotes
untouched. Did you test it and did it work then?
Best regards,
Andreas
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Andreas,
>
> A quick fix (for LaTeX, odt and HTML), if you want to use second-level
> quotes as first-level quotes in parts of your document, could be to
> define a filter. You must put these quotes as ´ ... ´ (for example):
>
> #+LANGUAGE: de
> #+OPTIONS: ':t
>
> #+BIND: org-export-filter-final-output-functions (single-quote-filter)
> #+begin_src emacs-lisp :exports results :results none
>
> (defun single-quote-filter (text backend info)
> (cond ((or (org-export-derived-backend-p backend 'html)
> (org-export-derived-backend-p backend 'odt))
> (replace-regexp-in-string "´\\([[:graph:]]+\\)" "‚\\1"
> (replace-regexp-in-string "\\([[:graph:]]+\\)´" "\\1‘"
> text)))
> ((org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "´\\([[:graph:]]+\\)" "‚\\\\glq{}\\1"
> (replace-regexp-in-string "\\([[:graph:]]+\\)´" "\\1\\\\grq{}"
> text)))))
> #+end_src
>
> It's a ´test´. "Please".
>
> Best regards,
>
> Juan Manuel
>
> Andreas Gösele writes:
>
>> Thanks Juan Manuel!
>>
>> Your suggestion works for LaTeX, but I need the other formats too. I
>> tried to convert the LaTeX document with pandoc, tex4h and latex2html to
>> odt and html but none of them produces the correct output.
>>
>> So I'm wondering whether there is any way to make org export to
>> recognize single quotes also outside from double quote. It should be
>> possible as inner quotes is not the only use of simple quotes.
>>
>> Thanks again!
>>
>> Andreas
>>
>> Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>>> Hi Andreas,
>>>
>>> I don't know if this is a bug, but I would say that in principle it's
>>> the expected result. Single quotes are understood here as inner quotes
>>> or second-level quotation marks, therefore they are only activated
>>> nested in text with first level quotes: " ... '...' ... "
>>>
>>> lorem "ipsum 'dolor sit' amet"
>>>
>>> For LaTeX output, however, the csquotes package is a more powerful
>>> option to control the correct quotation marks for each language. For
>>> example:
>>>
>>> #+LaTeX_Header: \usepackage[german,english]{babel}
>>> #+LaTeX_Header: \usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
>>> #+LaTeX_Header: \MakeOuterQuote{"}
>>> #+LaTeX_Header: \MakeInnerQuote{´}
>>>
>>> #+LaTeX: \selectlanguage{german}\EnableQuotes
>>> It's a ´test´. "Please".
>>>
>>> lorem "ipsum ´dolor´ sit" amet
>>>
>>> Best regards,
>>>
>>> Juan Manuel
>>>
>>> Andreas Gösele writes:
>>>
>>>> Hi,
>>>>
>>>> even using "smart quotes", single quotes are not correctly exported into
>>>> html, odt or latex.
>>>>
>>>> I have as document:
>>>>
>>>> | #+LANGUAGE: de
>>>> | #+OPTIONS: ':t
>>>> | #+OPTIONS: toc:nil
>>>> | It's a 'test'. "Please".
>>>>
>>>> If I export it to html I get:
>>>>
>>>> | It’s a ’test’. „Please“.
>>>>
>>>> I should get:
>>>>
>>>> | It’s a ‚test‘. „Please“.
>>>>
>>>> If I export to latex I get:
>>>>
>>>> | It's a 'test'. "`Please"'.
>>>>
>>>> I should get:
>>>>
>>>> | It's a \glq{}test\grq{}. "`Please"'.
>>>>
>>>> If I export to odt I get:
>>>>
>>>> | It’s a ’test’. „Please“.
>>>>
>>>> I should get:
>>>>
>>>> | It’s a ‚test‘. „Please“.
>>>>
>>>> (The odt example outputs use utf8, I hope it gets transmitted.)
>>>>
>>>> So in all three cases apostrophes and double quotes are correctly
>>>> exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
>>>> en".
>>>>
>>>> I have org-mode 9.3 with emacs 27.1.
>>>>
>>>> What could I do to get single quotes to be exported correctly?
>>>>
>>>> Thanks a lot!
>>>>
>>>> Andreas
>>>>
^ permalink raw reply [relevance 7%]
* Re: Smart quotes not working correctly with single quotes
@ 2021-05-28 20:19 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-28 20:19 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicholas,
Nicolas Goaziou writes:
> Genuine question: what language uses two different styles of outer
> (level 1) quotes? And in what context?
I answer in the case of Spanish. In Spanish the level 1 quotes are «»
(french quotes). The level 2 are “...” (english quotes). Only in some
cases, and according to some writers and manuals, single quotation marks
‘...’ are correct as 1 level quotes (left single quotation mark ...
right single quotation mark), in short segments, generally when you want
to indicate the translation of a term. i.e.:
car (‘coche’)
Anyway, in Spanish it is not correct to use second level quotes “...” as
first-level quotes. I do not know if it is correct in German.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 15:42 7% ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
@ 2021-05-28 17:55 0% ` Albert Krewinkel
2 siblings, 0 replies; 200+ results
From: Albert Krewinkel @ 2021-05-28 17:55 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Juan Manuel =?utf-8?Q?Mac=C3=ADas?=
Andreas Gösele <agoesele@sju.edu> writes:
> [...] I tried to convert the LaTeX document with pandoc, tex4h and
> latex2html to odt and html but none of them produces the correct
> output.
>
> So I'm wondering whether there is any way to make org export to
> recognize single quotes also outside from double quote. It should be
> possible as inner quotes is not the only use of simple quotes.
I apologize for the non-Emacs solution, but you can use pandoc in
combination with the following Lua filter to get the desired result:
https://github.com/pandoc/lua-filters/tree/master/pandoc-quotes.lua
For LaTeX output, you can also pass -Vcsquotes as a parameter to force
pandoc to make use of the csquotes package. Both should give you the
desired results.
HTH
> Juan Manuel MacÃas <maciaschain@posteo.net> writes:
>
>> Hi Andreas,
>>
>> I don't know if this is a bug, but I would say that in principle it's
>> the expected result. Single quotes are understood here as inner quotes
>> or second-level quotation marks, therefore they are only activated
>> nested in text with first level quotes: " ... '...' ... "
>>
>> lorem "ipsum 'dolor sit' amet"
>>
>> For LaTeX output, however, the csquotes package is a more powerful
>> option to control the correct quotation marks for each language. For
>> example:
>>
>> #+LaTeX_Header: \usepackage[german,english]{babel}
>> #+LaTeX_Header: \usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
>> #+LaTeX_Header: \MakeOuterQuote{"}
>> #+LaTeX_Header: \MakeInnerQuote{´}
>>
>> #+LaTeX: \selectlanguage{german}\EnableQuotes
>> It's a ´test´. "Please".
>>
>> lorem "ipsum ´dolor´ sit" amet
>>
>> Best regards,
>>
>> Juan Manuel
>>
>> Andreas Gösele writes:
>>
>>> Hi,
>>>
>>> even using "smart quotes", single quotes are not correctly exported into
>>> html, odt or latex.
>>>
>>> I have as document:
>>>
>>> | #+LANGUAGE: de
>>> | #+OPTIONS: ':t
>>> | #+OPTIONS: toc:nil
>>> | It's a 'test'. "Please".
>>>
>>> If I export it to html I get:
>>>
>>> | It’s a ’test’. „Please“.
>>>
>>> I should get:
>>>
>>> | It’s a ‚test‘. „Please“.
>>>
>>> If I export to latex I get:
>>>
>>> | It's a 'test'. "`Please"'.
>>>
>>> I should get:
>>>
>>> | It's a \glq{}test\grq{}. "`Please"'.
>>>
>>> If I export to odt I get:
>>>
>>> | It’s a ’test’. „Please“.
>>>
>>> I should get:
>>>
>>> | It’s a ‚test‘. „Please“.
>>>
>>> (The odt example outputs use utf8, I hope it gets transmitted.)
>>>
>>> So in all three cases apostrophes and double quotes are correctly
>>> exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
>>> en".
>>>
>>> I have org-mode 9.3 with emacs 27.1.
>>>
>>> What could I do to get single quotes to be exported correctly?
>>>
>>> Thanks a lot!
>>>
>>> Andreas
>>>
--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
^ permalink raw reply [relevance 0%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 15:42 7% ` Andreas Gösele
@ 2021-05-28 17:02 9% ` Juan Manuel Macías
2021-05-28 20:27 7% ` Andreas Gösele
2021-05-28 17:55 0% ` Albert Krewinkel
2 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-28 17:02 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
Hi Andreas,
A quick fix (for LaTeX, odt and HTML), if you want to use second-level
quotes as first-level quotes in parts of your document, could be to
define a filter. You must put these quotes as ´ ... ´ (for example):
#+LANGUAGE: de
#+OPTIONS: ':t
#+BIND: org-export-filter-final-output-functions (single-quote-filter)
#+begin_src emacs-lisp :exports results :results none
(defun single-quote-filter (text backend info)
(cond ((or (org-export-derived-backend-p backend 'html)
(org-export-derived-backend-p backend 'odt))
(replace-regexp-in-string "´\\([[:graph:]]+\\)" "‚\\1"
(replace-regexp-in-string "\\([[:graph:]]+\\)´" "\\1‘"
text)))
((org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "´\\([[:graph:]]+\\)" "‚\\\\glq{}\\1"
(replace-regexp-in-string "\\([[:graph:]]+\\)´" "\\1\\\\grq{}"
text)))))
#+end_src
It's a ´test´. "Please".
Best regards,
Juan Manuel
Andreas Gösele writes:
> Thanks Juan Manuel!
>
> Your suggestion works for LaTeX, but I need the other formats too. I
> tried to convert the LaTeX document with pandoc, tex4h and latex2html to
> odt and html but none of them produces the correct output.
>
> So I'm wondering whether there is any way to make org export to
> recognize single quotes also outside from double quote. It should be
> possible as inner quotes is not the only use of simple quotes.
>
> Thanks again!
>
> Andreas
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Hi Andreas,
>>
>> I don't know if this is a bug, but I would say that in principle it's
>> the expected result. Single quotes are understood here as inner quotes
>> or second-level quotation marks, therefore they are only activated
>> nested in text with first level quotes: " ... '...' ... "
>>
>> lorem "ipsum 'dolor sit' amet"
>>
>> For LaTeX output, however, the csquotes package is a more powerful
>> option to control the correct quotation marks for each language. For
>> example:
>>
>> #+LaTeX_Header: \usepackage[german,english]{babel}
>> #+LaTeX_Header: \usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
>> #+LaTeX_Header: \MakeOuterQuote{"}
>> #+LaTeX_Header: \MakeInnerQuote{´}
>>
>> #+LaTeX: \selectlanguage{german}\EnableQuotes
>> It's a ´test´. "Please".
>>
>> lorem "ipsum ´dolor´ sit" amet
>>
>> Best regards,
>>
>> Juan Manuel
>>
>> Andreas Gösele writes:
>>
>>> Hi,
>>>
>>> even using "smart quotes", single quotes are not correctly exported into
>>> html, odt or latex.
>>>
>>> I have as document:
>>>
>>> | #+LANGUAGE: de
>>> | #+OPTIONS: ':t
>>> | #+OPTIONS: toc:nil
>>> | It's a 'test'. "Please".
>>>
>>> If I export it to html I get:
>>>
>>> | It’s a ’test’. „Please“.
>>>
>>> I should get:
>>>
>>> | It’s a ‚test‘. „Please“.
>>>
>>> If I export to latex I get:
>>>
>>> | It's a 'test'. "`Please"'.
>>>
>>> I should get:
>>>
>>> | It's a \glq{}test\grq{}. "`Please"'.
>>>
>>> If I export to odt I get:
>>>
>>> | It’s a ’test’. „Please“.
>>>
>>> I should get:
>>>
>>> | It’s a ‚test‘. „Please“.
>>>
>>> (The odt example outputs use utf8, I hope it gets transmitted.)
>>>
>>> So in all three cases apostrophes and double quotes are correctly
>>> exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
>>> en".
>>>
>>> I have org-mode 9.3 with emacs 27.1.
>>>
>>> What could I do to get single quotes to be exported correctly?
>>>
>>> Thanks a lot!
>>>
>>> Andreas
>>>
^ permalink raw reply [relevance 9%]
* Re: Smart quotes not working correctly with single quotes
2021-05-28 10:10 9% ` Juan Manuel Macías
@ 2021-05-28 15:42 7% ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Andreas Gösele @ 2021-05-28 15:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Thanks Juan Manuel!
Your suggestion works for LaTeX, but I need the other formats too. I
tried to convert the LaTeX document with pandoc, tex4h and latex2html to
odt and html but none of them produces the correct output.
So I'm wondering whether there is any way to make org export to
recognize single quotes also outside from double quote. It should be
possible as inner quotes is not the only use of simple quotes.
Thanks again!
Andreas
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Andreas,
>
> I don't know if this is a bug, but I would say that in principle it's
> the expected result. Single quotes are understood here as inner quotes
> or second-level quotation marks, therefore they are only activated
> nested in text with first level quotes: " ... '...' ... "
>
> lorem "ipsum 'dolor sit' amet"
>
> For LaTeX output, however, the csquotes package is a more powerful
> option to control the correct quotation marks for each language. For
> example:
>
> #+LaTeX_Header: \usepackage[german,english]{babel}
> #+LaTeX_Header: \usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header: \MakeOuterQuote{"}
> #+LaTeX_Header: \MakeInnerQuote{´}
>
> #+LaTeX: \selectlanguage{german}\EnableQuotes
> It's a ´test´. "Please".
>
> lorem "ipsum ´dolor´ sit" amet
>
> Best regards,
>
> Juan Manuel
>
> Andreas Gösele writes:
>
>> Hi,
>>
>> even using "smart quotes", single quotes are not correctly exported into
>> html, odt or latex.
>>
>> I have as document:
>>
>> | #+LANGUAGE: de
>> | #+OPTIONS: ':t
>> | #+OPTIONS: toc:nil
>> | It's a 'test'. "Please".
>>
>> If I export it to html I get:
>>
>> | It’s a ’test’. „Please“.
>>
>> I should get:
>>
>> | It’s a ‚test‘. „Please“.
>>
>> If I export to latex I get:
>>
>> | It's a 'test'. "`Please"'.
>>
>> I should get:
>>
>> | It's a \glq{}test\grq{}. "`Please"'.
>>
>> If I export to odt I get:
>>
>> | It’s a ’test’. „Please“.
>>
>> I should get:
>>
>> | It’s a ‚test‘. „Please“.
>>
>> (The odt example outputs use utf8, I hope it gets transmitted.)
>>
>> So in all three cases apostrophes and double quotes are correctly
>> exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
>> en".
>>
>> I have org-mode 9.3 with emacs 27.1.
>>
>> What could I do to get single quotes to be exported correctly?
>>
>> Thanks a lot!
>>
>> Andreas
>>
^ permalink raw reply [relevance 7%]
* Re: Smart quotes not working correctly with single quotes
@ 2021-05-28 10:10 9% ` Juan Manuel Macías
2021-05-28 15:42 7% ` Andreas Gösele
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-28 10:10 UTC (permalink / raw)
To: Andreas Gösele; +Cc: orgmode
Hi Andreas,
I don't know if this is a bug, but I would say that in principle it's
the expected result. Single quotes are understood here as inner quotes
or second-level quotation marks, therefore they are only activated
nested in text with first level quotes: " ... '...' ... "
lorem "ipsum 'dolor sit' amet"
For LaTeX output, however, the csquotes package is a more powerful
option to control the correct quotation marks for each language. For
example:
#+LaTeX_Header: \usepackage[german,english]{babel}
#+LaTeX_Header: \usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header: \MakeOuterQuote{"}
#+LaTeX_Header: \MakeInnerQuote{´}
#+LaTeX: \selectlanguage{german}\EnableQuotes
It's a ´test´. "Please".
lorem "ipsum ´dolor´ sit" amet
Best regards,
Juan Manuel
Andreas Gösele writes:
> Hi,
>
> even using "smart quotes", single quotes are not correctly exported into
> html, odt or latex.
>
> I have as document:
>
> | #+LANGUAGE: de
> | #+OPTIONS: ':t
> | #+OPTIONS: toc:nil
> | It's a 'test'. "Please".
>
> If I export it to html I get:
>
> | It’s a ’test’. „Please“.
>
> I should get:
>
> | It’s a ‚test‘. „Please“.
>
> If I export to latex I get:
>
> | It's a 'test'. "`Please"'.
>
> I should get:
>
> | It's a \glq{}test\grq{}. "`Please"'.
>
> If I export to odt I get:
>
> | It’s a ’test’. „Please“.
>
> I should get:
>
> | It’s a ‚test‘. „Please“.
>
> (The odt example outputs use utf8, I hope it gets transmitted.)
>
> So in all three cases apostrophes and double quotes are correctly
> exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
> en".
>
> I have org-mode 9.3 with emacs 27.1.
>
> What could I do to get single quotes to be exported correctly?
>
> Thanks a lot!
>
> Andreas
>
^ permalink raw reply [relevance 9%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-26 21:05 5% ` Nicolas Goaziou
@ 2021-05-26 23:02 6% ` Juan Manuel Macías
2021-05-29 20:22 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-26 23:02 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]
Nicolas Goaziou writes:
> I cannot apply it on top of master however. On what commit did you base
> it?
I'm sorry, it's my fault. It's already fixed. I think the patch attached
here should apply well...
> [...]
> I don't know if this example is a good illustration because you can
> currently achieve the same with:
>
> #+attr_latex: :options {german}
>
> #+begin_foreigndisplayquote
> some text in German...
> #+end_foreigndisplayquote
>
> Are there use cases that would be better than using special blocks as in
> the example above?
I think I have not explained well about the rationale for this patch,
sorry. The advantage (IMHO) of being able to choose between several
LaTeX environments to the export of the quote blocks has more to do with
the consistency between various output formats (and a single origin). Of
course, quotation, quoting, foreigndisplayquote and a few more can be
obtained using special blocks. But for LaTeX they are just different
styles and ways to create a quote environment. At the end of the day
they are all 'quote'. It's ok that Org has only one single quote block
that is exported indistinctly to LaTeX, html, odt, etc. (Org tends to be
format agnostic and focuses more on the logical structure of the text).
But in the case of LaTeX it would be nice if the user could choose
between several ways or formats to do quotes (in LaTeX), without
resorting to special blocks. On the other hand, the standard LaTeX
`quote' environment is already far exceeded by other more powerful
options, like the csquotes package.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block.patch --]
[-- Type: text/x-patch, Size: 4973 bytes --]
From c2e39f5f3046d7a8e90878351b35c89656dacdfc Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 26 May 2021 23:58:05 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* doc/org-manual.org (Quote blocks in LaTeX export): manual updated
* etc/ORG-NEWS (Support quote blocks in LaTeX export): news updated
* lisp/ox-latex.el (latex): add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
doc/org-manual.org | 42 ++++++++++++++++++++++++++++++++++++++++++
etc/ORG-NEWS | 7 +++++++
lisp/ox-latex.el | 22 ++++++++++++++++++++--
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 118d97e0e..dd51df27e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13919,6 +13919,48 @@ To eat the world’s due, by the grave and thee.
,#+END_VERSE
#+end_src
+*** Quote blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to quote blocks.
+:END:
+
+#+cindex: quote blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+#+cindex: org-latex-default-quote-environment
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=. For example, to choose the environment =quotation=,
+included as an alternative to =quote= in standard LaTeX classes:
+
+#+begin_example
+,#+ATTR_LATEX: :environment quotation
+,#+BEGIN_QUOTE
+some text...
+,#+END_QUOTE
+#+end_example
+
+To choose the =foreigndisplayquote= environment, included in the LaTeX
+package =csquotes=, with the =german= option, use this syntax:
+
+#+begin_example
+,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
+,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
+,#+BEGIN_QUOTE
+some text in German...
+,#+END_QUOTE
+#+end_example
+
+#+texinfo: @noindent
+which is exported to LaTeX as
+
+#+begin_example
+\begin{foreigndisplayquote}{german}
+some text in German...
+\end{foreigndisplayquote}
+#+end_example
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8707222e0..c8a93c933 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -244,6 +244,13 @@ require the external LaTeX package =verse.sty=, wich is an extension
of the standard LaTeX environment. The purpose of these attributes is
explained below.
+*** Support quote blocks in LaTeX export
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=.
+
*** =org-set-tags-command= selects tags from ~org-global-tags-completion-table~
Let ~org-set-tags-command~ TAB fast tag completion interface complete
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..9e2e7be47 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+ (:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' blocks."
+ :group 'org-export-latex
+ :package-version '(Org . "9.5")
+ :type 'string
+ :safe t)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,9 +2903,19 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let ((environment
+ (or (org-export-read-attribute :attr_latex quote-block :environment)
+ (plist-get info :latex-default-quote-environment)))
+ (options
+ (or (org-export-read-attribute :attr_latex quote-block :options)
+ "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ environment
+ options
+ contents
+ environment)
+ info)))
;;;; Radio Target
--
2.31.1
^ permalink raw reply related [relevance 6%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 20:50 7% ` Juan Manuel Macías
@ 2021-05-26 21:05 5% ` Nicolas Goaziou
2021-05-26 23:02 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-26 21:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is the updated patch, with the corresponding additions in the
> manual and ORG-NEWS.
Thanks.
I cannot apply it on top of master however. On what commit did you base
it?
There are also some nits, but I can fix them when applying your patch.
> +#+cindex: quote blocks, in @LaTeX{} export
> +#+cindex: @samp{ATTR_LATEX}, keyword
This is not related to your patch (it can be encountered elsewhere), but
the index entry above is too generic to be useful. Maybe
#+cindex: @samp{ATTR_LATEX}, in quote blocks
would be better.
> +#+cindex: org-latex-default-quote-environment
This should be #+vindex: ...
> +The LaTeX export back-end accepts two attributes for quote blocks:
> +=:environment=, for an arbitrary quoting environment (the default
> +value is that of =org-latex-default-quote-environment=: ="quote"=) and
~org-latex-default-quote-environment~ and ~"quote"~ since they both
refer to Lisp code, not Org syntax.
> +=:options=. For example, to choose the environment =quotation=,
> +included as an alternative to =quote= in standard LaTeX classes:
> +
> +#+begin_example
> +,#+ATTR_LATEX: :environment quotation
> +,#+BEGIN_QUOTE
> +some text...
> +,#+END_QUOTE
> +#+end_example
Note that you can currently write, perhaps more elegantly,
#+begin_quotation
some text...
#+end_quotation
> +To choose the =foreigndisplayquote= environment, included in the LaTeX
> +package =csquotes=, with the =german= option, use this syntax:
> +
> +#+begin_example
> +,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
> +,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
> +,#+BEGIN_QUOTE
> +some text in German...
> +,#+END_QUOTE
> +#+end_example
I don't know if this example is a good illustration because you can
currently achieve the same with:
#+attr_latex: :options {german}
#+begin_foreigndisplayquote
some text in German...
#+end_foreigndisplayquote
Are there use cases that would be better than using special blocks as in
the example above?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 15:52 6% ` Nicolas Goaziou
@ 2021-05-25 20:50 7% ` Juan Manuel Macías
2021-05-26 21:05 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-25 20:50 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi Nicolas,
Nicolas Goaziou writes:
> You can do it in the same patch.
Here is the updated patch, with the corresponding additions in the
manual and ORG-NEWS.
Best regards,
Juan Manuel
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block.patch --]
[-- Type: text/x-patch, Size: 4973 bytes --]
From 987566d52cd36c990d3db3f83d2c6433254ac2e3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 25 May 2021 22:18:06 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* doc/org-manual.org (Quote blocks in LaTeX export): manual updated
* etc/ORG-NEWS (Support quote blocks in LaTeX export): news updated
* lisp/ox-latex.el (latex): add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
doc/org-manual.org | 42 ++++++++++++++++++++++++++++++++++++++++++
etc/ORG-NEWS | 7 +++++++
lisp/ox-latex.el | 22 ++++++++++++++++++++--
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 118d97e0e..dd51df27e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13919,6 +13919,48 @@ To eat the world’s due, by the grave and thee.
,#+END_VERSE
#+end_src
+*** Quote blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to quote blocks.
+:END:
+
+#+cindex: quote blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+#+cindex: org-latex-default-quote-environment
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=. For example, to choose the environment =quotation=,
+included as an alternative to =quote= in standard LaTeX classes:
+
+#+begin_example
+,#+ATTR_LATEX: :environment quotation
+,#+BEGIN_QUOTE
+some text...
+,#+END_QUOTE
+#+end_example
+
+To choose the =foreigndisplayquote= environment, included in the LaTeX
+package =csquotes=, with the =german= option, use this syntax:
+
+#+begin_example
+,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
+,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
+,#+BEGIN_QUOTE
+some text in German...
+,#+END_QUOTE
+#+end_example
+
+#+texinfo: @noindent
+which is exported to LaTeX as
+
+#+begin_example
+\begin{foreigndisplayquote}{german}
+some text in German...
+\end{foreigndisplayquote}
+#+end_example
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8707222e0..c8a93c933 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -244,6 +244,13 @@ require the external LaTeX package =verse.sty=, wich is an extension
of the standard LaTeX environment. The purpose of these attributes is
explained below.
+*** Support quote blocks in LaTeX export
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=.
+
*** =org-set-tags-command= selects tags from ~org-global-tags-completion-table~
Let ~org-set-tags-command~ TAB fast tag completion interface complete
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..9e2e7be47 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+ (:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' blocks."
+ :group 'org-export-latex
+ :package-version '(Org . "9.5")
+ :type 'string
+ :safe t)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,10 +2903,19 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let ((environment
+ (or (org-export-read-attribute :attr_latex quote-block :environment)
+ (plist-get info :latex-default-quote-environment)))
+ (options
+ (or (org-export-read-attribute :attr_latex quote-block :options)
+ "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ environment
+ options
+ contents
+ environment)
+ info)))
;;;; Radio Target
--
2.31.1
^ permalink raw reply related [relevance 7%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 12:42 8% ` Juan Manuel Macías
@ 2021-05-25 15:52 6% ` Nicolas Goaziou
2021-05-25 20:50 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-25 15:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Thank you for your indications. Attached the updated patch.
Thanks.
I forgot to ask: could you add some documentation about it in the
manual, too?
> Do you need me to prepare another patch to document the modifications
> and add them to org-NEWS?
You can do it in the same patch.
Regards,
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-25 9:21 5% ` Nicolas Goaziou
@ 2021-05-25 12:42 8% ` Juan Manuel Macías
2021-05-25 15:52 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-25 12:42 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
Hi Nicolas,
Thank you for your indications. Attached the updated patch.
Do you need me to prepare another patch to document the modifications
and add them to org-NEWS?
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
>
> Thank you. Some comments follow.
>
>> +(defcustom org-latex-default-quote-environment "quote"
>> + "Default environment used to `quote' environment."
>
> --> Default environment used for "quote" blocks.
>
>> + :group 'org-export-latex
>> + :version "24.4"
>> + :package-version '(Org . "8.0")
>
> You can remove the :version keyword. And :package-version is wrong.
>
>> + :type 'string)
>
> You also need to add :safe t
>
>> (defcustom org-latex-default-table-mode 'table
>> "Default mode for tables.
>>
>> @@ -2895,9 +2903,17 @@ channel."
>> "Transcode a QUOTE-BLOCK element from Org to LaTeX.
>> CONTENTS holds the contents of the block. INFO is a plist
>> holding contextual information."
>> + (let* ((env (org-export-read-attribute :attr_latex quote-block :environment))
>> + (opt (org-export-read-attribute :attr_latex quote-block :options))
>> + (current-env (if env env org-latex-default-quote-environment))
>> + (current-opt (if opt opt "")))
>
> We don't use global variables directly as above, but use
>
> (plist-get info :latex-default-quote-environment)
>
> instead. This could be written as
>
>
> (let ((environment
> (or (org-export-read-attribute :attr_latex quote-block :environment)
> (plist-get info :latex-default-quote-environment)))
> (options
> (or (org-export-read-attribute :attr_latex quote-block :options)
> "")))
> ...)
>
> Could you send an updated patch?
>
> Regards,
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block_updated.patch --]
[-- Type: text/x-patch, Size: 2348 bytes --]
From eea6956e1baa07c9a9753ed71be48a1e962442a9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 25 May 2021 14:02:06 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* lisp/ox-latex.el (latex): add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
lisp/ox-latex.el | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..c4f2c6f53 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+ (:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' blocks."
+ :group 'org-export-latex
+ :package-version '(Org . "9.5")
+ :type 'string
+ :safe t)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,10 +2903,19 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let ((environment
+ (or (org-export-read-attribute :attr_latex quote-block :environment)
+ (plist-get info :latex-default-quote-environment)))
+ (options
+ (or (org-export-read-attribute :attr_latex quote-block :options)
+ "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ environment
+ options
+ contents
+ environment)
+ info)))
;;;; Radio Target
--
2.31.1
^ permalink raw reply related [relevance 8%]
* Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
2021-05-24 12:14 7% [PATCH] ox-latex.el: add LaTeX attributes to quote block Juan Manuel Macías
@ 2021-05-25 9:21 5% ` Nicolas Goaziou
2021-05-25 12:42 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-25 9:21 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
Thank you. Some comments follow.
> +(defcustom org-latex-default-quote-environment "quote"
> + "Default environment used to `quote' environment."
--> Default environment used for "quote" blocks.
> + :group 'org-export-latex
> + :version "24.4"
> + :package-version '(Org . "8.0")
You can remove the :version keyword. And :package-version is wrong.
> + :type 'string)
You also need to add :safe t
> (defcustom org-latex-default-table-mode 'table
> "Default mode for tables.
>
> @@ -2895,9 +2903,17 @@ channel."
> "Transcode a QUOTE-BLOCK element from Org to LaTeX.
> CONTENTS holds the contents of the block. INFO is a plist
> holding contextual information."
> + (let* ((env (org-export-read-attribute :attr_latex quote-block :environment))
> + (opt (org-export-read-attribute :attr_latex quote-block :options))
> + (current-env (if env env org-latex-default-quote-environment))
> + (current-opt (if opt opt "")))
We don't use global variables directly as above, but use
(plist-get info :latex-default-quote-environment)
instead. This could be written as
(let ((environment
(or (org-export-read-attribute :attr_latex quote-block :environment)
(plist-get info :latex-default-quote-environment)))
(options
(or (org-export-read-attribute :attr_latex quote-block :options)
"")))
...)
Could you send an updated patch?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* [PATCH] ox-latex.el: add LaTeX attributes to quote block
@ 2021-05-24 12:14 7% Juan Manuel Macías
2021-05-25 9:21 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-24 12:14 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
Hi all,
The `quote' block is exported to LaTeX as a `quote' environment.
However, standard LaTeX classes have two environments for quotes:
`quote' and `quotation', with certain format differences: it is often
said that `quotation' is intended for longer quotes with several
paragraphs and applies a first line indent to each paragraph. In
addition there are several very popular packages that offer more
environments and features for quoting, for example `quoting' or
`csquotes', which includes a set of quote environments and very powerful
options. Even some languages as Spanish option for Babel have their own
quoting environment. Given all this variety, I think it would be nice to
offer the user at least a couple of LaTeX attributes to choose:
`:environment' (by default the environment would remain `quote') and
`:options'. I attach a possible patch for it (if the patch sounds good,
I can add the documentation for the new features).
An example with a quote in German:
#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}
#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
sich in ihr vorgesetzt, sowie über die Veranlassungen und das
Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
einer philosophischen Schrift nicht nur überflüssig, sondern um der
Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
#+end_quote
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-LaTeX-attributes-to-quote-block.patch --]
[-- Type: text/x-patch, Size: 2368 bytes --]
From 1164c3066f0ea7e639382b01c5da2d7b5b46efb8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 24 May 2021 13:19:01 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* lisp/ox-latex.el: add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
lisp/ox-latex.el | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..3704267c9 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+ (:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' environment."
+ :group 'org-export-latex
+ :version "24.4"
+ :package-version '(Org . "8.0")
+ :type 'string)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,9 +2903,17 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let* ((env (org-export-read-attribute :attr_latex quote-block :environment))
+ (opt (org-export-read-attribute :attr_latex quote-block :options))
+ (current-env (if env env org-latex-default-quote-environment))
+ (current-opt (if opt opt "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ current-env
+ current-opt
+ contents
+ current-env)
+ info)))
;;;; Radio Target
--
2.26.0
^ permalink raw reply related [relevance 7%]
* Re: [PATCH] org.el: use only link descriptions in indirect buffer names
2021-05-23 10:41 6% ` Ihor Radchenko
@ 2021-05-23 11:25 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-23 11:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Ihor Radchenko writes:
> You can simply do (org-link-display-format (org-get-heading 'no-tags))
>
> Best,
> Ihor
Oh!! I see that with my code I just reinvented the wheel :-D:
---
org-link-display-format is a compiled Lisp function in ‘ol.el’.
(org-link-display-format S)
Replace links in string S with their description.
If there is no description, use the link target.
---
Thank you very much for the suggestion, Ihor!
(new patch attached)
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-el-use-only-link-descriptions-in-indirect-buffer.patch --]
[-- Type: text/x-patch, Size: 953 bytes --]
From b859f45abaa94e546e625b7b8c9f47ed64d6b4b4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 22 May 2021 15:33:15 +0200
Subject: [PATCH] org.el: use only link descriptions in indirect buffer names
* lisp/org.el (org-tree-to-indirect-buffer): If the variable `heading'
contains a link with a description, it is replaced by the description string.
---
lisp/org.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..ca87cac67 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6895,8 +6895,7 @@ frame is not changed."
(while (> (setq level (org-outline-level)) arg)
(org-up-heading-safe)))
(setq beg (point)
- heading (org-get-heading 'no-tags))
+ heading (org-link-display-format (org-get-heading 'no-tags)))
(org-end-of-subtree t t)
(when (org-at-heading-p) (backward-char 1))
(setq end (point)))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] org.el: use only link descriptions in indirect buffer names
2021-05-22 14:12 9% [PATCH] org.el: use only link descriptions in indirect buffer names Juan Manuel Macías
@ 2021-05-23 10:41 6% ` Ihor Radchenko
2021-05-23 11:25 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-05-23 10:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> + heading (replace-regexp-in-string
> + org-link-bracket-re
> + (lambda (x)
> + (pcase (match-string 2 x)
> + (`nil (match-string 1 x))
> + ((pred stringp) (match-string 2 x))))
> + (org-get-heading 'no-tags)))
You can simply do (org-link-display-format (org-get-heading 'no-tags))
Best,
Ihor
^ permalink raw reply [relevance 6%]
* [PATCH] org.el: use only link descriptions in indirect buffer names
@ 2021-05-22 14:12 9% Juan Manuel Macías
2021-05-23 10:41 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-22 14:12 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Hi,
When a heading contains a link with a description,
`org-tree-to-indirect-buffer' can produce in the name of the indirect
buffer strings like this:
"streaming.org-[[url-media:http://192.168.1.36:8888/Radiohead%20-%20Studio%20Discography/OK%20Computer%20%281997%29/recurse.m3u][Radiohead
-- OK Computer (1997)]]-1"
I would like to propose the attached patch, so that only the link
description is used in the indirect buffer name:
"streaming.org-Radiohead -- OK Computer (1997)-1"
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-el-use-only-link-descriptions-in-indirect-buffer.patch --]
[-- Type: text/x-patch, Size: 1228 bytes --]
From b859f45abaa94e546e625b7b8c9f47ed64d6b4b4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 22 May 2021 15:33:15 +0200
Subject: [PATCH] org.el: use only link descriptions in indirect buffer names
* lisp/org.el (org-tree-to-indirect-buffer): If the variable `heading'
contains a link with a description, it is replaced by the description string.
---
lisp/org.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..ca87cac67 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6895,8 +6895,13 @@ frame is not changed."
(while (> (setq level (org-outline-level)) arg)
(org-up-heading-safe)))
(setq beg (point)
- heading (org-get-heading 'no-tags))
+ heading (replace-regexp-in-string
+ org-link-bracket-re
+ (lambda (x)
+ (pcase (match-string 2 x)
+ (`nil (match-string 1 x))
+ ((pred stringp) (match-string 2 x))))
+ (org-get-heading 'no-tags)))
(org-end-of-subtree t t)
(when (org-at-heading-p) (backward-char 1))
(setq end (point)))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* Re: An attempt to prepare critical editions within Org
2021-05-20 11:45 8% An attempt to prepare critical editions within Org Juan Manuel Macías
@ 2021-05-20 12:24 6% ` Denis Maier
0 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-05-20 12:24 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Am 20.05.2021 um 13:45 schrieb Juan Manuel Macías:
> Hi,
>
> If there is a philologist among the colisters who is working on critical
> editions (a type of text with several complex apparatus of footnotes and
> endnotes, and with numbering and various material at the margin ---an
> example of critical edition I recently typesetted for a German publisher:
> https://maciaschain.gitlab.io/lunotipia/images/muestras_cariton1.png),
> you may find the following interesting.
>
> I am working on a package, org-critical-edition, to prepare philological
> critical editions from the comfort of Org Mode. The natural backend of
> these documents should be LaTeX with the 'reledmac' package
> (https://ctan.org/pkg/reledmac), an excellent package mantained by
> Maïeul Rouquette (https://github.com/maieul/ledmac), that is the most
> mature option to work in this type of texts within LaTeX. But in the
> future I may add some support to export data to the TEI-xml standard,
> widely used in Humanities.
>
> The basic idea of my package is that the 'critical notes' are always
> hidden and only the annotated passages are shown in the text (they are
> actually Org links, but what is shown is the target, while the
> description and the target label remains invisible). Each critical note
> can be edited or created (over a marked region) in a dedicated buffer.
>
> Soon I will upload to GitLab a first version of the package (quite
> immature at the moment: feedback welcome!) but here is a brief
> screencast:
> https://lunotipia.juanmanuelmacias.com/images/org-critical-edition.mp4
>
> Best regards,
>
> Juan Manuel
>
Not a philologist, but that looks very promising.
Denis
^ permalink raw reply [relevance 6%]
* An attempt to prepare critical editions within Org
@ 2021-05-20 11:45 8% Juan Manuel Macías
2021-05-20 12:24 6% ` Denis Maier
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-20 11:45 UTC (permalink / raw)
To: orgmode
Hi,
If there is a philologist among the colisters who is working on critical
editions (a type of text with several complex apparatus of footnotes and
endnotes, and with numbering and various material at the margin ---an
example of critical edition I recently typesetted for a German publisher:
https://maciaschain.gitlab.io/lunotipia/images/muestras_cariton1.png),
you may find the following interesting.
I am working on a package, org-critical-edition, to prepare philological
critical editions from the comfort of Org Mode. The natural backend of
these documents should be LaTeX with the 'reledmac' package
(https://ctan.org/pkg/reledmac), an excellent package mantained by
Maïeul Rouquette (https://github.com/maieul/ledmac), that is the most
mature option to work in this type of texts within LaTeX. But in the
future I may add some support to export data to the TEI-xml standard,
widely used in Humanities.
The basic idea of my package is that the 'critical notes' are always
hidden and only the annotated passages are shown in the text (they are
actually Org links, but what is shown is the target, while the
description and the target label remains invisible). Each critical note
can be edited or created (over a marked region) in a dedicated buffer.
Soon I will upload to GitLab a first version of the package (quite
immature at the moment: feedback welcome!) but here is a brief
screencast:
https://lunotipia.juanmanuelmacias.com/images/org-critical-edition.mp4
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [org-footnote--allow-reference-p]
2021-05-20 10:21 0% ` [org-footnote--allow-reference-p] Uwe Brauer
@ 2021-05-20 10:38 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-20 10:38 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer writes:
> Ah! That was it, thanks!
> I think the documentation of org-footnote-action
> could be a bit more explicit and cover this case.
In the manual the use of the zero width space character is in the section
'Escape Character'. Perhaps it would be nice to add more usage examples. A
very typical (and practical) use is when you want to emphasize a part of a
word:
with /meta/<zero-with-space>literature you get (LaTeX)
\emph{meta}literature instead of the literal /meta/literature...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [org-footnote--allow-reference-p]
2021-05-20 10:17 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
@ 2021-05-20 10:21 0% ` Uwe Brauer
2021-05-20 10:38 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Uwe Brauer @ 2021-05-20 10:21 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Uwe,
> Uwe Brauer writes:
>> It seems that the function org-footnote--allow-reference-p
>> is the culprit, but which places are *forbidden* the doc string does not
>> say much.
> If you mean to insert a note in an empty cell, you can insert just
> before the note mark a zero width space (M-x insert-char RET 200b RET)
Ah! That was it, thanks!
I think the documentation of org-footnote-action
could be a bit more explicit and cover this case.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [org-footnote--allow-reference-p]
@ 2021-05-20 10:17 10% ` Juan Manuel Macías
2021-05-20 10:21 0% ` [org-footnote--allow-reference-p] Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-20 10:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer writes:
> It seems that the function org-footnote--allow-reference-p
> is the culprit, but which places are *forbidden* the doc string does not
> say much.
If you mean to insert a note in an empty cell, you can insert just
before the note mark a zero width space (M-x insert-char RET 200b RET)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Multilingual support (proposals and state of the question)
2021-05-17 16:03 6% ` Denis Maier
@ 2021-05-17 18:10 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-17 18:10 UTC (permalink / raw)
To: Denis Maier; +Cc: orgmode
Hi Denis,
Denis Maier writes:
> Why not add a :lang property to other blocks as well?
>
> #+begin_quote :lang en
> this is english.
> #+end_quote
>
> WDYT?
>
> Denis
It's an interesting possibility. However, I think that the advantage of
Org src blocks is that you can include anything you want, even quote
blocks. And you also have org-edit-special...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Multilingual support (proposals and state of the question)
2021-05-17 15:41 8% Multilingual support (proposals and state of the question) Juan Manuel Macías
@ 2021-05-17 16:03 6% ` Denis Maier
2021-05-17 18:10 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Denis Maier @ 2021-05-17 16:03 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Am 17.05.2021 um 17:41 schrieb Juan Manuel Macías:
> Hi all,
>
> I would like to start a thread on this question, leaving some basic ideas and
> sketches of my own, in case someone else wanted to join the discussion.
>
> I think it would be nice if Org Mode offered consistent support (out of
> the box) for multilingual documents. That is, those documents where
> there is a main language and it is possible to toggle between a list of
> others 'secondary' languages, in the LaTeX Babel way. Those documents
> could be consistently exported to other formats with multilingual
> support: LaTeX, of course, but also html, odt, etc.
>
> What is your opinion?
>
> I think Org documents should have three levels in multilingual management:
>
> - Short text segments, something like an 'inline block' for other languages
> - Blocks
> - Sections
>
> For short inline segments, IMHO and without the need to innovate, I
> think an excellent candidate are the links defined with
> org-link-set-parameters. For example:
>
> Lorem ipsum [[lang:de][some text in German]] dolor sit amet
>
> (For structures of this kind I found very interesting ideas here:
> https://github.com/alhassy/org-special-block-extras)
>
> As for blocks, I think of a hypothetical 'lang' block:
>
> #+begin_lang el :variant polytonic
> Some text in polytonic Greek...
> #+end_lang
>
> However, in a previous thread
> (https://orgmode.org/list/87k0og8fss.fsf@list.aleks.bg/) Aleksandar
> Dimitrov proposed an idea that seemed very suggestive, at least in
> concept: add a ':lang' argument to the Org code blocks:
>
> #+begin_src org :lang fr
> Some text in french
> #+end_src
Why not add a :lang property to other blocks as well?
#+begin_quote :lang en
this is english.
#+end_quote
WDYT?
Denis
^ permalink raw reply [relevance 6%]
* Multilingual support (proposals and state of the question)
@ 2021-05-17 15:41 8% Juan Manuel Macías
2021-05-17 16:03 6% ` Denis Maier
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-17 15:41 UTC (permalink / raw)
To: orgmode
Hi all,
I would like to start a thread on this question, leaving some basic ideas and
sketches of my own, in case someone else wanted to join the discussion.
I think it would be nice if Org Mode offered consistent support (out of
the box) for multilingual documents. That is, those documents where
there is a main language and it is possible to toggle between a list of
others 'secondary' languages, in the LaTeX Babel way. Those documents
could be consistently exported to other formats with multilingual
support: LaTeX, of course, but also html, odt, etc.
What is your opinion?
I think Org documents should have three levels in multilingual management:
- Short text segments, something like an 'inline block' for other languages
- Blocks
- Sections
For short inline segments, IMHO and without the need to innovate, I
think an excellent candidate are the links defined with
org-link-set-parameters. For example:
Lorem ipsum [[lang:de][some text in German]] dolor sit amet
(For structures of this kind I found very interesting ideas here:
https://github.com/alhassy/org-special-block-extras)
As for blocks, I think of a hypothetical 'lang' block:
#+begin_lang el :variant polytonic
Some text in polytonic Greek...
#+end_lang
However, in a previous thread
(https://orgmode.org/list/87k0og8fss.fsf@list.aleks.bg/) Aleksandar
Dimitrov proposed an idea that seemed very suggestive, at least in
concept: add a ':lang' argument to the Org code blocks:
#+begin_src org :lang fr
Some text in french
#+end_src
And finally, for sections, you could think of a new property ':lang:'
* Header
:PROPERTIES:
:LANG: pt
:END:
...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [Question] Custom parse tree filter
2021-05-16 15:59 5% ` Nicolas Goaziou
@ 2021-05-17 12:20 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-17 12:20 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Thank you very much for your excelent explanation, which has helped me
to learn new and valuable things.
I chose `headline' instead of `section' because in the scenario where I
want to apply those LaTeX groups I was looking for something like this:
{level 1 - group 1
{level 2 group 1 + group 2
{level 3 group 1 + group 2 + group 3
{etc. }}}}
I have tested your function and it works fine when all headers are at
the same level, but with different levels the filter understands both
properties as `font' (?). Anyway, and only for practical purposes, and
because I think that my initial idea of 2 properties was uneconomical, I
have slightly modified your function with a single property
`:fontspec:'. Now, with a couple of marks and some regexp both the
\fontspec group and the one with \addfontfeature are extracted:
| :fontspec: font ! optional: features | \fontspec{font}[features] |
|----------------------------------------+---------------------------|
| :fontspec: > features | \addfontfeature{features} |
then the variable `fontspec':
(let* ((font <font-string-obtained-via-regexp>)
(fontfeature <fontfeature-string-obtained-via-regexp>)
(fontspec (cond (font font) (fontfeature fontfeature))))
is passed as an argument of `(funcall create-export-snippet ...)'
With a single property it works fine, although I have to test more...
Thak you very much!
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I am writing a custom parse tree filter that does the following (LaTeX
>> backend): if a heading has the ':font:' property, the content of that
>> heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
>> then the content is enclosed in a different group. The filter works fine
>> when all the headings are at the same level. But with different levels,
>> it does not returns the expected result. It's evident that I'm doing
>> something catastrophically wrong :-). I wonder if anyone could put me on
>> the track of the origin of my error...
>>
>> Below, the offender function and a sample. Thanks in advance!
>
> I think you are operating at the wrong level. Higher level headlines
> contain lower level ones. I suggest to operate on sections instead.
>
> Also, using `org-element-interpret-data' is meh because you're operating
> at the parse tree level. You can insert export-snippet objects directly.
>
> Here's a proposal. This could be refactored, but you get the idea.
>
> (defun my-custom-filters/fontspec-headline (tree backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (org-element-map tree 'section
> (lambda (section)
> (let ((font (org-export-get-node-property :FONT section t))
> (fontfeature (org-export-get-node-property :FONTFEATURE section t))
> (create-export-snippet
> ;; Create "latex" export-snippet with value V.
> (lambda (v)
> (org-element-create 'export-snippet (list :back-end "latex" :value v)))))
> (cond
> (font
> (apply #'org-element-set-contents
> section
> (append (list (funcall create-export-snippet "%font start\n"))
> (org-element-contents section)
> (list (funcall create-export-snippet "%font end\n")))))
> (fontfeature
> (apply #'org-element-set-contents
> section
> (append (list (funcall create-export-snippet "%fontfeature start\n"))
> (org-element-contents section)
> (list (funcall create-export-snippet "%fontfeature end\n"))))))))
> info)
> tree))
>
> Also, when "org-cite-wip" is merged, you will be able to replace, e.g.,
>
> (funcall create-export-snippet "%fontfeature start\n")
>
> with
>
> (org-export-raw-string "%fontfeature start\n")
>
> Regards,
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-16 12:17 6% ` Bastien
@ 2021-05-16 16:48 0% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-05-16 16:48 UTC (permalink / raw)
To: emacs-orgmode
On 16/05/2021 19:17, Bastien wrote:
>
> Juan Manuel Macías writes:
>
>> (On the other hand, maybe better than an alternate separator, some kind of
>> warning for unescaped commas might be more useful, as Maxim commented
>> here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
>
> Yes, probably -- feel free to propose a patch for this. Thanks!
Such warnings should be property of particular macros. Sometimes
ignoring of arguments may be handy. So no patch is required. The trick
could be documented somewhere, but I am unsure concerning proper place.
Actually, I do not think, fatal error is user-friendly behavior. I am
not aware if export already have convenient facilities to report
warnings. Currently I do not feel I am ready to implement such feature
if it does not exist yet.
However the point of that message was that extra commas may be made
"transparent" for macros by introducing additional substitution, e.g.
"$_" that expands into "rest" arguments. I consider "$@" or "$*" as
worse variant since it rather mean "all arguments", so it is less
flexible. For "eval" lisp macros, it is just replacing "_" by "$_" in
argument list. Simple text macros require a bit more work but it is
still comparable with documenting the feature.
We need a decision if "rest arguments" feature should be introduced.
Once added, it will be harder to discard it due to compatibility issues.
^ permalink raw reply [relevance 0%]
* Re: [Question] Custom parse tree filter
2021-05-16 15:31 8% [Question] Custom parse tree filter Juan Manuel Macías
@ 2021-05-16 15:59 5% ` Nicolas Goaziou
2021-05-17 12:20 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-05-16 15:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am writing a custom parse tree filter that does the following (LaTeX
> backend): if a heading has the ':font:' property, the content of that
> heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
> then the content is enclosed in a different group. The filter works fine
> when all the headings are at the same level. But with different levels,
> it does not returns the expected result. It's evident that I'm doing
> something catastrophically wrong :-). I wonder if anyone could put me on
> the track of the origin of my error...
>
> Below, the offender function and a sample. Thanks in advance!
I think you are operating at the wrong level. Higher level headlines
contain lower level ones. I suggest to operate on sections instead.
Also, using `org-element-interpret-data' is meh because you're operating
at the parse tree level. You can insert export-snippet objects directly.
Here's a proposal. This could be refactored, but you get the idea.
--8<---------------cut here---------------start------------->8---
(defun my-custom-filters/fontspec-headline (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'section
(lambda (section)
(let ((font (org-export-get-node-property :FONT section t))
(fontfeature (org-export-get-node-property :FONTFEATURE section t))
(create-export-snippet
;; Create "latex" export-snippet with value V.
(lambda (v)
(org-element-create 'export-snippet (list :back-end "latex" :value v)))))
(cond
(font
(apply #'org-element-set-contents
section
(append (list (funcall create-export-snippet "%font start\n"))
(org-element-contents section)
(list (funcall create-export-snippet "%font end\n")))))
(fontfeature
(apply #'org-element-set-contents
section
(append (list (funcall create-export-snippet "%fontfeature start\n"))
(org-element-contents section)
(list (funcall create-export-snippet "%fontfeature end\n"))))))))
info)
tree))
--8<---------------cut here---------------end--------------->8---
Also, when "org-cite-wip" is merged, you will be able to replace, e.g.,
(funcall create-export-snippet "%fontfeature start\n")
with
(org-export-raw-string "%fontfeature start\n")
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* [Question] Custom parse tree filter
@ 2021-05-16 15:31 8% Juan Manuel Macías
2021-05-16 15:59 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-16 15:31 UTC (permalink / raw)
To: orgmode
Hi all,
I am writing a custom parse tree filter that does the following (LaTeX
backend): if a heading has the ':font:' property, the content of that
heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
then the content is enclosed in a different group. The filter works fine
when all the headings are at the same level. But with different levels,
it does not returns the expected result. It's evident that I'm doing
something catastrophically wrong :-). I wonder if anyone could put me on
the track of the origin of my error...
Below, the offender function and a sample. Thanks in advance!
Best regards,
Juan Manuel
#+BIND: org-export-filter-parse-tree-functions (my-custom-filters/fontspec-headline)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/fontspec-headline (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'headline
(lambda (hl)
(cond ((org-element-property :FONT hl)
(let* ((font (org-element-property :FONT hl))
(contents (org-element-interpret-data (org-element-contents hl)))
(contents-new (concat
"@@latex:{\\fontspec{@@"
(replace-regexp-in-string "\s*\\(\\[.+\\]\\)\s*" "" font)
"@@latex:}%@@\n"
(if (string-match "\\(\\[.+\\]\\)" font)
(concat "@@latex:" (match-string 1 font) "%@@\n\n")
"\n")
contents
"\n@@latex:}@@")))
(org-element-set-contents hl (with-temp-buffer
(insert contents-new)
(org-element-parse-buffer)))))
((org-element-property :FONTFEATURE hl)
(let* ((fontfeature (org-element-property :FONTFEATURE hl))
(contents (org-element-interpret-data (org-element-contents hl)))
(contents-new (concat
"@@latex:{\\addfontfeature{@@"
fontfeature
"@@latex:}%@@\n"
contents
"\n@@latex:}@@")))
(org-element-set-contents hl (with-temp-buffer
(insert contents-new)
(org-element-parse-buffer)))))))
info)
tree))
#+end_src
* Minion Pro
:PROPERTIES:
:font: Minion Pro [Style=Historic,Color=teal]
:END:
Lorem ipsum dolor.
** Lowercase Numbers
:PROPERTIES:
:fontfeature: Numbers=Lowercase
:END:
Lorem ipsum dolor 1234567890.
*** Letter Space
:PROPERTIES:
:fontfeature: LetterSpace=14.6
:END:
Lorem ipsum dolor 1234567890.
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 21:05 10% ` Juan Manuel Macías
@ 2021-05-16 12:17 6% ` Bastien
2021-05-16 16:48 0% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-05-16 12:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> (On the other hand, maybe better than an alternate separator, some kind of
> warning for unescaped commas might be more useful, as Maxim commented
> here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
Yes, probably -- feel free to propose a patch for this. Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 20:25 6% ` Bastien
@ 2021-05-15 21:05 10% ` Juan Manuel Macías
2021-05-16 12:17 6% ` Bastien
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-15 21:05 UTC (permalink / raw)
To: Bastien; +Cc: orgmode, Eric S Fraga
Hi Bastien,
Bastien writes:
> I'm skeptical too, so perhaps the best thing to do is to see if you
> need it or not, and if proven useful after a while, repost a patch?
I totally agree. I will try these modifications for a while, if they are
really useful. Anyway, as Nicolas commented in a previous post, it seems
that the natural habitat of macros consists of short lengths of text. I
am exploring now other interesting alternatives (ie.
org-link-set-parameters).
(On the other hand, maybe better than an alternate separator, some kind of
warning for unescaped commas might be more useful, as Maxim commented
here: https://orgmode.org/list/s7gfc6@ciao.gmane.io/)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 20:14 9% ` Juan Manuel Macías
@ 2021-05-15 20:25 6% ` Bastien
2021-05-15 21:05 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-05-15 20:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Anyway, I admit that I have become somewhat skeptical about the
> usefulness of my patch. Perhaps, as a patch, it is too premature and
> perhaps it's better to leave the macros issue, for the moment, as it
> is... What do you think?
I'm skeptical too, so perhaps the best thing to do is to see if you
need it or not, and if proven useful after a while, repost a patch?
Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-15 13:29 6% ` Bastien
@ 2021-05-15 20:14 9% ` Juan Manuel Macías
2021-05-15 20:25 6% ` Bastien
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-15 20:14 UTC (permalink / raw)
To: Bastien; +Cc: orgmode, Eric S Fraga
Hi Bastien,
Bastien writes:
> I'll let Eric test and comment, but in the meantime, I'm just
> noticing the patch breaks many tests in master.
>
> If Nicolas thinks this change is good and Eric validate the patch,
> please prepare one with a commit message, updating the tests too.
Ok, if necessary I will prepare an updated version of the patch, with
the updated tests, and with a commit message (a thousand apologies for
my continuous forgetting in commit messages...).
I have noticed certain bugs in my patch, especially within
org-element-macro-parser (a bad regexp and something else). That caused
macros with a single argument to be incorrectly interpreted (and it also
caused an error in one of the tests). If Eric (or someone else) wants
an updated version of the patch I could send it him.
Anyway, I admit that I have become somewhat skeptical about the
usefulness of my patch. Perhaps, as a patch, it is too premature and
perhaps it's better to leave the macros issue, for the moment, as it
is... What do you think?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] to allow org-attach-git to handle individual repositories
2021-04-28 3:57 6% ` Bastien
@ 2021-05-15 14:08 6% ` Bastien
1 sibling, 0 replies; 200+ results
From: Bastien @ 2021-05-15 14:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I would like to propose and discuss this patch for org-attach-git,
> following a series of comments and suggestions from Ihor Radchenko in
> this thread:
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html
Applied in master with a commit message, thanks.
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-08 7:31 6% ` Juan Manuel Macías
@ 2021-05-15 13:46 6% ` Bastien
0 siblings, 0 replies; 200+ results
From: Bastien @ 2021-05-15 13:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Eric Fraga, orgmode, TEC
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here I am attaching a new version of the patch that includes a commit
> message.
Correct me if I'm wrong but the patch did not contain a commit
message, so I added it.
Applied in master, together with an entry in etc/ORG-NEWS.
Thanks,
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-11 18:25 9% ` Juan Manuel Macías
@ 2021-05-15 13:29 6% ` Bastien
2021-05-15 20:14 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-05-15 13:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is the fixed version of the patch.
I'll let Eric test and comment, but in the meantime, I'm just
noticing the patch breaks many tests in master.
If Nicolas thinks this change is good and Eric validate the patch,
please prepare one with a commit message, updating the tests too.
Thanks,
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Possibility of using alternative separators in macros
[not found] ` <87im3prvz8.fsf@ucl.ac.uk>
@ 2021-05-11 18:25 9% ` Juan Manuel Macías
2021-05-15 13:29 6% ` Bastien
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-11 18:25 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
Here is the fixed version of the patch.
Best regards,
Juan Manuel
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Could you create a new patch so I can try this easily?
>
> gracias,
> eric
[-- Attachment #2: 0001-Alternative-args-separator-for-replacement-macros_fixed.patch --]
[-- Type: text/x-patch, Size: 3094 bytes --]
From 4aae61c3600fba136dfa101d54011c0aef9169a3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macías <maciaschain@posteo.net>
Date: Tue, 11 May 2021 18:41:34 +0200
Subject: [PATCH] Alternative args separator for replacement macros
---
lisp/org-element.el | 11 ++++++++---
lisp/org-macro.el | 9 +++++----
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..da4035689 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3279,21 +3279,25 @@ CONTENTS is the contents of the object, or nil."
"Parse macro at point, if any.
When at a macro, return a list whose car is `macro' and cdr
-a plist with `:key', `:args', `:begin', `:end', `:value' and
+a plist with `:key', `:args', `:begin', `:end', `:sep', `:value' and
`:post-blank' as keywords. Otherwise, return nil.
Assume point is at the macro."
(save-excursion
- (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
- (let ((begin (point))
+ (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]*[^-a-zA-Z0-9_\s]*\\)\\((\\([^\000]*?\\))\\)?}}}")
+ (let* ((begin (point))
(key (downcase (match-string-no-properties 1)))
(value (match-string-no-properties 0))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point))
+ (sep (if (not (equal (match-string-no-properties 2) ""))
+ (match-string-no-properties 2)
+ ","))
(args (pcase (match-string-no-properties 3)
(`nil nil)
(a (org-macro-extract-arguments
+ sep
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
@@ -3302,6 +3306,7 @@ Assume point is at the macro."
:args args
:begin begin
:end end
+ :sep sep
:post-blank post-blank))))))
(defun org-element-macro-interpreter (macro _)
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 29c403658..e047cd78e 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -294,20 +294,21 @@ of `org-macro-extract-arguments'."
nil t)
s)))))
-(defun org-macro-extract-arguments (s)
+(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
-Return a list of arguments, as strings. This is the opposite of
+SEP is the character used to separate arguments. Return a list
+of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
- "\\(\\\\*\\),"
+ (format "\\(\\\\*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str))))
(concat (make-string (/ len 2) ?\\)
- (if (zerop (mod len 2)) "\000" ","))))
+ (if (zerop (mod len 2)) "\000" (format "%s" sep)))))
s nil t)
"\000"))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-11 11:01 5% ` Eric S Fraga
@ 2021-05-11 16:12 5% ` Juan Manuel Macías
[not found] ` <87im3prvz8.fsf@ucl.ac.uk>
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-11 16:12 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hello Eric,
It's a typo, sorry: I forgot, when I made the patch, to add the asterisk
to the `let' expression in org-element-macro-parser, therefore the `sep'
variable was not recognized.
The correct function is:
(defun org-element-macro-parser ()
"Parse macro at point, if any.
When at a macro, return a list whose car is `macro' and cdr
a plist with `:key', `:args', `:begin', `:end', `:value', `:sep' and
`:post-blank' as keywords. Otherwise, return nil.
Assume point is at the macro."
(save-excursion
(when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]?[^-a-zA-Z0-9_\s]?\\)\\((\\([^\000]*?\\))\\)?}}}")
(let* ((begin (point)) ;; <==== missing asterisk :-(
(key (downcase (match-string-no-properties 1)))
(value (match-string-no-properties 0))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point))
(sep (if (not (equal (match-string-no-properties 2) ""))
(match-string-no-properties 2)
","))
(args (pcase (match-string-no-properties 4)
(`nil nil)
(a (org-macro-extract-arguments
sep
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
(list :key key
:value value
:args args
:begin begin
:end end
:sep sep
:post-blank post-blank))))))
Eric S Fraga writes:
> Hello Juan,
>
> On Friday, 30 Apr 2021 at 13:26, Juan Manuel Macías wrote:
>> Hi all,
>>
>> I would like to propose (patch attached) the possibility of using an
>> alternate character for separate arguments in replacement macros,
>> following a suggestion from Nicolas Goaziou in this (closed) thread:
>> https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
>
> I finally got around to trying this out, applying the patch just now to
> the latest org from the git repository. I get the following when I try
> to export:
>
> Debugger entered--Lisp error: (void-variable sep)
> org-element-macro-parser()
> org-element--object-lex((bold code entity export-snippet
> footnote-reference inline-babel-call inline-src-block italic
> line-break latex-fragment link macro radio-target statistics-cookie
> strike-through subscript superscript target timestamp underline
> verbatim))
> org-element-context()
> org-macro-replace-all((("date" . "") ("title" . "The title")
> ("email" . "") ("author" . "Professor Eric S Fraga") ("lastchange" .
> "2021.03.31 15:03") ("calc" .
> "@@latex:{\\color{green!50!black}\\texttt{ $1 }}@@") ("cite" .
> "[[$2][@@latex:\\vfill\\Citation{$1}@@]]") ("overlay" .
> "@@latex:\\begin{textblock}{$4}($2,$3)@@[[file:$1]]@...") ("parameter"
> . "src_elisp[:results value raw :var $1=(esf/get-para...") ("constant"
> closure (t) (&optional $1 &rest _) (progn (message "Getting constant
> %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org")
> ("modification-time" . #f(compiled-function (arg1 &optional arg2 &rest
> _) #<bytecode 0x1a91bc3b547f3a1c>)) ("keyword" lambda (arg1 &rest _)
> (org-macro--find-keyword-value arg1)) ("n" lambda (&optional arg1 arg2
> &rest _) (org-macro--counter-increment arg1 arg2)) ("property" lambda
> (arg1 &optional arg2 &rest _) (org-macro--get-property arg1 arg2))
> ("time" lambda (arg1 &rest _) (format-time-string arg1)))
> ("DESCRIPTION" "KEYWORDS" "SUBTITLE" "DATE" "TITLE" "DATE" "AUTHOR"))
> org-export-as(latex nil nil nil nil)
> org-export-to-buffer(latex "*Org LATEX Export*" nil nil nil nil nil #f(compiled-function () #<bytecode 0xbb0539acd91d>))
> org-latex-export-as-latex(nil nil nil nil)
> org-export-dispatch(nil)
> funcall-interactively(org-export-dispatch nil)
> command-execute(org-export-dispatch)
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-04-30 13:26 6% [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
@ 2021-05-11 11:01 5% ` Eric S Fraga
2021-05-11 16:12 5% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Eric S Fraga @ 2021-05-11 11:01 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello Juan,
On Friday, 30 Apr 2021 at 13:26, Juan Manuel Macías wrote:
> Hi all,
>
> I would like to propose (patch attached) the possibility of using an
> alternate character for separate arguments in replacement macros,
> following a suggestion from Nicolas Goaziou in this (closed) thread:
> https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
I finally got around to trying this out, applying the patch just now to
the latest org from the git repository. I get the following when I try
to export:
Debugger entered--Lisp error: (void-variable sep)
org-element-macro-parser()
org-element--object-lex((bold code entity export-snippet footnote-reference inline-babel-call inline-src-block italic line-break latex-fragment link macro radio-target statistics-cookie strike-through subscript superscript target timestamp underline verbatim))
org-element-context()
org-macro-replace-all((("date" . "") ("title" . "The title") ("email" . "") ("author" . "Professor Eric S Fraga") ("lastchange" . "2021.03.31 15:03") ("calc" . "@@latex:{\\color{green!50!black}\\texttt{ $1 }}@@") ("cite" . "[[$2][@@latex:\\vfill\\Citation{$1}@@]]") ("overlay" . "@@latex:\\begin{textblock}{$4}($2,$3)@@[[file:$1]]@...") ("parameter" . "src_elisp[:results value raw :var $1=(esf/get-para...") ("constant" closure (t) (&optional $1 &rest _) (progn (message "Getting constant %s" $1) (org-table-get-constant $1))) ("input-file" . "m.org") ("modification-time" . #f(compiled-function (arg1 &optional arg2 &rest _) #<bytecode 0x1a91bc3b547f3a1c>)) ("keyword" lambda (arg1 &rest _) (org-macro--find-keyword-value arg1)) ("n" lambda (&optional arg1 arg2 &rest _) (org-macro--counter-increment arg1 arg2)) ("property" lambda (arg1 &optional arg2 &rest _) (org-macro--get-property arg1 arg2)) ("time" lambda (arg1 &rest _) (format-time-string arg1))) ("DESCRIPTION" "KEYWORDS" "SUBTITLE" "DATE" "TITLE" "DATE" "AUTHOR"))
org-export-as(latex nil nil nil nil)
org-export-to-buffer(latex "*Org LATEX Export*" nil nil nil nil nil #f(compiled-function () #<bytecode 0xbb0539acd91d>))
org-latex-export-as-latex(nil nil nil nil)
org-export-dispatch(nil)
funcall-interactively(org-export-dispatch nil)
command-execute(org-export-dispatch)
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd.dirty
^ permalink raw reply [relevance 5%]
* [tip] Export annotations with the 'Mindflow' LaTeX package
@ 2021-05-10 7:19 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-10 7:19 UTC (permalink / raw)
To: orgmode
Hi all,
A new LaTeX package, mindflow, has recently been uploaded to CTAN
(https://www.ctan.org/pkg/mindflow), which I found interesting and
useful for my org workflow. With this package we can add annotations and
ideas to our document. I mean, all that is in a `mindflow'
environment (including entire sections) will appear as in a kind of
'draft mode', with different format and colour. There is a global option
that allows you to choose between showing or not showing those
annotations.
I think it can be useful (for example) to export custom Org drawers to
that environment. But it also occurred to me to write the following, to
export a entire tree as a `mindflow' environment, with the tag
`:annotation:'
#+begin_src emacs-lisp
(defun my-org-add-mindflow-env-heading (backend)
(when (eq backend 'latex)
(org-show-all)
(save-excursion
(goto-char (point-min))
(while (re-search-forward org-heading-regexp nil t)
(let ((element (org-element-at-point)))
(when (member "annotation" (org-element-property :tags element))
(save-restriction
(org-narrow-to-subtree)
(save-excursion
(goto-char (point-min))
(insert "\n\n@@latex:\\begin{mindflow}@@\n\n")
(goto-char (point-max))
(insert "\n\n@@latex:\\end{mindflow}@@\n\n")))))))))
(add-hook 'org-export-before-processing-hook #'my-org-add-mindflow-env-heading)
#+end_src
Here are some screenshots: https://imgur.com/a/jo320AI
Best regards,
Juan Manuel
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 8%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-01 10:58 6% ` Bastien
2021-05-01 11:46 10% ` Juan Manuel Macías
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
@ 2021-05-08 7:31 6% ` Juan Manuel Macías
2021-05-15 13:46 6% ` Bastien
2 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-08 7:31 UTC (permalink / raw)
To: orgmode; +Cc: Bastien, TEC, Eric Fraga
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
Hi all,
Here I am attaching a new version of the patch that includes a commit
message.
I put here an example for those who want to try it, a fragment of a
poem by W.H. Auden.
Best regards,
Juan Manuel
#+begin_src org
,#+LaTeX_Header: \usepackage{verse}
,#+ATTR_LATEX: :center t
,#+ATTR_LATEX: :versewidth Teach the free man how to praise.
,#+ATTR_LATEX: :lines 5 :latexcode \small
,#+begin_verse
Earth, receive an honoured guest:
William Yeats is laid to rest.
Let the Irish vessel lie
Emptied of its poetry.
In the nightmare of the dark
All the dogs of Europe bark,
And the living nations wait,
Each sequestered in its hate;
Intellectual disgrace
Stares from every human face,
And the seas of pity lie
Locked and frozen in each eye.
Follow, poet, follow right
To the bottom of the night,
With your unconstraining voice
Still persuade us to rejoice;
With the farming of a verse
Make a vineyard of the curse,
Sing of human unsuccess
In a rapture of distress;
In the deserts of the heart
Let the healing fountain start,
In the prison of his days
Teach the free man how to praise.
,#+end_verse
#+end_src
https://juanmanuelmacias.com/
[-- Attachment #2: 0001-Add-LaTeX-attributes-for-verse-blocks.patch --]
[-- Type: text/x-patch, Size: 4774 bytes --]
From 337014731e89f7f28873b8f5d9a917901e810c95 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 8 May 2021 09:03:10 +0200
Subject: [PATCH] Add LaTeX attributes for verse blocks
---
doc/org-manual.org | 48 ++++++++++++++++++++++++++++++++++++++++++++++
lisp/ox-latex.el | 20 +++++++++++++++----
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index ab12fa70a..c752ce46d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13861,6 +13861,54 @@ The LaTeX export back-end converts horizontal rules by the specified
-----
#+end_example
+*** Verse blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to special blocks.
+:END:
+
+#+cindex: verse blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+
+The LaTeX export back-end accepts four attributes for verse blocks:
+=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
+require the external LaTeX package =verse.sty=, wich is an extension
+of the standard LaTeX environment. The purpose of these attributes is
+explained below.
+
+- =:lines= :: To add marginal verse numbering. Its value is an
+ integer, the sequence in which the verses should be numbered.
+- =:center= :: With value =t= all the verses on the page are optically
+ centered (a typographic convention for poetry), taking as a
+ reference the longest verse, which must be indicated by the
+ attribute =:versewidth=.
+- =:versewidth= :: Its value is a literal text string with the longest
+ verse.
+- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
+ included within a LaTeX =verse= environment.
+
+A complete example with Shakespeare's first sonnet:
+
+#+begin_src org
+,#+ATTR_LaTeX: :center t :latexcode \color{red} :lines 5
+,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
+,#+begin_verse
+From fairest creatures we desire increase,
+That thereby beauty’s rose might never die,
+But as the riper should by time decrease,
+His tender heir mught bear his memeory:
+But thou, contracted to thine own bright eyes,
+Feed’st thy light’st flame with self-substantial fuel,
+Making a famine where abundance lies,
+Thyself thy foe, to thy sweet self too cruel.
+Thou that art now the world’s fresh ornament
+And only herald to the gaudy spring,
+Within thine own bud buriest thy content
+And, tender churl, makest waste in niggarding.
+Pity the world, or else this glutton be,
+To eat the world’s due, by the grave and thee.
+,#+end_verse
+#+end_src
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c3fc83b1b..0376dffd1 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3513,6 +3513,17 @@ channel."
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
+ (let*
+ ((lin (org-export-read-attribute :attr_latex verse-block :lines))
+ (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if lin "\n\\poemlines{0}" "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3520,19 +3531,20 @@ contextual information."
;; character and change each white space at beginning of a line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
- (format "\\begin{verse}\n%s\\end{verse}"
+ (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ vwidth
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
"^[ \t]*\\\\\\\\$" "\\vspace*{1em}"
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
- contents nil t) nil t) nil t))
+ contents nil t) nil t) nil t) linreset)
info)
;; Insert footnote definitions, if any, after the environment, so
;; the special formatting above is not applied to them.
- (org-latex--delayed-footnotes-definitions verse-block info)))
-
+ (org-latex--delayed-footnotes-definitions verse-block info))))
\f
;;; End-user functions
--
2.26.0
^ permalink raw reply related [relevance 6%]
* Re: About multilingual documents
2021-05-04 8:44 2% ` Aleksandar Dimitrov
@ 2021-05-06 11:11 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-06 11:11 UTC (permalink / raw)
To: Aleksandar Dimitrov; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 4300 bytes --]
Hi Aleksandar,
Aleksandar Dimitrov writes:
> [...]
> I must admit that I find the inline org-src notation (of which I
> didn't know yet) somewhat jarring, and certainly less pleasant to
> read. Perhaps we could use a similar mechanism to
> =org-hide-emphasis-markers= to make it more pleasant to read. [1]
You may be interested in this thread: https://orgmode.org/list/87a6r6avgg.fsf@gmail.com/
> I definitely agree that Org would benefit from more multilingual
> support. I'm not very experienced in emacs-lisp but would love to contribute.
>
> One problem I foresee is the translation of locales into LaTeX macros
> for either (LaTeX)-Babel or Polyglossia (which is what I use.) So a
> string like "en" or "en_UK" (which is readily understood by
> ([ai]|hun)spell) would have to be translated to the necessary
> macros. For example for Polyglossia [2] the preamble would read
>
> \setdefaultlanguage[variant=uk]{english}
>
> And then the inline commands would have to be rendered as
> \textenglish{…} or \textlang{english}{…} (probably the latter would be easier.)
Since these days I had some free time, I have written this little
snippet, based on your idea. Of course, it is only a 'sketch', or a
'proof of concept'. It has obvious limitations and does not collect all
the features that your idea suggests. Here I only apply the (LaTeX)
Babel environments, but they can be easily substituted by those of
Polyglossia [1], or add both possibilities using a defcustom. I have put
two options: `:lang' and `:lang-quotes'. The second option is to use it
with the csquotes package. As I have only focused on exporting to LaTeX
I have not included support for html (or odt), but I agree with you that
it would be necessary to add some multilingual support as well for these
backends. And there's no support for inline blocks either, as the output
of the variables I've added is multiline. Anyway, it is a very hasty
sketch (maybe too hasty ;-)), but if you want to try it, I attach here a
small test document.
The code:
#+begin_src emacs-lisp
(defun my-lang-org-backend (lang body)
(cond
((org-export-derived-backend-p org-export-current-backend 'latex)
(format "@@latex:\\begin{otherlanguage}{%s}@@\n%s\n@@latex:\\end{otherlanguage}@@" lang body))
((or (org-export-derived-backend-p org-export-current-backend 'html)
(org-export-derived-backend-p org-export-current-backend 'odt))
(format "%s" body))))
(defun my-lang-csquotes-org-backend (lang body)
(cond
((org-export-derived-backend-p org-export-current-backend 'latex)
(format "@@latex:\\begin{otherlanguage*}{%s}\n\\EnableQuotes@@\n%s\n@@latex:\\end{otherlanguage*}@@" lang body))
((or (org-export-derived-backend-p org-export-current-backend 'html)
(org-export-derived-backend-p org-export-current-backend 'odt))
(format "%s" body))))
(defun org-babel-execute:org (body params)
"Execute a block of Org code with.
This function is called by `org-babel-execute-src-block'."
(let ((result-params (split-string (or (cdr (assq :results params)) "")))
(lang (cdr (assq :lang params)))
(lang-quotes (cdr (assq :lang-quotes params)))
(body (org-babel-expand-body:org
(replace-regexp-in-string "^," "" body) params)))
(cond
(lang
(my-lang-org-backend lang body))
(lang-quotes
(my-lang-csquotes-org-backend lang-quotes body))
((member "latex" result-params)
(org-export-string-as (concat "#+Title: \n" body) 'latex t))
((member "html" result-params) (org-export-string-as body 'html t))
((member "ascii" result-params) (org-export-string-as body 'ascii t))
(t body))))
#+end_src
Best regards,
Juan Manuel
[1] I used Polyglossia for a while, when I migrated to XeTeX and then to
LuaTeX, and babel at that time did not support both engines. But now
Babel does give them full support and has grown so much that it has
surpassed (IMHO) to Polyglossia. I recommend taking a look at all
novelties and new functionalities that has added the current Babel
maintainer, Javier Bezos:
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
[-- Attachment #2: langs-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2120 bytes --]
^ permalink raw reply [relevance 6%]
* Re: About multilingual documents
2021-05-03 20:33 9% ` Juan Manuel Macías
@ 2021-05-04 8:44 2% ` Aleksandar Dimitrov
2021-05-06 11:11 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Aleksandar Dimitrov @ 2021-05-04 8:44 UTC (permalink / raw)
To: org-mode-email
Hi Juan,
> Thank you very much for your interesting comments. I think your idea of
> applying org-babel to (multi) language support is tremendously
> suggestive and, of course, more org-centric. I suppose it could be
> applied also to languages within the paragraph by inline blocks... I
> really liked what you propose.
>
> Well, I admit that my marks are a bit exotic :-D. The main problem I see
> is that they are not as robust as Org's own marks, since they are
> controlled by an export filter. Doing some further tests, by the way, I
> think it would be better to add the filter to
> `org-export-filter-plain-text-functions', instead of
> `...final-output-functions'. I also see that it would be convenient to
> avoid their expansion in verbatim texts, with a `(unless
> (org-in-verbatim-emphasis)...)'.
What I like about =org-edit-special= is that it gives you a dedicated
little environment in a different language (either natural, or
programming language!) This allows me to focus on the task of editing it
really easily.
I must admit that I find the inline org-src notation (of which I didn't
know yet) somewhat jarring, and certainly less pleasant to read. Perhaps
we could use a similar mechanism to =org-hide-emphasis-markers= to make
it more pleasant to read. [1]
> Anyway, I think (in general terms) it would be interesting for Org to
> incorporate some multilingual support and the ability to toggle between
> languages in a document, and the idea you propose seems to
> me that it makes a lot of sense.
I definitely agree that Org would benefit from more multilingual
support. I'm not very experienced in emacs-lisp but would love to contribute.
One problem I foresee is the translation of locales into LaTeX macros
for either (LaTeX)-Babel or Polyglossia (which is what I use.) So a
string like "en" or "en_UK" (which is readily understood by
([ai]|hun)spell) would have to be translated to the necessary
macros. For example for Polyglossia [2] the preamble would read
\setdefaultlanguage[variant=uk]{english}
And then the inline commands would have to be rendered as
\textenglish{…} or \textlang{english}{…} (probably the latter would be easier.)
I forgot what it is for LaTeX-Babel.
Note that the HTML export backend, too, could (or should) support
declaring multiple languages. [3]
There's a lot of work in there, but I would say that any implementation
effort should focus on one thing first. That could be switching the
dictionary on org-edit-special if a :lang-variable is set, or it could
be re-using what you, Juan, already wrote for LaTeX-Babel
exports. Support for Polyglossia or HTML could come at a later time.
Cheers,
Aleks
[1] https://stackoverflow.com/questions/20309842/how-to-syntax-highlight-for-org-mode-inline-source-code-src-lang/28059832#28059832
[2] https://ftp.rrze.uni-erlangen.de/ctan/macros/unicodetex/latex/polyglossia/polyglossia.pdf
[3] https://www.w3.org/International/questions/qa-html-language-declarations
>
> Best regards,
>
> Juan Manuel
>
> Aleksandar Dimitrov writes:
>
>> Hi Juan,
>>
>> this sounds very interesting to me, as I, too, mostly write in Org
>> and, sometimes write documents in multiple languages, usually with
>> different varieties of either Latin or Cyrillic.
>>
>> I have some suggestions:
>>
>> Apart from the export, one of my biggest gripes is
>> flyspell. Specifically, the fact that you have to choose one language to
>> spell check the entire document with. That is insufficient in my case.
>>
>> I think that the syntax you're suggesting looks good, but I'm not
>> sure how well it'd fit into org-mode's ecosystem. I had something in
>> mind that was closer to how org-babel works (it's called *babel*
>> for a reason, isn't it? :D)
>>
>> #+begin_src org :lang pl
>> … po polsku
>> #+end_src
>>
>> #+begin_src org :lang de
>> … auf deutsch
>> #+end_src
>>
>>
>> This would make use of org-mode's edit special environment function. It
>> would make it easier to persuade flyspell to do the right thing. You
>> could, perhaps, add
>>
>> #+LANGUAGE: en
>>
>> to the parent document, and then org would take care to set the correct
>> flyspell language (and the correct macros on LaTeX-export) and change
>> these parameters in the special environments.
>>
>> I'm not 100% sure it should be #+begin_src org, maybe introducing a
>> different special environment would be better, say #+begin_lang XX where
>> XX is the ISO-code of said language, or the locale (think en_US
>> vs. en_GB.)
>>
>> The drawback, and the clear disadvantage compared to your method is that
>> this works great only when the languages are separated by paragraph
>> breaks.
>>
>> Therefore, I think our suggestions might be somewhat orthogonal. Yours
>> could be a shorthand syntax for introducing inline foreign-language
>> snippets.
>>
>> What do you think?
>>
>> Regards,
>> Aleks
>>
>> Juan Manuel Macías writes:
>>
>>> Hi all,
>>>
>>> I'm curious to see how other Org users deal with multilingual documents,
>>> that is, those documents (for example, philology or linguistics texts)
>>> that contain a significant number of online quotes in other languages.
>>> Naturally, this makes more sense in the LaTeX backend, since it is
>>> convenient to enclose these quotes in a \foreignlanguage command to
>>> ensure that LaTeX at least apply the correct hyphenation patterns for
>>> words in other languages.
>>>
>>> Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
>>> need to do this when it comes to languages whose script is different
>>> from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
>>> We can, for example, define Russian and Greek as:
>>>
>>> #+begin_src latex
>>> \babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
>>> \babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
>>> #+end_src
>>>
>>> And also the fonts for both languages:
>>>
>>> #+begin_src latex
>>> \babelfont[russian]{rm}{Linux Libertine O}
>>> \babelfont[greek]{rm}]{Free Serif}
>>> #+end_src
>>>
>>> For Latin-based scripts it is still necessary enclose the text in the
>>> \foreignlanguage command. And now comes the question: how do Org users
>>> who work in multilingual documents to obtain this command when exporting
>>> to Latex?
>>>
>>> I usually use macros, which always tend to work fine. But lately I have
>>> been testing an alternative markup system using an export filter. The
>>> idea would be something like:
>>>
>>> %(lang) lorem ipsum dolor %()
>>>
>>> I start from a list of the most used languages:
>>>
>>> #+begin_src emacs-lisp
>>> (langs '(("en" "english")
>>> ("fr" "french")
>>> ("de" "german")
>>> ("it" "italian")
>>> ("pt" "portuguese")))
>>> #+end_src
>>>
>>> And other possible languages that Babel supports can be indicated
>>> explicitly, by prepending "--":
>>>
>>> %(fr) ... %()
>>>
>>> %(--esperanto) ... %()
>>>
>>> (If someone wants to try it, I attach a small Org document).
>>>
>>> Best regards,
>>>
>>> Juan Manuel
>>
>>
>
> --
^ permalink raw reply [relevance 2%]
* Re: About multilingual documents
2021-05-03 6:58 5% ` Aleksandar Dimitrov
@ 2021-05-03 20:33 9% ` Juan Manuel Macías
2021-05-04 8:44 2% ` Aleksandar Dimitrov
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-03 20:33 UTC (permalink / raw)
To: Aleksandar Dimitrov; +Cc: orgmode
Hi Aleksandar,
Thank you very much for your interesting comments. I think your idea of
applying org-babel to (multi) language support is tremendously
suggestive and, of course, more org-centric. I suppose it could be
applied also to languages within the paragraph by inline blocks... I
really liked what you propose.
Well, I admit that my marks are a bit exotic :-D. The main problem I see
is that they are not as robust as Org's own marks, since they are
controlled by an export filter. Doing some further tests, by the way, I
think it would be better to add the filter to
`org-export-filter-plain-text-functions', instead of
`...final-output-functions'. I also see that it would be convenient to
avoid their expansion in verbatim texts, with a `(unless
(org-in-verbatim-emphasis)...)'.
Anyway, I think (in general terms) it would be interesting for Org to
incorporate some multilingual support and the ability to toggle between
languages in a document, and the idea you propose seems to
me that it makes a lot of sense.
Best regards,
Juan Manuel
Aleksandar Dimitrov writes:
> Hi Juan,
>
> this sounds very interesting to me, as I, too, mostly write in Org
> and, sometimes write documents in multiple languages, usually with
> different varieties of either Latin or Cyrillic.
>
> I have some suggestions:
>
> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.
>
> I think that the syntax you're suggesting looks good, but I'm not
> sure how well it'd fit into org-mode's ecosystem. I had something in
> mind that was closer to how org-babel works (it's called *babel*
> for a reason, isn't it? :D)
>
> #+begin_src org :lang pl
> … po polsku
> #+end_src
>
> #+begin_src org :lang de
> … auf deutsch
> #+end_src
>
>
> This would make use of org-mode's edit special environment function. It
> would make it easier to persuade flyspell to do the right thing. You
> could, perhaps, add
>
> #+LANGUAGE: en
>
> to the parent document, and then org would take care to set the correct
> flyspell language (and the correct macros on LaTeX-export) and change
> these parameters in the special environments.
>
> I'm not 100% sure it should be #+begin_src org, maybe introducing a
> different special environment would be better, say #+begin_lang XX where
> XX is the ISO-code of said language, or the locale (think en_US
> vs. en_GB.)
>
> The drawback, and the clear disadvantage compared to your method is that
> this works great only when the languages are separated by paragraph
> breaks.
>
> Therefore, I think our suggestions might be somewhat orthogonal. Yours
> could be a shorthand syntax for introducing inline foreign-language
> snippets.
>
> What do you think?
>
> Regards,
> Aleks
>
> Juan Manuel Macías writes:
>
>> Hi all,
>>
>> I'm curious to see how other Org users deal with multilingual documents,
>> that is, those documents (for example, philology or linguistics texts)
>> that contain a significant number of online quotes in other languages.
>> Naturally, this makes more sense in the LaTeX backend, since it is
>> convenient to enclose these quotes in a \foreignlanguage command to
>> ensure that LaTeX at least apply the correct hyphenation patterns for
>> words in other languages.
>>
>> Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
>> need to do this when it comes to languages whose script is different
>> from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
>> We can, for example, define Russian and Greek as:
>>
>> #+begin_src latex
>> \babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
>> \babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
>> #+end_src
>>
>> And also the fonts for both languages:
>>
>> #+begin_src latex
>> \babelfont[russian]{rm}{Linux Libertine O}
>> \babelfont[greek]{rm}]{Free Serif}
>> #+end_src
>>
>> For Latin-based scripts it is still necessary enclose the text in the
>> \foreignlanguage command. And now comes the question: how do Org users
>> who work in multilingual documents to obtain this command when exporting
>> to Latex?
>>
>> I usually use macros, which always tend to work fine. But lately I have
>> been testing an alternative markup system using an export filter. The
>> idea would be something like:
>>
>> %(lang) lorem ipsum dolor %()
>>
>> I start from a list of the most used languages:
>>
>> #+begin_src emacs-lisp
>> (langs '(("en" "english")
>> ("fr" "french")
>> ("de" "german")
>> ("it" "italian")
>> ("pt" "portuguese")))
>> #+end_src
>>
>> And other possible languages that Babel supports can be indicated
>> explicitly, by prepending "--":
>>
>> %(fr) ... %()
>>
>> %(--esperanto) ... %()
>>
>> (If someone wants to try it, I attach a small Org document).
>>
>> Best regards,
>>
>> Juan Manuel
>
>
--
--
^ permalink raw reply [relevance 9%]
* Re: About multilingual documents
2021-05-02 20:20 8% About multilingual documents Juan Manuel Macías
@ 2021-05-03 6:58 5% ` Aleksandar Dimitrov
2021-05-03 20:33 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Aleksandar Dimitrov @ 2021-05-03 6:58 UTC (permalink / raw)
To: emacs-orgmode
Hi Juan,
this sounds very interesting to me, as I, too, mostly write in Org
and, sometimes write documents in multiple languages, usually with
different varieties of either Latin or Cyrillic.
I have some suggestions:
Apart from the export, one of my biggest gripes is
flyspell. Specifically, the fact that you have to choose one language to
spell check the entire document with. That is insufficient in my case.
I think that the syntax you're suggesting looks good, but I'm not
sure how well it'd fit into org-mode's ecosystem. I had something in
mind that was closer to how org-babel works (it's called *babel*
for a reason, isn't it? :D)
#+begin_src org :lang pl
… po polsku
#+end_src
#+begin_src org :lang de
… auf deutsch
#+end_src
This would make use of org-mode's edit special environment function. It
would make it easier to persuade flyspell to do the right thing. You
could, perhaps, add
#+LANGUAGE: en
to the parent document, and then org would take care to set the correct
flyspell language (and the correct macros on LaTeX-export) and change
these parameters in the special environments.
I'm not 100% sure it should be #+begin_src org, maybe introducing a
different special environment would be better, say #+begin_lang XX where
XX is the ISO-code of said language, or the locale (think en_US
vs. en_GB.)
The drawback, and the clear disadvantage compared to your method is that
this works great only when the languages are separated by paragraph
breaks.
Therefore, I think our suggestions might be somewhat orthogonal. Yours
could be a shorthand syntax for introducing inline foreign-language
snippets.
What do you think?
Regards,
Aleks
Juan Manuel Macías writes:
> Hi all,
>
> I'm curious to see how other Org users deal with multilingual documents,
> that is, those documents (for example, philology or linguistics texts)
> that contain a significant number of online quotes in other languages.
> Naturally, this makes more sense in the LaTeX backend, since it is
> convenient to enclose these quotes in a \foreignlanguage command to
> ensure that LaTeX at least apply the correct hyphenation patterns for
> words in other languages.
>
> Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
> need to do this when it comes to languages whose script is different
> from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
> We can, for example, define Russian and Greek as:
>
> #+begin_src latex
> \babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
> \babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
> #+end_src
>
> And also the fonts for both languages:
>
> #+begin_src latex
> \babelfont[russian]{rm}{Linux Libertine O}
> \babelfont[greek]{rm}]{Free Serif}
> #+end_src
>
> For Latin-based scripts it is still necessary enclose the text in the
> \foreignlanguage command. And now comes the question: how do Org users
> who work in multilingual documents to obtain this command when exporting
> to Latex?
>
> I usually use macros, which always tend to work fine. But lately I have
> been testing an alternative markup system using an export filter. The
> idea would be something like:
>
> %(lang) lorem ipsum dolor %()
>
> I start from a list of the most used languages:
>
> #+begin_src emacs-lisp
> (langs '(("en" "english")
> ("fr" "french")
> ("de" "german")
> ("it" "italian")
> ("pt" "portuguese")))
> #+end_src
>
> And other possible languages that Babel supports can be indicated
> explicitly, by prepending "--":
>
> %(fr) ... %()
>
> %(--esperanto) ... %()
>
> (If someone wants to try it, I attach a small Org document).
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Possibility of using alternative separators in macros
2021-05-01 21:50 8% ` Juan Manuel Macías
@ 2021-05-02 21:08 5% ` Christian Moe
0 siblings, 0 replies; 200+ results
From: Christian Moe @ 2021-05-02 21:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Bastien, orgmode, Nicolas Goaziou
I frequently need to escape commas in macros, which is a bit of a pain
and easy to forget. My most frequent use case is a macro that expands in
ODT export to a margin comment (like #+begin_annotation does, but
without causing a line break). It takes one argument which typically
consists of several lines of text with commas in them. If I forget to
escape a comma, the rest of the comment is silently lost to the reader.
So a backwards-compatible remedy would be nice. Juan's/Nicholas's
solution is smart, but I'm not sure if it's exactly what I've been
waiting for. It saves escaping every comma, but I'd still have to
remember to add the separator character every time I *invoke* a macro,
and remembering is the tricky part. I don't know if you've already
considered the option of instead specifying a different separator in the
macro *definition*, say something like
#+macro: comment @@html:<!-- $1 -->@@ :sep "&"
Another point: Something that would help, without adding new syntax, is
making macro expansion smart enough to *ignore* separators when the
macro definition contains only *one* argument anyway, as in the cases
above. That behavior would also be safely backwards-compatible, I
think. It would not help with macros with more than one arg, like Juan's
example, but it would solve most of my problems, for example.
Yours,
Christian
Juan Manuel Macías writes:
> Hi all,
>
> Thanks for your comments, Bastien and Nicolas.
>
> I think macros can work out of the box as a perfect 'backend' for those
> LaTeX commands that include at least one argument with textual content.
> In my case they are very useful to 'extend' the markup language. Apart
> from the LaTeX example that I put previously
> (\foreignlanguage{lang}{short-text}), there are commands like
> \textsc{text in small caps}, \textcolor{color}{text}, and so on. When
> one of the arguments consists of textual content, even if it is a short
> text, it can be tedious to escape constantly commas[1]. Anyway, I
> understand that my use case may not be that of the rest of the users,
> and what is a 'problem' for me, it may not be seen as a problem by other
> users; therefore, I fully understand Bastien's warnings about making a
> modification to something that already works fine, and has been working
> fine since always.
>
> Nicolas's suggestion seemed the most reasonable, or the least
> destructive, in the hypothetical scenario that there would be a great
> demand among users of an alternative separator. Now I see unlikely,
> however, that such a demand exists ;-) So, if my use case is a minority,
> of course I agree with give up this proposal...
>
> [1] To mitigate 'comma issue' I wrote a function that escapes commas
> when saving document :-D
>
> Best regards,
>
> Juan Manuel
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Bastien <bzg@gnu.org> writes:
>>
>>> thank you for the patch. I understand the general idea, but I think
>>> we should be careful not to overload the macro syntax - escaping the
>>> coma seems okay to me. I'm closing this suggestion.
>>>
>>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>>> course insist on rejecting it.
>>
>> This is a followup to a previous discussion in this mailing list, in
>> which Juan Manuel explained his use-case for a different argument
>> separator in macros. I noticed then that there was an opening for
>> a backward compatible syntax extension for it. As I was also not certain
>> it would be a good idea overall, I suggested him to start a new, more
>> visible, thread with the proposal, and collect feedback.
>>
>> So, maybe it is a bit early to close it.
>>
>> BTW, I would like to amend the proposed syntax, so as to limit friction
>> with the rest of Org. What would be more reasonable is the following:
>>
>> {{{macroname·(...)}}}
>>
>> where · is either nothing or a _single_ printable non-alphanumeric
>> non-space non-parenthesis character that isn't already meaningful in
>> Org. For example, if for some reason, we limit ourselves to ASCII
>> characters only, the set of allowed separators would be:
>>
>> ! % & , ; ? `
>>
>> So, again, I'm not saying we should do this. TBH, I'm not convinced by
>> the idea of duplicate syntax (comma-escaping and alternate characters)
>> for the same thing. But hard-core macro users may have a word to say
>> about it.
>>
>> WDYT?
>>
>> Regards,
^ permalink raw reply [relevance 5%]
* About multilingual documents
@ 2021-05-02 20:20 8% Juan Manuel Macías
2021-05-03 6:58 5% ` Aleksandar Dimitrov
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-02 20:20 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]
Hi all,
I'm curious to see how other Org users deal with multilingual documents,
that is, those documents (for example, philology or linguistics texts)
that contain a significant number of online quotes in other languages.
Naturally, this makes more sense in the LaTeX backend, since it is
convenient to enclose these quotes in a \foreignlanguage command to
ensure that LaTeX at least apply the correct hyphenation patterns for
words in other languages.
Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
need to do this when it comes to languages whose script is different
from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
We can, for example, define Russian and Greek as:
#+begin_src latex
\babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
\babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
#+end_src
And also the fonts for both languages:
#+begin_src latex
\babelfont[russian]{rm}{Linux Libertine O}
\babelfont[greek]{rm}]{Free Serif}
#+end_src
For Latin-based scripts it is still necessary enclose the text in the
\foreignlanguage command. And now comes the question: how do Org users
who work in multilingual documents to obtain this command when exporting
to Latex?
I usually use macros, which always tend to work fine. But lately I have
been testing an alternative markup system using an export filter. The
idea would be something like:
%(lang) lorem ipsum dolor %()
I start from a list of the most used languages:
#+begin_src emacs-lisp
(langs '(("en" "english")
("fr" "french")
("de" "german")
("it" "italian")
("pt" "portuguese")))
#+end_src
And other possible languages that Babel supports can be indicated
explicitly, by prepending "--":
%(fr) ... %()
%(--esperanto) ... %()
(If someone wants to try it, I attach a small Org document).
Best regards,
Juan Manuel
[-- Attachment #2: test-langs.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2263 bytes --]
^ permalink raw reply [relevance 8%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
@ 2021-05-02 11:09 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-02 11:09 UTC (permalink / raw)
To: Eric S Fraga; +Cc: Bastien, orgmode, TEC
Hi Eric and all,
Thank you for your comments.
Eric S Fraga writes:
> What is being proposed looks reasonable to me. I don't use =verse= very
> often but have used it now and again and I can particular see the need
> for numbering and centring, in particular.
Indeed, optical centering is the correct typographic representation for
poetry and poetry quotes. There would only be a couple exceptions: a)
Certain types of avant-garde poetry (whose representation on paper is
usually freer) and b) those poems whose verses spill over the margins
and span several lines (in such case, the attribute :versewidth would
have to take the value \textwidth, and then the verse package takes care
of adjusting the overflowing part of the verses).
Here I have uploaded two very illustrative examples of optical
centering, two pages from a Tolkien book (/The Monsters and the Critics
and Other Essays/) and another page from a book that I recently
typesetted (here also includes verse numbering):
https://imgur.com/a/cGi4CpD
> Is the verse package loaded automatically already? I did not see any
> change in the patch to that aspect and when I export a simple test, the
> package is not loaded.
For now, you need to load the verse package or add it to
org-latex-packages-alist...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Possibility of using alternative separators in macros
@ 2021-05-01 21:50 8% ` Juan Manuel Macías
2021-05-02 21:08 5% ` Christian Moe
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-05-01 21:50 UTC (permalink / raw)
To: Nicolas Goaziou, Bastien; +Cc: orgmode
Hi all,
Thanks for your comments, Bastien and Nicolas.
I think macros can work out of the box as a perfect 'backend' for those
LaTeX commands that include at least one argument with textual content.
In my case they are very useful to 'extend' the markup language. Apart
from the LaTeX example that I put previously
(\foreignlanguage{lang}{short-text}), there are commands like
\textsc{text in small caps}, \textcolor{color}{text}, and so on. When
one of the arguments consists of textual content, even if it is a short
text, it can be tedious to escape constantly commas[1]. Anyway, I
understand that my use case may not be that of the rest of the users,
and what is a 'problem' for me, it may not be seen as a problem by other
users; therefore, I fully understand Bastien's warnings about making a
modification to something that already works fine, and has been working
fine since always.
Nicolas's suggestion seemed the most reasonable, or the least
destructive, in the hypothetical scenario that there would be a great
demand among users of an alternative separator. Now I see unlikely,
however, that such a demand exists ;-) So, if my use case is a minority,
of course I agree with give up this proposal...
[1] To mitigate 'comma issue' I wrote a function that escapes commas
when saving document :-D
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
>> thank you for the patch. I understand the general idea, but I think
>> we should be careful not to overload the macro syntax - escaping the
>> coma seems okay to me. I'm closing this suggestion.
>>
>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>> course insist on rejecting it.
>
> This is a followup to a previous discussion in this mailing list, in
> which Juan Manuel explained his use-case for a different argument
> separator in macros. I noticed then that there was an opening for
> a backward compatible syntax extension for it. As I was also not certain
> it would be a good idea overall, I suggested him to start a new, more
> visible, thread with the proposal, and collect feedback.
>
> So, maybe it is a bit early to close it.
>
> BTW, I would like to amend the proposed syntax, so as to limit friction
> with the rest of Org. What would be more reasonable is the following:
>
> {{{macroname·(...)}}}
>
> where · is either nothing or a _single_ printable non-alphanumeric
> non-space non-parenthesis character that isn't already meaningful in
> Org. For example, if for some reason, we limit ourselves to ASCII
> characters only, the set of allowed separators would be:
>
> ! % & , ; ? `
>
> So, again, I'm not saying we should do this. TBH, I'm not convinced by
> the idea of duplicate syntax (comma-escaping and alternate characters)
> for the same thing. But hard-core macro users may have a word to say
> about it.
>
> WDYT?
>
> Regards,
^ permalink raw reply [relevance 8%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-01 10:58 6% ` Bastien
@ 2021-05-01 11:46 10% ` Juan Manuel Macías
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
2021-05-08 7:31 6% ` Juan Manuel Macías
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-05-01 11:46 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Thank you very much again for your kind suggestions.
Bastien writes:
> I'm copying Eric, a poweruser of the LaTeX backend, so that he can
> perhaps comment on the general usefulness of this addition.
I think these additions (line numbers, optical centering of the poem,
etc.) can be useful (IMHO) for the correct representation of poetry
(generally in Humanities), since the verse.sty package is a sort of
'unofficial' replacement for the standard LaTeX verse environment, which
has certain limitations.
> The patch lacks a commit message - see this explanations:
> https://orgmode.org/worg/org-contribute.html#commit-messages
Sorry again for not including a commit message. If the patch it is
finally accepted, I can submit a new version that includes a commit
message (and a few minor fixes I made to the code).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-05-01 10:58 6% ` Bastien
@ 2021-05-01 10:58 6% ` Timothy
1 sibling, 0 replies; 200+ results
From: Timothy @ 2021-05-01 10:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Sorry it's still taking a while for your patch to be looked at.
Assuming it does get merged, it would be good to check if you'd be
willing to write a manual entry to accompany this (in a separate patch
works).
Thanks again for the patch,
Timothy.
Juan Manuel Macías <maciaschain@posteo.net> writes:
^ permalink raw reply [relevance 6%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2021-05-01 10:58 6% ` Bastien
2021-05-01 11:46 10% ` Juan Manuel Macías
` (2 more replies)
2021-05-01 10:58 6% ` Timothy
1 sibling, 3 replies; 200+ results
From: Bastien @ 2021-05-01 10:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Eric Fraga, orgmode, TEC
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a new version of my patch for adding LaTeX attributes to
> verse blocks. Following the kind suggestions from Timothy, I have also
> documented this new features that I propose. I don't know if I have done
> it correctly and in the right place...
thanks a lot -- we need to wait for the FSF copyright assignment
process to be finished in order to accept this patch.
I'm copying Eric, a poweruser of the LaTeX backend, so that he can
perhaps comment on the general usefulness of this addition.
The patch lacks a commit message - see this explanations:
https://orgmode.org/worg/org-contribute.html#commit-messages
Let us know if you need more directions and how to produce a patch
that we can more easily apply.
Thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?
2021-04-30 20:40 10% ` Juan Manuel Macías
@ 2021-04-30 23:40 3% ` Richard Stanton
0 siblings, 0 replies; 200+ results
From: Richard Stanton @ 2021-04-30 23:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
That works. Thanks Juan Manuel!
> On Apr 30, 2021, at 1:40 PM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Richard,
>
> Richard Stanton <rhstanton@berkeley.edu> writes:
>
>> I’d like to define a macro called, say, articletext, to insert this
>> header into my document before exporting to LaTeX, so the org file
>> would look something like this:
>>
>> {{{article text}}}
>> This text appears only in the article version.
>
> Macro definitions do not allow spaces.
>
> You can try something like:
>
> #+MACRO: article_text (eval (concat "*** More explanation coming" "\s" ":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))
>
> {{{article_text}}}
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 3%]
* Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?
@ 2021-04-30 20:40 10% ` Juan Manuel Macías
2021-04-30 23:40 3% ` Richard Stanton
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-30 20:40 UTC (permalink / raw)
To: Richard Stanton; +Cc: orgmode
Hi Richard,
Richard Stanton <rhstanton@berkeley.edu> writes:
> I’d like to define a macro called, say, articletext, to insert this
> header into my document before exporting to LaTeX, so the org file
> would look something like this:
>
> {{{article text}}}
> This text appears only in the article version.
Macro definitions do not allow spaces.
You can try something like:
#+MACRO: article_text (eval (concat "*** More explanation coming" "\s" ":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))
{{{article_text}}}
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [PATCH] Possibility of using alternative separators in macros
@ 2021-04-30 13:26 6% Juan Manuel Macías
2021-05-11 11:01 5% ` Eric S Fraga
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-30 13:26 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]
Hi all,
I would like to propose (patch attached) the possibility of using an
alternate character for separate arguments in replacement macros,
following a suggestion from Nicolas Goaziou in this (closed) thread:
https://orgmode.org/list/87o8ead42u.fsf@nicolasgoaziou.fr/
The idea would be to explicitly indicate the separator just before the
parentheses. The allowed characters are any character other than a
letter, a number, a space, a dash, a low line or a parenthesis.
A new property `:sep' is added to `org-element-macro-parser', whose
default value is a comma.
Example of use. Suppose we define this macro:
#+MACRO: foo (eval (format "%s and %s" $1 $2))
Under normal conditions, the expected separator will be the comma:
{{{foo(x,z\, y)}}}
=> x and z, y
But we can also do this:
{{{foo@(x@z, y \@)}}}
=> x and z, y @
I think sometimes it may be preferable to separate the arguments by an
alternative character. For example, let's imagine we define a macro
(named 'lg') for LaTeX export, which admits two arguments, exactly the
same args as the Babel (LaTeX) macro \foreignlanguage{lang}{short-text}:
{{{lg(lang,short-text)}}}.
It would be much more comfortable something like:
{{{lg|(latin|trado, tradidi, traditur)}}}
instead of having to escape commas in:
{{{lg(latin,trado\, tradidi\, traditur)}}}
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Alternative-args-separator-for-replacement-macros.patch --]
[-- Type: text/x-patch, Size: 2967 bytes --]
From 400d5779508fd7206a353bdb444c3cba382b8f01 Mon Sep 17 00:00:00 2001
From: juanmanuel <maciaschain@posteo.net>
Date: Fri, 30 Apr 2021 14:45:54 +0200
Subject: [PATCH] Alternative args separator for replacement macros
---
lisp/org-element.el | 9 +++++++--
lisp/org-macro.el | 9 +++++----
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..34a9b880a 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3279,21 +3279,25 @@ CONTENTS is the contents of the object, or nil."
"Parse macro at point, if any.
When at a macro, return a list whose car is `macro' and cdr
-a plist with `:key', `:args', `:begin', `:end', `:value' and
+a plist with `:key', `:args', `:begin', `:end', `:sep', `:value' and
`:post-blank' as keywords. Otherwise, return nil.
Assume point is at the macro."
(save-excursion
- (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
+ (when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]*[^-a-zA-Z0-9_\s]*\\)\\((\\([^\000]*?\\))\\)?}}}")
(let ((begin (point))
(key (downcase (match-string-no-properties 1)))
(value (match-string-no-properties 0))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point))
+ (sep (if (not (equal (match-string-no-properties 2) ""))
+ (match-string-no-properties 2)
+ ","))
(args (pcase (match-string-no-properties 3)
(`nil nil)
(a (org-macro-extract-arguments
+ sep
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
@@ -3302,6 +3306,7 @@ Assume point is at the macro."
:args args
:begin begin
:end end
+ :sep sep
:post-blank post-blank))))))
(defun org-element-macro-interpreter (macro _)
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 29c403658..e047cd78e 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -294,20 +294,21 @@ of `org-macro-extract-arguments'."
nil t)
s)))))
-(defun org-macro-extract-arguments (s)
+(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
-Return a list of arguments, as strings. This is the opposite of
+SEP is the character used to separate arguments. Return a list
+of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
- "\\(\\\\*\\),"
+ (format "\\(\\\\*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str))))
(concat (make-string (/ len 2) ?\\)
- (if (zerop (mod len 2)) "\000" ","))))
+ (if (zerop (mod len 2)) "\000" (format "%s" sep)))))
s nil t)
"\000"))
--
2.26.0
^ permalink raw reply related [relevance 6%]
* Re: [patch] to allow org-attach-git to handle individual repositories
2021-04-28 3:57 6% ` Bastien
@ 2021-04-28 13:42 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-28 13:42 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Bastien writes:
> It looks good but it is significative enough to require you to sign
> the FSF copyright assignment. If you're willing to go through this
> (which will secure future contributions too), please see:
Thanks for the advice. I just signed and sent the FSF copyright
assignment.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-28 5:46 6% ` Bastien
@ 2021-04-28 6:37 0% ` Nicolas Goaziou
0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-04-28 6:37 UTC (permalink / raw)
To: Bastien; +Cc: Juan Manuel Macías, orgmode
Hello,
Bastien <bzg@gnu.org> writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Done! I've attached the corrected patch. Sorry for the flaws in me
>> previous patch: I'm a bit of a novice at submitting patches...
>
> applied in the maint branch as commit 5be650714.
Unfortunately, this is not a proper fix for the problem, as discussed in
the thread.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 0%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
2021-04-17 13:27 5% ` Maxim Nikulin
@ 2021-04-28 5:46 6% ` Bastien
2021-04-28 6:37 0% ` Nicolas Goaziou
2 siblings, 1 reply; 200+ results
From: Bastien @ 2021-04-28 5:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Nicolas Goaziou
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Done! I've attached the corrected patch. Sorry for the flaws in me
> previous patch: I'm a bit of a novice at submitting patches...
applied in the maint branch as commit 5be650714.
The patch was missing a proper changelog entry: please see
https://orgmode.org/worg/org-contribute.html#commit-messages
for future patches.
Thanks!
^ permalink raw reply [relevance 6%]
* Re: [patch] to allow org-attach-git to handle individual repositories
@ 2021-04-28 3:57 6% ` Bastien
2021-04-28 13:42 10% ` Juan Manuel Macías
2021-05-15 14:08 6% ` Bastien
1 sibling, 1 reply; 200+ results
From: Bastien @ 2021-04-28 3:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I would like to propose and discuss this patch for org-attach-git,
> following a series of comments and suggestions from Ihor Radchenko in
> this thread:
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html
thanks for the patch and sorry for the slow reply.
It looks good but it is significative enough to require you to sign
the FSF copyright assignment. If you're willing to go through this
(which will secure future contributions too), please see:
https://orgmode.org/request-assign-future.txt
Thanks!
^ permalink raw reply [relevance 6%]
* Re: [tip] search this mailing list with helm-surfraw
2021-04-25 5:00 7% ` Bastien
@ 2021-04-27 20:20 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-27 20:20 UTC (permalink / raw)
To: Bastien; +Cc: orgmode
Hi Bastien,
Bastien writes:
> Neat!
>
> You might want to write another one for the public-inbox archive:
>
> E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas
I was unaware that searches in the public-box archive are faster...
Thank you very much for the advice :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [tip] search this mailing list with helm-surfraw
2021-04-05 9:25 8% [tip] search this mailing list with helm-surfraw Juan Manuel Macías
@ 2021-04-25 5:00 7% ` Bastien
2021-04-27 20:20 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-04-25 5:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have written some elvis for my
> personal use, among them this simple script to search this mailing list,
> which I share here in case someone finds it useful:
Neat!
You might want to write another one for the public-inbox archive:
E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas
^ permalink raw reply [relevance 7%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-22 13:46 10% ` Juan Manuel Macías
@ 2021-04-25 3:46 6% ` Timothy
0 siblings, 0 replies; 200+ results
From: Timothy @ 2021-04-25 3:46 UTC (permalink / raw)
To: emacs-orgmode
As you have said you'll start a new thread for your revised proposal,
I'll mark this as closed on updates.orgmode.org via the X-Woof-Patch
header.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ok, I agree. Next week I will start a new thread for submit this new
> proposal.
>
> Best regards,
>
> Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-21 15:45 9% ` Juan Manuel Macías
@ 2021-04-24 14:41 5% ` Maxim Nikulin
0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-04-24 14:41 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Nicolas Goaziou
On 21/04/2021 22:45, Juan Manuel Macías wrote:
>
> I have tried the Nicolas' patch (latest version) and I see that the
> items with emphasis are already ordered well. However, it seems that the
> problem with identical items with or without emphasis still persists:
> which items should go before and in what order? For example, in the
> following list I get:
>
> - /a/
> - *a*
> - a
> - *b*
> - /b/
> - b
> - /v/
> - *v*
> - v
I am afraid, there is no easy way to take into account emphasis. Each
item have to be split into logical units and locale-aware multilevel
comparison should be applied to each unit separately. E.g. for
description list, only term should be compared at first to properly
order emphasized items, it does not matter if description starts from
"a" or from "z". Simple `string-collate-lessp' for whole item uses
further levels only strings are considered identical on previous levels.
I had an idea to augment sort keys with some text properties for custom
string comparator, but I decided that such complications would not
ensure reliable sort for all possible cases.
- A :: B
- /A/ :: C
- *A* :: A
However `org-sort-remove invisible' still has some room for improvements
(it is not mandatory in my opinion). I have realized it reading the
thread on title representation for HTML export
https://orgmode.org/list/87h7jy4ebe.fsf@nicolasgoaziou.fr/
- <<target>>A
- <<<radio>>>
- B
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-22 12:55 5% ` Nicolas Goaziou
@ 2021-04-22 13:46 10% ` Juan Manuel Macías
2021-04-25 3:46 6% ` Timothy
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-22 13:46 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas,
Thank you very much for your suggestions.
Nicolas Goaziou writes:
> This change will need to be tested extensively in "test-org-element.el"
> and "test-org-macro.el".
>
> However, as a start, I suggest starting a new thread about a suggested
> change in the syntax, with a clear title, examples, and code. Then we
> can leave time for users to react to it.
>
> Do you want to take care of it?
Ok, I agree. Next week I will start a new thread for submit this new
proposal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-21 16:01 4% ` Juan Manuel Macías
@ 2021-04-22 12:55 5% ` Nicolas Goaziou
2021-04-22 13:46 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-22 12:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think it's a very interesting idea. I've made this sketch (at least
> as a proof of concept), what do you think of the approach?
I think there are a few things to fix. For example, the separator may
need to be stored in the properties of the macro. Otherwise,
interpreting data back would return to comma-separated arguments, which
may not be desirable, although correct.
Also, I would limit separator to a single character. You also need to
exclude space characters.
> Example (and code below):
>
> #+macro: foo (eval (format "%s and %s" $1 $2))
>
> {{{foo(xxx,zzz\, yyy)}}}
>
> {{{foo|(xxx|zzz, aaa)}}}
>
> {{{foo@(xxx@zzz, sss)}}}
>
> {{{foo|(xxx|zzz\| aaa)}}}
>
> {{{foo@(xxx@zzz\@ sss)}}}
This change will need to be tested extensively in "test-org-element.el"
and "test-org-macro.el".
However, as a start, I suggest starting a new thread about a suggested
change in the syntax, with a clear title, examples, and code. Then we
can leave time for users to react to it.
Do you want to take care of it?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-19 9:19 5% ` Nicolas Goaziou
2021-04-20 13:56 8% ` Juan Manuel Macías
@ 2021-04-21 16:01 4% ` Juan Manuel Macías
2021-04-22 12:55 5% ` Nicolas Goaziou
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-21 16:01 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello again.
I forgot to answer this question on your previous message, sorry...
Nicolas Goaziou writes:
> That being said, we can discuss syntax that is not depending upon some
> variable. For example macro names are written with a limited set of
> characters (alphanumeric, dash, underscore). We might allow the optional
> argument separator to be located right before the opening parenthesis,
> e.g.,
>
> {{{macroname@(latin@Lorem ipsum dolor sit amet, ...)}}}
> {{{macroname|(latin|Lorem ipsum dolor sit amet, ...)}}}
I think it's a very interesting idea. I've made this sketch (at least
as a proof of concept), what do you think of the approach?
Example (and code below):
#+macro: foo (eval (format "%s and %s" $1 $2))
{{{foo(xxx,zzz\, yyy)}}}
{{{foo|(xxx|zzz, aaa)}}}
{{{foo@(xxx@zzz, sss)}}}
{{{foo|(xxx|zzz\| aaa)}}}
{{{foo@(xxx@zzz\@ sss)}}}
#+begin_src emacs-lisp
(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
Return a list of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
(format "\\(\\\\*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str))))
(concat (make-string (/ len 2) ?\\)
(if (zerop (mod len 2)) "\000" (format "%s" sep)))))
s nil t)
"\000"))
(defun org-element-macro-parser ()
"Parse macro at point, if any.
When at a macro, return a list whose car is `macro' and cdr
a plist with `:key', `:args', `:begin', `:end', `:value' and
`:post-blank' as keywords. Otherwise, return nil.
Assume point is at the macro."
(save-excursion
(when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z]*[^-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
(let ((begin (point))
(key (downcase (match-string-no-properties 1)))
(value (match-string-no-properties 0))
(post-blank (progn (goto-char (match-end 0))
(skip-chars-forward " \t")))
(end (point))
(args (pcase (match-string-no-properties 4)
(`nil nil)
(a (org-macro-extract-arguments
(if (not (equal (match-string-no-properties 2) ""))
(match-string-no-properties 2)
",")
(replace-regexp-in-string
"[ \t\r\n]+" " " (org-trim a)))))))
(list 'macro
(list :key key
:value value
:args args
:begin begin
:end end
:post-blank post-blank))))))
(defun org-macro-extract-arguments (sep s)
"Extract macro arguments from string S.
S is a string containing comma separated values properly escaped.
Return a list of arguments, as strings. This is the opposite of
`org-macro-escape-arguments'."
;; Do not use `org-split-string' since empty strings are
;; meaningful here.
(split-string
(replace-regexp-in-string
(format "\\(\\\\*\\)%s" sep)
(lambda (str)
(let ((len (length (match-string 1 str))))
(concat (make-string (/ len 2) ?\\)
(if (zerop (mod len 2)) "\000" (format "%s" sep)))))
s nil t)
"\000"))
#+end_src
^ permalink raw reply [relevance 4%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-21 15:45 9% ` Juan Manuel Macías
2021-04-24 14:41 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-21 15:45 UTC (permalink / raw)
To: orgmode
Hi all,
Maxim Nikulin writes:
> I think, new variant should be committed even it does not fix Juan's
> case. He have not confirmed the fix yet.
Sorry, I have been busy with other matters and had lost the thread of
the discussion. I'm catching up on the messages...
I have tried the Nicolas' patch (latest version) and I see that the
items with emphasis are already ordered well. However, it seems that the
problem with identical items with or without emphasis still persists:
which items should go before and in what order? For example, in the
following list I get:
- /a/
- *a*
- a
- *b*
- /b/
- b
- /v/
- *v*
- v
Anyway, I think it is a minor problem (I can't think of many
scenarios in real life where this problem is relevant). In a more
realistic case, the result is correct:
- lo /bueno/
- lo bueno
- lo /vano/
- lo vano
...
- /a/
- b
- /v/
- *z*
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
2021-04-19 9:19 5% ` Nicolas Goaziou
@ 2021-04-20 13:56 8% ` Juan Manuel Macías
2021-04-21 16:01 4% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-20 13:56 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hi Nicolas
Nicolas Goaziou writes:
> Even though Org syntax partly is, I don't think parameterizable syntax
> is a way to go. I'd rather have less variables controlling it. (I'm
> looking at you `org-list-allow-alphabetical', and
> `org-plain-list-ordered-item-terminator'.)
Thanks for your explanations. I understand that the use of variables
here is perhaps not the happiest solution. Naturally, I speak of
'solution' assuming there is a 'problem', the choice of the comma as an
argument separator; but I also assume that what is a problem for me, it
doesn't have to be for other users, as here everything is subjective.
Anyway, I couldn't think of another way to respect the original comma
(and backward compatibility), but leaving the user some freedom to
choose a different separator. I also understand that implementing that
can lead to confusion.
>> Rationale for this patch: There are many contexts where the comma character can be
>> inappropriate as an argument separator, since it has to be escaped
>> many times.
>
> That's true. But I wonder if you're hitting a limit of replacement
> macros use case. IMO, macros are good for short text. For bigger ones,
> you may want to use some Babel code, in the language of your choice.
> WDYT?
I think replacement macros have huge potential, that I often explore in
my daily work and (I admit) wearing the things to the limit, which means
struggling with resistance to the material ;-) Perhaps that emerging
potential was not originally foreseen ... Of course, the scenario is
always in short texts, I agree. But even in those scenarios, the comma
as an argument separator is somewhat uncomfortable and confusing. That
is, macros have great potential (IMHO) in contrast to an "ugly" syntax.
But at this point it has a difficult solution...
A typical use case for macros (for me) can be to export to LaTeX with
the command \foreignlanguage{lang}{short text} in multilingual documents
(see this screenshot:
https://gnutas.juanmanuelmacias.com/images/macros-sample.png). I can't
think of another way to do (easily) something like that (with the plus
of being able to evaluate some Elisp in there and add a conditional for
the backend, etc.).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Startup option to separate macros arguments with an alternative string
@ 2021-04-19 9:19 5% ` Nicolas Goaziou
2021-04-20 13:56 8% ` Juan Manuel Macías
2021-04-21 16:01 4% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Nicolas Goaziou @ 2021-04-19 9:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I would like to propose this (possible) patch.
>
> With `#+STARTUP: macro-arg-sep-other' the macros arguments can be
> separated by a string other than comma, whose value is defined in
> `org-macro-arg-sep-other' (by default it is "'@").
Even though Org syntax partly is, I don't think parameterizable syntax
is a way to go. I'd rather have less variables controlling it. (I'm
looking at you `org-list-allow-alphabetical', and
`org-plain-list-ordered-item-terminator'.)
That being said, we can discuss syntax that is not depending upon some
variable. For example macro names are written with a limited set of
characters (alphanumeric, dash, underscore). We might allow the optional
argument separator to be located right before the opening parenthesis,
e.g.,
{{{macroname@(latin@Lorem ipsum dolor sit amet, ...)}}}
{{{macroname|(latin|Lorem ipsum dolor sit amet, ...)}}}
But see below.
> Rationale for this patch: There are many contexts where the comma character can be
> inappropriate as an argument separator, since it has to be escaped
> many times.
That's true. But I wonder if you're hitting a limit of replacement
macros use case. IMO, macros are good for short text. For bigger ones,
you may want to use some Babel code, in the language of your choice.
WDYT?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-18 21:20 11% ` Juan Manuel Macías
@ 2021-04-19 8:33 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-19 8:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I wonder if this other approach can be viable or if it is something
> crazy: if the spaces in org-sort-remove-invisible are a
> problem only for the first emphasis of each item, how about this
> fix to org-sort-list? (not modifying org-sort-remove-invisible):
I think `org-sort-remove-invisible' is wrong, so it is the one that
needs to be fixed.
Could you try the following instead?
--8<---------------cut here---------------start------------->8---
(defun org-sort-remove-invisible (s)
"Remove invisible part of links and emphasis markers from string S."
(let ((remove-markers
(lambda (m)
(concat (match-string 1 m)
(match-string 4 m)
(match-string 5 m)))))
(remove-text-properties 0 (length s) org-rm-props s)
(replace-regexp-in-string
org-verbatim-re remove-markers
(replace-regexp-in-string org-emph-re remove-markers (org-link-display-format s) t tt)
t t)))
--8<---------------cut here---------------end--------------->8---
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-18 17:52 9% ` Juan Manuel Macías
@ 2021-04-18 21:20 11% ` Juan Manuel Macías
2021-04-19 8:33 5% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-18 21:20 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> It seems that what I was proposing as a patch at the beginning is not,
> finally, a viable solution for all contexts...
>
> The problem is that, if the first space is removed, we get this
> abnormal result:
>
> #+begin_src emacs-lisp
> (org-sort-remove-invisible "- lo /bueno/")
> #+end_src
>
> #+RESULTS:
> : - lobueno
I wonder if this other approach can be viable or if it is something
crazy: if the spaces in org-sort-remove-invisible are a
problem only for the first emphasis of each item, how about this
fix to org-sort-list? (not modifying org-sort-remove-invisible):
@@ -2940,10 +2940,20 @@ function is being called interactively."
(org-sort-remove-invisible
(buffer-substring (match-end 0) (point-at-eol)))))
((= dcst ?a)
- (funcall case-func
- (org-sort-remove-invisible
- (buffer-substring
- (match-end 0) (point-at-eol)))))
+ (if (save-excursion
+ (beginning-of-line)
+ (forward-char)
+ (looking-at-p org-emph-re))
+ (replace-regexp-in-string
+ "\\(^\\)\s+" "\\1"
+ (funcall case-func
+ (org-sort-remove-invisible
+ (buffer-substring
+ (match-end 0) (point-at-eol)))))
+ (funcall case-func
+ (org-sort-remove-invisible
+ (buffer-substring
+ (match-end 0) (point-at-eol))))))
((= dcst ?t)
(cond
;; If it is a timer list, convert timer to seconds
^ permalink raw reply [relevance 11%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-17 13:27 5% ` Maxim Nikulin
@ 2021-04-18 17:52 9% ` Juan Manuel Macías
2021-04-18 21:20 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-18 17:52 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Maxim Nikulin writes:
> On 10/04/2021 07:01, Juan Manuel Macías wrote:
>> Nicolas Goaziou writes:
>>> Could you apply the same fix to the `org-verbatim-re' match above, and
>>> provide an appropriate commit message?
>> Done! I've attached the corrected patch. Sorry for the flaws in me
>> previous patch: I'm a bit of a novice at submitting patches...
>
> I have not read yet the following documents to realize what pitfalls
> could be expected due to significant space added to Spanish and Polish
> collation rules in libc.
>
> http://www.unicode.org/reports/tr10/
> Unicode® Technical Standard #10
> Unicode Collation Algorithm
>
> http://www.unicode.org/reports/tr35/tr35-collation.html#CLDR_Collation_Algorithm
> Unicode Technical Standard #35
> Unicode Locale Data Markup Language (LDML)
> Part 5: Collation
>
> In the meanwhile I have realized that org-sort-remove-invisible
> function has rather strange behavior. There are no tests, so I am in
> doubt if the following result is expected and intended (unpatched
> version)
All this research you've done on spaces and collation rules is very
interesting and enlightening.
Certainly, space is important, as the following list in Spanish is
correctly ordered as:
- lo raro
- lo vano
- localidad
However, with the 'unpatched' version of org-sort-remove invisible I get
this result (which is correct) for this list:
- lo bueno
- lo /bueno/
- lo vano
- lo /vano/
And with the patched version, I get this, which is wrong (!):
- lo bueno
- lo vano
- lo /bueno/
- lo /vano/
It seems that what I was proposing as a patch at the beginning is not,
finally, a viable solution for all contexts...
The problem is that, if the first space is removed, we get this
abnormal result:
#+begin_src emacs-lisp
(org-sort-remove-invisible "- lo /bueno/")
#+end_src
#+RESULTS:
: - lobueno
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
@ 2021-04-17 13:27 5% ` Maxim Nikulin
2021-04-18 17:52 9% ` Juan Manuel Macías
2021-04-28 5:46 6% ` Bastien
2 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-04-17 13:27 UTC (permalink / raw)
To: emacs-orgmode
On 10/04/2021 07:01, Juan Manuel Macías wrote:
> Nicolas Goaziou writes:
>> Could you apply the same fix to the `org-verbatim-re' match above, and
>> provide an appropriate commit message?
>
> Done! I've attached the corrected patch. Sorry for the flaws in me
> previous patch: I'm a bit of a novice at submitting patches...
I have not read yet the following documents to realize what pitfalls
could be expected due to significant space added to Spanish and Polish
collation rules in libc.
http://www.unicode.org/reports/tr10/
Unicode® Technical Standard #10
Unicode Collation Algorithm
http://www.unicode.org/reports/tr35/tr35-collation.html#CLDR_Collation_Algorithm
Unicode Technical Standard #35
Unicode Locale Data Markup Language (LDML)
Part 5: Collation
In the meanwhile I have realized that org-sort-remove-invisible function
has rather strange behavior. There are no tests, so I am in doubt if the
following result is expected and intended (unpatched version)
(org-sort-remove-invisible "- (*bold*)")
"- bold "
I would expect
"- (bold)"
P.S.
On 10/04/2021 17:19, Nicolas Goaziou wrote:
>
> Do you have a simple test case to reproduce the problem? Currently
> sorting the following trivial lists causes no issue:
After the lengthy discussion the problem is traced down to the following:
- Ensure that you have *compiled* recent enough es_ES.UTF-8 locale
(description includes
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hp=d17612f6726d0c098ac981e06f3702106540bb23;hb=159738548130d5ac4fe6178977e940ed5f8cfdc4;hpb=ce6636b06b67d6bb9b3d6927bf2a926b9b7478f5)
- LC_ALL= LANG=es_ES.UTF-8 emacs
- (org-sort-list t ?a) for the following snippet
- /a/
- a
- /v/
- v
Significance of space should be better illustrated with multi-word items
but I am not ready to provide an impressive example yet.
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-15 18:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-15 18:21 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim
Maxim Nikulin writes:
> I can reproduce the issue with emacs-27.1 from ubuntu-21.04 beta live
> image running in qemu. Org mode is current git HEAD. It seems that
> something is changed in emacs since locale is correct:
>
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
> | LANG=C.UTF-8 sort
> - /a/
> - /v/
> - a
> - v
> ubuntu@ubuntu:~$ printf '%s- v\n- /v/\n- a\n- /a/\n' '' \
> | LANG=es_ES.UTF-8 sort
> - /a/
> - a
> - /v/
> - v
>
> Concerning org-sort-list, I do not see any problem with en_US.UTF-8,
> it_IT.UTF-8, and ru_RU.UTF-8 locales. However emphasized items are
> sorted first for at least es_ES.UTF-8, es_MX.UTF-8, and es_US.UTF-8.
> I have found some evidence that the problem is on the org side
>
> cat list.el
> (message "%S" (sort '("- /v/" "- v" "- a" "- /a/")
> #'string-collate-lessp))
>
> LC_ALL=C.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- /v/" "- a" "- v")
>
> LC_ALL=en_US.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- a" "- /v/" "- v")
>
> LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list.el
> ("- /a/" "- a" "- /v/" "- v")
>
> So even string-collate-lessp works as expected.
>
> I'm puzzled why the problem is specific to org-sort-list and namely to
> Spanish locales.
>
>
Well that's pretty weird ... I wonder if the (spurious?) spaces in
`org-sort-remove-invisible' that I mentioned at the beginning may be
helpful to keep a track, or if it's just something that masks the
problem.
Anyway, I have noticed that the only space that seems determinant (from
some way that escapes me) is this (where I put the @ sign):
org-emph-re (lambda (m) (format "@%s " (match-string 4 m)))
Following your examples, it occurred to me to try this, which I don't
know if it is relevant or if I have entered a dead end:
#+begin_src emacs-lisp :tangle list-var.el
(message "%S" (sort '("-\s\sv" "-\sv" "-\sa" "-\s\sa")
#'string-collate-lessp))
#+end_src
#+begin_src sh
exec 2>&1
LC_ALL=en_US.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
#+RESULTS:
: - a" "- a" "- v" "- v
#+begin_src sh
exec 2>&1
LC_ALL=es_ES.UTF-8 emacs --batch -Q -l list-var.el
#+end_src
#+RESULTS:
: - a" "- v" "- a" "- v
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-14 17:07 9% ` Juan Manuel Macías
@ 2021-04-14 21:36 12% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-14 21:36 UTC (permalink / raw)
To: orgmode
Hello again,
Since I have an old Emacs version (24.5.1) on my Raspberry, I've done
a few more tests. The situation is the following:
1. On Arch Linux and Emacs 27.2:
- The system locales are set to "es_ES.UTF-8". When, inside Emacs, I do M-x
getenv RET LANG RET, I get "es_ES.UTF-8".
org-sort-list a -> wrong result;
- Launching Emacs from terminal with
LANG=es_ES.UTF-8 \
etc...
org-sort-list a -> wrong result again.
2. On Fedora 32 (virtual machine) and Emacs 27.1
- Everything as in the previous case.
3. On Raspian stretch and Emacs 24.5.1:
- The system locales are set to "es_ES.UTF-8" as well. When, inside a
normal Emacs session, I do M-x getenv RET lang RET, I get "es_ES.UTF-8".
org-sort-list a -> wrong result;
- Launching Emacs from terminal with
LANG=es_ES.UTF-8 \
etc...
In this case the list is ordered correctly, but I observe that similar
forms with or without emphasis are not always ordered in the same way.
Sometimes the non-emphasized forms are ordered before and sometimes
they are ordered after (?).
I don't know if I'm missing something...
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Hi Maxim,
>
> Thanks again. In my case, I keep getting the wrong result. In addition
> to the test I did in a virtual machine with Fedora, I use Arch Linux in
> my every day computers, with locales correctly (I hope) configured as
> es_ES.UTF-8 (there was a typo in my previous mail, sorry:
> 'en_ES.UTF-8'). In my /etc/locale.conf file I have:
>
> LANG=es_ES.UTF-8
> LC_ADDRESS=es_ES.UTF-8
> LC_IDENTIFICATION=es_ES.UTF-8
> LC_MEASUREMENT=es_ES.UTF-8
> LC_MONETARY=es_ES.UTF-8
> LC_NAME=es_ES.UTF-8
> LC_NUMERIC=es_ES.UTF-8
> LC_PAPER=es_ES.UTF-8
> LC_TELEPHONE=es_ES.UTF-8
> LC_TIME=es_ES.UTF-8
>
> And with locale -a, I get a list of enabled locales:
>
> C
> en_US.utf8
> es_ES.utf8
> POSIX
>
> However, I keep getting the wrong result :-( (Arch, Emacs 27.2).
>
> Even with
>
> LANG=en_EN.UTF-8 \
> emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> Maybe the problem is on Arch's side (?), although it was also reproducible
> in the test I did with Fedora in virtual machine and Emacs 27.
>
> Best regards,
>
> Juan Manuel
>
> Maxim Nikulin writes:
>
>> On 14/04/2021 02:08, Juan Manuel Macías wrote:
>>> The situation is that with locales configured for Spanish from Spain
>>> (en_ES.UTF-8) the list is not ordered correctly, unless those three
>>> spaces from org-sort-remove-invisible are removed. But I couldn't say
>>> why or if that would be appropriate as a patch...
>>
>> Did not you get a warning like the following one?
>>
>> (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
>> library.
>> Using the fallback 'C' locale.
>>
>>> Regarding the collation rule of forms with emphasis, at least in Spanish
>>> these should come after the non-emphasized forms. I don't know if this
>>> is a general rule also for other languages (at least it seems more
>>> natural that the forms without emphasis are placed before).
>>
>> LANG=es_ES.UTF-8 \
>> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
>> list.org
>>
>> - a
>> - /a/
>> - v
>> - /v/
>>
>> So it works accordingly to your expectation. Emacs 25.2.2,
>> Ubuntu-18.04 container.
>>
>> I have generated es_ES.UTF-8 locale using
>>
>> dpkg-reconfigure locales
>>
>> Depending on linux distribution you run, the locale may be ready to
>> use or not. I tend to think that in minimal environment of virtual
>> machine it was missed.
>>
>> I had an idea to add a test for sorting of items including emphasized
>> ones but test-org-list/sort forces C locale. Maybe it was done to
>> avoid failures due to missed locale.
>>
>>
>
^ permalink raw reply [relevance 12%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-14 15:42 5% ` Maxim Nikulin
@ 2021-04-14 17:07 9% ` Juan Manuel Macías
2021-04-14 21:36 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-14 17:07 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim,
Thanks again. In my case, I keep getting the wrong result. In addition
to the test I did in a virtual machine with Fedora, I use Arch Linux in
my every day computers, with locales correctly (I hope) configured as
es_ES.UTF-8 (there was a typo in my previous mail, sorry:
'en_ES.UTF-8'). In my /etc/locale.conf file I have:
LANG=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_IDENTIFICATION=es_ES.UTF-8
LC_MEASUREMENT=es_ES.UTF-8
LC_MONETARY=es_ES.UTF-8
LC_NAME=es_ES.UTF-8
LC_NUMERIC=es_ES.UTF-8
LC_PAPER=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_TIME=es_ES.UTF-8
And with locale -a, I get a list of enabled locales:
C
en_US.utf8
es_ES.utf8
POSIX
However, I keep getting the wrong result :-( (Arch, Emacs 27.2).
Even with
LANG=en_EN.UTF-8 \
emacs -nw -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
Maybe the problem is on Arch's side (?), although it was also reproducible
in the test I did with Fedora in virtual machine and Emacs 27.
Best regards,
Juan Manuel
Maxim Nikulin writes:
> On 14/04/2021 02:08, Juan Manuel Macías wrote:
>> The situation is that with locales configured for Spanish from Spain
>> (en_ES.UTF-8) the list is not ordered correctly, unless those three
>> spaces from org-sort-remove-invisible are removed. But I couldn't say
>> why or if that would be appropriate as a patch...
>
> Did not you get a warning like the following one?
>
> (process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
> library.
> Using the fallback 'C' locale.
>
>> Regarding the collation rule of forms with emphasis, at least in Spanish
>> these should come after the non-emphasized forms. I don't know if this
>> is a general rule also for other languages (at least it seems more
>> natural that the forms without emphasis are placed before).
>
> LANG=es_ES.UTF-8 \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> - a
> - /a/
> - v
> - /v/
>
> So it works accordingly to your expectation. Emacs 25.2.2,
> Ubuntu-18.04 container.
>
> I have generated es_ES.UTF-8 locale using
>
> dpkg-reconfigure locales
>
> Depending on linux distribution you run, the locale may be ready to
> use or not. I tend to think that in minimal environment of virtual
> machine it was missed.
>
> I had an idea to add a test for sorting of items including emphasized
> ones but test-org-list/sort forces C locale. Maybe it was done to
> avoid failures due to missed locale.
>
>
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-13 19:08 9% ` Juan Manuel Macías
@ 2021-04-14 15:42 5% ` Maxim Nikulin
2021-04-14 17:07 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-04-14 15:42 UTC (permalink / raw)
To: emacs-orgmode
On 14/04/2021 02:08, Juan Manuel Macías wrote:
>
> The situation is that with locales configured for Spanish from Spain
> (en_ES.UTF-8) the list is not ordered correctly, unless those three
> spaces from org-sort-remove-invisible are removed. But I couldn't say
> why or if that would be appropriate as a patch...
Did not you get a warning like the following one?
(process:220): Gtk-WARNING **: 15:17:45.066: Locale not supported by C
library.
Using the fallback 'C' locale.
> Regarding the collation rule of forms with emphasis, at least in Spanish
> these should come after the non-emphasized forms. I don't know if this
> is a general rule also for other languages (at least it seems more
> natural that the forms without emphasis are placed before).
LANG=es_ES.UTF-8 \
emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
- a
- /a/
- v
- /v/
So it works accordingly to your expectation. Emacs 25.2.2, Ubuntu-18.04
container.
I have generated es_ES.UTF-8 locale using
dpkg-reconfigure locales
Depending on linux distribution you run, the locale may be ready to use
or not. I tend to think that in minimal environment of virtual machine
it was missed.
I had an idea to add a test for sorting of items including emphasized
ones but test-org-list/sort forces C locale. Maybe it was done to avoid
failures due to missed locale.
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-13 17:31 5% ` Maxim Nikulin
@ 2021-04-13 19:08 9% ` Juan Manuel Macías
2021-04-14 15:42 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-13 19:08 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi, Maxim,
Thanks for clearing things up. So it seems obvious that the root
of the problem is in the locales and the collation rules.
The situation is that with locales configured for Spanish from Spain
(en_ES.UTF-8) the list is not ordered correctly, unless those three
spaces from org-sort-remove-invisible are removed. But I couldn't say
why or if that would be appropriate as a patch...
Regarding the collation rule of forms with emphasis, at least in Spanish
these should come after the non-emphasized forms. I don't know if this
is a general rule also for other languages (at least it seems more
natural that the forms without emphasis are placed before).
Best regards,
Juan Manuel
Maxim Nikulin writes:
> I could reproduce such result but I am in doubt if it is a reason to
> merge the patch. I believe, the following behavior is almost expected
>
> list.org:
> - v
> - /v/
> - /a/
> - a
>
> LC_COLLATE=C.UTF-8 LC_ALL= LANGUAGE= \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> (org-sort-list t ?a)
>
> - /a/
> - /v/
> - a
> - v
>
> LC_COLLATE=en_US.UTF-8 LC_ALL= LANGUAGE= \
> emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
> list.org
>
> (org-sort-list t ?a)
>
> - /a/
> - a
> - /v/
> - v
>
> Collation rules depend on language. The question is if emphasized
> variant should be sorted first.
>
> P.S. The thread is broken. Some new messages do not have proper
> In-Reply-To header. Original question was not referenced in the
> message with patch as well:
> https://orgmode.org/list/87blbac0k0.fsf@posteo.net/
^ permalink raw reply [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 11:41 10% ` Juan Manuel Macías
@ 2021-04-13 17:31 5% ` Maxim Nikulin
2021-04-13 19:08 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-04-13 17:31 UTC (permalink / raw)
To: emacs-orgmode
On 10/04/2021 18:41, Juan Manuel Macías wrote:
> Nicolas Goaziou writes:
>
>> Do you have a simple test case to reproduce the problem? Currently
>> sorting the following trivial lists causes no issue:
>>
>> - b
>> - *a*
>>
>> and
>>
>> - *b*
>> - a
>
> The current result is wrong:
>
> - /a/
> - /v/
> - a
> - b
I could reproduce such result but I am in doubt if it is a reason to
merge the patch. I believe, the following behavior is almost expected
list.org:
- v
- /v/
- /a/
- a
LC_COLLATE=C.UTF-8 LC_ALL= LANGUAGE= \
emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
(org-sort-list t ?a)
- /a/
- /v/
- a
- v
LC_COLLATE=en_US.UTF-8 LC_ALL= LANGUAGE= \
emacs -Q -L ~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/ \
list.org
(org-sort-list t ?a)
- /a/
- a
- /v/
- v
Collation rules depend on language. The question is if emphasized
variant should be sorted first.
P.S. The thread is broken. Some new messages do not have proper
In-Reply-To header. Original question was not referenced in the message
with patch as well: https://orgmode.org/list/87blbac0k0.fsf@posteo.net/
^ permalink raw reply [relevance 5%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-12 23:52 6% ` Samuel Wales
@ 2021-04-13 14:16 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-13 14:16 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Hi Samuel,
Samuel Wales writes:
> probably not a relevant non-confirmation but in recent maint, my config:
>
> - a
> - /a/
> - b
Thanks for trying. I've uploaded this screencast with a minimal Emacs on
a virtual machine:
https://gnutas.juanmanuelmacias.com/images/org-sort-issue-2021-04-13_15.44.52.mp4
and, as you can see, in my case `org-sort-list' can not sort the list
correctly. Maybe it's something related to locales (??), but the only
thing that I can confirm is that if I remove those spaces in
`org-sort-remove-invisible', the list is then sorted correctly.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-12 23:18 10% ` Juan Manuel Macías
@ 2021-04-12 23:52 6% ` Samuel Wales
2021-04-13 14:16 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Samuel Wales @ 2021-04-12 23:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ypo, orgmode, Nicolas Goaziou
probably not a relevant non-confirmation but in recent maint, my config:
- a
- /a/
- b
On 4/12/21, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi Ypo,
>
> Ypo writes:
>
>> This is my result after doing "org-sort-list a":
>>
>> - /a/
>> - /v/
>> - a
>> - b
>>
>> Regards
>
> Thanks for trying. So it seems that you can reproduce the problem as
> well... I wonder if anyone else is able to reproduce it, preferably in a
> minimal emacs.
>
> Best regards,
>
> Juan Manuel
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-12 23:18 10% ` Juan Manuel Macías
2021-04-12 23:52 6% ` Samuel Wales
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-12 23:18 UTC (permalink / raw)
To: Ypo; +Cc: orgmode, Nicolas Goaziou
Hi Ypo,
Ypo writes:
> This is my result after doing "org-sort-list a":
>
> - /a/
> - /v/
> - a
> - b
>
> Regards
Thanks for trying. So it seems that you can reproduce the problem as
well... I wonder if anyone else is able to reproduce it, preferably in a
minimal emacs.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-12 13:50 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-12 13:50 UTC (permalink / raw)
To: orgmode
Nicolas Goaziou writes:
> I cannot reproduce it. With your initial list, and a minimal init file,
> I get:
>
> - /a/
> - a
> - b
> - /v/
>
> Could you try with a minimal Emacs, too?
That's weird ... I have tried launching emacs -q in a virtual machine,
and I keep getting the wrong result (git version, master branch):
- /a/
- /v/
- a
- b
I have tried with the typical keyboard shortcut and also with M-: and
evaluating (org-sort-list t? a nil nil nil)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 10:19 6% ` Nicolas Goaziou
@ 2021-04-10 11:41 10% ` Juan Manuel Macías
2021-04-13 17:31 5% ` Maxim Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-10 11:41 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello Nicolas,
Nicolas Goaziou writes:
> Do you have a simple test case to reproduce the problem? Currently
> sorting the following trivial lists causes no issue:
>
> - b
> - *a*
>
> and
>
> - *b*
> - a
Consider this (unordered) list:
- a
- b
- /v/
- /a/
The current result is wrong:
- /a/
- /v/
- a
- b
With the spaces removed in `org-sort-remove-invisible', this would be the
expected result[1]:
- a
- /a/
- b
- /v/
[1] According to the National Information Standards Organization:
"Different typefaces (italic, boldface, blackletter, etc.) do not affect
the arrangement of letters." (see p. 3 on:
https://www.niso.org/sites/default/files/2017-08/tr03.pdf)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-10 0:01 9% ` Juan Manuel Macías
@ 2021-04-10 10:19 6% ` Nicolas Goaziou
2021-04-10 11:41 10% ` Juan Manuel Macías
2021-04-17 13:27 5% ` Maxim Nikulin
2021-04-28 5:46 6% ` Bastien
2 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-10 10:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Done! I've attached the corrected patch. Sorry for the flaws in me
> previous patch: I'm a bit of a novice at submitting patches...
No problem. Thank you.
Do you have a simple test case to reproduce the problem? Currently
sorting the following trivial lists causes no issue:
- b
- *a*
and
- *b*
- a
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-09 22:28 6% ` Nicolas Goaziou
@ 2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-10 0:01 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Hellow Nicolas:
Nicolas Goaziou writes:
> Thank you.
>
> Could you apply the same fix to the `org-verbatim-re' match above, and
> provide an appropriate commit message?
Done! I've attached the corrected patch. Sorry for the flaws in me
previous patch: I'm a bit of a novice at submitting patches...
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-spurious-spaces-in-org-sort-remove-invisible.patch --]
[-- Type: text/x-patch, Size: 1172 bytes --]
From ab104bb079e3e32d622a6ff53824b5047dc25c14 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 2 Apr 2021 21:20:17 +0200
Subject: [PATCH] Remove spurious spaces in org-sort-remove-invisible
Some spurious spaces in org-sort-remove-invisible is causing
org-sort-list not to sort correctly (alphabetically) the items that
contain emphasis marks in a plain list
---
lisp/org.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 675a614e2..74e2afac9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8113,9 +8113,9 @@ Optional argument WITH-CASE means sort case-sensitively."
"Remove invisible part of links and emphasis markers from string S."
(remove-text-properties 0 (length s) org-rm-props s)
(replace-regexp-in-string
- org-verbatim-re (lambda (m) (format "%s " (match-string 4 m)))
+ org-verbatim-re (lambda (m) (format "%s" (match-string 4 m)))
(replace-regexp-in-string
- org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
+ org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
(org-link-display-format s)
t t) t t))
--
2.26.0
^ permalink raw reply related [relevance 9%]
* Re: [Patch] to correctly sort the items with emphasis marks in a list
2021-04-02 18:15 9% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
@ 2021-04-09 22:28 6% ` Nicolas Goaziou
2021-04-10 0:01 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-04-09 22:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have noticed that a couple of (spurious?) spaces in a `format'
> expression of `org-sort-remove-invisible' is causing `org-sort-list' not
> to sort correctly (alphabetically) the items that contain emphasis marks
> in a plain list. I propose this very simple patch to fix that problem.
Thank you.
Could you apply the same fix to the `org-verbatim-re' match above, and
provide an appropriate commit message?
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 17:53 6% ` physiculus
@ 2021-04-07 19:52 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-07 19:52 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hello again,
physiculus writes:
> Yes that works!
> usually i do not use imagemagick. I use graphicsmagick, but ido not know
> how i have to set the right command line.
> SVG does nothing.
> Very sad :-(
> I want to use this because of quality reasons.
> Do you know, how i can test svg?
the dvisvgm option with luatex is definitely wrong, since dvisvgm does
not support opentype fonts. Sorry for having you confused with my other
snippet. The good news, it seems, is that dvisvgm will support opentype
fonts as of version 2.10, which I assume the next version of texlive
will include it. The actual version is 2.9.1 (command dvisvgm
--version).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 17:26 9% ` Juan Manuel Macías
@ 2021-04-07 17:53 6% ` physiculus
2021-04-07 19:52 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: physiculus @ 2021-04-07 17:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, physiculus
Am Mi, 2021-04-07, 19:26 +0200, Juan Manuel Macías <maciaschain@posteo.net> schrieb:
Yes that works!
usually i do not use imagemagick. I use graphicsmagick, but ido not know
how i have to set the right command line.
SVG does nothing.
Very sad :-(
I want to use this because of quality reasons.
Do you know, how i can test svg?
Regards
Poul
>
> It's weird, it should work :-( ... I assume you have dvisvgm installed
> in your TeX Live installation, is that right? (You can excute something
> like 'dvisvgm --help' in your terminal)
>
> What is your SO?
>
> Anyway, you can try the imagemagick option:
>
> (setq luamagick
> '(luamagick
> :programs ("lualatex" "convert")
> :description "pdf > png"
> :message "you need to install lualatex and imagemagick."
> :use-xcolor t
> :image-input-type "pdf"
> :image-output-type "png"
> :image-size-adjust (1.0 . 1.0)
> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
> (add-to-list 'org-preview-latex-process-alist luamagick)
>
> (setq org-preview-latex-default-process 'luamagick)
^ permalink raw reply [relevance 6%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 16:57 4% ` physiculus
@ 2021-04-07 17:26 9% ` Juan Manuel Macías
2021-04-07 17:53 6% ` physiculus
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-07 17:26 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hello,
physiculus writes:
> Hello again,
>
> thanks for the snippet, but unfortunately it doesn't work :-(
>
> Now it doesn't stop with error, it happens nothing.
> here is my config.
>
> Variable:
> org-preview-latex-default-process is a variable defined in ‘org.el’.
> Its value is ‘luasvg’
> Original value was ‘dvipng’
It's weird, it should work :-( ... I assume you have dvisvgm installed
in your TeX Live installation, is that right? (You can excute something
like 'dvisvgm --help' in your terminal)
What is your SO?
Anyway, you can try the imagemagick option:
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq org-preview-latex-default-process 'luamagick)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-06 19:13 9% ` Juan Manuel Macías
@ 2021-04-07 16:57 4% ` physiculus
2021-04-07 17:26 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: physiculus @ 2021-04-07 16:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, physiculus
Am Di, 2021-04-06, 21:13 +0200, Juan Manuel Macías <maciaschain@posteo.net> schrieb:
Hello again,
thanks for the snippet, but unfortunately it doesn't work :-(
Now it doesn't stop with error, it happens nothing.
here is my config.
Variable:
org-preview-latex-default-process is a variable defined in ‘org.el’.
Its value is ‘luasvg’
Original value was ‘dvipng’
Variable:
org-preview-latex-process-alist
Value:
((luasvg :programs
("lualatex" "dvisvgm")
:description "dvi > svg" :message "you need to install lualatex and dvisvgm." :use-xcolor t :image-input-type "dvi" :image-output-type "svg" :image-size-adjust
(1.7 . 1.5)
:latex-compiler
("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
:image-converter
("dvisvgm %f -n -b min -c %S -o %O"))
(dvipng :programs
("latex" "dvipng")
:description "dvi > png" :message "you need to install the programs: latex and dvipng." :image-input-type "dvi" :image-output-type "png" :image-size-adjust
(1.0 . 1.0)
:latex-compiler
("latex -interaction nonstopmode -output-directory %o %f")
:image-converter
("dvipng -D %D -T tight -o %O %f"))
(dvisvgm :programs
("latex" "dvisvgm")
:description "dvi > svg" :message "you need to install the programs: latex and dvisvgm." :image-input-type "dvi" :image-output-type "svg" :image-size-adjust
(1.7 . 1.5)
:latex-compiler
("latex -interaction nonstopmode -output-directory %o %f")
:image-converter
("dvisvgm %f -n -b min -c %S -o %O"))
(imagemagick :programs
("latex" "convert")
:description "pdf > png" :message "you need to install the programs: latex and imagemagick." :image-input-type "pdf" :image-output-type "png" :image-size-adjust
(1.0 . 1.0)
:latex-compiler
("pdflatex -interaction nonstopmode -output-directory %o %f")
:image-converter
("convert -density %D -trim -antialias %f -quality 100
%O")))
here is the testfile:
\begin{displaymath}
\sqrt{a^2-b^2}=c
\end{displaymath}
\begin{equation} % arbitrary environments,
x=\sqrt{b} % even tables, figures
\end{equation} % etc
If $a^2=b$ and \( b=2 \), then the solution must be
either $$ a=+\sqrt{2} $$ or \[ a=-\sqrt{2} \].
I use your luasvg snippet.
Do i have to do anything else?
Any command afterwards?
Hope someone could help :-)
Regards
Poul
> Hi physiculus,
>
> physiculus writes:
>
>> Hello,
>> i use LuaTex / LuaLatex successfully after some configs and readings.
>> The result (quality and speed) for me is better then with the old latex engine.
>> I'm satisfied.
>> BUT one thing isn't working and as far as i read here, there is no
>> solution yet :-(
>> The latex-preview inside org-mode is not possible, because it seems,
>> that org-mode needs the dvi subprocess for running the neccessary tools.
>> With LuaLatex there is no dvi file, because it produces a pdf right
>> away.
>> Any solution will be wellcome.
>
> I have this in my ~/.emacs:
>
> #+begin_src emacs-lisp
> (setq luamagick
> '(luamagick
> :programs ("lualatex" "convert")
> :description "pdf > png"
> :message "you need to install lualatex and imagemagick."
> :use-xcolor t
> :image-input-type "pdf"
> :image-output-type "png"
> :image-size-adjust (1.7 . 1.5)
> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
> (add-to-list 'org-preview-latex-process-alist luamagick)
>
> (setq luasvg
> '(luasvg
> :programs ("lualatex" "dvisvgm")
> :description "dvi > svg"
> :message "you need to install lualatex and dvisvgm."
> :use-xcolor t
> :image-input-type "dvi"
> :image-output-type "svg"
> :image-size-adjust (1.7 . 1.5)
> :latex-compiler ("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
> :image-converter ("dvisvgm %f -n -b min -c %S -o %O")))
> (add-to-list 'org-preview-latex-process-alist luasvg)
> (setq org-preview-latex-default-process 'luasvg)
> #+end_src
>
> You can set 'org-preview-latex-default-process' to luasvg or luamagick
>
> Best regards,
>
> Juan Manuel
>
> --
> --
> ------------------------------------------------------
> https://juanmanuelmacias.com/
>
--
Jens Reimer
^ permalink raw reply [relevance 4%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-07 14:16 6% ` Diego Zamboni
@ 2021-04-07 15:29 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-07 15:29 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hi Diego
Diego Zamboni writes:
> Hi Juan Manuel,
>
> Thank you for writing this, which is the clearest explanation I have
> seen of the advantages of LuaLaTeX/XeLaTeX. I have been using LaTeX
> for nearly 30 years, but stopped using it intensively every day when
> pdfLaTeX was still the bleeding edge. When I started again in the last
> couple of years, it has been a bit confusing to understand why and
> what all these different versions are. These days I use LuaLaTeX as
> well, but most of the documents I process are exported from Org-mode.
Certainly, LuaTeX has many possibilities, although perhaps we would have
liked more if there was a "LispTeX" :-D (by the way, the most lispy thing
I've seen on planet TeX is this strange and interesting package [a Lisp
interpreter written in TeX! language]:
https://www.ctan.org/pkg/lisp-on-tex)
This is a very simple example of what can be done in LuaTeX through its
Lua interpreter (from Org): we define a command, with a simple Lua
function, that put all capital letters of the document in TeX Gyre
Pagella font, in red and scaled; and all digits in bold. (Anyway, this
can also be done in Org Mode with a custom filter...):
#+NAME:luacode
#+begin_src lua :exports none
function change_test ( text )
text = string.gsub ( text, "%d", "\\textbf{%0}" )
text = string.gsub ( text, "%u", "{\\myfamily %0}" )
return text
end
#+end_src
#+NAME:latexcode
#+begin_src latex :exports none :noweb yes
\usepackage{fontspec}
\usepackage{luacode}
\usepackage{xcolor}
\setmainfont{Linux Libertine O}
\newfontfamily\myfamily{TeX Gyre Pagella}[Scale=2,Color=red]
\begin{luacode}
<<luacode>>
\end{luacode}
\newcommand\change{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , change_test , "change_test" )}}
\newcommand\nochange{\directlua{luatexbase.remove_from_callback
( "process_input_buffer" , "change_test" )}}
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<latexcode>>
#+end_src
#+LaTeX:\change
Lorem ImpsuM DoloR Sit aMet
1234567890
#+LaTeX:\nochange
Lorem ImpsuM DoloR Sit aMet
1234567890
x-----
For more esoteric features I recommend trying the chickenize
package (very didactic): https://www.ctan.org/pkg/chickenize
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-05 20:48 6% Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
@ 2021-04-07 14:16 6% ` Diego Zamboni
2021-04-07 15:29 8% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Diego Zamboni @ 2021-04-07 14:16 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 5025 bytes --]
Hi Juan Manuel,
Thank you for writing this, which is the clearest explanation I have seen
of the advantages of LuaLaTeX/XeLaTeX. I have been using LaTeX for nearly
30 years, but stopped using it intensively every day when pdfLaTeX was
still the bleeding edge. When I started again in the last couple of years,
it has been a bit confusing to understand why and what all these different
versions are. These days I use LuaLaTeX as well, but most of the documents
I process are exported from Org-mode.
Best,
--Diego
On Mon, Apr 5, 2021 at 10:49 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi all,
>
> There have been some threads recently about exporting to LaTeX, but I
> think something that I consider interesting for novice Org/LaTeX users
> has not been commented: the choice of the TeX engine. I think this is
> important because although people often say they "use LaTeX", what they
> actually use is TeX via the La-TeX format. What TeX engine to choose? I
> would dare to say the following: unless you want to maintain some
> backward compatibility with old documents, I highly recommend using
> LuaTeX or XeTeX, especially LuaTeX. Although pdfTeX is very popular
> among average or veterans LaTeX users, I think using it nowadays doesn't
> make much sense (IMHO). LuaTeX is the natural evolution of pdfTeX and
> adds the great advantage of accesing the TeX internals through Lua
> scripting.
>
> (What follows is specially intended for those Org users who haven't used
> XeTeX or LuaTeX yet).
>
> LuaTeX and XeTeX are *100% Unicode-based* and you can use your system
> fonts (open type, true type, etc.) in your documents in a simple way
> through the fontspec (https://www.ctan.org/pkg/fontspec) package, which
> provides a very neat interface and manages all OpenType features (LuaTeX
> and XeTeX use HarfBuzz as otf rendering engine). In LuaTeX also you can
> use any font that is not installed in your system: just indicate the
> path to the fonts files. This is very useful to test new fonts without
> installing them... In all modern word processing systems the user has
> always been able to pick a font easily, and that has been historically
> quite complex, hard and complicated in the (La)TeX ecosystem.
>
> For example, if we want to use globally the Palatino Linotype family in
> our LuaLaTeX document:
>
> \setmainfont{Palatino Linotype}
>
> We can add some OpenType features, like old style numbering:
>
> \setmainfont{Linux Libertine O}[Numbers=LowerCase]
>
> And if we want to use another font for italics, with certain properties
> (color[1] and scaling):
>
> \setmainfont{Crimson}
> [Numbers=Lowercase,
> ItalicFont=MinionPro-It.otf,
> ItalicFeatures={Color=red,
> Scale=MatchLowercase}]
>
> ([1] Requires the xcolor package)
>
> We can also define our own family with its properties (for example, with
> upper case numbers and letters tracking):
>
> \newfontfamily\myfamily{crimson}
> [Numbers=Lining,LetterSpace=3.0]
>
> Furthermore (for more advanced users), in LuaTeX we can define new
> opentype features on the fly, both positional and of substitution (as
> long as the typeface includes the glyphs needed to replace). For
> example, if I use the Crimson typeface, a contextual substitution for
> character Q + u can be defined, by including some Lua code through the
> LuaTeX primitive `directlua':
>
> \directlua{
> fonts.handlers.otf.addfeature{
> name = "mycontextual",
> type = "chainsubstitution",
> lookups = {
> {
> type = "substitution",
> data = {
> ["Q"] = "Q.alt01",
> },
> },
> },
> data = {
> rules = {
> {
> after = { { "u" } },
> current = { { "Q" } },
> lookups = { 1 },
> },
> },
> },
> }
> }
>
> ... And add anywhere in the text:
>
> \addfontfeature{RawFeature=+mycontextual}
>
> If I had to choose, finally, between XeTeX and LuaTeX, I would choose
> LuaTeX, for things like these and many other reasons. In addition, there
> are emerging cool new packages that only work with LuaTeX.
>
> Anyway, XeTeX is another very good option too, especially for users who
> prefer something that works more "out of the box" and is less esotheric
> than LuaTeX.
>
> To export to PDF always with LuaTeX we can put in our ~ /.emacs:
>
> (setq org-latex-pdf-process
> '("lualatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"
> "lualatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"
> "lualatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"))
>
> Or with latexmk, which will take care of compiling as many times as
> necessary for indexes, bibliographies, etc .:
>
> (setq org-latex-pdf-process
> '("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape
> %%S/' %f"))
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 5923 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 20:44 3% Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2021-04-06 20:44 UTC (permalink / raw)
To: maciaschain, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Thanks, Juan Manuel, if LuaTeX just solved the "symbols problem" it
would be a great feature.
But.., why nothing in TeX seems to be easy?! ;D
lualatex: security risk: running with elevated privileges
This is LuaHBTeX, Version 1.12.0 (MiKTeX 20.11)
system commands enabled.
lualatex: file not writable for security reasons: .log
! I can't write on file `.log'.
Please type another transcript file name
! Emergency stop
! ==> Fatal error occurred, no output PDF file produced!
Probably a Windowz problem, don't care. Just moaning ;D
But I take your advise and save it.
Best regards
> *From*: Juan Manuel Macías
> *Subject*: Choosing a LaTeX Compiler (my predilection for LuaTeX)
> *Date*: Mon, 05 Apr 2021 22:48:48 +0200
> *User-agent*: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
>
[-- Attachment #2: Type: text/html, Size: 2455 bytes --]
^ permalink raw reply [relevance 3%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 20:09 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-06 20:09 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hi Tomas,
tomas@tuxteam.de writes:
> AFAIK Lua(La)Tex can output dvi (and Juan Manuel's answer implies
> thati, too). Either via the option --output-format=dvi or invoking
> it as "dviluatex".
>
> But perhaps I missed something.
Yes, the first option I have commented in my previous mail (setq
luamagick etc ...) converts from pdf to png via 'convert' (imagemagick);
in the second option (setq luasvg etc ...) compiles with the option
`-output-format dvi' and then the converter is dvisvgm.
Best regards,
Juan Manuel
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 10%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-06 19:13 9% ` Juan Manuel Macías
2021-04-07 16:57 4% ` physiculus
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-06 19:13 UTC (permalink / raw)
To: physiculus; +Cc: orgmode
Hi physiculus,
physiculus writes:
> Hello,
> i use LuaTex / LuaLatex successfully after some configs and readings.
> The result (quality and speed) for me is better then with the old latex engine.
> I'm satisfied.
> BUT one thing isn't working and as far as i read here, there is no
> solution yet :-(
> The latex-preview inside org-mode is not possible, because it seems,
> that org-mode needs the dvi subprocess for running the neccessary tools.
> With LuaLatex there is no dvi file, because it produces a pdf right
> away.
> Any solution will be wellcome.
I have this in my ~/.emacs:
#+begin_src emacs-lisp
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq luasvg
'(luasvg
:programs ("lualatex" "dvisvgm")
:description "dvi > svg"
:message "you need to install lualatex and dvisvgm."
:use-xcolor t
:image-input-type "dvi"
:image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-format dvi -output-directory %o %f")
:image-converter ("dvisvgm %f -n -b min -c %S -o %O")))
(add-to-list 'org-preview-latex-process-alist luasvg)
(setq org-preview-latex-default-process 'luasvg)
#+end_src
You can set 'org-preview-latex-default-process' to luasvg or luamagick
Best regards,
Juan Manuel
--
--
------------------------------------------------------
https://juanmanuelmacias.com/
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
@ 2021-04-05 21:36 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-05 21:36 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: orgmode
Hi Arne,
Dr. Arne Babenhauserheide writes:
> Except if there is any feature you want to use that doesn’t work under
> LuaTeX.
>
> pdfpages for example says that it only supports pdflatex and vtex.
pdfpages works perfectly with both LuaTeX and XeTeX. I've been using it
in LuaLaTeX for quite some time, by the way. Please read the first page
on the package documentation:
http://mirrors.ctan.org/macros/latex/contrib/pdfpages/pdfpages.pdf
Currently There are very few things that will not work under luatex, for
now (certain microtype properties, like letter tracking, and little
else). In fact, the current trend is the opposite: many new packages
that are emerging do not work under pdftex. The natural evolution of the
TeX ecosystem is heading to LuaTeX, although it is normal for the TeX
community to be cautious about backward compatibility and still mantain
pdfTeX. But the present is already LuaTeX, clearly. The future, who
knows...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
2021-04-05 20:48 6% Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
@ 2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
2021-04-05 21:36 9% ` Juan Manuel Macías
2021-04-07 14:16 6% ` Diego Zamboni
1 sibling, 1 reply; 200+ results
From: Dr. Arne Babenhauserheide @ 2021-04-05 21:17 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
> would dare to say the following: unless you want to maintain some
> backward compatibility with old documents, I highly recommend using
> LuaTeX or XeTeX, especially LuaTeX. Although pdfTeX is very popular
> among average or veterans LaTeX users, I think using it nowadays doesn't
> make much sense (IMHO).
Except if there is any feature you want to use that doesn’t work under
LuaTeX.
pdfpages for example says that it only supports pdflatex and vtex.
Is there a way to replicate the functionality with LuaTeX? Possibly, but
you have to find out how, and it’s not the first hit on stackoverflow.
Currently LaTeX hasn’t converged on one implementation (which would imply
that all features exist in the implementation it converged on and all
packages were ported or have obvious replacements), so I don’t see a
clearcut decision.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [relevance 5%]
* Choosing a LaTeX Compiler (my predilection for LuaTeX)
@ 2021-04-05 20:48 6% Juan Manuel Macías
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
2021-04-07 14:16 6% ` Diego Zamboni
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-05 20:48 UTC (permalink / raw)
To: orgmode
Hi all,
There have been some threads recently about exporting to LaTeX, but I
think something that I consider interesting for novice Org/LaTeX users
has not been commented: the choice of the TeX engine. I think this is
important because although people often say they "use LaTeX", what they
actually use is TeX via the La-TeX format. What TeX engine to choose? I
would dare to say the following: unless you want to maintain some
backward compatibility with old documents, I highly recommend using
LuaTeX or XeTeX, especially LuaTeX. Although pdfTeX is very popular
among average or veterans LaTeX users, I think using it nowadays doesn't
make much sense (IMHO). LuaTeX is the natural evolution of pdfTeX and
adds the great advantage of accesing the TeX internals through Lua
scripting.
(What follows is specially intended for those Org users who haven't used
XeTeX or LuaTeX yet).
LuaTeX and XeTeX are *100% Unicode-based* and you can use your system
fonts (open type, true type, etc.) in your documents in a simple way
through the fontspec (https://www.ctan.org/pkg/fontspec) package, which
provides a very neat interface and manages all OpenType features (LuaTeX
and XeTeX use HarfBuzz as otf rendering engine). In LuaTeX also you can
use any font that is not installed in your system: just indicate the
path to the fonts files. This is very useful to test new fonts without
installing them... In all modern word processing systems the user has
always been able to pick a font easily, and that has been historically
quite complex, hard and complicated in the (La)TeX ecosystem.
For example, if we want to use globally the Palatino Linotype family in
our LuaLaTeX document:
\setmainfont{Palatino Linotype}
We can add some OpenType features, like old style numbering:
\setmainfont{Linux Libertine O}[Numbers=LowerCase]
And if we want to use another font for italics, with certain properties
(color[1] and scaling):
\setmainfont{Crimson}
[Numbers=Lowercase,
ItalicFont=MinionPro-It.otf,
ItalicFeatures={Color=red,
Scale=MatchLowercase}]
([1] Requires the xcolor package)
We can also define our own family with its properties (for example, with
upper case numbers and letters tracking):
\newfontfamily\myfamily{crimson}
[Numbers=Lining,LetterSpace=3.0]
Furthermore (for more advanced users), in LuaTeX we can define new
opentype features on the fly, both positional and of substitution (as
long as the typeface includes the glyphs needed to replace). For
example, if I use the Crimson typeface, a contextual substitution for
character Q + u can be defined, by including some Lua code through the
LuaTeX primitive `directlua':
\directlua{
fonts.handlers.otf.addfeature{
name = "mycontextual",
type = "chainsubstitution",
lookups = {
{
type = "substitution",
data = {
["Q"] = "Q.alt01",
},
},
},
data = {
rules = {
{
after = { { "u" } },
current = { { "Q" } },
lookups = { 1 },
},
},
},
}
}
... And add anywhere in the text:
\addfontfeature{RawFeature=+mycontextual}
If I had to choose, finally, between XeTeX and LuaTeX, I would choose
LuaTeX, for things like these and many other reasons. In addition, there
are emerging cool new packages that only work with LuaTeX.
Anyway, XeTeX is another very good option too, especially for users who
prefer something that works more "out of the box" and is less esotheric
than LuaTeX.
To export to PDF always with LuaTeX we can put in our ~ /.emacs:
(setq org-latex-pdf-process
'("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o %f"))
Or with latexmk, which will take care of compiling as many times as
necessary for indexes, bibliographies, etc .:
(setq org-latex-pdf-process
'("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape %%S/' %f"))
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* [tip] search this mailing list with helm-surfraw
@ 2021-04-05 9:25 8% Juan Manuel Macías
2021-04-25 5:00 7% ` Bastien
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-05 9:25 UTC (permalink / raw)
To: orgmode
Hi all,
I am a fanatic Helm user, and within Helm I make intensive use of
helm-surfraw. It is necessary to install Surfraw on the system (in Arch
it is in the community repository). For who does not know, Surfraw
(https://en.wikipedia.org/wiki/Surfraw) is a script written by Julian
Assange that lets you perform searches across many engines and internet
sites. Every kind of search is controlled by a set of scripts called
elvi. We can also write our custom elvis, and save them in the
~/.config/surfraw/elvi/ folder. I have written some elvis for my
personal use, among them this simple script to search this mailing list,
which I share here in case someone finds it useful:
#+begin_src sh :shebang #!/bin/sh :tangle ~/.config/surfraw/elvi/orgmode-ml
# DESC: search Org Mode mailing list archives
# elvis: orgmode-ml -- Search Org Mode mailing list archives (https://lists.gnu.org/archive/html/emacs-orgmode/)
. surfraw || exit 1
w3_usage_hook () {
cat <<EOF
Usage: $w3_argv0 [search words]...
Description:
Search in Org Mode mailing list (https://lists.gnu.org/archive/html/emacs-orgmode/)
EOF
w3_global_usage
}
w3_config
w3_parse_args "$@"
if test -z "$w3_args"; then
w3_browse_url "https://lists.gnu.org/archive/html/emacs-orgmode/"
else
escaped_args=`w3_url_of_arg $w3_args`
w3_browse_url "https://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=emacs-orgmode&sort=score&result=normal&max=20&submit=Search!&query=${escaped_args}"
fi
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: First steps exporting to tex
2021-04-04 11:04 6% ` Ypo
@ 2021-04-04 11:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-04 11:36 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> I've already tried that. But it doesn't seem to understand the HOME
> directory ~~/~. At least at Windows.
I haven't touched Windows for a thousand years :-), but maybe this thread
can help you:
https://stackoverflow.com/questions/13584118/how-to-write-a-path-with-latex
best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: how to export (latex) a image without using figure
2021-04-04 11:17 10% ` Juan Manuel Macías
@ 2021-04-04 11:33 1% ` Uwe Brauer
0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-04-04 11:33 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hi Juan,
> Hi Uwe,
> Try:
> #+ATTR_LaTeX: :float nil
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> [[./images/dfp_03.png]]
Muchas gracias, I mean thank you very much.
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: how to export (latex) a image without using figure
@ 2021-04-04 11:17 10% ` Juan Manuel Macías
2021-04-04 11:33 1% ` Uwe Brauer
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-04 11:17 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Try:
#+ATTR_LaTeX: :float nil
#+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
[[./images/dfp_03.png]]
Best regards,
Juan Manuel
Uwe Brauer writes:
> Hi
>
> Currently
>
> #+CAPTION: La función La función $x^2 e^{-\alpha x} = \frac{1}{\alpha}$, $\alpha=-\ln(1-p)$ con $p=0.01$ con $p=0.3$
> #+NAME: fig:plotcalor23
>
> [[./images/dfp_03.png]]
>
> Gets translated to
>
> \begin{figure}[htbp]
> \centering
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \caption{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
> \end{figure}
>
> For reasons that needs a longer explanation I would need.
>
>
>
> \includegraphics[width=.9\linewidth]{./images/dfp_03.png}
> \captionof{figure}{\label{fig:plotcalor23}La función La función \(x^2 e^{-\alpha x} = \frac{1}{\alpha}\), \(\alpha=-\ln(1-p)\) con \(p=0.01\) con \(p=0.3\)}
>
>
> How can this be achieved?
>
> Thanks
>
> Uwe Brauer
>
>
>
>
^ permalink raw reply [relevance 10%]
* Re: First steps exporting to tex
@ 2021-04-04 11:04 6% ` Ypo
2021-04-04 11:36 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ypo @ 2021-04-04 11:04 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 8063 bytes --]
>>>>>>> El 03/04/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
> Message: 34
> Date: Sun, 04 Apr 2021 00:31:24 +1100
> To:emacs-orgmode@gnu.org
> Subject: Re: First steps exporting to tex
> Message-ID:<871rbr7ag1.fsf@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
>
> Why do you think you need any of this for your 'first steps'. Start by
> just writing your org file and exporting it to LaTeX or pdf. Then, once
> you have your first document, see what you think needs changing and come
> back and ask advice on what you need to do to make the changes you want.
> In your first document, don't use any LaTeX commands, header options or
> anything else - just write your document using standard org mode.
>
> Org already sets up a reasonable starting default. Once you know what
> the default is, then we can discuss what you may need to change. For
> many documents, you may not need to change much at all and you may not
> need any templates - for example, you will likely want to change the
> margin sizes (this is a common request) or you may want to see what some
> of the other 'standard' LaTeX document classes are like. All of this can
> be achieved with just minor configuration of org mode.
>
> The org export to LaTeX only needs to be as complicated as you need it
> to be. Org has variables which can be used to add/remove things from the
> preamble and once you have those configured, you don't have to put
> anything in the org file itself. Start simple and add as you find a need
> rather than try to start with something complex which might not be
> necessary.
>
> -- Tim Cross
Hi Tim
I have been exporting from orgmode to PDF time ago, but very basic PDFs,
playing with some basic options of orgmode. When I tried to produce a
meeting minute with a logo in the heading, I decided that I should learn
better a way of exporting, because the minute meeting was a first
challenge, but many more would come. For example, for that task I
started with this code, which I think it goes far beyond what the "LaTeX
Defaults" can offer (I must yet "play around" a lot with it):
#+BEGIN_SRC
#+options: toc:nil
#+options: num:1
#+options: d:nil
#+export_file_name: BORRAR
#+options: broken-links:mark
#+LaTeX_header_extra: \usepackage{fancyhdr}
#+begin_export LaTeX
\thispagestyle{fancy}
\lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN
CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO ANAGRAMAS/SELLO1_grueso.png}}
\rhead{Student Name: John Doe\\
Student ID: 1234\\
Course: IDB 601 (Fall 2020)}
#+end_export
#+END_SRC
The buffer I exported my meeting notes from has much more information
which is not related with meetings nor with the logo. So I foresaw 3
things:
1. A fast cluttering of the buffers with LaTeX headings would happen,
as I will learn more about LaTeX and I will want to add more and
more packages.
2. A need for flexibility to be able to export different kinds of
documents from the same buffer, ideally achieved just by changing a
line (or few lines) in the buffer. Although, from my example, it
seems that ~#+begin_export...~ contents can't be added in that way.
3. A great potential if it were possible to use already existing, and
well curated, LaTeX templates frictionless through orgmode.
I find quite useful to analyse the default generated TeX file though.
Best regards
>>>>>>> El 03/04/2021 a las 12:15, Martin Steffen escribió:
Good morning, Martin
> For the "preamble" of a latex document, the general setup that comes
> _before_ \begin{document} and before any output is generated, I use
> native latex using instructions like
>
> #+BEGIN_SRC
> #+latex_header: \input{switches}
> #+latex_header: \input{preamble}
> #+latex_header: \input{style/style-common}
> #+latex_header: \input{macros}
> #+END_SRC
Thanks for your input. I'll keep with that.
> As far controlling input is concerned, I also rely on latex-specific
> setting (outside org, also outside emacs), things like environment
> settings like $TEXINPUT, a path-specification, where one can control
> where LaTeX finds (additional) stylefiles, outside of the standard
> ``load-path''.
>
> Thus, I often try to avoid to use hardcoded things, like
>
> >>> \input{~//export//template.tex}
>
> I would use \input{template} (".tex" is not needed) and I make sure, the
> templatex.tex file is included in the $TEXINPUTS-path. Typically, the
> current directory "./" should be included by default (and stuff from
> the latex-installation is also routinely found)
Thanks. But I can read in this post:
https://tex.stackexchange.com/questions/93712/definition-of-the-texinputs-variable
that ~$TEXINPUT~ could give some problems with LuaLaTeX, could it be? It
seems important, since LuaLaTeX is the safe recommendation of our
mailing list pal Juan Manuel Macías [maciaschain@...].
>>>>>>> El 03/04/2021 a las 12:43, Dr. Arne Babenhauserheide escribió:
A pleasure, Arne.
> Alternatively you can use #+INCLUDE: template.org
> to grab more than just the org-setup.
And there you show me a different way: ~#+INCLUDE,~ "competing" with
~\input{}~. What would be the difference?
> Have a look at \DeclareUnicodeCharacter:
> https://www.draketo.de/light/english/emacs/char-not-setup-latex
Does that mean that some symbols must be declared one by one in order to
be exported using LaTeX?
>>>>>>> El 03/04/2021 a las 14:10, Juan Manuel Macías escribió:
Hi, Juan Manuel :-)
> The correct way is \input{~/export/template.tex}
I've already tried that. But it doesn't seem to understand the HOME
directory ~~/~. At least at Windows.
> A *.sty file is what is known in LaTeX jargon as a "package", and it
> would come to be the equivalent of what is a *.el file in Emacs,
> /mutatis mutandis/. In a sty file you can put whatever you want, but a
> different syntax must be used and these files are subject to a series of
> good practices. Therefore, a sty file is more indicated to introduce
> 'heavy' code that you want reuse in other documents (defined commands
> and macros, etc.). In short, what comes to be a package ;-) At the user
> level, and unless you want to write your own package (see:
> https://www.overleaf.com/learn/latex/Writing_your_own_package), it is
> almost never necessary.
So I will keep myself far away from .sty by now.
> Great care must be taken here. One thing is a LaTeX class, which is
> something laborious and complex to write, and another thing what Org
> understands for a LaTeX class :-) Classen and the class concept are a
> essential component for LaTeX, as a class is the first thing you must
> declare in a preamble with the command \documentclass{}. There are the
> standard classes (article, book and others) and other ones, more
> specialized. A class changes globally the behavior of the document and
> all LaTeX commands as \section, \subsection and many more, and add its
> own commands.
>
> A 'LaTeX class' for Org is a light translation of the above. It is
> actually "what type of LaTeX document you want to get".
>
> You can easily define your own LaTeX 'classes' for Org documents. For
> example: I have an 'empty class', to be able to add the entire preamble,
> without Org charging me anything before the \begin{document}
> (add-to-list 'org-latex-classes
> '("empty"
> "[NO-DEFAULT-PACKAGES]
> [PACKAGES]
> [EXTRA]"
> ("\\section{%s}" . "\\section*{%s}")
> ("\\subsection{%s}" . "\\subsection*{%s}")
> ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
> ("\\paragraph{%s}" . "\\paragraph*{%s}")
> ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>
> And I have in my ~/.emacs:
>
> (setq org-latex-default-class "empty")
> (setq org-latex-default-packages-alist nil)
> (setq org-latex-packages-alist nil)
> (setq org-latex-hyperref-template nil)
Thanks for your class. I suppose that "nulls" the orgmode LaTeX export
defaults, so you can control it completely.
Thank you all
[-- Attachment #2: Type: text/html, Size: 12095 bytes --]
^ permalink raw reply [relevance 6%]
* Re: How to expand macro in LaTeX export? How to use different options per export type?
@ 2021-04-03 21:57 9% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 21:57 UTC (permalink / raw)
To: Jean Louis; +Cc: orgmode
Jean Louis writes:
> Another issue related to this setup is that I would like:
>
> - for HTML export: title:t toc:t
>
> - for LaTeX PDF export: title:nil toc:nil
>
> Is there way to have options different for different exports?
You can do it with a macro like this:
#+MACRO: titletoc (eval (cond ((org-export-derived-backend-p org-export-current-backend 'latex) "#+OPTIONS: title:nil\n#+OPTIONS: toc:nil")((org-export-derived-backend-p org-export-current-backend 'html) "#+OPTIONS: title:t\n#+OPTIONS: toc:t")))
{{{titletoc}}}
...
But maybe it would be better to use a block here:
#+begin_src emacs-lisp :exports results :results raw
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
"#+OPTIONS: title:t\n#+OPTIONS: toc:t")
((org-export-derived-backend-p org-export-current-backend 'html)
"#+OPTIONS: title:nil\n#+OPTIONS: toc:nil"))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: First steps exporting to tex
2021-04-03 18:36 4% ` Jean Louis
@ 2021-04-03 20:46 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 20:46 UTC (permalink / raw)
To: Jean Louis; +Cc: orgmode
Hi Jean Louis,
Jean Louis writes:
> Do you have a specific remark on what would be major wrong with the
> default LaTeX export from your viewpoint?
>
> For me, I like larger letters and more space on paper. I find it
> narrow and not enough legible. But that is not typographically
> technical comment.
It would be too long to comment here... The flaws of a typical LaTeX
ouput could be divided into formal defects and orthotypographic defects.
It's not LaTeX's fault (actually TeX and LaTeX represent the greatest
advance in typography since Gutenberg); the problem is that a book needs
a lot of fixes before reaching the printing press. And everything also
depends on each type of book and each book in particular: typography is
the science of exceptions. Luckily, TeX offers a lot of resources and
packages for fine tuning, and LuaTeX even more. I invite you to read the
documentation of these two packages: impnattypo
(https://www.ctan.org/pkg/impnattypo) and lua-typo
(https://www.ctan.org/pkg/lua-typo) where a part of these issues is
discussed.
Anyway, I am not saying that all average users should become experts in
typesetting. I just wanted emphasize that LaTeX is /just/ the tool (like
linotypes and monotypes were in his time) but LaTeX does not do
everything, although his standard output is of very good
quality compared to other systems. But that is so because TeX works very
well, it justifies very well the paragraphs, etc.
> [...]
> Org user may not need nothing about LaTeX. Even if exporting is often,
> Org user need not know nothing about LaTeX. Other converter like
> `pandoc' also offer conversion to LaTeX and user need not know nothing
> about it.
An average Org user does not need to know almost anything about LaTeX if
what he wants is just to produce /simple/ PDF documents. I agree. But
when he wants to do more complex things, he will need to know how to do
them in LaTeX and how to do them also from Org (in case he wants to
continue working in Org: even I work in Org when I do professional
typesetting, because for me Org is, among other things, the /almost/
perfect interface for LaTeX). If Org users get covered eyes with LaTeX
and LaTeX processes, then they will end up filling the Org forums with
questions that should rather be asked in the LaTeX forums (I am not
saying that it should not be asked here, but if no one knows anything
about LaTeX, no one could give answers to problems that are related to
LaTeX and not to Org). Let's imagine this hypothetical case:
User X enters the Org forum Z and asks: "How can I export to PDF with a
two colums layout?"
The correct answer is on the LaTeX side: "you have to use the multicol
package (and read the package documentation, if fine-tuning is
required)",
Once the LaTeX oracle has given its answer, the Org oracle will declare
that a multicols environment can be created in Org with a special block:
#+begin_src org
,#+ATTR_LaTeX: :options {2}
,#+begin_multicols
.............
,#+end_multicols
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: How to get a table into a variable in a shell code block?
@ 2021-04-03 19:01 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 19:01 UTC (permalink / raw)
To: Greg Minshall; +Cc: orgmode
Hi Greg and William,
Greg Minshall writes:
> William,
>
> try
>
> #+begin_src shell :results output :var n=numbers
> echo ${n[1]}
> #+end_src
>
> cheers, Greg
I don't know if I'm saying something wrong, but wouldn't it be better
this way?:
#+begin_src shell :results output :var n=numbers
echo ${n[@]}
#+end_src
echo ${n[1]} returns the second element (two) of the list (0, returns
one and 2 returns three)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: First steps exporting to tex
2021-04-03 17:49 8% ` Juan Manuel Macías
@ 2021-04-03 18:36 4% ` Jean Louis
2021-04-03 20:46 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Jean Louis @ 2021-04-03 18:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: William Denton, orgmode
* Juan Manuel Macías <maciaschain@posteo.net> [2021-04-03 20:51]:
> William Denton writes:
>
> > [...] and it looks like a published book or journal article!
>
> Something similar I thought, in my student days, when at the early '90 I
> saw a document printed in word perfect, just because it had a book
> typeface (Times Roman), footnotes and many more fancy stuff. It looked
> /almost/ like a book.
>
> With LaTeX something similar happens for the user who is not trained in
> professional typesetting. TeX as a typographic engine makes an excellent
> work at the 'physical' level, but as we say in Spain, the trees do
> not let us see the forest. A LaTeX document produced from standard way
> will need (likely) a lot of fine tuning, and a solid typographic culture
> acquired by those who check it out.
TeX and LaTeX must be prime chose who need professional typesetting.
Org mode offers limited insight into powers of LaTeX.
Org offers quick document creation by using LaTeX and LaTeX may be
used to extend Org. It cannot satisfy all people by default. Each
person may need customization.
Do you have a specific remark on what would be major wrong with the
default LaTeX export from your viewpoint?
For me, I like larger letters and more space on paper. I find it
narrow and not enough legible. But that is not typographically
technical comment.
> On the other hand, I think that if an Org user is going to export often
> to LaTeX, he should know LaTeX reasonably well.
Opposite may be said as well. Exporting to LaTeX may be just a side
effect in order to create a PDF file. Org user may not need nothing
about LaTeX. Even if exporting is often, Org user need not know
nothing about LaTeX. Other converter like `pandoc' also offer
conversion to LaTeX and user need not know nothing about it. That is
the beauty. It does not help the professional though, as professional
must know all the specific details.
> I do not say that he
> become a LaTeXpert, but at least the user should have clear which
> concepts are from Org and which concepts are from LaTeX. The LaTeX
> packages you may need as you want to do more complex things, and how to
> use those packages. Etc. On the Org side there are many and excellent
> resources to control the export process. But in any translation process
> you have to know the source language (Org) and what can be expressed in
> the final language (LaTeX) and how.
What you describe relates to advanced LaTeX users who need good
quality or who have special needs. Average Org user who knows that Org
can export to LaTeX will rather use it as side effect in order to get
PDF file.
> And the the same happens if the
> output is HTML, Epub or whatever. I think Org is an excellent tool, full
> of possibilities (maybe a lot of them don't explored yet) and wonderful
> things, but it is not magic, although its logo is an unicorn ;-)
It is not magic. Yet integration provided by developers brought it to
point that simple Org file, text file, can be quickly converted into
nice PDF documents. It does not matter if files are edited remotely on
mobile devices by using any kind of editor, once file is processed by
Emacs and exported it becomes universally accepted.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/
^ permalink raw reply [relevance 4%]
* Re: First steps exporting to tex
@ 2021-04-03 17:49 8% ` Juan Manuel Macías
2021-04-03 18:36 4% ` Jean Louis
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-03 17:49 UTC (permalink / raw)
To: William Denton; +Cc: orgmode
William Denton writes:
> [...] and it looks like a published book or journal article!
Something similar I thought, in my student days, when at the early '90 I
saw a document printed in word perfect, just because it had a book
typeface (Times Roman), footnotes and many more fancy stuff. It looked
/almost/ like a book.
With LaTeX something similar happens for the user who is not trained in
professional typesetting. TeX as a typographic engine makes an excellent
work at the 'physical' level, but as we say in Spain, the trees do
not let us see the forest. A LaTeX document produced from standard way
will need (likely) a lot of fine tuning, and a solid typographic culture
acquired by those who check it out.
On the other hand, I think that if an Org user is going to export often
to LaTeX, he should know LaTeX reasonably well. I do not say that he
become a LaTeXpert, but at least the user should have clear which
concepts are from Org and which concepts are from LaTeX. The LaTeX
packages you may need as you want to do more complex things, and how to
use those packages. Etc. On the Org side there are many and excellent
resources to control the export process. But in any translation process
you have to know the source language (Org) and what can be expressed in
the final language (LaTeX) and how. And the the same happens if the
output is HTML, Epub or whatever. I think Org is an excellent tool, full
of possibilities (maybe a lot of them don't explored yet) and wonderful
things, but it is not magic, although its logo is an unicorn ;-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: First steps exporting to tex
@ 2021-04-03 12:10 7% ` Juan Manuel Macías
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-03 12:10 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Hi Ypo,
I think that, as a starting point, the concepts that belong to Org and
those that belong to LaTeX should be separated.
Ypo writes:
> [...]
> 2 template.tex -> this could be added to the SETUPFILE:
> #+LATEX_HEADER: \input{template.tex}. But it seems to have no effect
> on the PDF output. BTW, I can't use emacs HOME path (~/) in the
> input header, like \input{~//export//template.tex}.
The keyword #+LaTeX_Header pass literal LaTeX commands in a single line
to thepreamble. The LaTeX \input{...} command should follow the path of
the file you want include, but I see that you are indicating the path
with a double //. The correct way is \input{~/export/template.tex}
> 3 Another friend told me that .sty templates were the best way.
A *.sty file is what is known in LaTeX jargon as a "package", and it
would come to be the equivalent of what is a *.el file in Emacs,
/mutatis mutandis/. In a sty file you can put whatever you want, but a
different syntax must be used and these files are subject to a series of
good practices. Therefore, a sty file is more indicated to introduce
'heavy' code that you want reuse in other documents (defined commands
and macros, etc.). In short, what comes to be a package ;-) At the user
level, and unless you want to write your own package (see:
https://www.overleaf.com/learn/latex/Writing_your_own_package), it is
almost never necessary.
> 4 I see some people that create customized LaTeX classes and add the
> desired class to the orgmode buffer.
Great care must be taken here. One thing is a LaTeX class, which is
something laborious and complex to write, and another thing what Org
understands for a LaTeX class :-) Classen and the class concept are a
essential component for LaTeX, as a class is the first thing you must
declare in a preamble with the command \documentclass{}. There are the
standard classes (article, book and others) and other ones, more
specialized. A class changes globally the behavior of the document and
all LaTeX commands as \section, \subsection and many more, and add its
own commands.
A 'LaTeX class' for Org is a light translation of the above. It is
actually "what type of LaTeX document you want to get".
You can easily define your own LaTeX 'classes' for Org documents. For
example: I have an 'empty class', to be able to add the entire preamble,
without Org charging me anything before the \begin{document}
(add-to-list 'org-latex-classes
'("empty"
"[NO-DEFAULT-PACKAGES]
[PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
And I have in my ~/.emacs:
(setq org-latex-default-class "empty")
(setq org-latex-default-packages-alist nil)
(setq org-latex-packages-alist nil)
(setq org-latex-hyperref-template nil)
My advice, as has already been commented here, is that you get familiar
with LaTeX for a while, and then see how you can fit LaTeX in your Org
workflow, if that's more productive for you.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Including Email Address in the Reply in Mailing-list
@ 2021-04-02 23:45 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-02 23:45 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross writes:
> I have no issue with this suggestion and am happy to try and comply.
>
> The challenge for many will be that they either
>
> - need to remember to remove the email details manually (line/header
> automatically added by mail client) while sorting out either
>
> - how to modify mail client for all replies (may not be appropriate for
> non-ML replies), or
>
> - how to modify mail client for just ML replies
> [...]
For Gnus users, one possibility might be:
(defun my-gnus-reply-ml ()
(interactive)
(let*
((message-citation-line-format "%N writes:\n")
(message-citation-line-function 'message-insert-formatted-citation-line))
(gnus-article-reply-with-original)))
...And then assign any free key to gnus-article-mode-map
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [Patch] to correctly sort the items with emphasis marks in a list
@ 2021-04-02 18:15 9% Juan Manuel Macías
2021-04-09 22:28 6% ` Nicolas Goaziou
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-04-02 18:15 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Hi all,
I have noticed that a couple of (spurious?) spaces in a `format'
expression of `org-sort-remove-invisible' is causing `org-sort-list' not
to sort correctly (alphabetically) the items that contain emphasis marks
in a plain list. I propose this very simple patch to fix that problem.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-sort-remove-invisible_remove_spaces.patch --]
[-- Type: text/x-patch, Size: 494 bytes --]
diff --git a/lisp/org.el b/lisp/org.el
index 04da1afcd..d10cc2f5c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8114,7 +8114,7 @@ Optional argument WITH-CASE means sort case-sensitively."
(replace-regexp-in-string
org-verbatim-re (lambda (m) (format "%s " (match-string 4 m)))
(replace-regexp-in-string
- org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
+ org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
(org-link-display-format s)
t t) t t))
^ permalink raw reply related [relevance 9%]
* Re: About exporting
@ 2021-04-01 14:21 7% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-04-01 14:21 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well. And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file. This definitely adds friction!
These days I'm working on a book (a dictionary) of over 1000 pages. The
preamble contains 1813 lines of code (+/-), and is written separately in
a Org document, through literary programming. Contains: a) A lot of
(La)TeX code written (or perpetrated) by me, b) some Lua functions to
control certain parts of the process, c) all the configuration for Xindy
(the indexes) in Common Lisp (inside a filecontents* environment).
Everything, of course, ordered by sections. With this cocktail it seems
that something can go wrong at some point :-) However I find it very
easy to debug having things well separated. And I can always tangle
different versions of the preamble...
As I have already mentioned, I use Org Publish intensively. Some parts
of my Org Publish setup for this project are:
[...]
:base-directory "~/Git/DHTC/libro/org/"
:base-extension "org"
; *.tex files and output
:publishing-directory "~/Git/DHTC/libro/tex/"
:publishing-function org-latex-publish-to-latex
:body-only t
:exclude "DHTC-master\\.org\\|bibli-dhtc\\.org"
Each part of the book is an *org document that I export to *tex using
Org-Publish (:body-only t). And each document only includes at the
beginning:
#+SETUPFILE: diccionario.setup
#+INCLUDE: "elisp"
(that is, a setup file and a file that I have named `elisp' where I include
functions and filters).
And then I have a master document, as simple as possible, where the
preamble and the subdocuments are added through '\input{...}'. I have
defined this macro:
#+MACRO: input (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\input{@@" $1 ".tex" "@@latex:}@@") $1))
And, with a simple Elisp function, I compile the final document (or
parts of it) using latexmk (with `start-process-shell-command'). I add
an argument so that a dedicated buffer is generated with the output of
latexmk. As latexmk runs in interactive mode, every time I do a change
in a subdocument and call Org-Publish again, latexmk rebuilds everything
automatically. The latexmk output is very neat and warns of possible
errors. Also I always have an alternative branch in the repository to do
tests when I put 'experimental' code.
By all this I mean that using LaTeX from Org (but without stopping using
LaTeX) gives me a pretty productive and organized workflow. I recommend
try it out for large books.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: "Org" source blocks and minted
2021-03-26 11:55 10% ` Juan Manuel Macías
@ 2021-04-01 8:07 6% ` Michael Gauland
0 siblings, 0 replies; 200+ results
From: Michael Gauland @ 2021-04-01 8:07 UTC (permalink / raw)
To: emacs-orgmode
Yes, this looks very promising. I'm looking forward to playing with it
when I have more time.
On 27/03/21 12:55 am, Juan Manuel Macías wrote:
> Hi Timothy,
>
> I really like your approach. And it is org/emacscentric! Minted has
> never quite convinced me, and gives me some trouble with certain
> packages in LuaLaTeX that I have not been able to solve. Thank you for
> this promising alternative.
>
> Best regards,
>
> Juan Manuel
>
> Timothy <tecosaur@gmail.com> writes:
>
>> Juan mentioned an Org lexer exists, but another approach that may be of
>> interest is using Emacs' own font-lock. I wrote a package that's like
>> HTMLize but works with LaTeX and currently have it sitting in my config.
>>
>> I plan on submitting a patch to Org at some point on this, but for now:
>> - https://github.com/tecosaur/engrave-faces
>> - https://tecosaur.github.io/emacs-config/config.html#pretty-code-blocks
>>
>> Sample output: all the code blocks in
>> https://tecosaur.github.io/emacs-config/config.pdf
>>
>> Since this uses Emacs' font-lock, this means that you can use any
>> language that you have a syntax-highlighting-mode for :)
>
^ permalink raw reply [relevance 6%]
* Re: About exporting
@ 2021-03-31 18:56 10% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-31 18:56 UTC (permalink / raw)
To: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> [...] And last not least; if I ``compile'' the document (firing off latex,
> bibtex, or index or whatever), the compilation runs in the background.
> As far as I do that in org (exporting to pdf), it blocks emacs. Not
> that it's a huge delay even, at least for smaller documents, I hate
> that an editor or some tool is slower than me, it gets on my nerves if
> the computer slows me down.
There is the async-export (C-a) option in org-export-dispatcher.
Anyway, I usually use the latexmk script a lot, even with Org
(combined with Org Publish: I export sub-documents to *tex from Org and
compile later with latexmk the master document. latexmk with the -pvc
options is wonderful.
I agree that AUCTeX is excellent; maybe (IMHO) the best LaTeX editor out
there.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: About exporting
2021-03-31 9:59 6% ` Eric S Fraga
@ 2021-03-31 18:28 3% ` Martin Steffen
0 siblings, 1 reply; 200+ results
From: Martin Steffen @ 2021-03-31 18:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
>>>>> "Eric" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:
Eric> On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
>> However, *I would not recommend anyone to use LaTeX for
>> writing*. A light markup language is more comfortable and
>> efficient for me.
Eric> Totally agree! Although, over the years, I have written many
Eric> papers in LaTeX directly, in the past decade I have
Eric> increasingly relied on org as the writing tool. It imposes
Eric> much less friction on the creative process and, as you say, it
Eric> enables better management of the writing task. And, as it
Eric> gives direct access to LaTeX when necessary, you lose nothing
Eric> by writing in org.
I would not go so far as not recommend latex (over org) for _anyone_ at
all. I for my part will stick with latex for a certain documents; for
others, org is better (has to do with the mentioned creative process,
and other advantages).
However, I write papers heavy in math-notation (in the more theoretical
corners of conmputer science). There is a lot of math discplay (and I
like to rely heavily on macros etc).
For me, part of the preference of latex is the ratio between math and
similar things over ``text''. a blog-like text (not heavy on math), or a
note, or a wiki-like document etc, all that's great with org.
For math-typesetting, that's less of a ``creative flow of ideas
thing''. Of course, as having been mentioned, I can always escape to
latex inline or for displays etc. And I can also import my
macro-definitions etc (and I do that).
But actually, when typing, I think I am faster in latex. There are a
couple of features, I like (and my muscle-memory of my fingers rely in
them) in latex-modes of emacs.
Tab completion for environments and macros, remembering the last
environments I used, support of bibtex (like also completion or showing
the reference). Indentention of environments plus highlighting. And last
not least; if I ``compile'' the document (firing off latex, bibtex, or
index or whatever), the compilation runs in the background. As far as I
do that in org (exporting to pdf), it blocks emacs. Not that it's a
huge delay even, at least for smaller documents, I hate that an editor
or some tool is slower than me, it gets on my nerves if the computer
slows me down. And there is a final thing which (for me) seem to work
better in latex-mode compared to org. That's jumping to the ``next
error'' with some key stroke. That's important, LaTeX's own error
output it quite poor, but jumping to error locations is vital.
I would not be surprised if some of that is somehow supported by org as
well (for TeX), only I have not figured it out, or perhaps I was too
lazy to figure it out how. Too lazy because LateX mode works for me fine
even for challenging and long documents (where for simpler ones or where
the focus is not on typesetting org works).
Martin
Eric> And *tables*! Enough said. :-)
Eric> But, as always, YMMV.
Eric> -- : Eric S Fraga via Emacs 28.0.50, Org
Eric> release_9.4.4-254-g37749c
^ permalink raw reply [relevance 3%]
* Re: About exporting
2021-03-30 15:44 7% ` Juan Manuel Macías
@ 2021-03-31 9:59 6% ` Eric S Fraga
2021-03-31 18:28 3% ` Martin Steffen
0 siblings, 1 reply; 200+ results
From: Eric S Fraga @ 2021-03-31 9:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
> However, *I would not recommend anyone to use LaTeX for writing*. A
> light markup language is more comfortable and efficient for me.
Totally agree! Although, over the years, I have written many papers in
LaTeX directly, in the past decade I have increasingly relied on org as
the writing tool. It imposes much less friction on the creative process
and, as you say, it enables better management of the writing task. And,
as it gives direct access to LaTeX when necessary, you lose nothing by
writing in org.
And *tables*! Enough said. :-)
But, as always, YMMV.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
^ permalink raw reply [relevance 6%]
* Re: About exporting
@ 2021-03-30 15:44 7% ` Juan Manuel Macías
2021-03-31 9:59 6% ` Eric S Fraga
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-30 15:44 UTC (permalink / raw)
To: Martin Steffen; +Cc: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> In my experience, ith latex, it's possible to write text together for
> well-intended people. Publishing houses tell you ``these are the classes
> and style files (among perhaps others) that you _have_ to use, and also
> do the following...'' (same possible for wisiwyg-editors, I assume),
> and if you don't mess that up (like overwriting the defaults) you have a
> chance to get a uniformely looking output (and on a halfway portable
> platform, like a CTAN compatible latex installation). I cannot imagine
> that publishers would prescibe ``this is the org-settings and features
> you as author must to use to publish with us''.
Unfortunately today the old 'division of powers' that always worked has
been broken in many scenarios: the author writes, the typesetter
composes the book and the publisher publishes it, and neither of them
interferes in the other's work, although all three live together in the
same body. The WYSIWYG word processors have had a lot to do with
distracting the author in untimely typographical concerns by imposing an
unnatural way of writing, where the format is confused with the content
and its structure. And DTP software, on the other hand, which is
intended for magazines and graphic design, have imposed a rather
negligent way of producing books.
Knuth created TeX in the '70s for his own books, because he was
disgusted with the result he was getting from an increasingly poor
publishing industry, in the transition from mechanical printing and
photocomposition to computerized editorial production. But somehow he
also reinvented the printing press of the digital age, since TeX is
first and foremost an emulator of the art and technique of ancient
linotypists, monotypists, typesetters and so on. Lamport wrote LaTeX for
his own documents, as a high-level language for TeX, since TeX only
works on the physical plane, and plainTeX was quite spartan. But time
has shown that LaTeX (and later ConTeXt) is the perfect semantic layer
of TeX. Tex and LaTeX are essentially *typographic* tools, with true
professional demands, but which authors can use on "autopilot" (a very
small part of LaTeX).
However, *I would not recommend anyone to use LaTeX for writing*. A
light markup language is more comfortable and efficient for me. Some
people prefer Markdown, but IMHO, Org Mode represents the most natural
way (aside from paper) to write. It helps me organize my ideas. And when
I write I don't worry about typographical problems at all, although I
work as a professional typesetter. Of course, with LaTeX and its
autopilot (standard classes, basic packages, no direct formatting, no
custom code, etc., etc.) you can do the same. But Org represents one
more step in confort and productivity.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: About exporting
@ 2021-03-30 11:04 6% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-30 11:04 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 30 Mar 2021 at 09:06, Tim Cross wrote:
>> The trick with Latex is to go with the flow, not against it.
>
> +1
>
> This is the first thing I tell my students. LaTeX knows much much more
> about how to make documents look good than any of us ever will.
If you don't know anything about typography, perhaps it is preferable to
let LaTeX do its work. With the standard classes (or non-standard ones,
like Koma) and a few packages the result it will always be better than
in a Word-style word processor. For example, TeX justifies paragraphs in
a very more intelligent way, understanding the paragraph as a whole, and
not line by line, as word processors do. In fact, the Plass-Knuth
algorithm (see:
http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf) from TeX was
implemented by Adobe for its layout software InDesign. pdfTeX
implemented, in addition, micro-typographic features (protrusion and
expansion), based on the theories of the great German typographer
Hermann Zapf (author of typefaces such as Palatino and Optima and friend
of Donald Knuth). Those properties were picked up by LuaTeX, which in
turn picked up the legacy of a TeX experimental variant (that I
used quite a bit in the early 2000), Omega, later Aleph.
So, yes, you can get very high-quality documents using LaTeX. And there
is also ConTeXt, another TeX format with a radically different
conception compared to LaTeX, more monolithic and, in certain aspects,
more avant-garde. But that does not mean that LaTeX, used as is, produce
a typographically finished result. LaTeX is the means, not the end. Of
course, through packages we can adjust many things at a high level. An
obvious example is the geometry package, but to establish good page
dimensions you have to know what you are doing... But other things can
only be adjusted by hand, visually, unless someday some AI comes to do
that job ;-)
A very typical example: the \raggedbottom option is almost never
acceptable in a book. The \flushbottom option requires that the height
of the composition box is a multiple of the line spacing. TeX also does
very good work with the vertical stretch gaps (glues), but we also want
to modify them depending on the chosen font, the main text body, etc.
And a penalty of widow and orphan lines will also be desirable. There
are many ways to do it (including packages), but the simplest is to add
a couple of TeX primitives to the preamble, with these values:
\widowpenalty=10000
\clubpenalty=10000
But if we have penalized widows or orphans we will get pages that have
one line less, *unacceptable* in a book. That we will have to fix
manually, probably adding a line to the paragraph (\looseness=1), but it
will depend on the context. If we use LuaTeX we can apply things like
the ones discussed in this thread:
https://tex.stackexchange.com/questions/372062/paragraph-callback-to-help-with-widows-orphans-hand-tuning
There are, in short, many things in a 'standard' LaTeX document that
require fine adjustment. Packages like lua-typo or impnattypo are
helpful in this regard. But some typography skills are required. Of
course, this knowledge is accessible to everyone. There are so many
bibliography, but I would highly recommend the writings of Stanley
Morison, author of the Times Roman and a great theorist of the modern
typography. Of course, as for TeX, the TeX Book is always an almost
obligatory (and exciting) read :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: About exporting
@ 2021-03-29 21:31 7% ` Juan Manuel Macías
2 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-29 21:31 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Hi,
Ypo <ypuntot@gmail.com> writes:
> LaTeX: I can see some masters here that make professional books, and I
> have some friends that publish scientific papers using LaTeX. But, it
> looks like a like a rabbit hole to me, since even the masters seem to
> have to modify the tex file directly (is this correct?), not being
> sufficient orgmode to culminate the work by itself. And to learn LaTeX
> seems a lifelong activity (almost like "learning" orgmode). BTW, when
> I export to LaTeX although it gets the job done, it sends a lot of
> error messages.
I can tell you some points about my experience with the export to LaTeX,
since that's what I work the most with.
The advantages of using Org instead of "pure" LaTeX (as I already
discussed in another thread) are, IMHO, (a) being able to work on a much
lighter and human readable source (consider, for example, what a list
looks like in Org and what it looks like in LaTeX); and (b) be able to
export to various formats consistently from a single source. Therefore,
it would not be necessary to edit the *.tex document, as we would lose
the latter advantage.
Of course, if you want to use Org to create "refined" documents or books
with LaTeX, you're going to have to learn LaTeX. But "learning LaTeX" is
a imprecise term, since LaTeX has a minimal kernel concept expanded by a
(infinity of) macro packages. Even you can write your own packages, if
you know how to do it. That is, learning latex involves: a) learning
LaTeX syntax (which is not especially arduous) and b) learn the packages
you are going to use (and, therefore, *study its documentation*). The
documentation for each package is on CTAN (https://www.ctan.org/); you
also have, of course, lots of online documentation about LaTeX and TeX
in general. A very good place is https://tex.stackexchange.com/
My personal story has been to use LaTeX for years, until I decided to do
it from Org, but still using LaTeX ...
It also depends on the type of book/document you want to make. When
deals with very large books I usually create the preamble in a Org
document separately, and then I tangle the code in a tex file. And I
also use Org Publish to separate the parts of the book into small
documents (very useful).
Another great thing about Org, on the other hand, is that it has many
resources for control the export process. For example, in a book I'm
working on I noticed that the font has a kerning (separation
between characters) too close between the sign "(" and the italic "f",
producing a rather ugly effect. Simply, with a simple function in Elisp
I was able to readjust that space in the export process (see:
https://orgmode.org/manual/Advanced-Export-Configuration.html#Advanced-Export-Configuration)
All of this that I have discussed, of course, may sound too abstract.
But I can comment in more detail on more specific issues, if you have
any questions :-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: "Org" source blocks and minted
@ 2021-03-26 11:55 10% ` Juan Manuel Macías
2021-04-01 8:07 6% ` Michael Gauland
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-03-26 11:55 UTC (permalink / raw)
To: Timothy; +Cc: orgmode
Hi Timothy,
I really like your approach. And it is org/emacscentric! Minted has
never quite convinced me, and gives me some trouble with certain
packages in LuaLaTeX that I have not been able to solve. Thank you for
this promising alternative.
Best regards,
Juan Manuel
Timothy <tecosaur@gmail.com> writes:
> Juan mentioned an Org lexer exists, but another approach that may be of
> interest is using Emacs' own font-lock. I wrote a package that's like
> HTMLize but works with LaTeX and currently have it sitting in my config.
>
> I plan on submitting a patch to Org at some point on this, but for now:
> - https://github.com/tecosaur/engrave-faces
> - https://tecosaur.github.io/emacs-config/config.html#pretty-code-blocks
>
> Sample output: all the code blocks in
> https://tecosaur.github.io/emacs-config/config.pdf
>
> Since this uses Emacs' font-lock, this means that you can use any
> language that you have a syntax-highlighting-mode for :)
^ permalink raw reply [relevance 10%]
* An interesting LaTeX package
@ 2021-03-25 9:40 8% Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-03-25 9:40 UTC (permalink / raw)
To: orgmode
Hi all,
This is not directly related to Org-Mode (apologies for the light
off-topic), but I thought this new LaTeX package uploaded to CTAN could
be of interest to those who regularly export from Org to LaTeX and want
to get a document as 'perfect' as possible, typographically speaking ;-)
The Lua-typo package (according to its description): "tracks common
typographic flaws in LuaLaTeX documents, especially widows, orphans,
hyphenated words split over two pages, consecutive lines ending with
hyphens, paragraphs ending on too short lines, etc."
(https://ctan.org/pkg/lua-typo).
This package can detect any of the following scenarios (taken from the
package documentation):
- paragraph’s last line nearly full?
- paragraph’s last line too short?
- nearly empty page (just a few lines)?
- overfull lines?
- underfull lines?
- widows (top of page)?
- orphans (bottom of page)
- hyphenated word split across two pages?
- too many consecutive hyphens?
- paragraph’s last full line hyphenated?
- short words (1 or 2 chars) at end of line?
- same (part of) word starting two consecutive lines?
- same (part of) word ending two consecutive lines?
It should be noted that the package works only in LuaLaTeX, and that it
highlights flaws only (in draft mode), but does not correct them. It's
similar to another older package, Impnattypo
(https://ctan.org/pkg/impnattypo).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
Results 1201-1400 of ~1600 next (older) | prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-12-17 17:23 [PATCH] A proposal to add LaTeX attributes to verse blocks Juan Manuel Macías
2021-01-03 10:25 ` TEC
2021-01-03 13:07 ` Juan Manuel Macías
2021-01-03 13:08 ` TEC
2021-01-07 18:52 ` Juan Manuel Macías
2021-05-01 10:58 6% ` Bastien
2021-05-01 11:46 10% ` Juan Manuel Macías
[not found] ` <87tunlxws3.fsf@ucl.ac.uk>
2021-05-02 11:09 9% ` Juan Manuel Macías
2021-05-08 7:31 6% ` Juan Manuel Macías
2021-05-15 13:46 6% ` Bastien
2021-05-01 10:58 6% ` Timothy
2021-01-31 19:37 [patch] to allow org-attach-git to handle individual repositories Juan Manuel Macías
2021-04-28 3:57 6% ` Bastien
2021-04-28 13:42 10% ` Juan Manuel Macías
2021-05-15 14:08 6% ` Bastien
2021-02-18 16:33 [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
2021-04-19 9:19 5% ` Nicolas Goaziou
2021-04-20 13:56 8% ` Juan Manuel Macías
2021-04-21 16:01 4% ` Juan Manuel Macías
2021-04-22 12:55 5% ` Nicolas Goaziou
2021-04-22 13:46 10% ` Juan Manuel Macías
2021-04-25 3:46 6% ` Timothy
2021-03-24 1:33 "Org" source blocks and minted Michael Gauland
2021-03-24 4:24 ` Timothy
2021-03-26 11:55 10% ` Juan Manuel Macías
2021-04-01 8:07 6% ` Michael Gauland
2021-03-25 9:40 8% An interesting LaTeX package Juan Manuel Macías
[not found] <mailman.51.1617033608.26133.emacs-orgmode@gnu.org>
2021-03-29 19:37 ` About exporting Ypo
2021-03-29 21:31 7% ` Juan Manuel Macías
2021-03-29 22:06 ` Tim Cross
2021-03-30 6:17 ` Eric S Fraga
2021-03-30 11:04 6% ` Juan Manuel Macías
2021-03-30 11:54 ` Martin Steffen
2021-03-30 12:44 ` autofrettage
2021-03-30 14:35 ` Martin Steffen
2021-03-30 15:44 7% ` Juan Manuel Macías
2021-03-31 9:59 6% ` Eric S Fraga
2021-03-31 18:28 3% ` Martin Steffen
2021-04-01 6:52 ` Eric S Fraga
2021-04-01 14:21 7% ` Juan Manuel Macías
2021-03-31 9:40 How to expand macro in LaTeX export? How to use different options per export type? Jean Louis
2021-04-03 21:57 9% ` Juan Manuel Macías
2021-03-31 18:56 10% About exporting Juan Manuel Macías
2021-04-02 15:54 Including Email Address in the Reply in Mailing-list Husain Alshehhi
2021-04-02 23:08 ` Tim Cross
2021-04-02 23:45 10% ` Juan Manuel Macías
2021-04-02 18:15 9% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
2021-04-09 22:28 6% ` Nicolas Goaziou
2021-04-10 0:01 9% ` Juan Manuel Macías
2021-04-10 10:19 6% ` Nicolas Goaziou
2021-04-10 11:41 10% ` Juan Manuel Macías
2021-04-13 17:31 5% ` Maxim Nikulin
2021-04-13 19:08 9% ` Juan Manuel Macías
2021-04-14 15:42 5% ` Maxim Nikulin
2021-04-14 17:07 9% ` Juan Manuel Macías
2021-04-14 21:36 12% ` Juan Manuel Macías
2021-04-15 14:58 ` Maxim Nikulin
2021-04-15 18:21 9% ` Juan Manuel Macías
2021-04-17 13:27 5% ` Maxim Nikulin
2021-04-18 17:52 9% ` Juan Manuel Macías
2021-04-18 21:20 11% ` Juan Manuel Macías
2021-04-19 8:33 5% ` Nicolas Goaziou
2021-04-19 12:34 ` Maxim Nikulin
2021-04-19 16:08 ` Nicolas Goaziou
2021-04-20 12:20 ` Maxim Nikulin
2021-04-20 13:57 ` Nicolas Goaziou
2021-04-20 15:51 ` Maxim Nikulin
2021-04-20 20:37 ` Nicolas Goaziou
2021-04-21 13:10 ` Maxim Nikulin
2021-04-21 15:45 9% ` Juan Manuel Macías
2021-04-24 14:41 5% ` Maxim Nikulin
2021-04-28 5:46 6% ` Bastien
2021-04-28 6:37 0% ` Nicolas Goaziou
2021-04-03 9:31 First steps exporting to tex Ypo
2021-04-03 10:15 ` Martin Steffen
2021-04-04 11:04 6% ` Ypo
2021-04-04 11:36 10% ` Juan Manuel Macías
2021-04-03 12:10 7% ` Juan Manuel Macías
2021-04-03 13:31 ` Tim Cross
2021-04-03 16:55 ` Diego Zamboni
2021-04-03 17:07 ` William Denton
2021-04-03 17:49 8% ` Juan Manuel Macías
2021-04-03 18:36 4% ` Jean Louis
2021-04-03 20:46 7% ` Juan Manuel Macías
2021-04-03 18:45 How to get a table into a variable in a shell code block? Greg Minshall
2021-04-03 19:01 10% ` Juan Manuel Macías
2021-04-04 10:31 how to export (latex) a image without using figure Uwe Brauer
2021-04-04 11:17 10% ` Juan Manuel Macías
2021-04-04 11:33 1% ` Uwe Brauer
2021-04-05 9:25 8% [tip] search this mailing list with helm-surfraw Juan Manuel Macías
2021-04-25 5:00 7% ` Bastien
2021-04-27 20:20 10% ` Juan Manuel Macías
2021-04-05 20:48 6% Choosing a LaTeX Compiler (my predilection for LuaTeX) Juan Manuel Macías
2021-04-05 21:17 5% ` Dr. Arne Babenhauserheide
2021-04-05 21:36 9% ` Juan Manuel Macías
2021-04-06 19:03 ` physiculus
2021-04-06 19:13 9% ` Juan Manuel Macías
2021-04-07 16:57 4% ` physiculus
2021-04-07 17:26 9% ` Juan Manuel Macías
2021-04-07 17:53 6% ` physiculus
2021-04-07 19:52 10% ` Juan Manuel Macías
2021-04-06 19:46 ` tomas
2021-04-06 20:09 10% ` Juan Manuel Macías
2021-04-07 14:16 6% ` Diego Zamboni
2021-04-07 15:29 8% ` Juan Manuel Macías
2021-04-06 20:44 3% Ypo
2021-04-12 13:50 10% [Patch] to correctly sort the items with emphasis marks in a list Juan Manuel Macías
[not found] <mailman.57.1618243212.17744.emacs-orgmode@gnu.org>
2021-04-12 18:51 ` Ypo
2021-04-12 23:18 10% ` Juan Manuel Macías
2021-04-12 23:52 6% ` Samuel Wales
2021-04-13 14:16 10% ` Juan Manuel Macías
2021-04-30 13:26 6% [PATCH] Possibility of using alternative separators in macros Juan Manuel Macías
2021-05-01 8:30 ` Bastien
2021-05-01 10:04 ` Nicolas Goaziou
2021-05-01 21:50 8% ` Juan Manuel Macías
2021-05-02 21:08 5% ` Christian Moe
2021-05-11 11:01 5% ` Eric S Fraga
2021-05-11 16:12 5% ` Juan Manuel Macías
[not found] ` <87im3prvz8.fsf@ucl.ac.uk>
2021-05-11 18:25 9% ` Juan Manuel Macías
2021-05-15 13:29 6% ` Bastien
2021-05-15 20:14 9% ` Juan Manuel Macías
2021-05-15 20:25 6% ` Bastien
2021-05-15 21:05 10% ` Juan Manuel Macías
2021-05-16 12:17 6% ` Bastien
2021-05-16 16:48 0% ` Maxim Nikulin
2021-04-30 15:19 How to create a macro that inserts multiline text with :B_ignoreheading: tag? Richard Stanton
2021-04-30 20:40 10% ` Juan Manuel Macías
2021-04-30 23:40 3% ` Richard Stanton
2021-05-02 20:20 8% About multilingual documents Juan Manuel Macías
2021-05-03 6:58 5% ` Aleksandar Dimitrov
2021-05-03 20:33 9% ` Juan Manuel Macías
2021-05-04 8:44 2% ` Aleksandar Dimitrov
2021-05-06 11:11 6% ` Juan Manuel Macías
2021-05-10 7:19 8% [tip] Export annotations with the 'Mindflow' LaTeX package Juan Manuel Macías
2021-05-16 15:31 8% [Question] Custom parse tree filter Juan Manuel Macías
2021-05-16 15:59 5% ` Nicolas Goaziou
2021-05-17 12:20 8% ` Juan Manuel Macías
2021-05-17 15:41 8% Multilingual support (proposals and state of the question) Juan Manuel Macías
2021-05-17 16:03 6% ` Denis Maier
2021-05-17 18:10 10% ` Juan Manuel Macías
2021-05-20 7:14 can't install footnotes in certain table cells Uwe Brauer
2021-05-20 9:57 ` [can't insert footnotes in all table cells] (was: can't install footnotes in certain table cells) Uwe Brauer
2021-05-20 10:06 ` [org-footnote--allow-reference-p] (was: [can't insert footnotes in all table cells]) Uwe Brauer
2021-05-20 10:17 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
2021-05-20 10:21 0% ` [org-footnote--allow-reference-p] Uwe Brauer
2021-05-20 10:38 10% ` [org-footnote--allow-reference-p] Juan Manuel Macías
2021-05-20 11:45 8% An attempt to prepare critical editions within Org Juan Manuel Macías
2021-05-20 12:24 6% ` Denis Maier
2021-05-22 14:12 9% [PATCH] org.el: use only link descriptions in indirect buffer names Juan Manuel Macías
2021-05-23 10:41 6% ` Ihor Radchenko
2021-05-23 11:25 9% ` Juan Manuel Macías
2021-05-24 12:14 7% [PATCH] ox-latex.el: add LaTeX attributes to quote block Juan Manuel Macías
2021-05-25 9:21 5% ` Nicolas Goaziou
2021-05-25 12:42 8% ` Juan Manuel Macías
2021-05-25 15:52 6% ` Nicolas Goaziou
2021-05-25 20:50 7% ` Juan Manuel Macías
2021-05-26 21:05 5% ` Nicolas Goaziou
2021-05-26 23:02 6% ` Juan Manuel Macías
2021-05-29 20:22 6% ` Nicolas Goaziou
2021-05-28 2:54 Smart quotes not working correctly with single quotes Andreas Gösele
2021-05-28 10:10 9% ` Juan Manuel Macías
2021-05-28 15:42 7% ` Andreas Gösele
2021-05-28 17:02 9% ` Juan Manuel Macías
2021-05-28 20:27 7% ` Andreas Gösele
2021-05-28 20:37 10% ` Juan Manuel Macías
2021-05-29 2:42 6% ` Andreas Gösele
2021-05-28 17:55 0% ` Albert Krewinkel
2021-05-28 19:48 ` Nicolas Goaziou
2021-05-28 20:19 10% ` Juan Manuel Macías
2021-05-30 17:33 TMIO Pre-release, request for feedback Timothy
2021-05-30 19:42 10% ` Juan Manuel Macías
2021-05-31 10:40 9% An attempt to convert Elfeed entries (with parameters) to Org trees Juan Manuel Macías
2021-06-23 14:56 6% ` Ihor Radchenko
2021-06-24 8:02 10% ` Juan Manuel Macías
2021-06-01 15:36 suggestion to change default org-latex-pdf-process to latexmk Bruce D'Arcus
2021-06-01 15:52 10% ` Juan Manuel Macías
2021-06-02 0:00 ` Tim Cross
2021-06-02 6:07 ` Stefan Nobis
2021-06-02 8:40 10% ` Juan Manuel Macías
2021-06-02 2:03 Format babel code block for export? Galaxy Being
2021-06-02 9:42 10% ` Juan Manuel Macías
2021-06-03 14:54 10% Remove all Org metadata with header argument `:comments org' Juan Manuel Macías
2021-06-20 13:58 6% ` Ihor Radchenko
2021-06-03 21:11 10% [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
2021-06-04 11:31 13% ` Juan Manuel Macías
2021-06-06 22:34 13% ` Juan Manuel Macías
2021-06-08 0:24 9% ` [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.) Juan Manuel Macías
2021-06-06 18:19 [PATCH] Allow LaTeX reference command (\ref) to be customised Timothy
2021-06-06 18:29 10% ` Juan Manuel Macías
2021-06-07 11:43 literate programming, development log -- ideas? Greg Minshall
2021-06-07 12:00 10% ` Juan Manuel Macías
2021-06-07 13:09 10% org-critical-edition (a package for philologists and classicists) Juan Manuel Macías
2021-06-14 8:50 6% ` Christian Moe
2021-06-15 12:44 9% ` Juan Manuel Macías
2021-06-08 15:49 org-attach a directory? John Kitchin
2021-06-08 16:21 ` Henrik Frisk
2021-06-08 20:41 ` John Kitchin
2021-06-09 1:38 6% ` [patch] " Juan Manuel Macías
2021-06-11 1:43 ` stardiviner
2021-06-11 16:35 ` John Kitchin
2021-06-11 17:10 4% ` Juan Manuel Macías
2021-06-08 17:15 literate programming, development log -- ideas? (ominbus reply) Greg Minshall
2021-06-08 17:21 ` Samuel Banya
2021-06-09 8:59 ` Eric S Fraga
2021-06-09 22:21 ` Dr. Arne Babenhauserheide
2021-06-10 22:07 ` Samuel Wales
2021-06-11 0:13 ` Samuel Banya
2021-06-11 14:30 10% ` Juan Manuel Macías
2021-06-11 15:02 6% ` Samuel Banya
2021-06-09 19:35 org-attach a directory? Ypo
2021-06-09 23:39 ` John Kitchin
2021-06-10 3:56 ` Ypo
2021-06-10 12:37 ` Christian Barthel
2021-06-10 14:01 10% ` Juan Manuel Macías
2021-06-10 16:13 13% ` Juan Manuel Macías
2021-06-11 17:53 Failure to resolve internal links on ox-html export? Tim Visher
2021-06-11 18:31 10% ` Juan Manuel Macías
2021-06-18 19:47 6% ` Tim Visher
2021-06-18 20:37 10% ` Juan Manuel Macías
2021-06-18 22:18 0% ` Tim Cross
2021-06-20 15:01 0% ` Tim Visher
2021-06-12 9:15 Write Markdown in Org mode leo
2021-06-12 12:35 9% ` Juan Manuel Macías
2021-06-12 15:14 6% ` leo
2021-06-12 15:51 10% ` Juan Manuel Macías
2021-06-12 23:51 7% [tip] LaTeX preview of a region Juan Manuel Macías
2021-06-16 9:33 no inline images anymore after reinstall Prof. Dr. Johanna May
2021-06-16 12:51 9% ` Juan Manuel Macías
2021-06-17 12:06 example paper written in org completely Eric S Fraga
2021-06-17 12:51 10% ` Juan Manuel Macías
2021-06-18 12:11 9% A dictionary made in Org Mode Juan Manuel Macías
2021-06-18 12:19 6% ` John Kitchin
2021-06-18 12:27 6% ` Detlef Steuer
2021-06-18 13:51 6% ` Samuel Banya
2021-06-18 22:15 publishing: no default publishing function, or symbol is not defined Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 12:48 11% ` Juan Manuel Macías
2021-06-19 18:23 5% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 18:28 5% ` [External Email] " Christopher W. Ryan via General discussions about Org-mode.
2021-06-19 19:32 9% ` Juan Manuel Macías
2021-06-22 20:26 7% ` Christopher W. Ryan via General discussions about Org-mode.
2021-06-25 8:38 10% ` Juan Manuel Macías
2021-06-23 19:27 appearance of list as results from evaluating code blocks Johannes Brauer
2021-06-23 19:43 10% ` Juan Manuel Macías
2021-06-23 20:03 3% ` Johannes Brauer
2021-06-26 14:44 Export Org mode files to (gag, barf) MS Office? Brandon Taylor
2021-06-26 15:15 10% ` Juan Manuel Macías
2021-06-29 11:25 Virtually prefix headlines according to content Rodrigo Morales
2021-06-29 13:34 10% ` Juan Manuel Macías
2021-06-29 13:53 5% ` John Kitchin
2021-06-29 20:44 0% ` Samuel Wales
2021-07-05 19:44 convert subtree or nested list to table Matt Price
2021-07-05 20:01 10% ` Juan Manuel Macías
[not found] ` <CAN_Dec8iqKS+3qvjkYvQxovegnEzqR_rra0Q-ZA9baPz1mXDAA@mail.gmail.com>
2021-07-06 12:56 8% ` Juan Manuel Macías
2021-07-07 6:18 0% ` Uwe Brauer
2021-07-07 18:27 10% ` Juan Manuel Macías
2021-07-07 18:44 0% ` Uwe Brauer
2021-07-07 21:16 6% ` Matt Price
2021-07-09 9:15 10% [PATCH] [BUG] Bad fontification in full displayed links Juan Manuel Macías
2021-07-10 1:50 6% ` Ihor Radchenko
2021-07-10 12:12 10% ` Juan Manuel Macías
2021-07-10 13:42 org-mode export to (latex) PDF Jean-Christophe Helary
2021-07-10 13:52 10% ` Juan Manuel Macías
2021-07-10 14:13 2% ` Jean-Christophe Helary
2021-07-10 14:38 8% ` Juan Manuel Macías
2021-07-10 14:59 4% ` Tim Cross
2021-07-10 17:40 8% ` Juan Manuel Macías
2021-07-12 3:09 4% ` Tim Cross
2021-07-10 15:01 1% ` Jean-Christophe Helary
2021-07-10 16:13 6% ` Maxim Nikulin
2021-07-10 16:44 ` Stefan Nobis
2021-07-13 16:53 ` Maxim Nikulin
2021-07-13 17:53 8% ` Juan Manuel Macías
2021-07-14 6:44 ` Stefan Nobis
2021-07-14 17:30 3% ` Maxim Nikulin
2021-07-14 19:05 ` Stefan Nobis
2021-07-14 23:26 ` Tim Cross
2021-07-15 12:06 8% ` Juan Manuel Macías
2021-07-15 17:10 ` Maxim Nikulin
2021-07-15 19:40 9% ` Juan Manuel Macías
2021-07-16 16:56 5% ` Maxim Nikulin
2021-07-16 18:34 7% ` Juan Manuel Macías
2021-07-14 19:29 9% ` Juan Manuel Macías
2021-07-10 18:43 ` Jonathan McHugh
2021-07-10 19:24 9% ` Juan Manuel Macías
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).