usually gives unexpected results, especially when tables
are used as float. In a float table, however, I would not use normal
footnotes via \footnotemark but the solution from the threeparttable package.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Well, next week I will continue commenting. I will try to stay up to
>> date with everything that is being discussed here. By the way, if
>> someone wants to collaborate on the branch, I can add them as a
>>
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> The latest added to the branch are Maxim's proposals (and code) for
>> backend control. See this thread:
>>
>> https://list.orgmode.org/?t=20240321102752
>>
>> And this other thread
see if I can find a space next week...
The latest added to the branch are Maxim's proposals (and code) for
backend control. See this thread:
https://list.orgmode.org/?t=20240321102752
And this other thread, continuation of the previous one:
https://list.orgmode.org/877ciavnwo.fsf...@posteo.net/
Best regards,
Juan Manuel
Ihor Radchenko writes:
> We may introduce \apostrophe entity.
>
> "two articles: 'my friends\apostrophe party' and 'the students\apostrophe
> papers'"
>
> "A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"
It's not a bad idea to use entities. I just discovered that an \rsquo
en
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ━━━
>> #+OPTIONS: ':t
>> #+language:es
>>
>> "my friends' party and the students' papers"
>> ━━
word, as in Greek:
"να 'ρθώ το βράδυ"
(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)
Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at l
Max Nikulin writes:
> I am afraid that :export will cause confusion with :exports for source
> code blocks. Its name differs by just "s" but possible values have
> nothing common.
I agree. At the moment two alternative names come to mind: :backends or
:export-rules
> Another issue is more gene
Max Nikulin writes:
> Would you mind against new thread as an umbrella for next bunch of
> topics? Current one becomes too large from my point of view.
Ok, I agree. I suggest that from now any new thread related to the new
object have as subject:
"inline-special-block: specific topic to discuss
Max Nikulin writes:
> An update with a couple of bugs fixed. Now it is possible to specify
> different export rules for a backend and all its derivatives:
I have implemented your code in the last commit. I think it is a great
improvement, thanks a lot.
As I mentioned in a past email, these days
(?* 'content)
> (?/ nil)
> (_ 'full
I've been testing your code and it works very well. It is certainly
finer than the current approach. I think it could be implemented, and we
are testing that.
Tomorrow I will make a new commit with your code.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Thank you for your comments.
Max Nikulin writes:
> On 15/03/2024 09:19, Juan Manuel Macías wrote:
>> The attribute supports one or more elements separated by a space. Each
>> element can be any of the following signs: "*" (export only the
>> content), "-&qu
To summarize the latest improvements and modifications to the `:export'
attribute...
The attribute supports one or more elements separated by a space. Each
element can be any of the following signs: "*" (export only the
content), "-" (do not export), "=" (export the rest normally), "=*"
(export th
Juan Manuel Macías writes:
> It was necessary with the previous implementation, which excessively
> abused regexp. Not now (I want to do a few more tests and I'll make a
> new commit with the changes). With the new implementation, now:
>
> - do not export
>
>
changes). With the new implementation, now:
- do not export
* export only the content
= rest (full)
=* rest (contents only)
backend- do not export this backend (and the backends derived from it)
backend+ (or, perhaps, just "backend") export this backend (idem)
backend* export
nt
- "==" :: rest (full)
- "=*" :: rest (only the content)
- "!backend-name+ :: export this backend (full)
- "!backend-name*" :: export this backend (only the content)
- "!backend-name- :: do not export this backend
?
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ds
@foo[:export latex rest*]{lorem ipsum dolor}
==> the opposite of the above.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
se a macro.
>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.
I will try to implement the "rest" option.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Max Nikulin writes:
> On 10/03/2024 09:08, Juan Manuel Macías wrote:
>> I'm thinking about adding a new global attribute, `:export', that
>> would granularly control whether or not to export the object and how to
>> export it.
>
> I have a bit differ
https://i.ibb.co/CBRnfXG/pantallazo-79248380551244229p8.png
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Juan Manuel Macías writes:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the
aTeX, but only the content would be exported to odt and html.
Wdyt?
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Max Nikulin writes:
>
>> However it is still gives
>>
>> (org-export-string-as "Alpha@Beta["
>> 'html
>> '(:export-options (body-only)))
>> Debugger entered--Lisp error: (wr
he problem is the contents-begin variable. When it is nil it
produces that error. I will make a new commit to fix the bug.
Thanks for all the tests you're doing!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Juan Manuel Macías escribió:
> Ok, I think you and Maxim are right. This is a clear bug. I hope it
> was fixed in the last commit.
Now:
(org-export-string-as "Alpha@Beta{" 'latex t))
==> Alpha@Beta\{
(org-export-string-as "Alpha@Beta{gamma}" 'la
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Debugger entered--Lisp error: (wrong-type-argument
>>> number-or-marker-p nil)
>>
>> Maybe in that case you could add a zero width space character.
>>
>> In any case, if someone has reas
ot;Alpha_Beta":
(org-export-string-as "Alpha_beta"
'html
'(:export-options (body-only)))
Alphabeta
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Juan Manuel Macías writes:
> Ihor Radchenko escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any speci
ort snippet).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
the point when Org mode is used as standard
> documentation format.)
I have modified the syntax in the last commit. Now:
@type[...]{...} (or @_[...]{...})
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> (org-export-string-as "Alpha&Beta{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts:
>> &_{subscript}...
>>
>> Perhaps we should think about a st
quot;
mmm, right. And there may also be a problem with the subscripts:
&_{subscript}...
Perhaps we should think about a structure less prone to ambiguities. For
example:
&:type[attrs]{text} / &:_[attrs]{text}
(I think someone had suggested something like this in a past message,
but
the content (in LaTeX, HTML and odt). You can try:
&_{/lorem/}&_{*ipsum*}&_{_dolor_}
==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}
==> HTML loremipsumdolor
==> ODT loremipsumdolor
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
t;b" :html-tag "b")("i" :html-tag "i"))
&b{intra}&i{word}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ey simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anywa
there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination
porters and the output format. So, how about
something like:
- Custom Export Fragment
- Custom Export Span
- Custom Export "Whatever"
- ...
?
(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdow
teractive)
│ (add-hook 'after-save-hook #'org-latex-export-to-latex nil t))
│ (remove-hook 'after-save-hook #'org-latex-export-to-latex t)
│ (when (equal (process-status "latexmk") 'run)
│ (kill-process "latexmk"
└
And a screencast:
<https://cloud.disroot.org/s/ztFfa27kdsnNkGc>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Max Nikulin writes:
> In Org syntax, "elements" are paragraphs and larger parts, while parts
> within paragraphs are named objects. I admit that for org-element
> everything is element.
In my initial message I used 'element' loosely. Note that
inline-special-block is included in org-element-all-o
om inline markup.
Custom span?
I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
eplace commands).
I think you're right. I have removed the need for "!" in the last
commit.
Now the syntax is:
&alias{text}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
#x27;s famous quote: \foreignlanguage{latin}{\textit{Alea iacta est}}
│
│ Caesar's famous quote:
{\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
└
== HTML:
┌
│ Caesar's famous quote: Alea iacta est
│
│ Caesar's famous quote: Alea iacta est
└
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
spite they may be exported to the same command.
>
>> In any case, I think that my implementation leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
>
prelatex:
&_[:prelatex \foo\bar\vaz\blah{}]{text}
==> {\foo\bar\vaz\blah{}text}
I'm not opposed to your ideas, I just can't find a use case for it. In
LaTeX, I mean. In the case of HTML I find it useful, indeed, to have
more control over the tags: , , etc.
In any case, I think th
Max Nikulin writes:
> #+options: custom-object(:type la :latex_element foreignlanguage
> :latex_pre "{latin}")
mmm, I see it as not very flexible and perhaps too complicated for the user.
My idea with the concept of inline-special-block is that it is like the
inline version of its older brother
Max Nikulin writes:
> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
ss:
> https://orgmode.org/worg/org-contribute.html#devs
Thank you! I think for the moment I will use GitLab to publish my
experimental branch, if it is not essential to do it in savannah (I am
more used to gitlab). As soon as I publish it, I'll share the
link.
Best regards,
Juan Manuel
h", "French", "Italian", "Greek", etc.?
(If I shared something in Spanish, I could translate the article in the
body of the message).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
use I
don't have enough knowledge of odt to work on this backend, which would
be the next step.
Thanks for the info!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
amet.
Related: https://list.orgmode.org/87ttlyloyr@posteo.net/
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
olor{blue}\foo{2345}{lorem ipsum dolor}}
There can only be one alias per element, but an alias can be combined
with other attributes. It is the closest thing to using styles,
and perhaps the most appropriate term would be ":style". But you can get
confused with the html "style"
Juan Manuel Macías writes:
> Regarding the "optional parameters", there is nothing defined, although
> I think they should be adapted to each backend. A possible use that
> occurs to me:
>
> &foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
&type[optional parameters]{contents}
k, which is the only case of "inline block" that
we have in Org.
Best regards,
Juan Manuel
ith this type of elements
inside the paragraph.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ould produce in LaTeX:
\foo[lorem]{blah blah}{ipsum}
and in HTML:
blah blah
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 587e77feb1c4e6881d527d1fd3a6e541efb596d4 Mon Sep 17 00:00:00 2001
From: Ju
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I'm dedicating a local branch to developing this proof of concept and
>> testing it in my workflow, so far with good results. The basic idea is
>> to provide Org with multilingual features and various metho
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements
age-ini-only language-ini-alt)))
(format "\\foreignlanguage{%s}{%s}" lang contents)
#+end_src
Opinions, suggestions, feedback, ideas?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ms that, as an example, open-office
> exporting understands the language.
Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:
https://list.orgmode.org/?t=20230830082719
Best regards,
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' w
epackage[AUTO]{babel}
(see 'LaTeX header and sectioning structure' in the Org Manual)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
of :imagemagick. Or you could even think of any possible
conversion process using a hypothetical :pdf-postprocess
- A branch for orf-create-formula-image
- a third branch to export to html, with org-babel-latex-htlatex.
Having three clearly differentiated branches would make the code easier
to maintain.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ypuntot writes:
> Is it related with AUTHOR property?
> I am starting to add these properties to every book, and chapter of
> the book, that I study. I hope this doesn't lead to a suboptimal
> workflow.
>
> Doesn't this work?
>
> :PROPERTIES:
> :AUTHOR: García-Ael, Cristina and Pérez-Gar
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> neither do I, This is why I'm asking for people to tell me what they
>>> use ;-)
>>
>> The babel ini files (why hadn't I thought of th
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Moreover, it would be nice to unify handling .png and imagemagick
>>> branches of the code.
>>
>> I agree. In any case, I still think that the coexistence of two methods
>> to convert to image
derivate = no
.
------>8
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
-latex-known-warnings regexp in the attached patch.
I think it should work fine now...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 742d67f2e8d4f1896d89f7543948facd65687ffe Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
ers as the European Latin (T1-encoded) Fonts, while in their
upper half (128–255) they contain letters and symbols for African
languages that use extended Latin alphabets."
etc.
But I can't find a simpler list anywhere.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Compos
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> When I try the patch with a simple file like
>>>
>>> Hello. 你好。
>>>
>>> I do not see any warnings or errors indicated.
>>
>> How weird... And don't they at least appe
Sorry, the previous patch was incomplete. The attached patch is correct.
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Rationale for the attached patch: It seems that a common problem that
> users have with exporting to LaTeX is unicode characters that cannot be
> repre
'warning' string.
Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipogra
s for
maintaining the code.
The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
aTeX?", in the end
a LaTeX manual is made instead of Org.
I'm glad you enjoyed the jump to LuaTeX. :-)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> + (process (cdr (assq :process params)))
>> + (org-pr
Juan Manuel Macías writes:
>> Ihor Radchenko writes:
>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>> locally to the block. This can be useful for evaluati
#x27;("cd %o && context %f")
\starttext
\startsection[title={Testing ConTeXt}]
Lorem ipsum dolor.
\stopsection
\stoptext
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From fe1
Irfan S writes:
> FYI, there is also
> [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which
> provides similar (and additional) functionality, and is on MELPA.
> Thanks for sharing your code.
Thank you very much, I didn't know that.
Best regards,
Juan Manuel
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>
adata like xmp. Maybe using the hyperxmp package, which you mentioned
in a thread months ago?
Maybe something like this:
#+latex_xmp
...
#+end
?
Best regards,
Juan Manuel
et.emacslife.com/ as a source, scrape it regularly (once per
> day/week or on every export), and embed the relevant links into the
> orgweb/index.html
>
> This way, visitors can easily see how active Org mode community is and
> discover Org-related blogs/forums.
+1
Best regards,
Juan Manuel
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Sorry if this is off topic, but something like this:
>>
>> #+AUTHOR: Fred Astaire
>> #+AUTHOR: Ginger Rogers
>>
>> is exported to LaTeX as:
>>
>> \author{Fred Astaire Ginger Rogers}
Astaire Ginger Rogers}
Shouldn't there be some separation? In LaTeX the usual thing is:
\author{Fred Astaire \and Ginger Rogers}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
truetype and opentype fonts in XeLatex and LuaLaTeX and setting
opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
would say that what Pedro proposes is limited only to the output in
pdfTeX.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de dato
here a
footnote of this type is expected. I know: it's ugly and corseted (what
to do if a title has more than one footnote or an "inner" footnote?).
But I suppose it would be safe for a basic case, since it would only be
necessary to modify org-latex-template, org-odt-template, etc., without
risk of unexpected results.
Best regards,
Juan Manuel
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ...
>> \title{Lorem ipsum dolor\thanks{blah blah}}
>> ...
>>
>> Org does not have support for this type of notes in the #+title or
>> #+author keywords. For LaTeX you can use a macro.
>
>
nice if Org had some kind of support for notes in
#+title and #+author...
Best regards,
Juan Manuel
numbering (symbols, letters...). The manyfoot and bigfoot packages
allow constructions of this type, with various footnote apparatus.
Best regards,
Juan Manuel
--
Juan Manuel Macías --
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> +#+begin_example
>>> +,#+latex_class_options: [greek,spanish,oneside]
>>> +,#+language: es
>>> +,#+latex_header: \PassOptionsToPackage{
in a previous email... I
hope not. I have a couple of filters written already, but I don't think
it will take much work for me to readjust them.
Best regards,
Juan Manuel
upport greek script
or this variant, using babelprovide and an INI file:
#+language: es
#+latex_header: \usepackage[greek]{babel}
#+latex_header: \babelprovide[import,main]{AUTO}
#+latex_header: \usepackage{alphabeta}
Best regards,
Juan Manuel
does not seem to
influence the output. In fact, that was how it was in Org in the days
pre org-latex-line-break-safe and there were never any problems.
Best regards,
Juan Manuel
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Paragraph\\
>>> @@latex:[foo]@@
>>
>> But since in both cases it is literal LaTeX code, the correct thing
>> would be for the user to be in charge of adding the curly braces to the
>> squa
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a quest
7; is found for it...
In any case, I would no longer see it necessary to modify
org-latex-verse-block anymore.
Best regards,
Juan Manuel
oo] & 2\\[0pt]
> {[}bar] & 3\\[0pt]
> \end{tabular}
> \end{center}
>
> \begin{itemize}
> \item {[}bax]
> \item {[}aur]
> \end{itemize}
Great! Simple and effective. And more surgical than pandoc's global
solution. But now a question arises... Your code clearly solves the
problem that led to the declaration of org-latex-line-break-safe,
without foreseeing any unwanted effects, since it is the solution that
is usually recommended from LaTeX. So, if this code is included in Org,
what is the future of org-latex-line-break-safe?
Best regards,
Juan Manuel
1 - 100 of 983 matches
Mail list logo
