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, con
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
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ━━━
>> #+OPTIONS: ':t
>> #+language:es
>>
>> "my friends' party and the students' papers"
>> ━
trophe in the word 'ρθώ with second-level
opening quotes)
Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at least add some brief warning in the manual: in certain
contexts it is safer to use a explic
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
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
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
(?/ 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
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
>
> * ex
changes). With the new implementation, now:
- do not export
* export only the content
= rest (full)
=* rest (contents only)
backend- do not export this backend (and the backends derived from it)
backend+ (or, perhaps, just "backend") export this backend (idem)
backend* export this
"==" :: 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
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 different expect
.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 content)
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: (wrong-ty
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}" 'latex t))
=
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
(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 special pr
nippet).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
oint 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{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts:
>> &_{subscript}...
>>
>> Perhaps we should think about a structure le
m, right. And there may also be a problem with the subscripts:
&_{subscript}...
Perhaps we should think about a structure less prone to ambiguities. For
example:
&:type[attrs]{text} / &:_[attrs]{text}
(I think someone had suggested something like this in a past message,
but I can't find i
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
quot; :html-tag "b")("i" :html-tag "i"))
{intra}{word}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
xported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
n
the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct forma
nd the output format. So, how about
something like:
- Custom Export Fragment
- Custom Export Span
- Custom Export "Whatever"
- ...
?
(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).
--
-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
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
I think you're right. I have removed the need for "!" in the last
commit.
Now the syntax is:
{text}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
cta 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
n leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
> implementation complexity. It would be unfortunate if most of users
> will have to create custom backends ev
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 that my implementation leaves open the possibility
of extending it with
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
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?
Hi, Bastien,
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> AFAIU, Juan does not have write access to savannah.
>> Should we give it? Of course, if he is willing to use savannah. Any
>> other public repo is also fine.
>
> Juan, let me know if you need acce
t;, "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
Ihor Radchenko writes:
> P.S. Juan, I will need some time to review previous discussions on
> inline special blocks before I can comment on your work in depth.
No problem, Ihor. These days I had enough free time to develop my idea,
translate it into code and get something usable from
xample of Latin text with small caps:
{\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit
amet}}
HTML ==>
This is an example of Latin text: lorem ipsum dolor sit amet.
This is an example of Latin text with small caps: lorem
ipsum dolor sit amet.
Related: https://
m ipsum dolor}}
There can only be one alias per element, but an alias can be combined
with other attributes. It is the closest thing to using styles,
and perhaps the most appropriate term would be ":style". But you can get
confused with the html "style" attribute.
Best regards,
Ju
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:
>
> [prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
[optional parameters]{contents}
k, which is the only case of "inline block" that
we have in Org.
Best regards,
Juan Manuel
ype 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
[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: Juan Manuel Macias
Date: Wed,
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 methods fo
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
mat "\\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
at, 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,
Jua
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' will be obsolete
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
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
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 this befo
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
s the European Latin (T1-encoded) Fonts, while in their
upper half (128–255) they contain letters and symbols for African
languages that use extended Latin alphabets."
etc.
But I can't find a simpler list anywhere.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipo
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 appear in
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
> re
by a 'warning' string.
Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>F
rst solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inco
;, 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)))
>> +
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-proc
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 evaluating a given
mp; 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 fe1b40e2b22e2c668440bea13fed
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:
>>
>
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
acslife.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 Roge
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
of 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 datos, diseño
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
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{
il... 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
his 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
o
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 questio
case, I would no longer see it necessary to modify
org-latex-verse-block anymore.
Best regards,
Juan Manuel
gt; {[}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
ber of commands with an optional argument. For
example \pagebreak. Something like this will give an error:
lorem @@latex:\pagebreak@@ [ipsum]
\item is another typical example, but in this case org adds \relax.
Best regards,
Juan Manuel
cument with the [greek,german] option and (probably, in
the class you are loading) babel is already loaded as well.
Try:
#+LaTeX_Header: \PassOptionsToPackage{greek,german}{babel}
Best regards,
Juan Manuel
re preserved and exported as
> ;; `\vspace*{\baselineskip}', including the blank lines before
> ;; or after CONTENTS.
>
> We may as well strip the trailing \\[0pt] there.
I think it would be best to remove the last \\[0pt] in the verse block.
I can prepare a patch, but I'm afraid that org-latex-verse-block is
becoming an homage to replace-regexp-in-string...
Best regards,
Juan Manuel
1 - 100 of 968 matches
Mail list logo
