* Re: "Org" source blocks and minted
@ 2021-03-24 4:18 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-24 4:18 UTC (permalink / raw)
To: Michael Gauland; +Cc: orgmode
Hi Mike,
Michael Gauland <mikelygee@gmail.com> writes:
> I want to include an "org" source block in a document as an example,
> and have it formatted with minted. Unfortunately, minted doesn't seem
> to recognize "org" as a language,and the block is missing in the
> resulting PDF. For the moment, I've changed this to a "text" source
> block, but it would be nice to have syntax highlighting in the export.
>
> Have any of you done this, or something similar?
>
> Kind regards,
> Mike
>
You can write your own pygments lexer:
https://pygments.org/docs/lexerdevelopment
But it seems that someone already did the work of writing a lexer for
Org Mode:
https://github.com/or/pygments-orgmode-lexer
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Items with emphasis marks are not sorted properly in a list
2021-03-22 21:59 10% Items with emphasis marks are not sorted properly in a list Juan Manuel Macías
@ 2021-03-23 8:36 13% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-23 8:36 UTC (permalink / raw)
To: orgmode
Hello again:
I think I have found where the problem is. On line 7 of
`org-sort-remove-invisible' there are two spurious spaces (in the `format'
expression):
7 org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
When the spaces are removed, then the items with emphasis marks are
sorted correctly in the list:
7 org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
Can this be a fix? Or were those spaces there for any other reason?
Best regards,
Juan Manuel
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> Consider this list:
>
> - vol.
> - adj.
> - /circa/
> - /vid./
>
> If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list'
> doesn't sort correctly items that contain an emphasis mark:
>
> - /circa/
> - /vid./
> - adj.
> - vol.
>
> I don't know if there is any solution to this, or if I'm doing something wrong...
>
> Best regards,
>
> Juan Manuel
>
^ permalink raw reply [relevance 13%]
* Items with emphasis marks are not sorted properly in a list
@ 2021-03-22 21:59 10% Juan Manuel Macías
2021-03-23 8:36 13% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-22 21:59 UTC (permalink / raw)
To: orgmode
Hi,
Consider this list:
- vol.
- adj.
- /circa/
- /vid./
If I evaluate `(org-sort-list t ?a)', it seems that `org-sort-list'
doesn't sort correctly items that contain an emphasis mark:
- /circa/
- /vid./
- adj.
- vol.
I don't know if there is any solution to this, or if I'm doing something wrong...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-20 22:49 6% ` Samuel Wales
@ 2021-03-21 8:43 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-21 8:43 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Hi Samuel,
Samuel Wales <samologist@gmail.com> writes:
> i like that. such an org edit special type feature could efven in
> principle work for a column or a row all at once.
I like the idea of being able to edit rows or columns as well...
As I mentioned in a previous message, I made this rudimentary proof of
concept (only with cells):
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
The idea is that the content of the cell would be 'filled' while it is in
the edit buffer and, back to the cell, it would be a single line again.
Certain marks (in my sample it is a simple macro (nl = latex \newline)
would cause a line break in the edit buffer, to facilitate editing.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-18 22:41 10% ` Juan Manuel Macías
2021-03-19 8:08 5% ` tomas
@ 2021-03-20 22:49 6% ` Samuel Wales
2021-03-21 8:43 9% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Samuel Wales @ 2021-03-20 22:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Tim Cross, orgmode
i like that. such an org edit special type feature could efven in
principle work for a column or a row all at once.
On 3/18/21, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> From watching these discussions in the past, I think the big stumbling
>> block is how easily multi-row columns can be added and maintained in the
>> various export formats. Some are easy, like HTML, but others are less
>> so. In particular, I know from my many years working with Latex,
>> multi-row columns are not straight-forward. There are lots of edge cases
>> to deal with and it is hard to get a consistent result programatically.
>>
>> Proposals like this one can seem simple and straight-forward on the
>> surface. However, implementation is another matter. All of the exporters
>> will need to be updated to handle this new syntax and it will probably
>> take a fair bit of work to handle it correctly in just plain org files
>> (formatting, highlighting etc).
>
> I don't know if anyone has come up with this other possibility: if the
> problem is (usually) the inconvenience of editing cells with a lot of
> text within an Org document (since when exporting to LaTeX for example,
> it makes no difference whether the cell content is on a single line, if
> the tabularx package is used properly), then the possibility of editing
> a cell in a dedicated buffer would be very practical here. A kind of
> `org-edit-special' for cells... That could be combined with
> `org-table-toggle-column-width'.
>
> 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: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-20 10:40 8% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-20 10:40 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> It has also been stated that the Latex exporter won't be a problem as
> tabularx (and other Latex packages) will just handle this. Sadly, I
> don't think it is that simple. I have used that package a lot over the
> years and there have been times I've had to render tables with
> multiple columns and rows. While the various latex table like packages
> do provide a much better outcome for tables with more complex cell
> structure, it is rare that you don't need to do a fair amount of
> tweaking to actually get good looking complex tables. Handling a cell
> with a couple of lines may be fine, but it is very easy to hit the
> limits of what the package can handle without some tweaking. This is
> where I think things begin to fall down. My suspicion is that the
> amount of work needed to make the Latex exporter handle the majority
> of common use cases for this new syntax is much larger and more
> complex than it seems and getting this to work reliably and
> consistently will be extremely difficult.
tabularx does a fairly acceptable job out of the box on tables whose
cells have complex or 'multi-line' content, such as paragraphs. But,
naturally, it all depends on the context and scenarios: table, page
dimensions, book type and many more factors. The typography, when
demanding, is the art of exceptions. And I think this is valid even in
such an 'automated' tool like LaTeX (fortunately, LaTeX and TeX are also
very ductile, if you know the code well).
In any case, I agree that it would not be a good idea to translate the
LaTeX tabular environment, with all its nuances, to Org tables. In
addition to the fact that Org would be burdened with a unnecessary
complexity, is the fact that the syntax of both types of tables differ
essentially. Org tables have a more visual character; the tabular
environment is a pure "what you see is what you mean".
In a tabular environment I see no problem in writing something like
this row (ugly, but acceptable) in 3 lines:
#+begin_src latex
lorem & Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin
quam nisl, tincidunt et, mattis eget, convallis nec, purus & ipsum \\
#+end_src
But in an Org table I don't see how it could be done without messing up
the spirit of its syntax ... that's why I think (IMHO) the least
traumatic option, in cases where cells have 'a lot of content', is the
possibility of edit cells in a dedicated buffer, like this proof of
concept that I did:
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
And if the table is very complex then I don't see any other option than
writing directly the LaTeX code (in case the intended target is only
LaTeX/PDF).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 13:43 6% ` tomas
@ 2021-03-19 15:07 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-19 15:07 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> [...] My point was that it probably makes sense to separate concerns
> here.
Yes, that separation is essential. I agree.
> That's right. OTOH, people will try to stretch it in every conceivable
> direction. That's in a way Org's biggest strength (and at the same time
> its biggest weakness :)
Great truth! I always try to take things to the extreme :-D, and I
continue thinking that Org is (among many other things) an excellent
'interface' for LaTeX (maybe the best). But I have to admit that a table
with a lot of complexity is a special case when maybe you have to write
LaTeX code, and get lost between all those & and backslashes, at least
if the goal is the typographic refinement. The greatest power of Org
resides in his lightness and in its chameleon versatility, but his worst
temptation may be to become in a (poor) LaTeX 'translation'.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 10:53 9% ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
@ 2021-03-19 13:43 6% ` tomas
2021-03-19 15:07 9% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: tomas @ 2021-03-19 13:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
On Fri, Mar 19, 2021 at 11:53:14AM +0100, Juan Manuel Macías wrote:
> tomas@tuxteam.de writes:
>
> > For export formats, there could be (yet another) "signal" to convey
> > "new paragraph here" which then is the exporter's job. Perhaps an
> > empty line (as is traditional in TeX) or something else.
>
> I think that signal would be a good solution within a single line. For
> example, for an emergency a simple macro would suffice, something as:
>
> #+MACRO: par @@latex:\par{}@@
Yes, something like that. My point was that it probably makes sense to
separate concerns here.
> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ...
That's right. OTOH, people will try to stretch it in every conceivable
direction. That's in a way Org's biggest strength (and at the same time
its biggest weakness :)
> LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end [...]
Rigth. (La)TeX is a typesetting language. Cool things can be done,
but they have a cost.
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 10:53 9% ` Juan Manuel Macías
@ 2021-03-19 11:08 12% ` Juan Manuel Macías
2021-03-19 13:43 6% ` tomas
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-19 11:08 UTC (permalink / raw)
To: tomas; +Cc: orgmode
* sorry for the typo. I meant "...n columns x n rows..."
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ... LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end. Org tables are visual (close to the WYSIWYG concept),
> which is why they are wonderful when it comes to mere data tables (and n
> files x n rows). The LaTeX tabular environment is crude, it is not
> 'visual' (except for the facilities provided by the editor), and when
> the table becomes large and complex it can be a torture working in
> there... So perhaps (IMHO) the solution to edit a cell in a dedicated
> buffer could be the least traumatic in complex cells, in case one wants
> to avoid going crazy by editing this kind of huge and literary tables in
> LaTeX ;-)
^ permalink raw reply [relevance 12%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 10:14 6% ` tomas
@ 2021-03-19 10:53 9% ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
2021-03-19 13:43 6% ` tomas
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-19 10:53 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> For export formats, there could be (yet another) "signal" to convey
> "new paragraph here" which then is the exporter's job. Perhaps an
> empty line (as is traditional in TeX) or something else.
I think that signal would be a good solution within a single line. For
example, for an emergency a simple macro would suffice, something as:
#+MACRO: par @@latex:\par{}@@
Anyway, I suspect that Org tables are not originally intended for such a
'literary' content :-) ... LaTeX tabular(x) environment and Org tables
have in common that they are plain text, but that’s where the
similarities end. Org tables are visual (close to the WYSIWYG concept),
which is why they are wonderful when it comes to mere data tables (and n
files x n rows). The LaTeX tabular environment is crude, it is not
'visual' (except for the facilities provided by the editor), and when
the table becomes large and complex it can be a torture working in
there... So perhaps (IMHO) the solution to edit a cell in a dedicated
buffer could be the least traumatic in complex cells, in case one wants
to avoid going crazy by editing this kind of huge and literary tables in
LaTeX ;-)
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 9:22 9% ` Juan Manuel Macías
@ 2021-03-19 10:14 6% ` tomas
2021-03-19 10:53 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: tomas @ 2021-03-19 10:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Fri, Mar 19, 2021 at 10:22:20AM +0100, Juan Manuel Macías wrote:
> tomas@tuxteam.de writes:
>
> > My post was rather a warning that "multi-line" will mean
> > different things to different people.
>
> Yes I agree. It is not the same as how a table is represented in Org and
> how it should be rendered when exported to some typographic format like
> (let's say) LaTeX [...]
Exactly :-)
> The problem here (IMHO) is a problem of discomfort of edit within Org,
> when the cell has a lot of text and when we are under the 'tyranny' of
> the single line.
I understood that this is your focus. And it's IMHO a good idea to
separate things and solve one at a time.
For export formats, there could be (yet another) "signal" to convey
"new paragraph here" which then is the exporter's job. Perhaps an
empty line (as is traditional in TeX) or something else.
But that's another building site :)
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 8:53 5% ` tomas
@ 2021-03-19 9:22 9% ` Juan Manuel Macías
2021-03-19 10:14 6% ` tomas
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-19 9:22 UTC (permalink / raw)
To: tomas; +Cc: orgmode
tomas@tuxteam.de writes:
> My post was rather a warning that "multi-line" will mean
> different things to different people.
Yes I agree. It is not the same as how a table is represented in Org and
how it should be rendered when exported to some typographic format like
(let's say) LaTeX. I think also 'multi-line' is a very imprecise concept
for Org tables. If we are talking about a cell whose content is a
paragraph, then for LaTeX it is no problem, with the help of the
tabularx package (in these contexts it is the best solution).
The problem here (IMHO) is a problem of discomfort of edit within Org,
when the cell has a lot of text and when we are under the 'tyranny' of
the single line. Luckily it is not a very extended issue, and the tables
in Org are much easier to view and edit than in LaTeX code, when it
comes to simple cells. What happens is that the LaTeX's `tabular(x)'
environment encompasses many more (typographic) contexts than the
concept of `table' in Org. It is a translation problem between Org and
LaTeX and vice versa...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 8:44 10% ` Juan Manuel Macías
@ 2021-03-19 8:53 5% ` tomas
2021-03-19 9:22 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: tomas @ 2021-03-19 8:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
On Fri, Mar 19, 2021 at 09:44:48AM +0100, Juan Manuel Macías wrote:
> Hi Tomas,
[...]
> I was writing yesterday some rudimentary code (just a proof of concept)
> and I've made this screencast:
>
> https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
Looks nice. And for a heavy table user, it might be useful.
It seems you are in the "table row is a big unstructured text" camp.
For my case, as I said, I'm not a heavy table user anyway.
Opening another window is (to me, at least) so disruptive
that I'd be motivated to find alternatives (I very rarely
use C-c ', org-edit-special for source blocks for the same
reason).
But I can envision people needing that badly.
My post was rather a warning that "multi-line" will mean
different things to different people.
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-19 8:08 5% ` tomas
@ 2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-19 8:53 5% ` tomas
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-19 8:44 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hi Tomas,
<tomas@tuxteam.de> writes:
> If the aim is "just rendering in Org" and "breaks have no special
> meaning" (so each render is allowed to re-flow), then your approach
> makes sense (I think Org table has something like that: you can
> set the column width and shrink/expand the column appropriately.
> Personally, I've found that somewhat awkward, so I don't use it,
> but OTOH I'm not a heavy table user: perhaps that's why).
I was writing yesterday some rudimentary code (just a proof of concept)
and I've made this screencast:
https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
2021-03-18 22:41 10% ` Juan Manuel Macías
@ 2021-03-19 8:08 5% ` tomas
2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-20 22:49 6% ` Samuel Wales
1 sibling, 1 reply; 144+ results
From: tomas @ 2021-03-19 8:08 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
On Thu, Mar 18, 2021 at 11:41:11PM +0100, Juan Manuel Macías wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
> > From watching these discussions in the past, I think the big stumbling
> > block is how easily multi-row columns can be added and maintained in the
> > various export formats [...]
> I don't know if anyone has come up with this other possibility: if the
> problem is (usually) the inconvenience of editing cells with a lot of
> text within an Org document (since when exporting to LaTeX [...]
I think this point is very important: "multi-row" is ambiguous.
Does it mean the rendering in Org? In someother output format? Are the
row breaks chosen by the user (and thus they have /some/ "meaning") or
are they chosen by some rendering mechanism (word wrap, perhaps
hyphenation)?
> the possibility of editing a cell in a dedicated buffer would be very
> practical here.
If the aim is "just rendering in Org" and "breaks have no special
meaning" (so each render is allowed to re-flow), then your approach
makes sense (I think Org table has something like that: you can
set the column width and shrink/expand the column appropriately.
Personally, I've found that somewhat awkward, so I don't use it,
but OTOH I'm not a heavy table user: perhaps that's why).
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-18 22:41 10% ` Juan Manuel Macías
2021-03-19 8:08 5% ` tomas
2021-03-20 22:49 6% ` Samuel Wales
1 sibling, 2 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-18 22:41 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> From watching these discussions in the past, I think the big stumbling
> block is how easily multi-row columns can be added and maintained in the
> various export formats. Some are easy, like HTML, but others are less
> so. In particular, I know from my many years working with Latex,
> multi-row columns are not straight-forward. There are lots of edge cases
> to deal with and it is hard to get a consistent result programatically.
>
> Proposals like this one can seem simple and straight-forward on the
> surface. However, implementation is another matter. All of the exporters
> will need to be updated to handle this new syntax and it will probably
> take a fair bit of work to handle it correctly in just plain org files
> (formatting, highlighting etc).
I don't know if anyone has come up with this other possibility: if the
problem is (usually) the inconvenience of editing cells with a lot of
text within an Org document (since when exporting to LaTeX for example,
it makes no difference whether the cell content is on a single line, if
the tabularx package is used properly), then the possibility of editing
a cell in a dedicated buffer would be very practical here. A kind of
`org-edit-special' for cells... That could be combined with
`org-table-toggle-column-width'.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-18 15:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-18 15:15 UTC (permalink / raw)
To: Atlas Cove; +Cc: orgmode
Atlas Cove <Atlas48@gmx.com> writes:
> In effect, yes. I'm proposing it as a syntax addition to make it easier to read, export, and manage, larger tables.
> I'm unsure if this would fit within the scope of org, but [[https://github.com/RedBug312/markdown-it-multimd-table][other projects]],
> like [[https://fletcher.github.io/MultiMarkdown-6/MMD_Users_Guide.html#tables][MultiMarkdown]] have exactly what I want in terms of table use.
> Since I've already proposed a single, solitary addition to org, we won't discuss all of those nice features /just/ yet!
Thanks for your clarification. I strongly support your proposal.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping
@ 2021-03-17 22:07 9% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-17 22:07 UTC (permalink / raw)
To: Atlas Cove; +Cc: orgmode
Hi,
Atlas Cove <Atlas48@gmx.com> writes:
> Code-wise, the use of the '\\' symbol is only tentative, as I
> understand that '\' has special meaning elsewhere in org's syntax, (I
> was even going to submit a patch to add two special symbols somewhere
> down the line). '\\' (or whatever symbol is decided on) would cause
> the org parser to concatenate the next line into the outputted
> previous cell, rendering the output of the first example identical to
> the second example.
I agree that what you are commenting on is the great problem of Org Mode
tables. Just a question. If I have understood it correctly, with this
new syntax you propose, should Org understand all the 'concatenated
text'
Very Citrusy! Very \\
nice indeed!
as a single row (and not as multiple rows)? If so that would be
great, since the best way to deal with this kind of tables with a lot of
text in LaTeX is with the tabularx package. For example, I would export
your table like this:
#+begin_src org
,#+LaTeX_Header:\usepackage{tabularx,array}
,#+ATTR_LaTeX: :environment tabularx :align l>{\raggedright\arraybackslash}Xl :width .6\textwidth :center t
| Name | Description | Price |
|--------------+-------------------------------------------------------+-------|
| Orange Juice | Very Citrusy! Very nice indeed! ... and a lot of text | 5.00 |
| Grape Juice | It's like wine, but you can have it all day! | 6.00 |
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Nested macros and fontification
@ 2021-03-15 17:10 9% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-15 17:10 UTC (permalink / raw)
To: orgmode
Hi,
I make heavy use of replacement macros, and often my Org documents are
full of nested macros (in the 'LaTeX way') throughout the text. The
problem is that `org-fontify-macros' breaks the macro fontification when
it is a nested construction.
I've found a simple high level solution that consists in ensuring that the
macros have a look identical to normal text (in my theme):
(set-face-attribute org-macro nil :bold nil :foreground black)
And then I only highlight the macro boundaries with `highlight-regexp'. I
think that this gives me a more legible and consistent text, without
that 'rainbow effect' that many themes apply to macros. I share a couple
of samples, in case this little solution is helpful to someone who also
uses a lot of (nested) replacement macros:
https://imgur.com/a/fSPHH0w
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org as a book publisher
2021-03-07 16:03 8% ` Juan Manuel Macías
@ 2021-03-08 10:46 6% ` Jonathan McHugh
0 siblings, 0 replies; 144+ results
From: Jonathan McHugh @ 2021-03-08 10:46 UTC (permalink / raw)
To: emacs-orgmode
To build on your analogy, would Tikz be the Graphics Designer?
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Diego,
>
> Thank you very much for your comments.
>
> Diego Zamboni <diego@zzamboni.org> writes:
>
>> I think with Org and a setup like you describe, we are one step closer
>> to separating content (what) from form (how) in a document. This was
>> one of the original goals of LaTeX, but of course in a LaTeX document
>> much of the "how" is still visible through the "what". With Org the
>> separation becomes clearer, by hiding the LaTeX structures (almost)
>> completely, and by allowing to produce multiple formats from the same
>> source document.
>
> I Totally agree. Leslie Lamport originally created LaTeX (as far as I
> know) as a simplified way of handling TeX for his own documents, since
> the other format of TeX, plainTeX, was quite spartan. Then LaTeX has
> grown incredibly thanks to its extensibility qualities: a small kernel
> (unlike ConTeXt, which is more monolithic) and a ecosystem of macro
> packages. If we make an analogy with the old days of mechanical
> printing, I always say that TeX is the typographer, the one who gets his
> hands dirty with ink, while LaTeX wears a tie and is in the editorial
> design department. TeX works on the merely physical plane, and he is
> only interested in how each element on the page is positioned in
> relation to other elements. Here the minimum indivisible element would
> be the letter, which to TeX's eyes is a box with certain dimensions.
> LaTeX lives more on a semantic plane: for LaTeX there is no lines or
> letters or paragraphs, but rather headings, heading levels, lists,
> quotes, verses, chapters, tables, equations, tables of contents... But,
> as you say, in LaTeX you can still see too many gears. With Org we can
> work on a lighter and cleaner document. And with a single source for
> multiple formats!
>
> Before moving to Org, I applied this `philosophy' to the markdown/pandoc
> tandem. But since I migrated to Emacs/Org a few years ago, it's almost
> like having superpowers :-D
>
> Best regards,
>
> Juan Manuel
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 6%]
* Re: Org as a book publisher
[not found] ` <87ft16hn62.fsf@emailmessageidheader.nil>
@ 2021-03-07 20:20 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-07 20:20 UTC (permalink / raw)
To: Bob Newell; +Cc: orgmode
Hi Bob, thank you for your comment.
Bob Newell <bobnewell@bobnewell.net> writes:
> Aloha,
>
> Thank you for your interesting and useful post.
>
> I must really look into your examples and process. I have
> published quite a number of books with LaTeX but my process
> has been to write in org-mode, then export, and do all the
> design and typesetting directly in LaTeX. I end up with a good
> result but I would really rather work more in org-mode.
>
> Layouts require a lot of fine-tuning, particularly complex
> layouts with multiple columns. If some or most of that could
> be accomplished in org-mode, it would be a great benefit.
Multiple column layout, for example, can be achieved from Org with a
special block (and loading the multicol package). For example:
#+LaTeX_Header: \usepackage{multicol}
#+ATTR_LaTeX: :options {2}
#+begin_multicols
...
#+end_multicols
As I mentioned in a previous message, I have to organize and clean all
the code in those two books of my samples, and upload it to GitLab, in
case it could be useful to someone...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org as a book publisher
@ 2021-03-07 18:30 8% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-07 18:30 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: orgmode
Hi Arne,
Thank you very much for sharing the code of your book. It seems very
interesting, I have to take a closer look at it. I want to upload to
GitLab all the code of those two books of my samples, but I need to
rearrange it before, as most of that code is in Spanish :-)
But, broadly speaking, my workflow (especially in these books that are
so long) consists of using Org Publish and compiling everything at the
end with the latexmk script. Each part of the book (chapters, or letters
in the case of the dictionary) are Org documents. And then I have
another Org document which works as a master document (which is the one
I compile in the end with latexmk; the rest of the documents are
exported to * .tex using org-publish, and I automate all that process
through a function in Elisp). I have also another Org document just for
the preamble and my LaTeX code (which is tangled to a tex file), another
document only with the Elisp code involved in the process of the books
(export filters) and, finally, a .setup file. I also add a * .xdy file,
since I use xindy for the index, instead of makeindex. The xdy file is
in Common Lisp, and unfortunately I don't have much knowledge of CL,
but I manage for a few adjustments.
Of course, some Emacs packages are very useful to me too, like the
excellent Org-Ref, Magit or Projectile.
Best regards,
Juan Manuel
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> Hi Juan,
>
> I’ve been going that route for a few years now, and I setup an autotools
> pipeline with all the little tweaks and hacks I needed to make
> everything work well together.
>
> I’m using LaTeX (pdflatex), scribus, calibre and imagemagick to publish
> a roleplaying book with charactersheet,
>
> Maybe some of it can help you. The entrypoints are the Makefile, the
> setup, and the configure.ac (for the hacks):
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/Makefile.am
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/basesetup.tex
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews30setup.tex
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews30setup.el
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/configure.ac
>
> The main document is
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews.org
>
> I also have some derived documents that use the included tables as data.
> Most complex example:
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in
>
>
> Best wishes,
> Arne
^ permalink raw reply [relevance 8%]
* Re: Org as a book publisher
2021-03-07 12:08 6% ` Diego Zamboni
2021-03-07 13:15 0% ` Vikas Rawal
@ 2021-03-07 16:03 8% ` Juan Manuel Macías
2021-03-08 10:46 6% ` Jonathan McHugh
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-07 16:03 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hi Diego,
Thank you very much for your comments.
Diego Zamboni <diego@zzamboni.org> writes:
> I think with Org and a setup like you describe, we are one step closer
> to separating content (what) from form (how) in a document. This was
> one of the original goals of LaTeX, but of course in a LaTeX document
> much of the "how" is still visible through the "what". With Org the
> separation becomes clearer, by hiding the LaTeX structures (almost)
> completely, and by allowing to produce multiple formats from the same
> source document.
I Totally agree. Leslie Lamport originally created LaTeX (as far as I
know) as a simplified way of handling TeX for his own documents, since
the other format of TeX, plainTeX, was quite spartan. Then LaTeX has
grown incredibly thanks to its extensibility qualities: a small kernel
(unlike ConTeXt, which is more monolithic) and a ecosystem of macro
packages. If we make an analogy with the old days of mechanical
printing, I always say that TeX is the typographer, the one who gets his
hands dirty with ink, while LaTeX wears a tie and is in the editorial
design department. TeX works on the merely physical plane, and he is
only interested in how each element on the page is positioned in
relation to other elements. Here the minimum indivisible element would
be the letter, which to TeX's eyes is a box with certain dimensions.
LaTeX lives more on a semantic plane: for LaTeX there is no lines or
letters or paragraphs, but rather headings, heading levels, lists,
quotes, verses, chapters, tables, equations, tables of contents... But,
as you say, in LaTeX you can still see too many gears. With Org we can
work on a lighter and cleaner document. And with a single source for
multiple formats!
Before moving to Org, I applied this `philosophy' to the markdown/pandoc
tandem. But since I migrated to Emacs/Org a few years ago, it's almost
like having superpowers :-D
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Org as a book publisher
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
@ 2021-03-07 15:57 6% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-07 15:57 UTC (permalink / raw)
To: M. ‘quintus’ Gülker; +Cc: orgmode
Hi Quintus:
Thank you very much for your comments.
M. ‘quintus’ Gülker <post+orgmodeml@guelker.eu> writes:
> [...] Many people seem to use org rather than direct LaTeX because they
> dislike LaTeX's syntax or find LaTeX too complex, which I never really
> understood. But you make some great points for why this combination is
> useful other than for that reason.
I think Org does a good job with what it offers out of the box for
`simple' documents, when the user also does not have a special interest
in LaTeX code and typographic `refinement'. But as the document becomes
more and more complex, there is a duty to study LaTeX and learn to write
code in LaTeX (even in pure TeX, if things get too demanding); and also
to study the documentation of the packages involved, because the great
power of LaTeX lies in its rich and extensive package ecosystem (two or
three new packages always appear every week!). If Org was a complete
translation of everything that each LaTeX package is capable of, then
Org would become as (needlessly) complex as LaTeX. The good thing about
Org is that it provides us with the tools needed to work with our LaTeX
code in the background. A simple example that comes to me now are the
lists, which in LaTeX can be managed in a very clean way with packages
like enumitem. In an Org document it would then be enough to put before
a list `#+ATTR_LaTeX: :options [enumitem options]' (or to write a
replacement macro), but of course the user have to read the enumitem
documentation...
(By the way, it seems that a fellow 'co-lister' is working on an Org to
Context exporter: https://github.com/Jason-S-Ross/ox-context/)
> For those who still use pdfLaTeX rather than LuaLaTeX (probably due to
> Microtype) there is not even an equivalent available.
Well, Microtype can already be used in LuaLaTeX. Except for a few minor
limitations, protrusion and expansion properties work well. In fact I
recently wrote a custom table of protrusion values for a font, and
microtype reads them perfectly in LuaLaTeX. In general nowadays the
migration from pdfTeX to LuaTeX is quite smooth, and it is worth it, for
various reasons: for example, there are a few cool new packages that
take advantage of LuaTeX. And there is also the LuaTeX ability to use
otf fonts and manage opentypes features. XeTeX can do that too, but
with LuaTeX we can even define new otf features on the fly, in Lua, for
a document (like kerning, contextual substitution, etc.) and apply them
to a certain font, without need to edit that font with a dedicated
software (fontforge).
But yeah, for pre-/post-process control I prefer Elisp/Org a thousand
times over Lua :-) Recently I needed to modify certain combining
diacritical marks only in the italics, and with Org it's a delight to do
that (writing a filter for org-export-filter-italic-functions)
> [...] May I ask what tooling you use to go from org to Epub?
Ox-epub works reasonably well, in my short experience: I'm afraid I
haven't explored the Epub output much, partly because this is a format
that I do not like, and I have used it for editorial requirements only.
And, in fact, it is a very limited format for certain types of books.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Org as a book publisher
2021-03-07 12:08 6% ` Diego Zamboni
@ 2021-03-07 13:15 0% ` Vikas Rawal
2021-03-07 16:03 8% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Vikas Rawal @ 2021-03-07 13:15 UTC (permalink / raw)
To: Diego Zamboni; +Cc: Juan Manuel Macías, orgmode
A few years ago, I had produced this book entirely on orgmode: https://cup.columbia.edu/book/ending-malnutrition/9789382381648. The source files of the book are here: https://github.com/vikasrawal/endingmalnutrition.
This was some years back, and there has been some change in the org mode syntax since then and the files would need some fixing before they could be compiled with the current versions of orgmode.
Vikas
On Sun, Mar 07, 2021 at 01:08:20PM +0100, Diego Zamboni wrote:
> Hi Juan Manuel,
>
> Thanks for sharing this - the output looks very nice.
>
> I think with Org and a setup like you describe, we are one step closer to
> separating content (what) from form (how) in a document. This was one of
> the original goals of LaTeX, but of course in a LaTeX document much of the
> "how" is still visible through the "what". With Org the separation becomes
> clearer, by hiding the LaTeX structures (almost) completely, and by
> allowing to produce multiple formats from the same source document.
>
> I have done something similar with my books, which I publish through
> Leanpub. I keep the source of each book in Org, and from there the exporter
> takes care of producing the Leanpub markup and format, which in turn takes
> care of converting it to PDF, ePub or other formats.
>
> Best,
> --Diego
>
>
>
> On Sat, Mar 6, 2021 at 8:35 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
> > Hi,
> >
> > I would like to share here two samples of one of the most intense uses
> > that I give Org Mode: for typesetting, layout and editorial design. In
> > other words, I use Org (and Org-Publish) where publishers today use DTP
> > proprietary software like InDesign or QuarkXpress (a type of software,
> > on the other hand, that was never intended to compose books but rather
> > magazines, posters, brochures and so on). The samples are from a book
> > on classical philology, recently published here in Spain, and from a
> > fairly extensive dictionary, still work in progress:
> >
> > https://imgur.com/gallery/yxAVkrY
> >
> > Naturally, what acts in the background here is TeX and LaTeX
> > (specifically Lua(La)TeX), so what I really do is use Org and
> > Org-Publish as a sort of high-level interface for LaTeX. But I don't
> > mean to avoid LaTeX: in fact, I've been working with LaTeX for a long
> > time. I like LaTeX and behind these jobs there is a lot of LaTeX code.
> > But Org gives me a much more light and productive workflow, allowing me
> > to work at two levels.
> >
> > The main advantages that I see for this workflow with Org/Org-Publish
> > are:
> >
> > 1. Lightness: LaTeX is too verbose.
> > 2. Control of the composition process at various points. One of the
> > qualities of LuaTeX is the possibility to control TeX primitives
> > through scripts in Lua, and to act at various points in the pre- or
> > post-process. But I have realized that with the happy fusion of Elisp
> > and Org we can be much more precise and "surgical" ;-). Here,
> > Org/LaTeX is much more powerful than LuaLaTeX.
> > 3. Org's synaptic and org-anizational ability to control and manage the
> > entire process of the creation of a book, from when the originals are
> > received until everything is prepared to send to the printer.
> > 4. An unique origin. The book can be produced on paper from a single
> > source, but you can also export, from that source consistently, to
> > other formats (HTML or Epub).
> >
> > Best regards,
> >
> > Juan Manuel
> >
> >
^ permalink raw reply [relevance 0%]
* Re: Org as a book publisher
2021-03-06 19:34 7% Org as a book publisher Juan Manuel Macías
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
@ 2021-03-07 12:08 6% ` Diego Zamboni
2021-03-07 13:15 0% ` Vikas Rawal
2021-03-07 16:03 8% ` Juan Manuel Macías
[not found] ` <87ft16hn62.fsf@emailmessageidheader.nil>
3 siblings, 2 replies; 144+ results
From: Diego Zamboni @ 2021-03-07 12:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
Hi Juan Manuel,
Thanks for sharing this - the output looks very nice.
I think with Org and a setup like you describe, we are one step closer to
separating content (what) from form (how) in a document. This was one of
the original goals of LaTeX, but of course in a LaTeX document much of the
"how" is still visible through the "what". With Org the separation becomes
clearer, by hiding the LaTeX structures (almost) completely, and by
allowing to produce multiple formats from the same source document.
I have done something similar with my books, which I publish through
Leanpub. I keep the source of each book in Org, and from there the exporter
takes care of producing the Leanpub markup and format, which in turn takes
care of converting it to PDF, ePub or other formats.
Best,
--Diego
On Sat, Mar 6, 2021 at 8:35 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I would like to share here two samples of one of the most intense uses
> that I give Org Mode: for typesetting, layout and editorial design. In
> other words, I use Org (and Org-Publish) where publishers today use DTP
> proprietary software like InDesign or QuarkXpress (a type of software,
> on the other hand, that was never intended to compose books but rather
> magazines, posters, brochures and so on). The samples are from a book
> on classical philology, recently published here in Spain, and from a
> fairly extensive dictionary, still work in progress:
>
> https://imgur.com/gallery/yxAVkrY
>
> Naturally, what acts in the background here is TeX and LaTeX
> (specifically Lua(La)TeX), so what I really do is use Org and
> Org-Publish as a sort of high-level interface for LaTeX. But I don't
> mean to avoid LaTeX: in fact, I've been working with LaTeX for a long
> time. I like LaTeX and behind these jobs there is a lot of LaTeX code.
> But Org gives me a much more light and productive workflow, allowing me
> to work at two levels.
>
> The main advantages that I see for this workflow with Org/Org-Publish
> are:
>
> 1. Lightness: LaTeX is too verbose.
> 2. Control of the composition process at various points. One of the
> qualities of LuaTeX is the possibility to control TeX primitives
> through scripts in Lua, and to act at various points in the pre- or
> post-process. But I have realized that with the happy fusion of Elisp
> and Org we can be much more precise and "surgical" ;-). Here,
> Org/LaTeX is much more powerful than LuaLaTeX.
> 3. Org's synaptic and org-anizational ability to control and manage the
> entire process of the creation of a book, from when the originals are
> received until everything is prepared to send to the printer.
> 4. An unique origin. The book can be produced on paper from a single
> source, but you can also export, from that source consistently, to
> other formats (HTML or Epub).
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 3585 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org as a book publisher
2021-03-06 19:34 7% Org as a book publisher Juan Manuel Macías
@ 2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
2021-03-07 15:57 6% ` Juan Manuel Macías
2021-03-07 12:08 6% ` Diego Zamboni
` (2 subsequent siblings)
3 siblings, 1 reply; 144+ results
From: M. ‘quintus’ Gülker @ 2021-03-07 9:17 UTC (permalink / raw)
To: emacs-orgmode
Am 06. März 2021 um 20:34 Uhr +0100 schrieb Juan Manuel Macías:
> I would like to share here two samples of one of the most intense
> uses that I give Org Mode: for typesetting, layout and editorial
> design. [...] The samples are from a book on classical philology,
> recently published here in Spain [...]. Naturally, what acts in the
> background here is TeX and LaTeX (specifically Lua(La)TeX), so what
> I really do is use Org and Org-Publish as a sort of high-level
> interface for LaTeX. But I don't mean to avoid LaTeX: in fact, I've
> been working with LaTeX for a long time. I like LaTeX and behind
> these jobs there is a lot of LaTeX code. But Org gives me a much
> more light and productive workflow, allowing me to work at two
> levels.
Thank you very much for sharing. This is an interesting insight. Many
people seem to use org rather than direct LaTeX because they dislike
LaTeX's syntax or find LaTeX too complex, which I never really
understood. But you make some great points for why this combination is
useful other than for that reason.
> 2. Control of the composition process at various points. One of the
> qualities of LuaTeX is the possibility to control TeX primitives
> through scripts in Lua, and to act at various points in the pre- or
> post-process. But I have realized that with the happy fusion of Elisp
> and Org we can be much more precise and "surgical" ;-). Here,
> Org/LaTeX is much more powerful than LuaLaTeX.
For those who still use pdfLaTeX rather than LuaLaTeX (probably due to
Microtype) there is not even an equivalent available.
> 4. An unique origin. The book can be produced on paper from a single
> source, but you can also export, from that source consistently, to
> other formats (HTML or Epub).
This is actually a strong argument. Even though I enjoy writing LaTeX
code, this one is a tough nut to crack with pure LaTeX, where I
achieved the best results with LaTeXML, but it was still lots of work.
May I ask what tooling you use to go from org to Epub?
-quintus
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | For security:
Passau, Germany | kontakt@guelker.eu | () Avoid HTML e-mail
European Union | PGP: see homepage | /\ http://asciiribbon.org
^ permalink raw reply [relevance 5%]
* Org as a book publisher
@ 2021-03-06 19:34 7% Juan Manuel Macías
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
` (3 more replies)
0 siblings, 4 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-06 19:34 UTC (permalink / raw)
To: orgmode
Hi,
I would like to share here two samples of one of the most intense uses
that I give Org Mode: for typesetting, layout and editorial design. In
other words, I use Org (and Org-Publish) where publishers today use DTP
proprietary software like InDesign or QuarkXpress (a type of software,
on the other hand, that was never intended to compose books but rather
magazines, posters, brochures and so on). The samples are from a book
on classical philology, recently published here in Spain, and from a
fairly extensive dictionary, still work in progress:
https://imgur.com/gallery/yxAVkrY
Naturally, what acts in the background here is TeX and LaTeX
(specifically Lua(La)TeX), so what I really do is use Org and
Org-Publish as a sort of high-level interface for LaTeX. But I don't
mean to avoid LaTeX: in fact, I've been working with LaTeX for a long
time. I like LaTeX and behind these jobs there is a lot of LaTeX code.
But Org gives me a much more light and productive workflow, allowing me
to work at two levels.
The main advantages that I see for this workflow with Org/Org-Publish
are:
1. Lightness: LaTeX is too verbose.
2. Control of the composition process at various points. One of the
qualities of LuaTeX is the possibility to control TeX primitives
through scripts in Lua, and to act at various points in the pre- or
post-process. But I have realized that with the happy fusion of Elisp
and Org we can be much more precise and "surgical" ;-). Here,
Org/LaTeX is much more powerful than LuaLaTeX.
3. Org's synaptic and org-anizational ability to control and manage the
entire process of the creation of a book, from when the originals are
received until everything is prepared to send to the printer.
4. An unique origin. The book can be produced on paper from a single
source, but you can also export, from that source consistently, to
other formats (HTML or Epub).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
2021-03-03 16:11 9% ` Juan Manuel Macías
@ 2021-03-05 13:02 4% ` Maxim Nikulin
0 siblings, 0 replies; 144+ results
From: Maxim Nikulin @ 2021-03-05 13:02 UTC (permalink / raw)
To: emacs-orgmode
On 03/03/2021 23:11, Juan Manuel Macías wrote:
> Maxim Nikulin writes:
>>
>> Please, do not forget to pass stings coming from user input through
>> shell-quote-argument.
>
> So, maybe it would look better like this (`start-process' instead of
> `start-process-shell-command')?:
My intention was just to warn you against of opening a door
to shell injections.
Personally, as a workaround I would add an org-file-apps entry with
a single argument combining page and search string and would write
a tiny script that splits such argument and invokes the viewer.
I consider it as a better option in the sense of forward compatibility
since it allows to avoid custom link types. I expect that the bug
will be fixed soon.
I still suppose that it is serious limitation that such link format
does not support named link targets inside PDF files. Maybe the part
before second "::" could be considered as a named target
if it does not look like a number. I am unsure concerning search
strings containing "::", they may require more accurate regexp
or using e.g. percent encoding as in URLs.
> #+begin_src emacs-lisp
> (org-link-set-parameters
> "pdf-pag"
> :follow (lambda (path)
> (let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
> (format "--page=%s" (match-string 1 path))
> (error "no pages")))
> (clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
> (str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
> (format "--find=%s" (match-string 2 path)))))
> (if str
> (start-process "zathura" nil "/usr/bin/zathura"
> clean-path
> pag
> str)
> (start-process "zathura" nil "/usr/bin/zathura"
> clean-path
> pag)))))
> #+end_src
If your are asking my opinion on your function, I think that the
variant with start-process is a better one. There is a low level
alternative make-process but it requires more code, so it is less
convenient. As to the style of lisp code, I am not a proper
person to make suggestions.
I suspect that your function has a problem with page numbers like 10.
I do not like repetition of the regexp and tend to think that minor
variations are unintended. On the other hand a variant I could offer
is not shorter despite just one regexp and just one call of a
match function.
#+begin_src elisp
(defun wa-pdf-destination-zathura-args (target)
(let ((suffix (string-match
"::\\(?:\\([0-9]+\\)?\\(?:::\\(.+\\)\\)?\\|\\(.*\\)\\)$"
target)))
(if (not suffix)
(list (expand-file-name target))
(let* ((invalid (match-string 3 target))
(file (cond
((zerop suffix) (error "No file path in '%s'" target))
(invalid (error "Invalid destination within file: '%s'"
invalid))
(t (substring target 0 suffix))))
(page (match-string 1 target))
(search (match-string 2 target)))
(seq-remove #'null
(list (and page "--page") page
(and search "--find") search
(expand-file-name file)))))))
(defun wa-launch-pdf-viewer (target)
(let ((viewer "zathura")
(command (wa-pdf-destination-zathura-args target))
;; Do not allocate a pty. Really required only if the application
;; spawns background children and exits (xdg-open, gio open,
;; kde-open5), see Emacs Bug #44824.
(process-connection-type nil))
(apply #'start-process viewer "*Messages*" viewer command)))
#+end_src
#+begin_src elisp :results value list
(mapcar #'wa-pdf-destination-zathura-args
'(
"~/Download/grub.pdf::95::do"
"file.pdf::95"
"file.pdf::::do"
"file.pdf"
;; "::"
;; "::95"
;; "file.pdf::a"
;; "file.pdf::95:do"
))
#+end_src
^ permalink raw reply [relevance 4%]
* Re: Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)]
@ 2021-03-05 12:01 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-05 12:01 UTC (permalink / raw)
To: Qqwy/Wiebe-Marten; +Cc: orgmode
Hi,
Qqwy/Wiebe-Marten <qqwy@gmx.com> writes:
> However, the LaTeX that is exported will still create normal `enumerize`
> lists that do /not/ show up as alphabetical but rather still use `1.`,
> `2.`, `3.` for numbering.
>
> I think this current behaviour is at the very least surprising, and
> possibly unintended.
I use the enumitem package
(http://mirrors.ctan.org/macros/latex/contrib/enumitem/enumitem.pdf) for
lists in LaTeX. For an alphabetical list, for example:
#+begin_src org
,#+LaTeX_Header: \usepackage{enumitem}
,#+ATTR_LaTeX: :options [label=\alph*.,widest=a]
a. Lorem
b. ipsum
c. dolor
#+end_src
And to export to LaTeX and HTML, you can define a macro like this:
#+begin_src org
,#+MACRO: alphalist (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) "#+ATTR_LaTeX: :options [label=\\alph*.,widest=a]" "#+ATTR_HTML: :type a"))
{{{alphalist}}}
a. Lorem
b. ipsum
c. dolor'
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
2021-03-03 14:51 6% ` Maxim Nikulin
@ 2021-03-03 16:11 9% ` Juan Manuel Macías
2021-03-05 13:02 4% ` Maxim Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-03 16:11 UTC (permalink / raw)
To: Maxim Nikulin; +Cc: orgmode
Hi Maxim
Thanks for your advice, which I appreciate very much.
Maxim Nikulin <manikulin@gmail.com> writes:
> On 03/03/2021 09:31, Juan Manuel Macías wrote:
>> (start-process-shell-command "zathura" nil (concat "zathura "
>> clean-path
>> " -P "
>> pag
>> (when str
>> (format " -f '%s' " str)))))))
>
> Please, do not forget to pass stings coming from user input through
> shell-quote-argument. There is combine-and-quote-strings function but
> its docstring tells that it is not safe enough. Ideally shell should
> be completely avoided in such cases and arguments should be passed as
> a list directly to exec. https://xkcd.com/327/
So, maybe it would look better like this (`start-process' instead of
`start-process-shell-command')?:
#+begin_src emacs-lisp
(org-link-set-parameters
"pdf-pag"
:follow (lambda (path)
(let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
(format "--page=%s" (match-string 1 path))
(error "no pages")))
(clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
(str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
(format "--find=%s" (match-string 2 path)))))
(if str
(start-process "zathura" nil "/usr/bin/zathura"
clean-path
pag
str)
(start-process "zathura" nil "/usr/bin/zathura"
clean-path
pag)))))
#+end_src
Best reagards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
2021-03-03 2:31 9% ` Juan Manuel Macías
@ 2021-03-03 14:51 6% ` Maxim Nikulin
2021-03-03 16:11 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Maxim Nikulin @ 2021-03-03 14:51 UTC (permalink / raw)
To: emacs-orgmode
On 03/03/2021 09:31, Juan Manuel Macías wrote:
> (start-process-shell-command "zathura" nil (concat "zathura "
> clean-path
> " -P "
> pag
> (when str
> (format " -f '%s' " str)))))))
Please, do not forget to pass stings coming from user input through
shell-quote-argument. There is combine-and-quote-strings function but
its docstring tells that it is not safe enough. Ideally shell should be
completely avoided in such cases and arguments should be passed as a
list directly to exec. https://xkcd.com/327/
^ permalink raw reply [relevance 6%]
* Re: Org mode links: Open a PDF file at a given page and highlight a given string
@ 2021-03-03 2:31 9% ` Juan Manuel Macías
2021-03-03 14:51 6% ` Maxim Nikulin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-03 2:31 UTC (permalink / raw)
To: Rodrigo Morales; +Cc: orgmode
Hi Rodrigo,
Rodrigo Morales <moralesrodrigo1100@gmail.com> writes:
> I want to be able to
>
> + create a Org link to specific pages of a PDF. I've managed to
> accomplish this by setting the following value.
> [ ... ]
> + create a Org link to specific pages of a PDF and highlight a given
> string.
A possible alternative, which gives you more control over the link, is
`org-link-set-parameters'. For example:
#+begin_src emacs-lisp
(org-link-set-parameters
"pdf-pag"
:follow (lambda (path)
(let ((pag (if (string-match "::\\([1-9]+\\):*:*\\(.*\\)" path)
(match-string 1 path)
(error "no pages")))
(clean-path (expand-file-name (replace-regexp-in-string "::.+" "" path)))
(str (when (string-match "::\\([1-9]+\\)::\\(.+\\)" path)
(match-string 2 path))))
(start-process-shell-command "zathura" nil (concat "zathura "
clean-path
" -P "
pag
(when str
(format " -f '%s' " str)))))))
#+end_src
And then:
#+begin_src org
[[pdf-pag:~/Downloads/grub.pdf::95::do]]
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 15:37 5% ` Julian M. Burgos
@ 2021-03-01 16:42 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-03-01 16:42 UTC (permalink / raw)
To: Julian M. Burgos; +Cc: orgmode
Hi Julian,
"Julian M. Burgos" <julian.burgos@hafogvatn.is> writes:
> This does not seem to be a limitation from emacs, as it is possible to
> open multiple indirect buffers from a base buffer, using for example
> clone-indirect-buffer. So it should be possible to make a function
> combining "clone-indirect-buffer" and "org-narrow-to-subtree" perhaps?
> I am thinking so this option is available not only to EXWM users.
I think that combining clone-indirect-buffer and org-narrow-to-subtree
would work well. Another way to isolate several trees at once is by
using the excellent package org-sidebar
(https://github.com/alphapapa/org-sidebar). In fact, I borrowed from
this package the idea of renaming the new buffers with the string :: (if
I open helm and start typing ::, it shows me the list of isolated trees,
so it's very useful to have a dedicated string). Although my method for
isolating each tree is more pedestrian :-). And it only makes sense in
EXWM...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 14:10 10% ` Juan Manuel Macías
@ 2021-03-01 15:37 5% ` Julian M. Burgos
2021-03-01 16:42 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Julian M. Burgos @ 2021-03-01 15:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
You are right. :) I have not noticed that org-tree-to-indirect-buffer reuses the indirect buffer when you call it for a second time. According to the manual, "with a C-u prefix, do not remove the previously used indirect buffer", but that does not seem to work. When you do Cu-Cc-Cx-b from a buffer that already has an indirect buffer you get a "cannot modify an area being edited in a dedicated buffer". If you try it from a different buffer, the prefix is ignored and the indirect buffer is assigned to the tree from the last buffer.
This does not seem to be a limitation from emacs, as it is possible to open multiple indirect buffers from a base buffer, using for example clone-indirect-buffer. So it should be possible to make a function combining "clone-indirect-buffer" and "org-narrow-to-subtree" perhaps? I am thinking so this option is available not only to EXWM users.
Ideally, there should be an option to allow org-tree-to-indirect-buffer to create more than one indirect buffer if desired.
My best,
Julian
Juan Manuel Macías writes:
> Hi Julian, thanks for your comment.
>
> "Julian M. Burgos" <julian.burgos@hafogvatn.is> writes:
>
>> Thank you, although I tested your functions and compared with the
>> original org-tree-to-indirect-buffer, the only difference I see is
>> that your function creates a new exwm workspace. The original function
>> already creates indirect buffers with their own names (using a slash
>> instead of the double colons). Or I am missing something?
>
> org-tree-to-indirect-buffer creates a new buffer, but (as far as I know)
> does not allow accumulating buffers. In other words, you cannot have
> several isolated trees at the time. In this method it just occurred to
> me to configure org-indirect-buffer-display as new-frame and take
> advantage of EXWM frame management.
>
> Best regards,
>
> Juan Manuel
--
Julian Mariano Burgos, PhD
Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/
Marine and Freshwater Research Institute
Botnsjávarsviðs / Demersal Division
Fornubúðir 5, IS-220 Hafnarfjörður, Iceland
www.hafogvatn.is
Sími/Telephone : +354-5752037
Netfang/Email: julian.burgos@hafogvatn.is
^ permalink raw reply [relevance 5%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 13:37 6% ` Julian M. Burgos
@ 2021-03-01 14:10 10% ` Juan Manuel Macías
2021-03-01 15:37 5% ` Julian M. Burgos
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-01 14:10 UTC (permalink / raw)
To: Julian M. Burgos; +Cc: orgmode
Hi Julian, thanks for your comment.
"Julian M. Burgos" <julian.burgos@hafogvatn.is> writes:
> Thank you, although I tested your functions and compared with the
> original org-tree-to-indirect-buffer, the only difference I see is
> that your function creates a new exwm workspace. The original function
> already creates indirect buffers with their own names (using a slash
> instead of the double colons). Or I am missing something?
org-tree-to-indirect-buffer creates a new buffer, but (as far as I know)
does not allow accumulating buffers. In other words, you cannot have
several isolated trees at the time. In this method it just occurred to
me to configure org-indirect-buffer-display as new-frame and take
advantage of EXWM frame management.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [tip for EXWM users] An alternative method for isolate trees
2021-03-01 12:55 9% [tip for EXWM users] An alternative method for isolate trees Juan Manuel Macías
@ 2021-03-01 13:37 6% ` Julian M. Burgos
2021-03-01 14:10 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Julian M. Burgos @ 2021-03-01 13:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan Manuel,
Thank you, although I tested your functions and compared with the original org-tree-to-indirect-buffer, the only difference I see is that your function creates a new exwm workspace. The original function already creates indirect buffers with their own names (using a slash instead of the double colons). Or I am missing something?
My best,
Julian
Juan Manuel Macías writes:
> Hi,
>
> Since EXWM uses Emacs frames as virtual desktops, I have written this
> alternative method of `org-tree-to-indirect-buffer', which I share here.
> With this method I can have several isolated trees, with their own name,
> and access them quickly (with helm-buffer-list, for example):
>
> #+begin_src emacs-lisp
> (defun my-goto-buffer-regexp (regexp)
> (dolist (buffer (buffer-list))
> (let ((name (buffer-name buffer)))
> (when (and name (not (string-equal name ""))
> (string-match regexp name))
> (switch-to-buffer buffer)))))
>
> (defun my-org-tree-to-indirect-buffer ()
> (interactive)
> (let ((buf (buffer-name))
> (ind-buf (replace-regexp-in-string "\\[.+\\]" "" (nth 4 (org-heading-components))))
> (org-indirect-buffer-display 'new-frame))
> (org-tree-to-indirect-buffer)
> (my-goto-buffer-regexp ind-buf)
> (rename-buffer (concat buf "::" ind-buf))))
> #+end_src
>
> Best regards,
>
> Juan Manuel
--
Julian Mariano Burgos, PhD
Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/
Marine and Freshwater Research Institute
Botnsjávarsviðs / Demersal Division
Fornubúðir 5, IS-220 Hafnarfjörður, Iceland
www.hafogvatn.is
Sími/Telephone : +354-5752037
Netfang/Email: julian.burgos@hafogvatn.is
^ permalink raw reply [relevance 6%]
* [tip for EXWM users] An alternative method for isolate trees
@ 2021-03-01 12:55 9% Juan Manuel Macías
2021-03-01 13:37 6% ` Julian M. Burgos
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-03-01 12:55 UTC (permalink / raw)
To: orgmode
Hi,
Since EXWM uses Emacs frames as virtual desktops, I have written this
alternative method of `org-tree-to-indirect-buffer', which I share here.
With this method I can have several isolated trees, with their own name,
and access them quickly (with helm-buffer-list, for example):
#+begin_src emacs-lisp
(defun my-goto-buffer-regexp (regexp)
(dolist (buffer (buffer-list))
(let ((name (buffer-name buffer)))
(when (and name (not (string-equal name ""))
(string-match regexp name))
(switch-to-buffer buffer)))))
(defun my-org-tree-to-indirect-buffer ()
(interactive)
(let ((buf (buffer-name))
(ind-buf (replace-regexp-in-string "\\[.+\\]" "" (nth 4 (org-heading-components))))
(org-indirect-buffer-display 'new-frame))
(org-tree-to-indirect-buffer)
(my-goto-buffer-regexp ind-buf)
(rename-buffer (concat buf "::" ind-buf))))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: printing org table landscape on complete page
2021-02-28 20:53 10% ` Juan Manuel Macías
@ 2021-03-01 0:18 2% ` andrés ramírez
0 siblings, 0 replies; 144+ results
From: andrés ramírez @ 2021-03-01 0:18 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi (Como estas). Juan.
>>>>> "Juan" == Juan Manuel Macías <maciaschain@posteo.net> writes:
[...]
Juan> #+ATTR_LaTeX: :float sideways :environment tabularx :width \textheigtht
I have tried it (with M-x org-export-dispatch).
This is the result:
,---- [ ]
| http://0x0.st/-Kgb.pdf
`----
It is centered.
Also I got a second option:
with this snippet and (M-x ps-print-buffer):
--8<---------------cut here---------------start------------->8---
(setq ps-left-margin 0
ps-paper-type 'a4
ps-font-size 16.0
ps-print-header nil
ps-landscape-mode t
ps-number-of-columns 1
ps-printer-name "pdf")
--8<---------------cut here---------------end--------------->8---
This is the result:
,---- [ ]
| http://0x0.st/-KgA.pdf
`----
The second option is going to be very useful when pdflatex is not
available. But it is NOT so well centered as the first option.
Thanks for your help.
Best Regards
^ permalink raw reply [relevance 2%]
* Re: printing org table landscape on complete page
@ 2021-02-28 20:53 10% ` Juan Manuel Macías
2021-03-01 0:18 2% ` andrés ramírez
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-28 20:53 UTC (permalink / raw)
To: Andrés Ramírez; +Cc: orgmode
Hi,
You can use:
#+ATTR_LaTeX: :float sideways
which is exported to LaTeX with the sidewaystable environment (rotating
package).
And for the table to fit vertically on the page:
#+LaTeX_Header: \usepackage{tabularx}
#+ATTR_LaTeX: :float sideways :environment tabularx :width \textheigtht
Regards,
Juan Manuel
Andrés Ramírez <rrandresf@gmail.com> writes:
> Hi.
>
> I want to print from emacs an org-table like this one:
>
> |-------------+-----------+----------+-----------+----------+---------|
> | DURATION | MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY |
> |-------------+-----------+----------+-----------+----------+---------|
> | 08:30-09:30 | CyT | RELIGION | GERMAN | ENGLISH | ENGLISH |
> |-------------+-----------+----------+-----------+----------+---------|
> | 09:50-10:50 | COMUNICAT | DPCC | COMUNICAT | COMUNIC | CyT |
> |-------------+-----------+----------+-----------+----------+---------|
> | 11:10-12:10 | COMPUTERS | CyT | E.FISICA | ART | GERMAN |
> |-------------+-----------+----------+-----------+----------+---------|
> | 12:30-13:30 | TUTORIA | MATH | MATH | CC.SS | MATH |
>
> on landscape on the content should enlarge to cover the full-page.
>
> Any ideas?
>
> Andrés Ramírez
>
^ permalink raw reply [relevance 10%]
* Re: content management in emacs
@ 2021-02-27 20:11 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-27 20:11 UTC (permalink / raw)
To: Martin Steffen; +Cc: orgmode
Martin Steffen <msteffen@ifi.uio.no> writes:
> I am not sure about the question. If I send to an email list, it's an
> address in BBDB. So I ``invoke'' BBDB (M-x bbdb) and give it the name of
> the entry (say org-mode). That's analogous to send to a person: If you
> remember the name (or part of the name), you find the entry, send then
> compose an email ("m") on the entry.
There is also helm-bbdb, wich is very useful
(https://github.com/emacs-helm/helm-bbdb). For Gnus I have defined this:
#+begin_src emacs-lisp
(require 'helm-bbdb)
(setq message-completion-alist '(("^\\(Newsgroups\\|Followup-To\\|Posted-To\\|Gcc\\):" . message-expand-group)
("^\\(Resent-\\)?\\(To\\|B?Cc\\):" . helm-bbdb-expand-name)
("^\\(Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):" . helm-bbdb-expand-name)
("^\\(Disposition-Notification-To\\|Return-Receipt-To\\):"
. helm-bbdb-expand-name)))
#+end_src
And to insert an address at point (for example, in Org, in the `mail_to'
property):
#+begin_src emacs-lisp
(defun my-insert-mail-address-helm-bbdb (_candidate)
(save-window-excursion
(helm-bbdb--view-person-action-1 (helm-bbdb--marked-contacts))
(call-interactively 'bbdb-mail-address)
(kill-buffer))
(yank))
(add-to-list 'helm-bbdb-actions '("Insert mail address" . my-insert-mail-address-helm-bbdb))
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Add color space and icc profile information to images
@ 2021-02-25 22:16 7% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-25 22:16 UTC (permalink / raw)
To: orgmode
Hi,
When working with images for print, I often need to get quickly the
color space and icc profile information of each included image, so I
came up with this function (code at the end of this mail) that I share
here, in case it is useful to someone. The function inserts the
information I need, under each image link in a document. For example:
#+begin_src org
[[file:~/Imágenes/Arte/Lilian_May_Miller_Blue_Hills_and_Crescent_Moon.jpg]]
# COLOR-INFO: Colorspace: sRGB | icc:description: Adobe RGB (1998)
[[file:~/CA/CA10/cubierta.jpg]]
# COLOR-INFO: Colorspace: CMYK | icc:description: ISO Coated v2 300% (ECI)
[[file:~/Escritorio/crespo.jpg]]
# COLOR-INFO: Colorspace: Gray | icc:description: GIMP built-in D65 Grayscale with sRGB TRC
#+end_src
The only problem is that the process is somewhat slow, especially when
the images are large or there are many images in the document. I think
that this is due in part to the imagemagick process itself, and in part
to the little elegance of my function ... ;-)
Best regards,
Juan Manuel
#+begin_src emacs-lisp
(defun my-org-comment-colorspace ()
(interactive)
(save-excursion
(goto-char (point-min))
(while (re-search-forward org-bracket-link-regexp nil t)
(when (string-match (regexp-opt '(".png" ".jpg")) (match-string 1))
(forward-char -1)
(let* ((link (assoc :link (org-context)))
(link-str (when link
(buffer-substring-no-properties (cadr link) (caddr link)))))
(string-match org-bracket-link-regexp link-str)
(let* ((identify-result (shell-command-to-string
(concat "identify -verbose "
"\""
(expand-file-name
(format "%s"
(replace-regexp-in-string
"file:" ""
(substring link-str
(match-beginning 1)
(match-end 1)))))
"\"")))
(colorspace (progn
(string-match "\\(Colorspace:.+\\)" identify-result)
(substring identify-result
(match-beginning 1)
(match-end 1))))
(icc (progn
(string-match "\\(icc:description:.+\\)" identify-result)
(substring identify-result
(match-beginning 1)
(match-end 1)))))
(forward-line 1)
(beginning-of-line)
(when (looking-at "\\(# COLOR-INFO:.+\\)")
(delete-region (match-beginning 0) (match-end 0)))
(insert (format "# COLOR-INFO: %s | %s" colorspace icc))))))))
#+end_src
^ permalink raw reply [relevance 7%]
* false-list-item-mode?
@ 2021-02-23 18:23 10% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-23 18:23 UTC (permalink / raw)
To: orgmode
Hi,
This is not a solution to what was commented in this recent thread
(https://lists.gnu.org/archive/html/emacs-orgmode/2021-02/msg00239.html)
on the false list item issue. But, in case anyone finds it useful, I
happened to sketch this minor mode to highlight, while typing, *only*
(+/-) those lines in a paragraph that start with a 'false' list item.
The code is in this GitLab snippet:
https://gitlab.com/-/snippets/2081294
And here a short screenshot:
https://gnutas.juanmanuelmacias.com/images/false-list-item-mode-test.mp4
Feedback Welcome!
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
@ 2021-02-22 0:21 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-22 0:21 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Tim Cross <theophilusx@gmail.com> writes:
> The issue is, if we decide this is a bug, can we fix it? Is it a bug or
> is it just an accepted limitation of the org document format and what we
> have to do is ensure either no line starts with a '1. ' or we use
> something like a unicode character so that it doesn't look like a
> number+period+space and therefore not a list item?
Interesting all the points you comment, and this paragraph is important.
I'm thinking that without a clear and explicit environment (a begin/end
marks), any possible solution will always have its exceptions. However,
IMHO, I would not find desirable two explicit marks environment in the
style of LaTeX, since this would go against the virtue of legibility and
lightness in Org. I don't know if Markdown (on what it has in common
with Org as a lightweight markup language) also has similar problems in
lists formatting, since I hardly use Markdown and am not aware of its
many implementations...
I still think that highlighting the items would at least be a preventive
solution for Org.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: 'false' list item
2021-02-21 19:33 10% ` Juan Manuel Macías
2021-02-21 19:40 7% ` Diego Zamboni
@ 2021-02-21 22:55 6% ` Kyle Meyer
1 sibling, 0 replies; 144+ results
From: Kyle Meyer @ 2021-02-21 22:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías writes:
> Kyle Meyer <kyle@kyleam.com> writes:
>
>> It seems that your approach would do a good job of helping you catch
>> cases that you don't want to be treated as lists. I'm not aware of any
>> related functionality in Org, so I don't think you're missing something
>> there.
>>
>> Once you know that there is a particular spot that you want to prevent
>> from being interpreted as a list, you could add a zero-width space in
>> front of it:
>>
>> (info "(org)Escape Character")
>>
>> I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.
You can find some previous discussion of this longstanding and known
behavior at <https://orgmode.org/list/874ndj13u5.fsf@gmail.com/T/#u>.
^ permalink raw reply [relevance 6%]
* Re: 'false' list item
2021-02-21 21:27 0% ` Samuel Wales
@ 2021-02-21 22:25 10% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-21 22:25 UTC (permalink / raw)
To: Samuel Wales; +Cc: orgmode
Samuel Wales <samologist@gmail.com> writes:
> perhaps if there is no blank line above or below, then it could be not a list.
I think this solution would be fine, although plain paragraphs starting
with digit/letter + period + space would be false positives. Anyway,
some kind of highlighting in the items, a defined face as in
markdown-mode (markdown-list-face), would be also helpful.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
2021-02-21 19:40 7% ` Diego Zamboni
@ 2021-02-21 21:27 0% ` Samuel Wales
2021-02-21 22:25 10% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Samuel Wales @ 2021-02-21 21:27 UTC (permalink / raw)
To: Diego Zamboni; +Cc: Juan Manuel Macías, Kyle Meyer, orgmode
perhaps if there is no blank line above or below, then it could be not a list.
On 2/21/21, Diego Zamboni <diego@zzamboni.org> wrote:
> Juan Manuel,
>
> YMMV depending on your needs and habits, but another workaround for this
> problem would be to use visual-line-mode instead of filling paragraphs.
>
> --Diego
>
>
>
>
> On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Kyle Meyer <kyle@kyleam.com> writes:
>>
>> > It seems that your approach would do a good job of helping you catch
>> > cases that you don't want to be treated as lists. I'm not aware of any
>> > related functionality in Org, so I don't think you're missing something
>> > there.
>> >
>> > Once you know that there is a particular spot that you want to prevent
>> > from being interpreted as a list, you could add a zero-width space in
>> > front of it:
>> >
>> > (info "(org)Escape Character")
>> >
>> > I'm not sure if that's the sort of solution you're asking for, though.
>>
>> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
>> avoid false positives. Anyway, like Tim Cross says, that situation
>> maybe should be considered as a bug. I think the ideal behavior would
>> be for Org to consider a list only when there is a blank line above.
>> But, well thought out, I am afraid that it would not prevent false
>> positives, as one may want perfectly write a list at the beginning of
>> the document, or start a plain paragraph with (for example) a digit + a
>> period + a space...
>>
>> 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: 'false' list item
2021-02-21 19:33 10% ` Juan Manuel Macías
@ 2021-02-21 19:40 7% ` Diego Zamboni
2021-02-21 21:27 0% ` Samuel Wales
2021-02-21 22:55 6% ` Kyle Meyer
1 sibling, 1 reply; 144+ results
From: Diego Zamboni @ 2021-02-21 19:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Kyle Meyer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Juan Manuel,
YMMV depending on your needs and habits, but another workaround for this
problem would be to use visual-line-mode instead of filling paragraphs.
--Diego
On Sun, Feb 21, 2021 at 8:34 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Kyle Meyer <kyle@kyleam.com> writes:
>
> > It seems that your approach would do a good job of helping you catch
> > cases that you don't want to be treated as lists. I'm not aware of any
> > related functionality in Org, so I don't think you're missing something
> > there.
> >
> > Once you know that there is a particular spot that you want to prevent
> > from being interpreted as a list, you could add a zero-width space in
> > front of it:
> >
> > (info "(org)Escape Character")
> >
> > I'm not sure if that's the sort of solution you're asking for, though.
>
> Thanks for your advice, Kyle. Adding the U+200B char. works fine to
> avoid false positives. Anyway, like Tim Cross says, that situation
> maybe should be considered as a bug. I think the ideal behavior would
> be for Org to consider a list only when there is a blank line above.
> But, well thought out, I am afraid that it would not prevent false
> positives, as one may want perfectly write a list at the beginning of
> the document, or start a plain paragraph with (for example) a digit + a
> period + a space...
>
> Best regards,
>
> Juan Manuel
>
>
[-- Attachment #2: Type: text/html, Size: 1982 bytes --]
^ permalink raw reply [relevance 7%]
* Re: 'false' list item
2021-02-21 6:56 6% ` Kyle Meyer
2021-02-21 7:05 0% ` Tim Cross
@ 2021-02-21 19:33 10% ` Juan Manuel Macías
2021-02-21 19:40 7% ` Diego Zamboni
2021-02-21 22:55 6% ` Kyle Meyer
1 sibling, 2 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-21 19:33 UTC (permalink / raw)
To: Kyle Meyer; +Cc: orgmode
Kyle Meyer <kyle@kyleam.com> writes:
> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists. I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
> (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.
Thanks for your advice, Kyle. Adding the U+200B char. works fine to
avoid false positives. Anyway, like Tim Cross says, that situation
maybe should be considered as a bug. I think the ideal behavior would
be for Org to consider a list only when there is a blank line above.
But, well thought out, I am afraid that it would not prevent false
positives, as one may want perfectly write a list at the beginning of
the document, or start a plain paragraph with (for example) a digit + a
period + a space...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
2021-02-21 7:05 0% ` Tim Cross
@ 2021-02-21 14:49 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-21 14:49 UTC (permalink / raw)
To: Tim Cross; +Cc: orgmode
Hi,
Tim Cross <theophilusx@gmail.com> writes:
> If a line starts with a number, period and space, but that line is
> within a paragraph (i.e. no blank line above), then I don't think it
> should be interpreted as an enumerated list item. If this is what the OP
> is referring to, I would argue it is a bug. If it is a 'paragraph'
> starting with a number, period and space, then being interpreted as a
> list item would be 'normal'.
The problem occurs on the lines within a paragraph (no blank line
above). I have uploaded this screenshot:
https://gnutas.juanmanuelmacias.com/images/false-list-item.webm
It also happens with a clean startup.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: 'false' list item
2021-02-21 6:56 6% ` Kyle Meyer
@ 2021-02-21 7:05 0% ` Tim Cross
2021-02-21 14:49 10% ` Juan Manuel Macías
2021-02-21 19:33 10% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Tim Cross @ 2021-02-21 7:05 UTC (permalink / raw)
To: emacs-orgmode
Kyle Meyer <kyle@kyleam.com> writes:
> Juan Manuel Macías writes:
>
>> If a line in a paragraph starts with a digit (or letter) + period +
>> space, Org misinterprets that as a list item. I almost always notice
>> this only when I export my document, which is a nuisance.
>>
>> I wonder if there is any standard solution to that, or if I'm missing
>> something... All that occurred to me is this "preventive" solution,
>> using `highlight-regexp':
>
> It seems that your approach would do a good job of helping you catch
> cases that you don't want to be treated as lists. I'm not aware of any
> related functionality in Org, so I don't think you're missing something
> there.
>
> Once you know that there is a particular spot that you want to prevent
> from being interpreted as a list, you could add a zero-width space in
> front of it:
>
> (info "(org)Escape Character")
>
> I'm not sure if that's the sort of solution you're asking for, though.
If a line starts with a number, period and space, but that line is
within a paragraph (i.e. no blank line above), then I don't think it
should be interpreted as an enumerated list item. If this is what the OP
is referring to, I would argue it is a bug. If it is a 'paragraph'
starting with a number, period and space, then being interpreted as a
list item would be 'normal'.
--
Tim Cross
^ permalink raw reply [relevance 0%]
* Re: 'false' list item
2021-02-15 17:37 10% 'false' list item Juan Manuel Macías
@ 2021-02-21 6:56 6% ` Kyle Meyer
2021-02-21 7:05 0% ` Tim Cross
2021-02-21 19:33 10% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Kyle Meyer @ 2021-02-21 6:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías writes:
> If a line in a paragraph starts with a digit (or letter) + period +
> space, Org misinterprets that as a list item. I almost always notice
> this only when I export my document, which is a nuisance.
>
> I wonder if there is any standard solution to that, or if I'm missing
> something... All that occurred to me is this "preventive" solution,
> using `highlight-regexp':
It seems that your approach would do a good job of helping you catch
cases that you don't want to be treated as lists. I'm not aware of any
related functionality in Org, so I don't think you're missing something
there.
Once you know that there is a particular spot that you want to prevent
from being interpreted as a list, you could add a zero-width space in
front of it:
(info "(org)Escape Character")
I'm not sure if that's the sort of solution you're asking for, though.
^ permalink raw reply [relevance 6%]
* [PATCH] Startup option to separate macros arguments with an alternative string
@ 2021-02-18 16:33 6% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-18 16:33 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Hi,
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 "'@").
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.
If the patch is relevant, I can take care of writing the documentation and docstrings.
Example:
#+begin_src org
,#+STARTUP: macro-arg-sep-other
,#+MACRO: lg (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 "\u200B" "@@latex:}@@") $2))
{{{lg(latin'@Lorem ipsum dolor sit amet, consectetuer adipiscing elit, donec hendrerit
tempor tellus, donec pretium posuere tellus, proin quam nisl, tincidunt et, mattis eget,
convallis nec, purus.)}}}
With the escaped character:
{{{lg(latin'@Lorem ipsum dolor sit amet \'@)}}}
#+end_src
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-macro-arg-sep.patch --]
[-- Type: text/x-patch, Size: 2302 bytes --]
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index f914a33d6..311eaf9a5 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -82,6 +82,8 @@ directly, use instead:
#+MACRO: name template")
+(defvar org-macro-arg-sep-other "'@")
+
;;; Functions
(defun org-macro--set-template (name value templates)
@@ -277,15 +279,19 @@ 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.
+ (let ((sep (cond ((eq org-startup-macro-arg-sep 'comma)
+ ",")
+ ((eq org-startup-macro-arg-sep 'other)
+ org-macro-arg-sep-other))))
(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"))
+ "\000")))
\f
;;; Helper functions and variables for internal macros
diff --git a/lisp/org.el b/lisp/org.el
index 7d8733448..a51893ed3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -974,6 +974,15 @@ case it is too late to set the variable `org-startup-truncated'."
:group 'org-startup
:type 'boolean)
+(defcustom org-startup-macro-arg-sep 'comma
+ "TODO"
+ :group 'org-startup
+ :package-version '(Org . "9.0")
+ :version "26.1"
+ :type '(choice
+ (const :tag "comma" comma)
+ (const :tag "other" other)))
+
(defcustom org-startup-indented nil
"Non-nil means turn on `org-indent-mode' on startup.
This can also be configured on a per-file basis by adding one of
@@ -4187,7 +4196,8 @@ After a match, the following groups carry important information:
("nohideblocks" org-hide-block-startup nil)
("beamer" org-startup-with-beamer-mode t)
("entitiespretty" org-pretty-entities t)
- ("entitiesplain" org-pretty-entities nil))
+ ("entitiesplain" org-pretty-entities nil)
+ ("macro-arg-sep-other" org-startup-macro-arg-sep other))
"Variable associated with STARTUP options for Org.
Each element is a list of three items: the startup options (as written
in the #+STARTUP line), the corresponding variable, and the value to set
^ permalink raw reply related [relevance 6%]
* Re: [question] lisp code in :results header arg.?
2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
@ 2021-02-16 18:25 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-16 18:25 UTC (permalink / raw)
To: Berry, Charles; +Cc: orgmode
"Berry, Charles" <ccberry@health.ucsd.edu> writes:
> I think you might do better to use noweb chunks, viz.
>
> #+name: pre-amble
> #+begin_src latex :exports none
>
> \usepackage{luacode}
> \usepackage{fontspec}
> \directlua
> {
> [...]
> }
> }
> \setmainfont{Linux Libertine O}
> [RawFeature={+ktest}]
> #+end_src
>
> #+begin_src latex :noweb yes :results drawer
> ,#+LaTeX_HEADER: <<pre-amble>>
> #+end_src
>
>
> Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . t)) gives what I suspect you want.
wow, it works great! Many thanks. I did not know this use of noweb ...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [question] lisp code in :results header arg.?
2021-02-16 16:30 9% [question] lisp code in :results header arg.? Juan Manuel Macías
@ 2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
2021-02-16 18:25 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Berry, Charles via General discussions about Org-mode. @ 2021-02-16 17:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
> On Feb 16, 2021, at 8:30 AM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi,
>
> I'm exploring some ways to include a complex LaTeX preamble using source
> blocks. Consider this (code at the end of this message), that works fine.
>
> My question is: In order to do it all in a single block, would there be
> any way to pass the output of the first block as an argument to a
> function, and put that function as a header arg (results)...?
[rest deleted]
I think you might do better to use noweb chunks, viz.
#+name: pre-amble
#+begin_src latex :exports none
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
[...]
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src latex :noweb yes :results drawer
,#+LaTeX_HEADER: <<pre-amble>>
#+end_src
Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . t)) gives what I suspect you want.
Note that using a drawer allows replacement of the result.
HTH,
Chuck
^ permalink raw reply [relevance 0%]
* [question] lisp code in :results header arg.?
@ 2021-02-16 16:30 9% Juan Manuel Macías
2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-16 16:30 UTC (permalink / raw)
To: orgmode
Hi,
I'm exploring some ways to include a complex LaTeX preamble using source
blocks. Consider this (code at the end of this message), that works fine.
My question is: In order to do it all in a single block, would there be
any way to pass the output of the first block as an argument to a
function, and put that function as a header arg (results)...?
Best Regards,
Juan Manuel
#+NAME:preamble
#+begin_src latex :results silent :exports results
\usepackage{luacode}
\usepackage{fontspec}
\directlua
{
fonts.handlers.otf.addfeature
{
name = "ktest",
type = "kern",
data =
{
["A"] = { ["V"] = -45 },
},
}
}
\setmainfont{Linux Libertine O}
[RawFeature={+ktest}]
#+end_src
#+begin_src emacs-lisp :var x=preamble :results raw :exports results
(let* ((lines (split-string x "\n" nil))
(headers (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n")))
headers)
#+end_src
#+RESULTS:
#+LaTeX_Header: \usepackage{luacode}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \directlua
#+LaTeX_Header: {
#+LaTeX_Header: fonts.handlers.otf.addfeature
#+LaTeX_Header: {
#+LaTeX_Header: name = "ktest",
#+LaTeX_Header: type = "kern",
#+LaTeX_Header: data =
#+LaTeX_Header: {
#+LaTeX_Header: ["A"] = { ["V"] = -45 },
#+LaTeX_Header: },
#+LaTeX_Header: }
#+LaTeX_Header: }
#+LaTeX_Header: \setmainfont{Linux Libertine O}
#+LaTeX_Header: [RawFeature={+ktest}]
^ permalink raw reply [relevance 9%]
* 'false' list item
@ 2021-02-15 17:37 10% Juan Manuel Macías
2021-02-21 6:56 6% ` Kyle Meyer
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-15 17:37 UTC (permalink / raw)
To: orgmode
Hi,
If a line in a paragraph starts with a digit (or letter) + period +
space, Org misinterprets that as a list item. I almost always notice
this only when I export my document, which is a nuisance.
I wonder if there is any standard solution to that, or if I'm missing
something... All that occurred to me is this "preventive" solution,
using `highlight-regexp':
#+begin_src emacs-lisp
(defface my-lists-item-box
'((t :weight bold :foreground "white" :background "orange"))
"")
(defun my-org-item-highlight ()
(highlight-regexp org-list-full-item-re 'my-lists-item-box))
(add-hook 'org-mode-hook 'my-org-item-highlight)
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [Tip] Write the LaTeX preamble in a source block
@ 2021-02-13 20:38 7% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-13 20:38 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3656 bytes --]
Hi,
Although I almost always use custom LaTeX classes and a separate file
for the preamble, I came up with this method to take advantage of
the 'latex' source blocks and write the entire preamble there. I guess
there will be a more elegant way to do it, but I think that it works
reasonably well ;-)
First, this function:
#+begin_src emacs-lisp
(defun multiple-latex-header ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "_src\s+latex\s+:latexheader" nil t)
(when (equal (org-element-type (org-element-at-point)) 'src-block)
(save-restriction
(org-narrow-to-block)
(goto-char (point-min))
(let ((lines (split-string (replace-regexp-in-string "#\\+.+" "" (buffer-string)) "\n" nil)))
(delete-region (point-min) (point-max))
(insert (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n"))))))))
#+end_src
And based on this concept, we could also take advantage of the 'lua'
source blocks to generate the luacode environment (with or without
asterisk) and send it to the preamble:
#+begin_src emacs-lisp
(defun env-luacode ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "_src\s+lua\s+:luacode" nil t)
(when (equal (org-element-type (org-element-at-point)) 'src-block)
(save-restriction
(org-narrow-to-block)
(goto-char (point-min))
(let ((luacode (save-excursion
(re-search-forward "\\(luacode\\**\\)" nil t)
(match-string 1))))
(when luacode
(while (re-search-forward "\\(#\\+begin_src\s+lua.+\\)" nil t)
(replace-match (format "\\\\begin{%s}" luacode) t nil))
(while (re-search-forward "\\(#\\+end_src\\)" nil t)
(replace-match (format "\\\\end{%s}" luacode) t nil))
(let ((lines (split-string (buffer-string) "\n" nil)))
(delete-region (point-min) (point-max))
(insert (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n"))))))))))
#+end_src
And finally:
#+begin_src emacs-lisp
(defun luacode-latexheader-filter (backend)
(when (eq backend 'latex)
(env-luacode)
(multiple-latex-header)))
(add-hook 'org-export-before-processing-hook #'luacode-latexheader-filter)
#+end_src
It can be tested with this example that includes a simple function in
Lua (in a luacode* environment) to colorize the texts in 'otherlanguage', but
only in draft mode:
#+begin_src org
,#+LATEX_CLASS: article
,#+LATEX_CLASS_OPTIONS: [draft]
,#+LATEX_COMPILER: lualatex
,#+OPTIONS: toc:nil
,#+LaTeX_Header: \usepackage{luacode}
,#+begin_src lua :luacode*
function foreignlanguage_draft ( text )
text = string.gsub ( text, "(\\begin{otherlanguage}{[^%s]+})", "%1\\color{teal}")
return text
end
,#+end_src
,#+begin_src latex :latexheader
\usepackage{fontspec}
\setmainfont[Numbers=Lowercase]{Linux Libertine O}
\usepackage[english,spanish]{babel}
\usepackage{xcolor}
\usepackage{ifdraft}
\usepackage{lipsum}
\newcommand\babeldraft{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , foreignlanguage_draft , "foreignlanguage_draft" )}}
\ifdraft{%
\AtBeginDocument{\babeldraft}
}{}
,#+end_src
@@latex:\lipsum[1]@@
,#+ATTR_LaTeX: :options {english}
,#+begin_otherlanguage
Most GNU/Linux distributions provide GNU Emacs in their repositories, which is the
recommended way to install Emacs unless you always want to use the latest release.
,#+end_otherlanguage
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 7%]
* Macros and possible alternatives to the comma character (enhancement?)
@ 2021-02-12 13:01 9% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-12 13:01 UTC (permalink / raw)
To: orgmode
Hi,
In my Org docs I make a heavy use of replacement macros. I think they
are a powerful and versatile. I only see one problem: in my opinion, the
comma as a character to separate arguments seems unproductive to me. I
often use macros to enter textual content, and I find it a bit tedious
having to constantly escape such a common symbol as the comma (\,). In fact,
for my personal use I have modified the `org-macro-extract-arguments'
function, and now I separate the arguments using '@ (quote + at).
Am I the only one who thinks there should be better alternatives to the
comma?
Do you think it would be good to add these alternatives as a '#+startup'
option?
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: local variables and export processing in hooks
@ 2021-02-10 15:43 6% ` Maxim Nikulin
0 siblings, 0 replies; 144+ results
From: Maxim Nikulin @ 2021-02-10 15:43 UTC (permalink / raw)
To: emacs-orgmode
On 09/02/2021 19:06, Eric S Fraga wrote:
> On Tuesday, 9 Feb 2021 at 12:30, tomas@tuxteam.de wrote:
>> Perhaps a file local variable?
>
> I tried but this doesn't seem to be propagated to the export as the
> export works on a copy of the buffer, not the buffer itself. That's
> what #+BIND is for, supposedly...
I have seen that you have achieved your goal with local variables.
Concerning BIND, there was a topic a month ago that bind has to be
enabled explicitly. Unsure if it makes parameter available early enough
however:
https://orgmode.org/list/87pn2iz3kr.fsf@posteo.net/
On 06/01/2021 18:51, Juan Manuel Macías wrote:
> (setq org-export-allow-bind-keywords t)
^ permalink raw reply [relevance 6%]
* Re: http links translated to html : target "_blank"
2021-02-01 21:01 10% ` Juan Manuel Macías
@ 2021-02-04 14:07 0% ` Uwe Brauer
0 siblings, 0 replies; 144+ results
From: Uwe Brauer @ 2021-02-04 14:07 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Uwe Brauer <oub@mat.ucm.es> writes:
>> That is odd (maybe my org version is a bit rusty (master june 2020)
> It's strange...
> It should work fine for you (as long as you set
> `org-export-allow-bind-keywords' as non-nil)
Aha, indeed it was nil! I was not even aware of this variable, after
switching to t, your code worked. Thanks because it save me the hassle
to add manually
#+attr_latex
On the other hand it is good to know that booth solution exits.
Thanks
Uwe
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: word counts and org-mode drawers
2021-02-01 23:29 10% ` Juan Manuel Macías
@ 2021-02-04 13:50 1% ` Sharon Kimble
0 siblings, 0 replies; 144+ results
From: Sharon Kimble @ 2021-02-04 13:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Juan.
Thanks very much for this code, it fits my purpose very well, thanks
again.
Thanks
Sharon.
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
> Hi,
>
> Sharon Kimble <boudiccas@skimble.plus.com> writes:
>
>> How can I exempt an org-mode drawer, and its contents, from word counts
>> please. I am using 'wc-mode' but I can't see how to do it.
>
> #+begin_src emacs-lisp
> (defun my-count-words-in-org-buffer ()
> (interactive)
> (let ((words 0))
> (save-excursion
> (save-restriction
> (narrow-to-region (point-min) (point-max))
> (goto-char (point-min))
> (while (forward-word-strictly 1)
> (if (org-at-drawer-p)
> (re-search-forward ":END:")
> (setq words (1+ words))))))
> (message "Org buffer has %d word%s."
> words (if (= words 1) "" "s"))))
> #+end_src
>
> Juan Manuel
>
- --
Debian 10.7, fluxbox 1.3.7, emacs 27.1.50, org 9.4.4
-----BEGIN PGP SIGNATURE-----
iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmAb+6sbHGJvdWRpY2Nh
c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbKfcP/i/rVfnnXUSViX7dD2Rm
Gu2+mvzfwv+lzyRMUsbZoEMi2hYDQ/5CkBChFVtgrG84KqF9+wmxjikCG9q2hL0b
BMYrZ60XNfwMsJ1nd7Q/CHypPgr7//cn6r89B29w2ez0/noWID9OiTDS+dfJFoQQ
8MFv32TeLQtlYiONsiO0Z38iqkyQDGn5aSOtQjMjIxOJ5fiAVAsO/GBiwrNunwbN
yeCrOJQhiooZB/dOQgYwZkd9yDOQ3C/jPfRflLxIBGWUJ3EgCuFqBCuKin+JBnhJ
JUghkoX1BSDfs72QDq5yyzezHTgDnq0IdKBdqz0GVrMH6tkHFxfLDdUbxJgY2KcF
uW/GX17A23EXLT11MhI0C+W3VnG68HWvqZc/x4kY0SKy9pxUbXy9y2BGJFdGl+no
CPMyEn3tA+E8klDVDWe6DSJj2JUxarAT0gaizs7KOJpHCDeHja2i+rN1S0eLZ+t8
PmY32zYHoe5w8yzdwm43V3+mZp6kvusK6SODNalRCIykqPrCeeYMmzolfwXpi6qW
va5g4OigBHmY165SfVdLr8iGzi96VqLlTWkzBN3bCiu9F/fJGqUiPdgDEAR8A2f0
/nFaEbYBNq4h1I8OMAMNhfA2PMeo0qn7vmBsmwboIXn6G+4yaTnQk9R80hb/7JFv
SN043NVKF1XKT5lcjxfDEIWr
=hiQu
-----END PGP SIGNATURE-----
^ permalink raw reply [relevance 1%]
* Re: emphasizing source code words
@ 2021-02-04 12:13 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-02-04 12:13 UTC (permalink / raw)
To: Luca Ferrari; +Cc: orgmode
Hi Luca
Luca Ferrari <fluca1978@gmail.com> writes:
> Thanks, but stil Im not able to figure it out. I've searched thru the
> org documentation without any luck.
>
> Luca
To use the minted package as backend (https://www.ctan.org/pkg/minted),
I have in my Emacs:
(setq org-latex-listings 'minted)
(setq org-latex-minted-options
'(("frame" "lines") ("linenos=true") ("breaklines")))
You also need to install the Python pigments library on your OS. In
Arch (in my case) is the python-pygments package.
And you have to make sure that when you export to LaTeX it always compiles
with the -shell-escape option. For example:
(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"))
Lastly, in Org docs you need of course to load the minted package:
#+LaTeX_HEADER: \usepackage{minted}
You can see how the highlighting looks like in this post from my blog (in
Spanish): under the title there is a button to download the entry in PDF
version: https://lunotipia.juanmanuelmacias.com/evitar_funcion_lua.html
Finally, you may be interested in this new package that TEC has written:
https://www.reddit.com/r/emacs/comments/lbkmmz/the_best_syntax_highlighting_in_a_pdf_youll_see_a/
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: word counts and org-mode drawers
@ 2021-02-01 23:29 10% ` Juan Manuel Macías
2021-02-04 13:50 1% ` Sharon Kimble
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-01 23:29 UTC (permalink / raw)
To: Sharon Kimble; +Cc: orgmode
Hi,
Sharon Kimble <boudiccas@skimble.plus.com> writes:
> How can I exempt an org-mode drawer, and its contents, from word counts
> please. I am using 'wc-mode' but I can't see how to do it.
It is not a solution with wc-mode, but maybe this simple function, based on
`count-words', can serve you. It counts the words in the buffer
excluding all drawers and their contents:
#+begin_src emacs-lisp
(defun my-count-words-in-org-buffer ()
(interactive)
(let ((words 0))
(save-excursion
(save-restriction
(narrow-to-region (point-min) (point-max))
(goto-char (point-min))
(while (forward-word-strictly 1)
(if (org-at-drawer-p)
(re-search-forward ":END:")
(setq words (1+ words))))))
(message "Org buffer has %d word%s."
words (if (= words 1) "" "s"))))
#+end_src
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: http links translated to html : target "_blank"
2021-02-01 15:20 0% ` Uwe Brauer
@ 2021-02-01 21:01 10% ` Juan Manuel Macías
2021-02-04 14:07 0% ` Uwe Brauer
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-01 21:01 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Uwe Brauer <oub@mat.ucm.es> writes:
> That is odd (maybe my org version is a bit rusty (master june 2020)
It's strange...
It should work fine for you (as long as you set
`org-export-allow-bind-keywords' as non-nil)
You can also try `org-export-filter-link-functions' instead of
`...-final-output-functions'.
Anyway, if the `#+attr_latex' solution works for you, then all is fine.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: http links translated to html : target "_blank"
2021-02-01 14:46 8% ` Juan Manuel Macías
@ 2021-02-01 15:20 0% ` Uwe Brauer
2021-02-01 21:01 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Uwe Brauer @ 2021-02-01 15:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Uwe Brauer, orgmode
[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi Uwe,
> Uwe Brauer <oub@mat.ucm.es> writes:
>> Thanks that works, but not for link in a list. The only solution
>> seems to be this one
> Doesn't it work for you in a list? I think it should work also in a
> list. If I export this:
> #+begin_src org
> ,#+BIND: org-export-filter-final-output-functions (correct-target-blank)
> ,#+begin_src emacs-lisp :exports results :results none
> (defun correct-target-blank (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
> ,#+end_src
> + [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
> + [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
> #+end_src
> I get this:
That is odd (maybe my org version is a bit rusty (master june 2020)
I obtain this:
<ul class="org-ul">
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1%20target=%22_blank%22">Book A4</a></li>
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1%20target=%22_blank%22">Book A4</a></li>
</ul>
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 0%]
* Re: http links translated to html : target "_blank"
2021-02-01 13:56 1% ` Uwe Brauer
@ 2021-02-01 14:46 8% ` Juan Manuel Macías
2021-02-01 15:20 0% ` Uwe Brauer
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-01 14:46 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
Hi Uwe,
Uwe Brauer <oub@mat.ucm.es> writes:
> Thanks that works, but not for link in a list. The only solution
> seems to be this one
Doesn't it work for you in a list? I think it should work also in a
list. If I export this:
#+begin_src org
,#+BIND: org-export-filter-final-output-functions (correct-target-blank)
,#+begin_src emacs-lisp :exports results :results none
(defun correct-target-blank (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
,#+end_src
+ [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
+ [[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1 target="_blank"][Book A4]]
#+end_src
I get this:
#+begin_src html
<ul class="org-ul">
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1" target="_blank">Book A4</a></li>
<li><a href="https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1" target="_blank">Book A4</a></li>
</ul>
#+end_src
Using `#+attr_html:' is a simpler and cleaner solution, of course, but I think that
would not work with links within a paragraph.
Best regards / saludos,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: http links translated to html : target "_blank"
2021-02-01 11:03 9% ` Juan Manuel Macías
@ 2021-02-01 13:56 1% ` Uwe Brauer
2021-02-01 14:46 8% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Uwe Brauer @ 2021-02-01 13:56 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]
>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
Hola Juan
> I think the problem is how the exporter understands the url string.
> Note that this:
> @@html:<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>@@
> [[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
> is exported like this:
> <p>
> <a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>
> </p>
> <p>
> <a href="https://www.mpic.de/4747361/risk-calculator%20target=%22_blank%22">Simulador de riesgo con más detalle</a>
> </p>
> The second link is wrong formatted. A dirty solution could be:
> #+BIND: org-export-filter-final-output-functions (correct-target-blank)
> #+begin_src emacs-lisp :exports results :results none
> (defun correct-target-blank (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
> #+end_src
> Best regards,
Thanks that works, but not for link in a list. The only solution
seems to be this one
#+attr_html: :target _blank
[[https://www.zeit.de/wissen/gesundheit/2020-11/coronavirus-aerosols-infection-risk-hotspot-interiors][Risk simulator]]
#+attr_html: :target _blank
[[https://www.mpic.de/4747361/risk-calculator][Risk simulator with more details]]
1. RocketBook
+ Book A4
#+attr_html: :target _blank
[[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1][Book A4]]
a. Book A4
#+attr_html: :target _blank
[[https://www.amazon.es/Rocketbook-Everlast-Notebook-riutilizzabile-Esecutivo/dp/B071Y3MSRK/ref=sr_1_5?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Rocketbook&qid=1607847519&sr=8-5&th=1][Book A4]]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]
^ permalink raw reply [relevance 1%]
* Re: http links translated to html : target "_blank"
@ 2021-02-01 11:03 9% ` Juan Manuel Macías
2021-02-01 13:56 1% ` Uwe Brauer
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-02-01 11:03 UTC (permalink / raw)
To: Uwe Brauer; +Cc: orgmode
I think the problem is how the exporter understands the url string.
Note that this:
@@html:<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>@@
[[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
is exported like this:
<p>
<a href="https://www.mpic.de/4747361/risk-calculator" target="_blank">Simulador de riesgo con más detalle</a>
</p>
<p>
<a href="https://www.mpic.de/4747361/risk-calculator%20target=%22_blank%22">Simulador de riesgo con más detalle</a>
</p>
The second link is wrong formatted. A dirty solution could be:
#+BIND: org-export-filter-final-output-functions (correct-target-blank)
#+begin_src emacs-lisp :exports results :results none
(defun correct-target-blank (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "%20target=%22_blank%22\"" "\" target=\"_blank\"" text)))
#+end_src
Best regards,
Juan Manuel
Uwe Brauer <oub@mat.ucm.es> writes:
> Hi
>
> I need to produce a html file, with links opening new tabs (pages) as in
>
> <a href="https://apps.apple.com/es/app/radar-covid/id1520443509" target="_blank">Descarga Directa</a>
>
> However
>
> [[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de riesgo con más detalle]]
>
> Did not work
>
> Any ideas?
>
> Thanks and regards
>
> Uwe Brauer
>
>
^ permalink raw reply [relevance 9%]
* [patch] to allow org-attach-git to handle individual repositories
@ 2021-01-31 19:37 6% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-31 19:37 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
Hi,
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
This patch would allow org-attach-git to handle individual repositories,
that is, any repository initialized in a directory attached to a node.
A custom variable is provided, that admits two values:
1. default: the default value, which is equivalent to the old behavior
2. individual-repository: which activates the 'new' feature.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-attach-git-individual-repositories.patch --]
[-- Type: text/x-patch, Size: 2664 bytes --]
diff --git a/lisp/org-attach-git.el b/lisp/org-attach-git.el
index 2091cbc61..54df5b9ba 100644
--- a/lisp/org-attach-git.el
+++ b/lisp/org-attach-git.el
@@ -52,9 +52,26 @@ If \\='ask, prompt using `y-or-n-p'. If t, always get. If nil, never get."
(const :tag "always get from annex if necessary" t)
(const :tag "never get from annex" nil)))
+(defcustom org-attach-git-dir 'default
+ "The attachment directory where a Git repository must be
+handled. The default value is `default', which is equivalent to
+`org-attach-id-dir'. If the value is `individual-repository', it
+means that the directory attached to the current node should be
+handled as a individual repository, as long as it has been
+conveniently initialized."
+ :group 'org-attach
+ :package-version '(Org . "9.0")
+ :version "26.1"
+ :type '(choice
+ (const :tag "Default" default)
+ (const :tag "Individual repository" individual-repository)))
+
(defun org-attach-git-use-annex ()
"Return non-nil if git annex can be used."
- (let ((git-dir (vc-git-root (expand-file-name org-attach-id-dir))))
+ (let ((git-dir (vc-git-root (cond ((eq org-attach-git-dir 'default)
+ (expand-file-name org-attach-id-dir))
+ ((eq org-attach-git-dir 'individual-repository)
+ (org-attach-dir))))))
(and org-attach-git-annex-cutoff
(or (file-exists-p (expand-file-name "annex" git-dir))
(file-exists-p (expand-file-name ".git/annex" git-dir))))))
@@ -62,7 +79,10 @@ If \\='ask, prompt using `y-or-n-p'. If t, always get. If nil, never get."
(defun org-attach-git-annex-get-maybe (path)
"Call git annex get PATH (via shell) if using git annex.
Signals an error if the file content is not available and it was not retrieved."
- (let* ((default-directory (expand-file-name org-attach-id-dir))
+ (let* ((default-directory (cond ((eq org-attach-git-dir 'default)
+ (expand-file-name org-attach-id-dir))
+ ((eq org-attach-git-dir 'individual-repository)
+ (org-attach-dir))))
(path-relative (file-relative-name path)))
(when (and (org-attach-git-use-annex)
(not
@@ -86,7 +106,10 @@ This checks for the existence of a \".git\" directory in that directory.
Takes an unused optional argument for the sake of being compatible
with hook `org-attach-after-change-hook'."
- (let* ((dir (expand-file-name org-attach-id-dir))
+ (let* ((dir (cond ((eq org-attach-git-dir 'default)
+ (expand-file-name org-attach-id-dir))
+ ((eq org-attach-git-dir 'individual-repository)
+ (org-attach-dir))))
(git-dir (vc-git-root dir))
(use-annex (org-attach-git-use-annex))
(changes 0))
^ permalink raw reply related [relevance 6%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 13:40 5% ` Ihor Radchenko
@ 2021-01-31 14:36 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-31 14:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> What is more tricky is making sure that workflow for people using the
> old behaviour is not broken. Just changing to (org-attach-dir) will
> break existing git repos in org-attach-id-dir. This should also not be
> too hard (say, we can introduce a custom variable defaulting to old
> behaviour), but exact details may need to be discussed.
I agree: I think a custom variable with the current behavior by default
would be fine.
> In any case, if you provide a patch, it will encourage the org
> maintainers to join this discussion and proceed with changes.
OK, this week I will try to propose a patch here, and bring it up for
(possible) discussion. Thanks for the suggestions.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 13:16 10% ` Juan Manuel Macías
@ 2021-01-31 13:40 5% ` Ihor Radchenko
2021-01-31 14:36 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2021-01-31 13:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Do you think a possible patch could simply consist of replacing (as I
> have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
> in `org-attach-git-commit'? This would allow you to handle attachment
> dirs as individual git repos, regardless of :ID: or :DIR: properties,
> since "[(org-attach-dir)] Return the directory associated with the
> current outline node. First check for DIR property, then ID property
> [...]".
All the instances of (expand-file-name org-attach-id-dir) should be
replaced. There are 3. That's not a big deal.
What is more tricky is making sure that workflow for people using the
old behaviour is not broken. Just changing to (org-attach-dir) will
break existing git repos in org-attach-id-dir. This should also not be
too hard (say, we can introduce a custom variable defaulting to old
behaviour), but exact details may need to be discussed.
In any case, if you provide a patch, it will encourage the org
maintainers to join this discussion and proceed with changes.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 10:52 5% ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
@ 2021-01-31 13:16 10% ` Juan Manuel Macías
2021-01-31 13:40 5% ` Ihor Radchenko
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-31 13:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> The other thing is that `org-attach-id-dir' makes much less sense from
> the time :DIR: property was introduced. So, I believe that
> org-attach-git should be updated. Probably, handling attachment dirs as
> individual git repos can be one of the ways to upgrade the current
> version. I guess, patches welcome.
Do you think a possible patch could simply consist of replacing (as I
have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
in `org-attach-git-commit'? This would allow you to handle attachment
dirs as individual git repos, regardless of :ID: or :DIR: properties,
since "[(org-attach-dir)] Return the directory associated with the
current outline node. First check for DIR property, then ID property
[...]".
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 10:52 5% ` Ihor Radchenko
@ 2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 10% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-31 11:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> I think you misunderstood how org-attach-git works.
>
> org-attach-git is:
>
> ;; An extension to org-attach. If `org-attach-id-dir' is initialized
> ;; as a Git repository, then org-attach-git will automatically commit
> ;; changes when it sees them. Requires git-annex.
>
> So, it is not designed to work when your actual attachment directory is
> a git repo, but rather when org-attach-id-dir is a git repo (initialised
> manually).
Thanks for the explanation: it is clear that I had misinterpreted
`org-attach-id-dir'. Now it makes sense that it didn't work for me.
Anyway, I think the manual at that point is somewhat ambiguous and it
should be more precise, IMHO.
> So, I believe that org-attach-git should be updated. Probably,
> handling attachment dirs as individual git repos can be one of the
> ways to upgrade the current version.
I agree, I think this possibility makes a lot more sense.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 10:29 9% ` Juan Manuel Macías
@ 2021-01-31 10:52 5% ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 10% ` Juan Manuel Macías
0 siblings, 2 replies; 144+ results
From: Ihor Radchenko @ 2021-01-31 10:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> But if I evaluate this, I get an 'incomplete' path:
I think you misunderstood how org-attach-git works.
org-attach-git is:
;; An extension to org-attach. If `org-attach-id-dir' is initialized
;; as a Git repository, then org-attach-git will automatically commit
;; changes when it sees them. Requires git-annex.
So, it is not designed to work when your actual attachment directory is
a git repo, but rather when org-attach-id-dir is a git repo (initialised
manually).
The other thing is that `org-attach-id-dir' makes much less sense from
the time :DIR: property was introduced. So, I believe that
org-attach-git should be updated. Probably, handling attachment dirs as
individual git repos can be one of the ways to upgrade the current
version. I guess, patches welcome.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: org-attach-git don't automatically commit changes
2021-01-31 3:33 5% ` Ihor Radchenko
@ 2021-01-31 10:29 9% ` Juan Manuel Macías
2021-01-31 10:52 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-31 10:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Does it mean that your attachment folder is set in :DIR: property?
No, my attachment folder is build using :ID: property. For example, in
my heading:
* Test
:PROPERTIES:
:ID: d0e690e2-2ecd-4224-891a-b91257db5389
:END:
And if I evaluate `org-attach-dir' here, it returns the correct path:
#+begin_src emacs-lisp
(org-attach-dir)
#+end_src
#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/d0/e690e2-2ecd-4224-891a-b91257db5389
But if I evaluate this, I get an 'incomplete' path:
#+begin_src emacs-lisp
(expand-file-name org-attach-id-dir)
#+end_src
#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/
So if I replace `(expand-file-name org-attach-id-dir)' with
`(org-attach-dir)' in `(org-attach-git-commit)' [line 7, the `dir'
variable], it works fine when I run 'C-c C-a z'.
Best regards
Juan Manuel
>
> I suspect that it is a leftover from the major changes in org-attach
> when :DIR: property was introduced. The org-attach-git presumes that all
> the attachments in current file are stored in sub-directories located
> inside org-attach-id-dir, which is no longer guaranteed. In fact, the
> existing approach to treat all the attachments to all headings in
> current file as files in a single git repo cannot be used. I can see two
> possible fixes:
> 1. Treat each attachment dir as individual git repo (breaking change for
> those who are using :ID: property to build the attachment dirs)
> 2. Treat attachment dirs defined by :DIR: property individually and
> leave the :ID:-defined attachments as they were treated before
> (inconsistent).
>
> I am in favour of the first approach since I do not like the idea of
> keeping all the attachments in the whole file in a single git repo.
> I think feedback from other is needed to decide what we need to do here.
>
> P.S. Marking this as a bug.
>
> Best,
> Ihor
>
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
2021-01-30 13:38 9% ` Juan Manuel Macías
@ 2021-01-31 3:33 5% ` Ihor Radchenko
2021-01-31 10:29 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2021-01-31 3:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The default value of `org-attach-id-dir' is "data/", and if I evaluate
> `(expand-file-name org-attach-id-dir)' on my current node, it returns a
> wrong path to the attached folder. `org-attach-sync' only works for me
> if I set in `org-attach-git-commit' the variable like this:
Does it mean that your attachment folder is set in :DIR: property?
> #+begin_src emacs-lisp
> ;; ...
> (let* ((dir (expand-file-name org-attach-id-dir))
> ;; ...
> #+end_src
I suspect that it is a leftover from the major changes in org-attach
when :DIR: property was introduced. The org-attach-git presumes that all
the attachments in current file are stored in sub-directories located
inside org-attach-id-dir, which is no longer guaranteed. In fact, the
existing approach to treat all the attachments to all headings in
current file as files in a single git repo cannot be used. I can see two
possible fixes:
1. Treat each attachment dir as individual git repo (breaking change for
those who are using :ID: property to build the attachment dirs)
2. Treat attachment dirs defined by :DIR: property individually and
leave the :ID:-defined attachments as they were treated before
(inconsistent).
I am in favour of the first approach since I do not like the idea of
keeping all the attachments in the whole file in a single git repo.
I think feedback from other is needed to decide what we need to do here.
P.S. Marking this as a bug.
Best,
Ihor
^ permalink raw reply [relevance 5%]
* Re: org-attach-git don't automatically commit changes
2021-01-30 5:10 6% ` Ihor Radchenko
@ 2021-01-30 13:38 9% ` Juan Manuel Macías
2021-01-31 3:33 5% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-30 13:38 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi Ihor,
Ihor Radchenko <yantar92@gmail.com> writes:
> Note that org "sees" changes in the attachment dir only when you use
> M-x org-attach command to manage the attachments. Directly changing the
> attachment directory will not be noticed. You can force org-mode to
> check for changes in attachment dir by running "C-c C-a z".
Thanks for the explanation. It seems that I had misinterpreted
what the manual said :-)
Anyway, in my case, it still doesn't work (?). I think it's for a path
problem. In `org-attach-git-commit' there is this variable:
#+begin_src emacs-lisp
;; ...
(let* ((dir (expand-file-name org-attach-id-dir))
;; ...
#+end_src
The default value of `org-attach-id-dir' is "data/", and if I evaluate
`(expand-file-name org-attach-id-dir)' on my current node, it returns a
wrong path to the attached folder. `org-attach-sync' only works for me
if I set in `org-attach-git-commit' the variable like this:
#+begin_src emacs-lisp
;; ...
(let* ((dir (org-attach-dir)) ;; <====
;; ...
#+end_src
In that case, it does recognize the path correctly. Again, I don't
know if I'm missing something...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: org-attach-git don't automatically commit changes
2021-01-29 16:03 9% org-attach-git don't automatically commit changes Juan Manuel Macías
@ 2021-01-30 5:10 6% ` Ihor Radchenko
2021-01-30 13:38 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Ihor Radchenko @ 2021-01-30 5:10 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I don't see that org-attach "automatically commit changes when it sees
> them". Only when I run in the attached directory `M-:
> (org-attach-git-commit) RET' it works fine.
Note that org "sees" changes in the attachment dir only when you use
M-x org-attach command to manage the attachments. Directly changing the
attachment directory will not be noticed. You can force org-mode to
check for changes in attachment dir by running "C-c C-a z".
I guess using something like inotify might be a good new feature to
make org detect changes automatically.
Best,
Ihor
^ permalink raw reply [relevance 6%]
* org-attach-git don't automatically commit changes
@ 2021-01-29 16:03 9% Juan Manuel Macías
2021-01-30 5:10 6% ` Ihor Radchenko
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-29 16:03 UTC (permalink / raw)
To: orgmode
Hi,
I don't know if this is a bug or if I am doing something wrong...
According to the manual:
#+begin_quote
If the directory attached to an outline node is a Git
repository, Org can be configured to automatically commit changes to
that repository when it sees them.
To make Org mode take care of versioning of attachments for you, add the
following to your Emacs config:
(require 'org-attach-git)
#+end_quote
I don't see that org-attach "automatically commit changes when it sees
them". Only when I run in the attached directory `M-:
(org-attach-git-commit) RET' it works fine.
`org-attach-after-change-hook' is set to `(org-attach-git-commit)'.
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-25 17:46 9% ` Juan Manuel Macías
@ 2021-01-25 18:30 5% ` Gustavo Barros
0 siblings, 0 replies; 144+ results
From: Gustavo Barros @ 2021-01-25 18:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On Mon, 25 Jan 2021 at 14:46, Juan Manuel Macías
<maciaschain@posteo.net> wrote:
>
> By the way... I have written some code to export the citations using
> make4ht. It's just a proof of concept, and not too elegant I'm afraid.
> But I wanted to explore a bit more the use of make4ht in this context.
>
Nice! I also think make4ht has potential for this
purpose. tex4ht/make4ht is usually a somewhat delicate tool for a
general LaTeX document (powerful, but complex), but the typical output
of citation and bibliography is text with emphasis/bold etc, and perhaps
a list, if we interpret the bibliography environment strictly. This is
much simpler (again, typically) than an arbitrary document, to the point
I believe it could be streamlined reliably for this subset of the
document.
> The idea is to write the citations in Org as mere bibLaTeX commands,
> but
> between !!- ... -!! (a provisional regexp, for convenience, and to see
> if it works). It can be tested in this Org file, which includes the
> code
> (you have to give a value to the variables `bib' and `preamble'):
>
> https://gitlab.com/-/snippets/2066135
>
I understand using the regexp to separate the problems, provisionally,
as you said. If it evolves, you might wish to go with the current state
of things in the wip-cite branch or, I reiterate the suggestion, look at
latex-preview, which allows you to specify the commands of interest, if
I recall correctly.
I hope you find your way trough the approach. If you do, please let me
know. Or, if you wish to discuss a particular issue, feel free to write
me directly.
Best regards,
Gustavo.
^ permalink raw reply [relevance 5%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-24 22:44 4% ` Gustavo Barros
@ 2021-01-25 17:46 9% ` Juan Manuel Macías
2021-01-25 18:30 5% ` Gustavo Barros
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-25 17:46 UTC (permalink / raw)
To: Gustavo Barros; +Cc: orgmode
Hi Gustavo,
Gustavo Barros <gusbrs.2016@gmail.com> writes:
> I'd also would love to see that. ;-)
>
> And I do think Org is, by far, the best placed tool to fill this
> place. But I also think citations and bibliography are a big
> bottleneck in that regard. Of course, there is a long ongoing effort
> in that area, in the `wip-cite' branch, and the related `org-citeproc'
> package. I'm still in the hope this will get merged in future not too
> distant, as it would change things in that regard. Not in the sense
> of "magically solving all of these problems", but in providing a
> convened base upon which people can than invest their time and effort,
> and try to figure each case out, with time.
I totally agree.
By the way... I have written some code to export the citations using
make4ht. It's just a proof of concept, and not too elegant I'm afraid.
But I wanted to explore a bit more the use of make4ht in this context.
The idea is to write the citations in Org as mere bibLaTeX commands, but
between !!- ... -!! (a provisional regexp, for convenience, and to see
if it works). It can be tested in this Org file, which includes the code
(you have to give a value to the variables `bib' and `preamble'):
https://gitlab.com/-/snippets/2066135
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-24 19:20 6% ` Juan Manuel Macías
@ 2021-01-24 22:44 4% ` Gustavo Barros
2021-01-25 17:46 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Gustavo Barros @ 2021-01-24 22:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
On Sun, 24 Jan 2021 at 16:20, Juan Manuel Macías
<maciaschain@posteo.net> wrote:
> I agree with what you comment here and in your previous message. In
> fact, I'm afraid this (humble) approach of mine is focused only on
> creating a mere list of references in HTML from a bib file, keeping
> the
> same bibliography styles that I have customized in bibLaTeX, but not
> on
> everything related to citations throughout the text and on the
> consistency between citations and bibliographies. I would say that my
> method is not a good starting point to implement a solution. [...]
>
> In my case, anyway, I had been using the TeX ecosystem almost
> exclusively for my work in typesetting and editorial design (I do not
> use DTP software, which is not intended to create books but magazines
> and newspapers), and Org Mode for writing and notes. But in recent
> years
> I have come to realize that a workflow based also on Org and
> Org-Publish
> is tremendously productive for me to manage the typesetting of a book,
> especially a complex book. Let's say now I also use Org as a
> high-level
> interface for LaTeX. I'm currently working on the /Hispanic Dictionary
> of Classical Tradition/ (/Diccionario Hispánico de la Tradición
> Clásica/), a volume of multiple authorship and about 1200 pages. The
> method I raised in this thread has to do with this scenario, where
> each
> dictionary entry is accompanied by a bibliography. As the dictionary
> will have an online secondary version, I wanted to keep the same
> bibliography style that I had defined for bibLaTeX. I have not had the
> problem of the citations here, since the entries do not contain
> citations (bibliographies only). Otherwise, I think an emergency
> solution could be to export from Org to *.tex, and then generate the
> HTML from there using make4ht and another preamble /ad hoc/, better
> than
> using a mixed csl/bibLaTeX method which, as you say, can result in
> many
> inconsistencies.
Well, I think your approach should work quite well for your use case,
and certainly a number of others. It is just a matter of being aware of
the limitations of the tool. That given, it is great. Of course, I was
also curious how you had figured things from a more general perspective.
> The
> essential problem, of course, is that our customization is
> LaTeXcentric:
> it resides in LaTeX/bibLaTeX and not in Org. [...]
>
I think it is more than just being "LaTeXcentric". Depending on
requirements, there is really no choice. We don't hear this often, but
the fact is that Org does not support citation and bibliography by
itself. A lot of things "work", and in many requirements scenarios that
seems to be enough, but what does work relies on outsourcing that task
to other tools. As far as I know, there are only two ways out of an Org
document with citation and bibliography: LaTeX (and its related tools:
bibtex, biblatex, biber, etc), and pandoc (which uses CSL to process
these features). The first option is extremely featureful, but
restricts us to .pdf output. The only sufficiently general option with
multi output is then pandoc, which in turn bypasses the whole Org export
infrastructure, implying its own trade-offs because of that. Besides,
there is no real link between the LaTeX infrastructure and pandoc/CSL,
so that if you want to reach "best results in LaTeX, and acceptable
results in other formats", you are bound to live with differences in
output for citation/references across formats and to remain under the
restrictions of the least featureful backend.
> Long ago I tended to be more in favor of the idea that a single
> source-text should produce multiple identical or interchangeable
> formats. I really still believe it with enthusiasm and I have not
> completely lost faith in such a utopia ;-)
I'd also would love to see that. ;-)
And I do think Org is, by far, the best placed tool to fill this place.
But I also think citations and bibliography are a big bottleneck in that
regard. Of course, there is a long ongoing effort in that area, in the
`wip-cite' branch, and the related `org-citeproc' package. I'm still in
the hope this will get merged in future not too distant, as it would
change things in that regard. Not in the sense of "magically solving
all of these problems", but in providing a convened base upon which
people can than invest their time and effort, and try to figure each
case out, with time.
Best regards,
Gustavo.
^ permalink raw reply [relevance 4%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
@ 2021-01-24 19:20 6% ` Juan Manuel Macías
2021-01-24 22:44 4% ` Gustavo Barros
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-24 19:20 UTC (permalink / raw)
To: Gustavo Barros; +Cc: orgmode
Hi Gustavo,
Thank you for your interesting comments.
Gustavo Barros <gusbrs.2016@gmail.com> writes:
> On Sun, 24 Jan 2021 at 08:37, Gustavo Barros <gusbrs.2016@gmail.com>
> wrote:
>
>> It should handle two limitations of your procedure, which
>> are: getting the bibliography with the entries actually cited in the
>> document and citation callouts. The first one is easy to handle in
>> your
>> current approach by means of any of the multiple alternatives to
>> generate a bib file with only the cited entries. The second one, much
>> harder, as far as I can see.
>
> Thinking this through: there is actually a third challenge to the
> approach, which is ensuring the relation of the citation callouts and
> the bibliography is correct. For example, if using a numeric or alpha
> style, how to be sure the labels are the same in the citation and the
> bibliography. Even in other styles, such as author-year, if
> disambiguation rules come into play (e.g. (Smith 1987a, Smith 1987b)),
> how to be sure the same rules are being applied by pandoc/CSL (on the
> citations) and biblatex (in the bibliography). As far as I can tell,
> this will hang on sorting, something which biblatex is known to be
> more capable than other tools, so that I would expect differences (at
> least potentially). Styles such as verbose or author-title would
> probably be safe, I guess. Have you given some thought about this?
> If so, how are you handling the case?
>
I agree with what you comment here and in your previous message. In
fact, I'm afraid this (humble) approach of mine is focused only on
creating a mere list of references in HTML from a bib file, keeping the
same bibliography styles that I have customized in bibLaTeX, but not on
everything related to citations throughout the text and on the
consistency between citations and bibliographies. I would say that my
method is not a good starting point to implement a solution. The
essential problem, of course, is that our customization is LaTeXcentric:
it resides in LaTeX/bibLaTeX and not in Org.
In my case, anyway, I had been using the TeX ecosystem almost
exclusively for my work in typesetting and editorial design (I do not
use DTP software, which is not intended to create books but magazines
and newspapers), and Org Mode for writing and notes. But in recent years
I have come to realize that a workflow based also on Org and Org-Publish
is tremendously productive for me to manage the typesetting of a book,
especially a complex book. Let's say now I also use Org as a high-level
interface for LaTeX. I'm currently working on the /Hispanic Dictionary
of Classical Tradition/ (/Diccionario Hispánico de la Tradición
Clásica/), a volume of multiple authorship and about 1200 pages. The
method I raised in this thread has to do with this scenario, where each
dictionary entry is accompanied by a bibliography. As the dictionary
will have an online secondary version, I wanted to keep the same
bibliography style that I had defined for bibLaTeX. I have not had the
problem of the citations here, since the entries do not contain
citations (bibliographies only). Otherwise, I think an emergency
solution could be to export from Org to *.tex, and then generate the
HTML from there using make4ht and another preamble /ad hoc/, better than
using a mixed csl/bibLaTeX method which, as you say, can result in many
inconsistencies.
Long ago I tended to be more in favor of the idea that a single
source-text should produce multiple identical or interchangeable
formats. I really still believe it with enthusiasm and I have not
completely lost faith in such a utopia ;-) But nuances are necessary and
it must be accepted that each format has its idiosyncrasies and
limitations. For example, TeX and what TeX produces is at a level (let's
say) higher than what can be achieved through HTML/CSS, odt, epub... It
is not only a question of typographic refinement or fancy appearance
(typical of TeX), but also (in my opinion) of the book typography itself as a
form of expression. The other formats will often lag behind TeX, and
this must be taken into account when exporting, pros and cons, etc. On
the other hand, bibLaTeX is powerful and highly customizable, but sadly
depends on LaTeX...
Regards,
Juan Manuel
> Best,
> Gustavo.
>
^ permalink raw reply [relevance 6%]
* Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
2021-01-23 11:03 7% [Tip] Export a bibliography to HTML with bibLaTeX and make4ht Juan Manuel Macías
@ 2021-01-24 11:37 4% ` Gustavo Barros
0 siblings, 1 reply; 144+ results
From: Gustavo Barros @ 2021-01-24 11:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
that's very interesting. Thanks for sharing.
On Sat, 23 Jan 2021 at 12:03, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> When I export to LaTeX an Org document that contains a bibliography, I
> use bibLaTeX with a very custom style (i.e. quite a few lines of code
> related to bibLaTeX in the preamble). I wanted to apply all that
> bibLaTeX setting and styles when exporting to HTML too, so I came up
> with this method, using make4ht. I share it here, in case it is useful
> to someone.
>
> The idea is to compile with make4ht (see:
> https://www.ctan.org/pkg/make4ht) a simple file with *only* the
> bibliography, and "embed" the HTML output in the Org document. You need
> to create in the working directory a tex file, which will serve as a
> minimal preamble and which also includes all code related to bibLaTeX.
> We can name it preamble.tex, and it would start like this:
Indeed, when one actually needs biblatex-biber to process their
bibliography, using Org is really hard. I have some history with this
problem, as I initially approached Emacs (once upon a time) trying to
use Org as a single source and multiple outputs (mainly pdf and odt).
However, as you, I rely on heavily customized styles, which simply won't
work with pandoc/CSL, so I got stuck. I eventually stayed in Emacs and
use Org for a number of things, but for my more formal writing use
AUCTeX + RefTeX, which is great too (alas, no odt..., at least not
easily).
For a long time I fancied trying something about it, pretty much in the
same lines as you are doing here. My idea was to use `preview-latex'
for this, which I still think is promising and, as far as I understand,
pretty much automates what you are doing, which is to generate a
stripped document, with a proper preamble, and run it on a piece of your
actual document. It is used by AUCTeX and LyX (Org too, I presume) to
generate images, but I don't see why it could not be streamlined to
generate a dvi which could then be fed to tex4ht and friends, just as
you do too. I thought that this procedure could, in principle, be used
to export to other formats, but also to Org itself, generating either a
second version of the source document with the citations and
bibliography already processed as text (sort of a
'org-biblatex-citeproc'), or as a preview, such as the ones for math.
Depending on how far you are willing to take your setup, this might be
one path. It should handle two limitations of your procedure, which
are: getting the bibliography with the entries actually cited in the
document and citation callouts. The first one is easy to handle in your
current approach by means of any of the multiple alternatives to
generate a bib file with only the cited entries. The second one, much
harder, as far as I can see.
To my dismay, my own style customizations for biblatex are mainly aimed
at citations (primary/archival sources for Economic History). But it
was quite interesting to see your approach here. So, again, thank you.
Best,
Gustavo.
^ permalink raw reply [relevance 4%]
* [Tip] Export a bibliography to HTML with bibLaTeX and make4ht
@ 2021-01-23 11:03 7% Juan Manuel Macías
2021-01-24 11:37 4% ` Gustavo Barros
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-23 11:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
Hi,
When I export to LaTeX an Org document that contains a bibliography, I
use bibLaTeX with a very custom style (i.e. quite a few lines of code
related to bibLaTeX in the preamble). I wanted to apply all that
bibLaTeX setting and styles when exporting to HTML too, so I came up
with this method, using make4ht. I share it here, in case it is useful
to someone.
The idea is to compile with make4ht (see:
https://www.ctan.org/pkg/make4ht) a simple file with *only* the
bibliography, and "embed" the HTML output in the Org document. You need
to create in the working directory a tex file, which will serve as a
minimal preamble and which also includes all code related to bibLaTeX.
We can name it preamble.tex, and it would start like this:
#+begin_src latex
\documentclass{article}
\usepackage{fontspec}
\usepackage[<whatever-language>]{babel}
\usepackage[backend=biber,style=authortitle,dashed=true,sorting=nyt]{biblatex}
%% more code related to bibLaTeX...
#+end_src
We also need a small lua file that will control the make4ht compilation.
If we run make4ht in draft mode it will not call Biber. This file can be
named build.lua:
#+begin_src lua
if mode=="draft" then
Make:htlatex {}
else
Make:htlatex {}
Make:biber {}
Make:htlatex {}
end
#+end_src
And finally, this function is defined in Elisp, which takes two
arguments: the preamble-file and the *.bib file to generate the list of
references. The optional draft argument is for make4ht to run in draft
mode (that is, so you don't rebuild the bibliography). In the end Pandoc
is executed with shell output to simplify the resulting HTML:
#+begin_src emacs-lisp
(defun my-biblio-html (preamble bib &optional draft)
(when (org-export-derived-backend-p org-export-current-backend 'html)
(let ((file (file-name-sans-extension bib))
(d (if draft
"-m draft "
"")))
(shell-command (concat
"echo \"\\input{"
preamble
"}"
"\\addbibresource{"
bib
"}"
"\\begin{document}
\\nocite{*}
\\printbibliography[heading=none]
\\end{document}\" > "
file "-bib.tex"))
(shell-command-to-string (concat "make4ht -ule build.lua "
d
file
"-bib.tex > /dev/null && "
"pandoc -f html -t html "
file
"-bib.html")))))
#+end_src
An example:
#+begin_src org
,#+HTML_HEAD: <style> dd { text-indent: -2em; margin-left: 2em; } </style>
,#+HTML_HEAD: <style> .rm-lmri-12{ font-style:italic;} </style>
,* References
,#+begin_src emacs-lisp :exports results :results html
(my-biblio-html "preamble.tex" "file.bib")
,#+end_src
#+end_src
As you can see, the method is somewhat tricky, but it works well, for now. I hope that
be useful!
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 7%]
* Re: Dealing with wide labels in description environment
2021-01-22 11:20 9% ` Juan Manuel Macías
@ 2021-01-22 12:37 6% ` Loris Bennett
0 siblings, 0 replies; 144+ results
From: Loris Bennett @ 2021-01-22 12:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello,
>
> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>> I have tried tweaking options such as labelindent and labelwidth in a
>> somewhat haphazard manner with, say,
>>
>> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>>
>> but most of my attempts seem to have the main effect of just shifting
>> the whole list to the right without right-justifying the labels.
>
> The question is more on the side of LaTeX, and the enumitem package
> (which you must have loaded for those options. See:
> https://www.ctan.org/pkg/enumitem). For the effect you are looking for
> you can try this (for horizontal lengths, it is better to use 'em' than
> 'ex):
Yes, of course - using Org for a decade so or has helped me avoid and thus
forget about certain LaTeX details.
> #+LATEX_HEADER: \usepackage{enumitem}
>
> #+attr_latex: :options
> [labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
> - short label :: this looks fine
> - very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer adipiscing
> elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl,
> tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
> dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam
> tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum
> accumsan nisl.
Thank, that's what I needed - 'leftmargin' seems to be the main thing
that was missing.
Gruß
Loris
--
This signature is currently under construction.
^ permalink raw reply [relevance 6%]
* Re: Dealing with wide labels in description environment
@ 2021-01-22 11:20 9% ` Juan Manuel Macías
2021-01-22 12:37 6% ` Loris Bennett
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-22 11:20 UTC (permalink / raw)
To: Loris Bennett; +Cc: orgmode
Hello,
"Loris Bennett" <loris.bennett@fu-berlin.de> writes:
> I have tried tweaking options such as labelindent and labelwidth in a
> somewhat haphazard manner with, say,
>
> #+attr_latex: :options [labelindent=0pt, labelwidth=10ex]
>
> but most of my attempts seem to have the main effect of just shifting
> the whole list to the right without right-justifying the labels.
The question is more on the side of LaTeX, and the enumitem package
(which you must have loaded for those options. See:
https://www.ctan.org/pkg/enumitem). For the effect you are looking for
you can try this (for horizontal lengths, it is better to use 'em' than
'ex):
#+LATEX_HEADER: \usepackage{enumitem}
#+attr_latex: :options [labelindent=0em,itemindent=0em,align=right,labelwidth=10em,labelsep=.5em,leftmargin=15.5em]
- short label :: this looks fine
- very annoying overly long label :: Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl,
tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam
tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum
accumsan nisl.
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Region-based meta-notes
@ 2021-01-19 22:39 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-19 22:39 UTC (permalink / raw)
To: Lawrence Bottorff; +Cc: orgmode
Hello,
Lawrence Bottorff <borgauf@gmail.com> writes:
> So yes, simply being able to select regions and make side notes about
> them could give you a very fine level of control over metadata in a
> file. Is there such a thing in the Emacs/org-mode world?
Take a look at the org-marginalia package:
https://github.com/nobiot/org-marginalia
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
2021-01-09 17:42 10% ` Juan Manuel Macías
@ 2021-01-13 1:16 6% ` Jason Ross
0 siblings, 0 replies; 144+ results
From: Jason Ross @ 2021-01-13 1:16 UTC (permalink / raw)
To: emacs-orgmode
I'm happy to hear you're able to use it! Any feedback or criticism
is appreciated, and I'd like to know what your output format looks
like if you're able to share.
Thanks,
Jason
On 1/9/21 9:42 AM, Juan Manuel Macías wrote:
> Hello, Jason,
>
> Jason Ross <jasonross1024@gmail.com> writes:
>
>> I recently had the same thought and I've started working on one.
>> You can see it here:
>>
>> https://github.com/Jason-S-Ross/ox-context/
>>
>> It's no substitute for the LaTeX exporter but it implements a lot
>> of the basics. I'm deriving from the LaTeX exporter but I have
>> to override most of the transcoders so it may be better to start
>> from scratch.
>>
>> Disclaimer: I'm learning elisp as I go, so please excuse the
>> rough edges.
>
> That's great news! I've been testing it a bit and it works very good. Of
> course, I encourage you to keep up this excellent work.
>
> Regards,
>
> Juan Manuel
>
>>
>> Jason Ross
>>
>
^ permalink raw reply [relevance 6%]
* A minor mode for inserting things while typing
@ 2021-01-12 22:30 9% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-12 22:30 UTC (permalink / raw)
To: orgmode
Hi,
I've written a 'lazy' minor mode for inserting things while typing
(without leave the comfort zone of the keyboard) especially when you are
at the end of a paragraph and then you want to insert a block, a list, a
table, a footnote, etc. The idea is: you type ",,," plus one character
-> a white line (with org-return) is inserted -> (depending on the
character typed) something is inserted. For example: ",,,h" inserts a
new heading at the same level; ",,,t", a TODO heading; ",,,-", a list;
",,,1", a numbered list; ",,,k", a check box list; ",,,:", a description
list; ",,,s", a source block; ",,,q", a quote block; ",,,|", a table
(calling org-table-create); ",,,f", a footnote. And so on.
It's a way to insert things that I find more comfortable (in certain
scenarios) than using `org-tempo'.
In case it could be useful to someone, I share it in this GitLab
snippet: https://gitlab.com/-/snippets/2060125
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org to ConTeXt exporter?
2021-01-08 2:37 5% ` Jason Ross
@ 2021-01-09 17:42 10% ` Juan Manuel Macías
2021-01-13 1:16 6% ` Jason Ross
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-09 17:42 UTC (permalink / raw)
To: Jason Ross; +Cc: orgmode
Hello, Jason,
Jason Ross <jasonross1024@gmail.com> writes:
> I recently had the same thought and I've started working on one.
> You can see it here:
>
> https://github.com/Jason-S-Ross/ox-context/
>
> It's no substitute for the LaTeX exporter but it implements a lot
> of the basics. I'm deriving from the LaTeX exporter but I have
> to override most of the transcoders so it may be better to start
> from scratch.
>
> Disclaimer: I'm learning elisp as I go, so please excuse the
> rough edges.
That's great news! I've been testing it a bit and it works very good. Of
course, I encourage you to keep up this excellent work.
Regards,
Juan Manuel
>
> Jason Ross
>
--
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
2021-01-08 2:37 5% ` Jason Ross
@ 2021-01-08 3:52 6% ` Jason Ross
2 siblings, 0 replies; 144+ results
From: Jason Ross @ 2021-01-08 3:52 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
On 12/28/20 5:38 AM, Juan Manuel Macías wrote:
> Hi,
>
> Just out of curiosity, I am wondering if there are plans to create an
> Org to ConTeXt exporter in the future, or if there is already some work
> in progress on this front.
>
> I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> but ConTeXt has very interesting features (grid typesetting, for
> example) that LaTeX lacks (for now) and has a more monolithic structure,
> that is, it does not need to be extended through packages as in LaTeX.
>
> Regards,
>
> Juan Manuel
>
I recently had the same thought and I've started working on one.
You can see it here:
https://github.com/Jason-S-Ross/ox-context/
It's no substitute for the LaTeX exporter but it implements a lot
of the basics. I'm deriving from the LaTeX exporter but I have
to override most of the transcoders so it may be better to start
from scratch.
Disclaimer: I'm learning elisp as I go, so please excuse the
rough edges.
Jason Ross
^ permalink raw reply [relevance 6%]
* Re: Org to ConTeXt exporter?
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
@ 2021-01-08 2:37 5% ` Jason Ross
2021-01-09 17:42 10% ` Juan Manuel Macías
2021-01-08 3:52 6% ` Jason Ross
2 siblings, 1 reply; 144+ results
From: Jason Ross @ 2021-01-08 2:37 UTC (permalink / raw)
To: maciaschain; +Cc: emacs-orgmode
On 2020-12-28, at 14:38, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> Just out of curiosity, I am wondering if there are plans to create an
> Org to ConTeXt exporter in the future, or if there is already some work
> in progress on this front.
>
> I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> but ConTeXt has very interesting features (grid typesetting, for
> example) that LaTeX lacks (for now) and has a more monolithic structure,
> that is, it does not need to be extended through packages as in LaTeX.
I recently had the same thought and I've started working on one.
You can see it here:
https://github.com/Jason-S-Ross/ox-context/
It's no substitute for the LaTeX exporter but it implements a lot
of the basics. I'm deriving from the LaTeX exporter but I have
to override most of the transcoders so it may be better to start
from scratch.
Disclaimer: I'm learning elisp as I go, so please excuse the
rough edges.
Jason Ross
^ permalink raw reply [relevance 5%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-01-03 13:08 5% ` TEC
@ 2021-01-07 18:52 5% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-07 18:52 UTC (permalink / raw)
To: orgmode; +Cc: TEC
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hi,
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...
A short reminder: `lines', `versewidth', and `center' require loading
the LaTeX package verse.sty (https://www.ctan.org/pkg/verse), which is
an extension of the standard LaTeX `verse' environment, and that adds
many features for typesetting poetry. `lines' deals with the marginal
verse numbering; `versewidth' and `center' are related to the optical
centering of the poem. The fourth attribute is to include arbitrary
LaTeX code within the verse environment, so I have provisionally named
it `latexcode'.
Of course, Feedback is welcome.
Regards,
Juan Manuel
[-- Attachment #2: verse-block-patch.diff --]
[-- Type: text/x-patch, Size: 5182 bytes --]
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b015b502c..fe21b5aca 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13870,6 +13870,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/etc/ORG-NEWS b/etc/ORG-NEWS
index 5e5f1954d..47e0ec40e 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -149,6 +149,19 @@ Example:
A new =u= mode flag for Calc formulas in Org tables has been added to
enable Calc units simplification mode.
+*** LaTeX attributes for verse blocks
+
+The LaTeX export back-end now accepts four attributes for verse
+blocks:
+
+- =:lines=, for marginal verse numbering;
+- =:center= and =:versewidth=, for optical centering of the verses;
+- =:latexcode=, for any arbitrary LaTeX code that can be included
+ within a LaTeX =verse= environment.
+
+The three first require the external LaTeX package =verse.sty=, wich
+is an extension of the standard LaTeX environment.
+
** Miscellaneous
*** =org-goto-first-child= now works before first heading
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index fb9fc3cd6..0931b7e9c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,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
@@ -3513,19 +3524,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
[-- Attachment #3: Type: text/plain, Size: 1827 bytes --]
TEC <tecosaur@gmail.com> writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Thank you very much for your response and your comments.
>
> Seriously, thanks for the patch. I think the ML is usually a bit more
> responsive, but it seems to be a bit quiet at the moment.
>
>> I agree to name "Insert, include, etc." the attribute to include
>> arbitrary LaTeX code, better than "options".
>
> Glad my feedback seems to have gone down well :). If the only likely use
> of this is adjusting the font, perhaps for the sake of consistency we
> can match the behaviour of tables, which take a :font LaTeX attribute?
>
>> Of course, I can add the necessary documentation to the files you tell
>> me. As I am new to submitting patches, I don't really know how to
>> proceed: do I have to send you the new version of the patch, with the
>> documentation? Should I send a new email with all of it to this list?
>
> Thanks for asking. Sometimes it seems the maintainers take the trouble of
> adding an ORG-NEWS entry or minor touching ups to the patch, but I think
> it's nice to leave as little for them to do as possible :)
>
> Announce changes in: etc/ORG-NEWS
> Document new/different behaviour in: doc/org-manual.org
>
> I think Markup for /Rich Contents > Paragraphs/ may be the right place
> to add a description of this functionality --- verse blocks are
> discussed around line 10750.
>
> Regarding how patches on this ML work, this is what I've observed:
> - Initial version of patch submitted, with justification/explanation
> - Feedback may be given
> - Revisions of the patch are attached in replies to feedback
> - Process repeats until everyone's happy
> - Patch is merged
>
> i.e. it all tends to happen in the same thread.
>
> Hope this helps,
>
> Timothy.
>
^ permalink raw reply related [relevance 5%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 15:58 10% ` Juan Manuel Macías
@ 2021-01-06 16:00 6% ` Mart van de Wege
0 siblings, 0 replies; 144+ results
From: Mart van de Wege @ 2021-01-06 16:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Wed, 2021-01-06 at 16:58 +0100, Juan Manuel Macías wrote:
> Mart van de Wege <mart@vdwege.eu> writes:
> > Can I just clone the repo and prepare a patch?
>
> As far as I know, you can create a diff and propose the patch here in
> the list, opening a new thread, that includes in the mail subject
> something like "[patch] etc"
Nice. I will make some time then this week. Should my mail follow the
guidelines for commit messages?
Regards,
Mart
^ permalink raw reply [relevance 6%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 12:24 10% ` Juan Manuel Macías
@ 2021-01-06 15:17 6% ` Mart van de Wege
2021-01-06 15:58 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Mart van de Wege @ 2021-01-06 15:17 UTC (permalink / raw)
To: Juan Manuel Macías, Mart van de Wege; +Cc: orgmode
On Wed, 2021-01-06 at 13:24 +0100, Juan Manuel Macías wrote:
> Mart van de Wege <mvdwege@gmail.com> writes:
>
> > Kind of weird it's not mentioned in the docs though (at least not
> > in
> > the same section as export filters); if you're going to tell people
> > that
> > you can bind local functions to an org file, then it might be nice
> > to
> > point out that you do need to turn that on.
>
> You're right. I think an addition could be proposed in the
> documentation: for example, a footnote in the section `Defining
> filters
> for individual files', since by default the variable
> `org-export-allow-bind-keywords' has value nil.
You're right. I looked up the variable, and there is only one mention
in the docs, and that is about binding emacs variables locally to the
org file buffer.
Can I just clone the repo and prepare a patch?
Regards,
Mart van de Wege
^ permalink raw reply [relevance 6%]
* Re: Possibility to copy text outside EMACS and send it to orgmode document
@ 2021-01-06 16:31 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2021-01-06 16:31 UTC (permalink / raw)
To: Gerardo Moro; +Cc: orgmode
Gerardo Moro <gerardomoro37@gmail.com> writes:
> Basically that: as I copy (Control-C) text from the browser (Chrome),
> I would like those copied sentences to be sent to a ordered list in an
> OrgMode document:
>
> - copied text 1
> - copied text 2
> - etc.
>
> Any ideas? This would be very useful.
> Thanks!
I don't know if it is exactly what you are looking for, but maybe you
might be interested in this extension for chrome and firefox that uses
org-protocol:
https://github.com/sprig/org-capture-extension
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 15:17 6% ` Mart van de Wege
@ 2021-01-06 15:58 10% ` Juan Manuel Macías
2021-01-06 16:00 6% ` Mart van de Wege
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-06 15:58 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mart@vdwege.eu> writes:
> You're right. I looked up the variable, and there is only one mention
> in the docs, and that is about binding emacs variables locally to the
> org file buffer.
>
> Can I just clone the repo and prepare a patch?
As far as I know, you can create a diff and propose the patch here in
the list, opening a new thread, that includes in the mail subject
something like "[patch] etc"
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 12:00 6% ` Mart van de Wege
@ 2021-01-06 12:24 10% ` Juan Manuel Macías
2021-01-06 15:17 6% ` Mart van de Wege
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-06 12:24 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mvdwege@gmail.com> writes:
> Kind of weird it's not mentioned in the docs though (at least not in
> the same section as export filters); if you're going to tell people that
> you can bind local functions to an org file, then it might be nice to
> point out that you do need to turn that on.
You're right. I think an addition could be proposed in the
documentation: for example, a footnote in the section `Defining filters
for individual files', since by default the variable
`org-export-allow-bind-keywords' has value nil.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 11:51 10% ` Juan Manuel Macías
@ 2021-01-06 12:00 6% ` Mart van de Wege
2021-01-06 12:24 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Mart van de Wege @ 2021-01-06 12:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Wed, 06 Jan 2021 12:51:00 +0100
Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Mart van de Wege <mvdwege@gmail.com> writes:
>
> > Thanks!
> >
> > But see my answer to Nick Dokos on the list, that does not do
> > anything either.
>
> Try putting this variable in your .emacs with non-nil value:
>
> (setq org-export-allow-bind-keywords t)
>
Well whaddayaknow? That works.
Kind of weird it's not mentioned in the docs though (at least not in
the same section as export filters); if you're going to tell people that
you can bind local functions to an org file, then it might be nice to
point out that you do need to turn that on.
Regards,
Mart
^ permalink raw reply [relevance 6%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-06 7:50 6% ` Mart van de Wege
@ 2021-01-06 11:51 10% ` Juan Manuel Macías
2021-01-06 12:00 6% ` Mart van de Wege
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-06 11:51 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Mart van de Wege <mvdwege@gmail.com> writes:
> Thanks!
>
> But see my answer to Nick Dokos on the list, that does not do anything
> either.
Try putting this variable in your .emacs with non-nil value:
(setq org-export-allow-bind-keywords t)
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Inserting LaTex expressions using a filter fails
2021-01-05 21:58 10% ` Juan Manuel Macías
@ 2021-01-06 7:50 6% ` Mart van de Wege
2021-01-06 11:51 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Mart van de Wege @ 2021-01-06 7:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Tue, 05 Jan 2021 22:58:33 +0100
Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hello,
>
> Mart van de Wege <mvdwege@gmail.com> writes:
>
> > I'm trying to replace U+00BD in an org buffer with \sfrac{1}{2}
> > during export to LaTex, and obviously I'm doing something wrong, or
> > I don't understand the documentation.
> >
> > I use the following code to set up the filter:
> >
> > #+BIND: org-export-filter-item-functions (latex-replace-half)
> > #+BEGIN_SRC emacs-lisp :exports results :results none
> >
> > (defun latex-replace-half (text backend info)
> > (when (org-export-derived-backend-p backend 'latex)
> > (replace-regexp-in-string "½" "\\sfrac{1}{2}" text)))
> > #+END_SRC
>
> You must add a double escape character to the backslash:
>
> ...
> (replace-regexp-in-string "½" "\\\\sfrac{1}{2}" text)))
> ...
>
Thanks!
But see my answer to Nick Dokos on the list, that does not do anything
either.
Regards,
Mart
^ permalink raw reply [relevance 6%]
* Re: Inserting LaTex expressions using a filter fails
@ 2021-01-05 21:58 10% ` Juan Manuel Macías
2021-01-06 7:50 6% ` Mart van de Wege
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-05 21:58 UTC (permalink / raw)
To: Mart van de Wege; +Cc: orgmode
Hello,
Mart van de Wege <mvdwege@gmail.com> writes:
> I'm trying to replace U+00BD in an org buffer with \sfrac{1}{2} during
> export to LaTex, and obviously I'm doing something wrong, or I don't
> understand the documentation.
>
> I use the following code to set up the filter:
>
> #+BIND: org-export-filter-item-functions (latex-replace-half)
> #+BEGIN_SRC emacs-lisp :exports results :results none
>
> (defun latex-replace-half (text backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (replace-regexp-in-string "½" "\\sfrac{1}{2}" text)))
> #+END_SRC
You must add a double escape character to the backslash:
...
(replace-regexp-in-string "½" "\\\\sfrac{1}{2}" text)))
...
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-01-03 13:07 10% ` Juan Manuel Macías
@ 2021-01-03 13:08 5% ` TEC
2021-01-07 18:52 5% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: TEC @ 2021-01-03 13:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Thank you very much for your response and your comments.
Seriously, thanks for the patch. I think the ML is usually a bit more
responsive, but it seems to be a bit quiet at the moment.
> I agree to name "Insert, include, etc." the attribute to include
> arbitrary LaTeX code, better than "options".
Glad my feedback seems to have gone down well :). If the only likely use
of this is adjusting the font, perhaps for the sake of consistency we
can match the behaviour of tables, which take a :font LaTeX attribute?
> Of course, I can add the necessary documentation to the files you tell
> me. As I am new to submitting patches, I don't really know how to
> proceed: do I have to send you the new version of the patch, with the
> documentation? Should I send a new email with all of it to this list?
Thanks for asking. Sometimes it seems the maintainers take the trouble of
adding an ORG-NEWS entry or minor touching ups to the patch, but I think
it's nice to leave as little for them to do as possible :)
Announce changes in: etc/ORG-NEWS
Document new/different behaviour in: doc/org-manual.org
I think Markup for /Rich Contents > Paragraphs/ may be the right place
to add a description of this functionality --- verse blocks are
discussed around line 10750.
Regarding how patches on this ML work, this is what I've observed:
- Initial version of patch submitted, with justification/explanation
- Feedback may be given
- Revisions of the patch are attached in replies to feedback
- Process repeats until everyone's happy
- Patch is merged
i.e. it all tends to happen in the same thread.
Hope this helps,
Timothy.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2021-01-03 10:25 6% ` TEC
@ 2021-01-03 13:07 10% ` Juan Manuel Macías
2021-01-03 13:08 5% ` TEC
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2021-01-03 13:07 UTC (permalink / raw)
To: TEC; +Cc: orgmode
Hi Timothy,
TEC <tecosaur@gmail.com> writes:
> Hi Juan,
>
> Thanks for your patch.
>
> This looks like a fairly sensible addition. Two comments from me:
>
> 1. I'm not sure that "options" is a good name for arbitrary LaTeX which
> is included inside the verse block. Perhaps something like "insert"
> or "include", etc. may be a better fit.
> 2. It's considered generally nice to document features like this :) The
> two documents which I'd think to note this in are ORG-NEWS and the
> manual (docs/manual.org).
Thank you very much for your response and your comments.
I agree to name "Insert, include, etc." the attribute to include
arbitrary LaTeX code, better than "options".
Of course, I can add the necessary documentation to the files you tell
me. As I am new to submitting patches, I don't really know how to
proceed: do I have to send you the new version of the patch, with the
documentation? Should I send a new email with all of it to this list?
Best regards,
Juan Manuel
> All the best,
>
> Timothy.
>
^ permalink raw reply [relevance 10%]
* Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
2020-12-17 17:23 5% [PATCH] " Juan Manuel Macías
@ 2021-01-03 10:25 6% ` TEC
2021-01-03 13:07 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: TEC @ 2021-01-03 10:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hi Juan,
Thanks for your patch.
This looks like a fairly sensible addition. Two comments from me:
1. I'm not sure that "options" is a good name for arbitrary LaTeX which
is included inside the verse block. Perhaps something like "insert"
or "include", etc. may be a better fit.
2. It's considered generally nice to document features like this :) The
two documents which I'd think to note this in are ORG-NEWS and the
manual (docs/manual.org).
All the best,
Timothy.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> (Sorry, due to a mistake, the text of my message did not appear in my previous email)
>
> Hi,
>
> I would like to propose this patch to add some LaTeX attributes to the verse block,
> especially to be able to apply certain features from the verse.sty package, which is an
> extension (widely used in Humanities) of the standard LaTeX 'verse' environment.
>
> These attributes would be:
>
> - `:lines' to add verse numbers, according to any numbering sequence
> - `:center' to apply the optical centering of the poem, which is a typographic convention
> whereby a poem or a group of verses is centered on the page, taking the width of the
> longest verse as a reference. In fact, optical centering is the correct arrangement of
> verses in a document.
> - `:versewidth' which expects a text string that is the longest verse of the poem,
> required when applying the `:center' attribute.
>
> As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
> attribute would be used to add arbitrary code within the verse environment.
>
> Consider this complete example with Shakespeare's first sonnet:
>
> #+begin_src org
> ,#+ATTR_LaTeX: :center t :options \small :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
>
> when exporting to LaTeX we get:
>
> #+begin_src latex
> \settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
> \begin{verse}[\versewidth]
> \poemlines{5}
> \small
> 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
>
> In an attached image I send a screenshot with the typographic result
>
> And finally, this is the patch I would propose
>
> #+begin_src diff
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 2a14b25d5..bc6b64e78 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3506,6 +3506,16 @@ 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))
> + (opt (org-export-read-attribute :attr_latex verse-block :options))
> + (cent (org-export-read-attribute :attr_latex verse-block :center))
> + (attr (concat
> + (if cent "[\\versewidth]" "")
> + (if lin (format "\n\\poemlines{%s}" lin) "")
> + (if opt (format "\n%s" opt) "")))
> + (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
> + (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
> (concat
> (org-latex--wrap-label
> verse-block
> @@ -3513,7 +3523,9 @@ 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}"
> + vwidth-attr
> + attr
> (replace-regexp-in-string
> "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
> (replace-regexp-in-string
> @@ -3524,7 +3536,7 @@ contextual information."
> 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))))
> #+end_src
>
> Regards,
>
> Juan Manuel
^ permalink raw reply [relevance 6%]
* Re: Org to ConTeXt exporter?
2020-12-28 17:54 7% ` Juan Manuel Macías
2020-12-28 19:06 5% ` Jonathan McHugh
@ 2020-12-29 21:51 5% ` Jonathan McHugh
1 sibling, 0 replies; 144+ results
From: Jonathan McHugh @ 2020-12-29 21:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: ludo, orgmode
Hello Juan,
I investigated further the Context engine for Skribilo:
https://git.savannah.gnu.org/gitweb/?p=skribilo.git;a=tree;f=src/guile/skribilo/engine;h=9c6353eb7c6eae70de007c2f0a8f01092ae669a2;hb=HEAD
While I cant comment on it's Context engine functionality or efficacy, it clearly has a
decent breakdown of usecases across its 1300 lines. It appears to have
had low updates frequency, probably as a consequence of the stability of
Context's syntax (rather than the momentum of the DSL). It may be useful
as a checklist of key terms to tick off, if not a consideration for
framing anything to serve Org-Moders.
I have CC’d Ludovic Courtès, who has spearheaded Skribilo and all the
commits for it’s Context engine. Judging by his output within the Guix
community it’s possible that he may have some insights concerning this
thread:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-12/msg00731.html
Part of Skribilo’s homepage blurb intrigued me:
"Last but not least, Skribilo can be thought of as a complete document
programming framework for the Scheme programming language that may be
used to automate a variety of document generation tasks. Technically,
the Skribilo language/API is an embedded domain-specific language
(EDSL), implemented via so-called “deep embedding”. Skribilo uses GNU
Guile 3.0 or 2.x as the underlying Scheme implementation."
https://nongnu.org/skribilo/index.html
Still early in my Lisp journey, I do not know whether it would be
abhorrent/inelegant for the eLisp orientation of Org-Mode to defer to Guile (at the
backend) for outputting in different formats.
Kind regards,
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello, Jonathan,
>
> Jonathan McHugh <indieterminacy@libre.brussels> writes:
>
>> I have wondered about the interoperability between Context and Latex.
>>
>> As somebody who (previously) invested a lot of time into Latex, my migration to
>> Context (due to its emphasis on Lua) grew problematic once other commitments
>> grew.
>
> What I like about ConTeXt is its (let's say) avant-garde vocation. But
> for my everyday work I prefer LaTeX: more extensible, more versatile,
> even more documented. But we must accept that ConTeXt is also an
> advanced typographic laboratory where many functionalities also end up
> in LaTeX over time. In fact, as far as I know, the future LaTeX3 adopts
> some ideas from ConTeXt.
>
> On Lua, LuaLaTeX also has good support. And many new LaTeX packages are
> already getting very good use of LuaTeX features.
>
>> The lack of Context support in Org-Mode has made me consider reverting
>> back to Latex.
>
> I know some advanced ConTeXt users (I am not) who are very interested in
> migrating to Org Mode. In that aspect, I think a native exporter to
> ConTeXt would be of great help.
>
> Generally speaking, I think Org is the perfect interface to use TeX and
> friends. One of the things I like the most about Org Mode is that it
> allows working in (La)TeX at a very high level. Of course, for advanced
> use, the more you know about LaTeX and TeX, the better. For example, if
> I work on a large book, I usually write the entire configuration (the
> preamble, my macros, my LaTeX code, etc.) to an Org file, and then I generate
> a Preamble.tex file using tangle. I have a master file and several
> subdocuments for the parts and sections of the book. And I make heavy
> use of Org Publish. But in all that workflow, LaTeX is always in the
> background. It is mainly a matter of comfort: I love TeX and its
> derivatives, its power and its typographic refinement, but its language
> is very verbose and the sources are difficult to debug. Org mode is much
> more human readable. And even much more readable and comfortable than
> Markdown.
>
>> If I had a lot of time it would be wonderful to develop parsing
>> expression grammars to capture it all, irrespective of direction ... mmm time....
>
> Yes, time is the problem: I think TODO lists were invented to have a
> foot of mud in the future :-)
>
> Regards,
>
> Juan Manuel
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 20:03 5% ` Marcin Borkowski
@ 2020-12-29 16:05 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-29 16:05 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Hello, Marcin,
Marcin Borkowski <mbork@mbork.pl> writes:
> Here's the thing. Some time ago, I have dedicated about 20 minutes per
> day (sometimes less, sometimes more, but the average over the past 6
> years is about 17 minutes now) to what I call "creative writing" -
> mainly the book I was working on for the past 5 years with two more
> people (and that book is now complete) and my blog. I will try to use
> some of that time to start that tutorial, and maybe I will then publish
> it on my blog or somewhere. (I also want to get back to the book on
> Elisp I started a long time ago, but that can wait a few more weeks.)
As I said, I think a tutorial on writing an Org exporter from scratch
would be very interesting and useful. If, finally, you can find time for
it, I could do a translation to publish it on my blog in Spanish
(https://gnutas.juanmanuelmacias.com/). With my translation of Homer's
Odyssey (work in progress) and other projects, I don't have a lot of free
time, but I can always find a moment.
> But here's the thing: I'll need help. I know LaTeX very well - I've
> been using plain TeX for about 25 years now and LaTeX for about 20
> years, including writing quite a few packages and classes - but I don't
> know ConTeXt that well. (I did use it a bit, but not very extensively.)
(In my case) I have not used much ConTeXt. Really, I prefer LaTeX. It's
a personal opinion and a matter of taste, but I find ConTeXt too
"monolithic". One of the main problems it has is (I think) its huge lack
of documentation (compared to LaTeX). I suppose, in part, because his
community is smaller. However, I also think that ConTeXt has interesting
features (grid typesetting, xml integration, etc.), and it would not be
a bad idea to have an alternative to LaTeX in Org. But I don't know if
it would be something feasible in the short term, beyond the concept...
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [tip] Export subfigures to LaTeX (and HTML)
2020-12-28 18:03 5% ` John Kitchin
@ 2020-12-29 15:00 9% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-29 15:00 UTC (permalink / raw)
To: John Kitchin; +Cc: orgmode
Hello, John,
Thank you very much for the two links.
John Kitchin <jkitchin@andrew.cmu.edu> writes:
> You might look at this
> http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
> for another way to do that.
Your idea of adding attributes to Org links is very interesting and
productive. It also shows the great potential that Org links have.
> Check out this alternative approach all together that also uses a
> special block.
>
> http://kitchingroup.cheme.cmu.edu/blog/2016/01/17/Side-by-side-figures-in-org-mode-for-different-export-outputs/
I also find your approach very interesting. What I like the most is
giving LaTeX a "Lisp skin". It is more elegant and legible. I love
(La)TeX and its potential, but I find its code somewhat ugly, often too
verbose. By the way (offtopic), there is a LaTeX package called
lisp-on-TeX that includes a rudimentary Lisp interpreter:
https://www.ctan.org/pkg/lisp-on-tex. It's interesting, and you can do
some things with it, but I think it's an abandoned project. The TeX
ecosystem has moved to Lua with LuaTeX and LuaMetaTeX, but a LispTeX
would have been wonderful! ;-)
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Org to ConTeXt exporter?
2020-12-28 18:03 10% ` Juan Manuel Macías
2020-12-28 19:23 6% ` Diego Zamboni
@ 2020-12-28 20:03 5% ` Marcin Borkowski
2020-12-29 16:05 9% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Marcin Borkowski @ 2020-12-28 20:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Diego Zamboni, orgmode
On 2020-12-28, at 19:03, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hello, Diego,
>
> Diego Zamboni <diego@zzamboni.org> writes:
>
>> I have never used ConTeXt, but from what I've seen, despite its many
>> differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
>> this, I think it might be easier to create a new derived exporter from
>> ox-latex, and override the parts that differ, instead of creating a
>> new one completely from scratch.
>
> You are right, maybe it is better to start with ox-latex, since LaTeX
> and ConTeXt are related.
I beg to differ. The relation between LaTeX and ConTeXt is that they
both come from plain TeX, but both came a long way, and there are
significant differences between the two. Personally, I'd rather start
that exporter from scratch. I wrote my exporter a few years ago, it's
not that difficult.
Here's the thing. Some time ago, I have dedicated about 20 minutes per
day (sometimes less, sometimes more, but the average over the past 6
years is about 17 minutes now) to what I call "creative writing" -
mainly the book I was working on for the past 5 years with two more
people (and that book is now complete) and my blog. I will try to use
some of that time to start that tutorial, and maybe I will then publish
it on my blog or somewhere. (I also want to get back to the book on
Elisp I started a long time ago, but that can wait a few more weeks.)
But here's the thing: I'll need help. I know LaTeX very well - I've
been using plain TeX for about 25 years now and LaTeX for about 20
years, including writing quite a few packages and classes - but I don't
know ConTeXt that well. (I did use it a bit, but not very extensively.)
Where could we start working on it? I suppose GitHub/GitLab is out of
question, so?
Best,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 18:03 10% ` Juan Manuel Macías
@ 2020-12-28 19:23 6% ` Diego Zamboni
2020-12-28 20:03 5% ` Marcin Borkowski
1 sibling, 0 replies; 144+ results
From: Diego Zamboni @ 2020-12-28 19:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
By the way, I just realized that the ox-pandoc exporter (
https://github.com/kawabata/ox-pandoc) has a number of "context" options,
since Pandoc itself supports ConTeXt output. I have no idea how well it
works, but it could be an option for ConTeXt users for the time being.
--Diego
On Mon, Dec 28, 2020 at 7:03 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hello, Diego,
>
> Diego Zamboni <diego@zzamboni.org> writes:
>
> > I have never used ConTeXt, but from what I've seen, despite its many
> > differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
> > this, I think it might be easier to create a new derived exporter from
> > ox-latex, and override the parts that differ, instead of creating a
> > new one completely from scratch.
>
> You are right, maybe it is better to start with ox-latex, since LaTeX
> and ConTeXt are related.
>
> > You can see an example in my own
> > https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
> > which uses ox-md as a backend for defining the new ox-markua exporter.
>
> Thank you very much for the link. As soon as I have some time I will
> study your code
>
> Regards,
>
> Juan Manuel
>
[-- Attachment #2: Type: text/html, Size: 1844 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Org to ConTeXt exporter?
2020-12-28 17:54 7% ` Juan Manuel Macías
@ 2020-12-28 19:06 5% ` Jonathan McHugh
2020-12-29 21:51 5% ` Jonathan McHugh
1 sibling, 0 replies; 144+ results
From: Jonathan McHugh @ 2020-12-28 19:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello Juan,
Thanks for validating my suspicions re Latex and Context.
One area I used a lot was with regards to Tikz. I will have to make many
detours before I get the chance to adapt bespoke Tikz projects to to
something more generic and action from org-mode. Hopefully by then the
choice of an outputting document management system will be less of a
consideration.
I half suspect that the Context author (Hans Hagen) focusing on Metapost
allowed the Context community to not value Tikz so much (transposing the
Tikz manual to Context would be a great win IMHO).
Checking in on Context I see that they have a new generation:
https://wiki.contextgarden.net/LMTX
Im sure there will be some scripts which will need updating given
updated conventions. Im pleased that that the project still has momentum
and look forward to investigating what this means.
A Guix user, it saddens me that it is not packaged properly (time, time,
time) - especially given the LMTX shift.
Broadening the topic, I wonder whether the wider stemming of Tex derived
products should be approached with as much of the equivalent encapsulation as
possible. New to the Emacs and Lisp world, I do not know whether suggesting
Org-Mode outputting Racket's Scribble or Guile's Skribilo is productive
or relevant (or trolling!).
More practically speaking, it is worth noting that Skribilo outputs
Context (in addition to Latex):
https://www.nongnu.org/skribilo/doc/user-38.html#context-engine
It is entirely possible that that community has resolved a lot of the
challenges the Org-Mode contingent is currently deliberating over.
Best wishes,
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello, Jonathan,
>
> Jonathan McHugh <indieterminacy@libre.brussels> writes:
>
>> I have wondered about the interoperability between Context and Latex.
>>
>> As somebody who (previously) invested a lot of time into Latex, my migration to
>> Context (due to its emphasis on Lua) grew problematic once other commitments
>> grew.
>
> What I like about ConTeXt is its (let's say) avant-garde vocation. But
> for my everyday work I prefer LaTeX: more extensible, more versatile,
> even more documented. But we must accept that ConTeXt is also an
> advanced typographic laboratory where many functionalities also end up
> in LaTeX over time. In fact, as far as I know, the future LaTeX3 adopts
> some ideas from ConTeXt.
>
> On Lua, LuaLaTeX also has good support. And many new LaTeX packages are
> already getting very good use of LuaTeX features.
>
>> The lack of Context support in Org-Mode has made me consider reverting
>> back to Latex.
>
> I know some advanced ConTeXt users (I am not) who are very interested in
> migrating to Org Mode. In that aspect, I think a native exporter to
> ConTeXt would be of great help.
>
> Generally speaking, I think Org is the perfect interface to use TeX and
> friends. One of the things I like the most about Org Mode is that it
> allows working in (La)TeX at a very high level. Of course, for advanced
> use, the more you know about LaTeX and TeX, the better. For example, if
> I work on a large book, I usually write the entire configuration (the
> preamble, my macros, my LaTeX code, etc.) to an Org file, and then I generate
> a Preamble.tex file using tangle. I have a master file and several
> subdocuments for the parts and sections of the book. And I make heavy
> use of Org Publish. But in all that workflow, LaTeX is always in the
> background. It is mainly a matter of comfort: I love TeX and its
> derivatives, its power and its typographic refinement, but its language
> is very verbose and the sources are difficult to debug. Org mode is much
> more human readable. And even much more readable and comfortable than
> Markdown.
>
>> If I had a lot of time it would be wonderful to develop parsing
>> expression grammars to capture it all, irrespective of direction ... mmm time....
>
> Yes, time is the problem: I think TODO lists were invented to have a
> foot of mud in the future :-)
>
> Regards,
>
> Juan Manuel
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 5%]
* Re: [tip] Export subfigures to LaTeX (and HTML)
2020-12-25 16:02 7% [tip] Export subfigures to LaTeX (and HTML) Juan Manuel Macías
@ 2020-12-28 18:03 5% ` John Kitchin
2020-12-29 15:00 9% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: John Kitchin @ 2020-12-28 18:03 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
This is an interesting use of links, in particular extending the
information in the description.
You might look at this
http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
for another way to do that.
Check out this alternative approach all together that also uses a
special block.
http://kitchingroup.cheme.cmu.edu/blog/2016/01/17/Side-by-side-figures-in-org-mode-for-different-export-outputs/
I don't use either of these today, and they are old so who knows if they
still work, but they have some fun ideas in them.
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hi,
>
> I have come up with a way to export subfigures to LaTeX (with the subfigure package) by
> defining a new link type. The 'subcaption' of the subfigure would be the description of
> the link. If we want to add parameters such as width, scale, etc., we can put them next
> between the marks '>( ... )'
>
> The code:
>
> #+begin_src emacs-lisp
> (org-link-set-parameters
> "subfig"
> :follow (lambda (file) (find-file file))
> :face '(:foreground "chocolate" :weight bold :underline t)
> :display 'full
> :export (lambda (file desc backend)
> (when (eq backend 'latex)
> (if (string-match ">(\\(.+\\))" desc)
> (concat "\\subfigure[" (replace-regexp-in-string "\s+>(.+)" "" desc) "]"
> "{\\includegraphics"
> "["
> (match-string 1 desc)
> "]"
> "{"
> file
> "}}")
> (format "\\subfigure[%s]{\\includegraphics{%s}}" desc file)))))
> #+end_src
>
> Example:
>
> #+begin_src org
> ,#+CAPTION: Lorem impsum dolor
> ,#+ATTR_LaTeX: :options \centering
> ,#+begin_figure
> [[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth)]]
>
> [[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth)]]
>
> [[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth)]]
> ,#+end_figure
> #+end_src
>
> Results:
>
> #+begin_src latex
> \begin{figure}\centering
> \subfigure[Caption of img1]{\includegraphics[width=.3\textwidth]{img1.jpg}}
>
> \subfigure[Caption of img2]{\includegraphics[width=.3\textwidth]{img2.jpg}}
>
> \subfigure[Caption of img3]{\includegraphics[width=.6\textwidth]{img3.jpg}}
> \caption{Lorem impsum dolor}
> \end{figure}
> #+end_src
>
> If we want to export to HTML it would be something more tricky. In this case, the export
> function could be like this (a width parameter would be enclosed between >{ ... }):
>
> #+begin_src emacs-lisp
> (lambda (file desc backend)
> (cond
> ((eq backend 'latex)
> (if (string-match ">(\\(.+\\))" desc)
> (concat "\\subfigure[" (replace-regexp-in-string "\s*>.+" "" desc) "]" "{\\includegraphics" "[" (match-string 1 desc) "]" "{" file "}}")
> (format "\\subfigure[%s]{\\includegraphics{%s}}" (replace-regexp-in-string "\s*>.+" "" desc) file)))
> ((eq backend 'html)
> (if (string-match ">{\\(.+\\)}" desc)
> (concat "<td><img src=\"" file "\" alt=\"" file "\"" " style=\"width:"
> (match-string 1 desc)
> "\""
> "/><br>"
> (replace-regexp-in-string "\s*>.+" "" desc)
> "</td>")
> (format "<td><img src=\"%s\" alt=\"%s\"/><br>%s</td>"
> file file
> (replace-regexp-in-string "\s*>.+" "" desc))))))
> #+end_src
>
> Example:
>
> #+begin_src org
> ,#+CAPTION: Lorem impsum dolor
> ,#+ATTR_LaTeX: :options \centering
> ,#+begin_figure
> @@html:<div class="org-center"><table style="margin-left:auto;margin-right:auto;"><tr>@@
>
> [[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth) >{300px}]]
>
> [[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth) >{300px}]]
>
> @@html:</tr></table><p> </p><table style="margin-left:auto;margin-right:auto;"><tr>@@
>
> [[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth) >{600px}]]
>
> @@html:</tr></table><br>Lorem ipsum dolor</div>@@
> ,#+end_figure
> #+end_src
>
> As you can see, it is not the panacea, and you have to apply some direct format...
>
> Happy holidays
>
> Juan Manuel
--
Professor John Kitchin
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 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 16:23 0% ` Diego Zamboni
@ 2020-12-28 18:03 10% ` Juan Manuel Macías
2020-12-28 19:23 6% ` Diego Zamboni
2020-12-28 20:03 5% ` Marcin Borkowski
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-28 18:03 UTC (permalink / raw)
To: Diego Zamboni; +Cc: orgmode
Hello, Diego,
Diego Zamboni <diego@zzamboni.org> writes:
> I have never used ConTeXt, but from what I've seen, despite its many
> differences, a lot is still similar to TeX/LaTeX (e.g. math). Given
> this, I think it might be easier to create a new derived exporter from
> ox-latex, and override the parts that differ, instead of creating a
> new one completely from scratch.
You are right, maybe it is better to start with ox-latex, since LaTeX
and ConTeXt are related.
> You can see an example in my own
> https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
> which uses ox-md as a backend for defining the new ox-markua exporter.
Thank you very much for the link. As soon as I have some time I will
study your code
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
2020-12-28 16:09 5% ` Jonathan McHugh
@ 2020-12-28 17:54 7% ` Juan Manuel Macías
2020-12-28 19:06 5% ` Jonathan McHugh
2020-12-29 21:51 5% ` Jonathan McHugh
0 siblings, 2 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-28 17:54 UTC (permalink / raw)
To: Jonathan McHugh; +Cc: orgmode
Hello, Jonathan,
Jonathan McHugh <indieterminacy@libre.brussels> writes:
> I have wondered about the interoperability between Context and Latex.
>
> As somebody who (previously) invested a lot of time into Latex, my migration to
> Context (due to its emphasis on Lua) grew problematic once other commitments
> grew.
What I like about ConTeXt is its (let's say) avant-garde vocation. But
for my everyday work I prefer LaTeX: more extensible, more versatile,
even more documented. But we must accept that ConTeXt is also an
advanced typographic laboratory where many functionalities also end up
in LaTeX over time. In fact, as far as I know, the future LaTeX3 adopts
some ideas from ConTeXt.
On Lua, LuaLaTeX also has good support. And many new LaTeX packages are
already getting very good use of LuaTeX features.
> The lack of Context support in Org-Mode has made me consider reverting
> back to Latex.
I know some advanced ConTeXt users (I am not) who are very interested in
migrating to Org Mode. In that aspect, I think a native exporter to
ConTeXt would be of great help.
Generally speaking, I think Org is the perfect interface to use TeX and
friends. One of the things I like the most about Org Mode is that it
allows working in (La)TeX at a very high level. Of course, for advanced
use, the more you know about LaTeX and TeX, the better. For example, if
I work on a large book, I usually write the entire configuration (the
preamble, my macros, my LaTeX code, etc.) to an Org file, and then I generate
a Preamble.tex file using tangle. I have a master file and several
subdocuments for the parts and sections of the book. And I make heavy
use of Org Publish. But in all that workflow, LaTeX is always in the
background. It is mainly a matter of comfort: I love TeX and its
derivatives, its power and its typographic refinement, but its language
is very verbose and the sources are difficult to debug. Org mode is much
more human readable. And even much more readable and comfortable than
Markdown.
> If I had a lot of time it would be wonderful to develop parsing
> expression grammars to capture it all, irrespective of direction ... mmm time....
Yes, time is the problem: I think TODO lists were invented to have a
foot of mud in the future :-)
Regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Org to ConTeXt exporter?
2020-12-28 15:04 6% ` Marcin Borkowski
2020-12-28 15:38 10% ` Juan Manuel Macías
@ 2020-12-28 16:23 0% ` Diego Zamboni
2020-12-28 18:03 10% ` Juan Manuel Macías
1 sibling, 1 reply; 144+ results
From: Diego Zamboni @ 2020-12-28 16:23 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Juan Manuel Macías, orgmode
[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]
I have never used ConTeXt, but from what I've seen, despite its many
differences, a lot is still similar to TeX/LaTeX (e.g. math). Given this, I
think it might be easier to create a new derived exporter from ox-latex,
and override the parts that differ, instead of creating a new one
completely from scratch.
You can see an example in my own
https://github.com/zzamboni/ox-leanpub/blob/master/ox-leanpub-markua.el,
which uses ox-md as a backend for defining the new ox-markua exporter.
There is also already some documentation at
https://orgmode.org/worg/dev/org-export-reference.html
--Diego
On Mon, Dec 28, 2020 at 4:09 PM Marcin Borkowski <mbork@mbork.pl> wrote:
>
> On 2020-12-28, at 14:38, Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
> > Hi,
> >
> > Just out of curiosity, I am wondering if there are plans to create an
> > Org to ConTeXt exporter in the future, or if there is already some work
> > in progress on this front.
> >
> > I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> > but ConTeXt has very interesting features (grid typesetting, for
> > example) that LaTeX lacks (for now) and has a more monolithic structure,
> > that is, it does not need to be extended through packages as in LaTeX.
>
> Creating an exporter from scratch is probably easier than you think.
> A few years ago I planned a tutorial about this, but another job
> happened, then covid happened etc. Now that I finished some big project
> taking me a lot of time, I might be tempted to revisit that. Would
> there be demand for a DYI Org-exporter-from-scratch tutorial?
>
> Best,
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>
[-- Attachment #2: Type: text/html, Size: 2420 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Org to ConTeXt exporter?
2020-12-28 15:38 10% ` Juan Manuel Macías
@ 2020-12-28 16:09 5% ` Jonathan McHugh
2020-12-28 17:54 7% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Jonathan McHugh @ 2020-12-28 16:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Hello \Context folks,
I have wondered about the interoperability between Context and Latex.
As somebody who (previously) invested a lot of time into Latex, my migration to
Context (due to its emphasis on Lua) grew problematic once other commitments
grew.
The lack of Context support in Org-Mode has made me consider reverting
back to Latex.
However, I have wondered if a possible shortcut is to compile a list of
the semantic differences between the two and attack it from there.
For example, the Context stub, 'From Latex to Context', gives some of the
distinctions:
https://wiki.contextgarden.net/From_LaTeX_to_ConTeXt
... which then cites a 45 page pdf (which may (possibly) be a little out
of date, having been written in 2003):
http://www.berenddeboer.net/tex/LaTeX2ConTeXt.pdf
Perhaps looking at Org-Modes Latex exporter and determining the Context
equivalent would help? After all, they should be satisfing equivalent requirements.
Even better, if a modern list of equivalents were in a locality suitable
for non Org-Mode users then it may become easier for users from either
communities to feed off eachothers work a little easier.
If I had a lot of time it would be wonderful to develop parsing
expression grammars to capture it all, irrespective of direction ... mmm time....
Best wishes,
Jonathan
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Hello, Marcin,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Creating an exporter from scratch is probably easier than you think.
>> A few years ago I planned a tutorial about this, but another job
>> happened, then covid happened etc. Now that I finished some big project
>> taking me a lot of time, I might be tempted to revisit that. Would
>> there be demand for a DYI Org-exporter-from-scratch tutorial?
>
> Thank you for your answer. Actually a tutorial on how to create an
> exporter from scratch (I think) would be really interesting. Some time
> ago I was tempted to start writing an exporter for ConTeXt, studying the
> code of the other exporters, but for time and work reasons I left the
> project abandoned.
>
> If you finally write that tutorial, I could also translate it into
> Spanish to spread it out among Spanish-speaking Org users.
>
> Regards,
>
> Juan Manuel
>
>> Best,
--
Jonathan McHugh
indieterminacy@libre.brussels
^ permalink raw reply [relevance 5%]
* Re: Org to ConTeXt exporter?
2020-12-28 15:04 6% ` Marcin Borkowski
@ 2020-12-28 15:38 10% ` Juan Manuel Macías
2020-12-28 16:09 5% ` Jonathan McHugh
2020-12-28 16:23 0% ` Diego Zamboni
1 sibling, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-28 15:38 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: orgmode
Hello, Marcin,
Marcin Borkowski <mbork@mbork.pl> writes:
> Creating an exporter from scratch is probably easier than you think.
> A few years ago I planned a tutorial about this, but another job
> happened, then covid happened etc. Now that I finished some big project
> taking me a lot of time, I might be tempted to revisit that. Would
> there be demand for a DYI Org-exporter-from-scratch tutorial?
Thank you for your answer. Actually a tutorial on how to create an
exporter from scratch (I think) would be really interesting. Some time
ago I was tempted to start writing an exporter for ConTeXt, studying the
code of the other exporters, but for time and work reasons I left the
project abandoned.
If you finally write that tutorial, I could also translate it into
Spanish to spread it out among Spanish-speaking Org users.
Regards,
Juan Manuel
> Best,
^ permalink raw reply [relevance 10%]
* Re: Org to ConTeXt exporter?
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
@ 2020-12-28 15:04 6% ` Marcin Borkowski
2020-12-28 15:38 10% ` Juan Manuel Macías
2020-12-28 16:23 0% ` Diego Zamboni
2021-01-08 2:37 5% ` Jason Ross
2021-01-08 3:52 6% ` Jason Ross
2 siblings, 2 replies; 144+ results
From: Marcin Borkowski @ 2020-12-28 15:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On 2020-12-28, at 14:38, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Hi,
>
> Just out of curiosity, I am wondering if there are plans to create an
> Org to ConTeXt exporter in the future, or if there is already some work
> in progress on this front.
>
> I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
> but ConTeXt has very interesting features (grid typesetting, for
> example) that LaTeX lacks (for now) and has a more monolithic structure,
> that is, it does not need to be extended through packages as in LaTeX.
Creating an exporter from scratch is probably easier than you think.
A few years ago I planned a tutorial about this, but another job
happened, then covid happened etc. Now that I finished some big project
taking me a lot of time, I might be tempted to revisit that. Would
there be demand for a DYI Org-exporter-from-scratch tutorial?
Best,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [relevance 6%]
* Org to ConTeXt exporter?
@ 2020-12-28 13:38 10% Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
` (2 more replies)
0 siblings, 3 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-28 13:38 UTC (permalink / raw)
To: orgmode
Hi,
Just out of curiosity, I am wondering if there are plans to create an
Org to ConTeXt exporter in the future, or if there is already some work
in progress on this front.
I have to say that among TeX formats I tend to prefer LaTeX to ConTeXt;
but ConTeXt has very interesting features (grid typesetting, for
example) that LaTeX lacks (for now) and has a more monolithic structure,
that is, it does not need to be extended through packages as in LaTeX.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
2020-12-27 20:14 6% ` tomas
@ 2020-12-27 21:33 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-27 21:33 UTC (permalink / raw)
To: tomas; +Cc: orgmode
Hello,
<tomas@tuxteam.de> writes:
> This would be a bug: tilde is an allowed URI character [1]
You're right. I have also noticed that if I write links like these:
[[*foo ~foo~ foo]][[foo]]
[[*foo =foo= foo]][[foo]]
There is an anomaly in the description similar to what Chris comments in
his email...
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
2020-12-27 19:17 9% ` Juan Manuel Macías
@ 2020-12-27 21:15 6% ` Kashyap Chamarthy
0 siblings, 0 replies; 144+ results
From: Kashyap Chamarthy @ 2020-12-27 21:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
On Sun, Dec 27, 2020 at 8:17 PM Juan Manuel Macías
<maciaschain@posteo.net> wrote:
>
> Hello again Kashyap,
Hey, Juan
> Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
>
> > Hmm, that fixes the new line before the "sub bullet under test 3, with
> > a quote". However, a new line still remains after the quote ends (and
> > before the "Test 4" starts). Is it possible to nuke that too? If
> > not, that's okay, I can live with it. :-)
>
> I'd say a vertical space before and after a block quote would be
> 'typographically' correct.
You're right, and I agree.
> But if you want to eliminate the space after
> the block quote, without having to modify it in a general way, it could
> be solved with a bit of Elisp, by defining a custom filter so that the
> <blockquote> tag would be modified only within a plain list. Thus, with the
> configuration that Diego has suggested, everything would be without
> vertical space except the space before each block quote:
>
> #+BIND: org-export-filter-plain-list-functions (my-filter-html)
> #+begin_src emacs-lisp :exports results :results none
> (defun my-filter-html (text backend info)
> (when (org-export-derived-backend-p backend 'html)
> (replace-regexp-in-string "<blockquote>" "<blockquote style=\"margin-bottom:0px\">" text)))
> #+end_src
Thank you for the code snippet. My only use of Emacs is Org-Mode, so I
haven't spent much time learning Elisp yet.
Regards,
Kashyap
^ permalink raw reply [relevance 6%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
2020-12-27 18:12 10% ` Juan Manuel Macías
@ 2020-12-27 20:14 6% ` tomas
2020-12-27 21:33 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: tomas @ 2020-12-27 20:14 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Sun, Dec 27, 2020 at 07:12:42PM +0100, Juan Manuel Macías wrote:
> Hello,
>
> I think the problem comes because in that url the tilde does not have an
> escape character. If it's just that case, you can try replacing each
> tilde with %7E (see
> https://www.w3schools.com/tags/ref_urlencode.asp). That way the
> link description would have to be formatted correctly, without spurious
> characters.
This would be a bug: tilde is an allowed URI character [1]
Cheers
[1] https://tools.ietf.org/html/rfc3986#section-2.3
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 6%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
@ 2020-12-27 19:17 9% ` Juan Manuel Macías
2020-12-27 21:15 6% ` Kashyap Chamarthy
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-27 19:17 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: orgmode
Hello again Kashyap,
Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
> Hmm, that fixes the new line before the "sub bullet under test 3, with
> a quote". However, a new line still remains after the quote ends (and
> before the "Test 4" starts). Is it possible to nuke that too? If
> not, that's okay, I can live with it. :-)
I'd say a vertical space before and after a block quote would be
'typographically' correct. But if you want to eliminate the space after
the block quote, without having to modify it in a general way, it could
be solved with a bit of Elisp, by defining a custom filter so that the
<blockquote> tag would be modified only within a plain list. Thus, with the
configuration that Diego has suggested, everything would be without
vertical space except the space before each block quote:
#+BIND: org-export-filter-plain-list-functions (my-filter-html)
#+begin_src emacs-lisp :exports results :results none
(defun my-filter-html (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "<blockquote>" "<blockquote style=\"margin-bottom:0px\">" text)))
#+end_src
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-27 18:12 10% ` Juan Manuel Macías
2020-12-27 20:14 6% ` tomas
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-27 18:12 UTC (permalink / raw)
To: Chris Hunt; +Cc: orgmode
Hello,
I think the problem comes because in that url the tilde does not have an
escape character. If it's just that case, you can try replacing each
tilde with %7E (see
https://www.w3schools.com/tags/ref_urlencode.asp). That way the
link description would have to be formatted correctly, without spurious
characters.
Regards
Juan Manuel
Chris Hunt <chrahunt@gmail.com> writes:
> I'm trying to create a link in an org file with this URL:
>
> https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d
>
> and this description: "metrics".
>
> To do it, I followed these steps:
>
> 1. run `emacs -Q test.org`, where test.org is not an existing file
> 2. emacs GUI displays, type `M-x org-insert-link`
> 3. a "Link" prompt is displayed, paste the link and press return
> 4. a "Description" prompt is displayed, type "metrics" and press return
>
> At this point I expect to see only the text "metrics" in the buffer, with normal
> link decoration (underline and highlight).
>
> Instead, I see "~(~'CWAgent~metrics" with some mix of link decoration
> and some other style, as shown in the following image:
>
> https://i.imgur.com/vb9vE43.png
>
> The actual text from the file is
>
> [[https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d][metrics]]
>
> This is emacs 27.1 from http://ppa.launchpad.net/kelleyk/emacs/ubuntu,
> with org version 9.3.
>
> Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.22.30, cairo version 1.15.10)
> of 2020-09-19
> Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
>
> current state:
> ==============
> (setq
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-link-shell-confirm-function 'yes-or-no-p
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
> org-mode-hook '(#[0 "\300\301\302\303\304$\207"
> [add-hook change-major-mode-hook org-show-all append local]
> 5]
> #[0 "\300\301\302\303\304$\207"
> [add-hook change-major-mode-hook org-babel-show-result-all
> append local]
> 5]
> org-babel-result-hide-spec org-babel-hide-all-hashes)
> org-archive-hook '(org-attach-archive-delete-maybe)
> org-confirm-elisp-link-function 'yes-or-no-p
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
> org-babel-pre-tangle-hook '(save-buffer)
> org-tab-first-hook '(org-babel-hide-result-toggle-maybe
> org-babel-header-arg-expand)
> org-occur-hook '(org-first-headline-recenter)
> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-speed-command-hook '(org-speed-command-activate
> org-babel-speed-command-activate)
> org-confirm-shell-link-function 'yes-or-no-p
> org-link-parameters '(("attachment" :follow org-attach-open-link :export
> org-attach-export-link :complete
> org-attach-complete-link)
> ("id" :follow org-id-open)
> ("eww" :follow eww :store org-eww-store-link)
> ("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
> ("mhe" :follow org-mhe-open :store org-mhe-store-link)
> ("irc" :follow org-irc-visit :store org-irc-store-link
> :export org-irc-export)
> ("info" :follow org-info-open :export org-info-export
> :store org-info-store-link)
> ("gnus" :follow org-gnus-open :store
> org-gnus-store-link)
> ("docview" :follow org-docview-open :export
> org-docview-export :store org-docview-store-link)
> ("bibtex" :follow org-bibtex-open :store
> org-bibtex-store-link)
> ("bbdb" :follow org-bbdb-open :export org-bbdb-export
> :complete org-bbdb-complete-link :store
> org-bbdb-store-link)
> ("w3m" :store org-w3m-store-link) ("file+sys")
> ("file+emacs") ("shell" :follow org-link--open-shell)
> ("news" :follow
> #[257 "\301\300\302 Q!\207" ["news" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("mailto" :follow
> #[257 "\301\300\302 Q!\207" ["mailto" browse-url ":"]
> 5 "\n\n(fn URL)"]
> )
> ("https" :follow
> #[257 "\301\300\302 Q!\207" ["https" browse-url ":"]
> 5 "\n\n(fn URL)"]
> )
> ("http" :follow
> #[257 "\301\300\302 Q!\207" ["http" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("ftp" :follow
> #[257 "\301\300\302 Q!\207" ["ftp" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
> ("help" :follow org-link--open-help)
> ("file" :complete org-link-complete-file)
> ("elisp" :follow org-link--open-elisp)
> ("doi" :follow org-link--open-doi))
> org-link-elisp-confirm-function 'yes-or-no-p
> )
>
^ permalink raw reply [relevance 10%]
* Re: A way to avoid unwanted new lines when using paragraph quotes?
@ 2020-12-27 13:55 10% ` Juan Manuel Macías
1 sibling, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-27 13:55 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: orgmode
Hello,
Kashyap Chamarthy <kashyap.cv@gmail.com> writes:
> Is there a way to avoid the said new lines in the above mentioned
> examples? (NB: A space right _before_ the quote starts is okay.) Or
> alternatively, is there a way to consistently force a new line in the
> HTML export, after each of "Test 1", "Test 2", et al?
A solution could be to 'force' a homogeneous space between all the items
of the list by modifying the 'margin' property
(https://www.w3schools.com/cssref/pr_margin.asp).
For example:
#+HTML_HEAD: <style> li{margin: 15px;}</style>
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* [tip] Export subfigures to LaTeX (and HTML)
@ 2020-12-25 16:02 7% Juan Manuel Macías
2020-12-28 18:03 5% ` John Kitchin
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-25 16:02 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]
Hi,
I have come up with a way to export subfigures to LaTeX (with the subfigure package) by
defining a new link type. The 'subcaption' of the subfigure would be the description of
the link. If we want to add parameters such as width, scale, etc., we can put them next
between the marks '>( ... )'
The code:
#+begin_src emacs-lisp
(org-link-set-parameters
"subfig"
:follow (lambda (file) (find-file file))
:face '(:foreground "chocolate" :weight bold :underline t)
:display 'full
:export (lambda (file desc backend)
(when (eq backend 'latex)
(if (string-match ">(\\(.+\\))" desc)
(concat "\\subfigure[" (replace-regexp-in-string "\s+>(.+)" "" desc) "]"
"{\\includegraphics"
"["
(match-string 1 desc)
"]"
"{"
file
"}}")
(format "\\subfigure[%s]{\\includegraphics{%s}}" desc file)))))
#+end_src
Example:
#+begin_src org
,#+CAPTION: Lorem impsum dolor
,#+ATTR_LaTeX: :options \centering
,#+begin_figure
[[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth)]]
[[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth)]]
[[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth)]]
,#+end_figure
#+end_src
Results:
#+begin_src latex
\begin{figure}\centering
\subfigure[Caption of img1]{\includegraphics[width=.3\textwidth]{img1.jpg}}
\subfigure[Caption of img2]{\includegraphics[width=.3\textwidth]{img2.jpg}}
\subfigure[Caption of img3]{\includegraphics[width=.6\textwidth]{img3.jpg}}
\caption{Lorem impsum dolor}
\end{figure}
#+end_src
If we want to export to HTML it would be something more tricky. In this case, the export
function could be like this (a width parameter would be enclosed between >{ ... }):
#+begin_src emacs-lisp
(lambda (file desc backend)
(cond
((eq backend 'latex)
(if (string-match ">(\\(.+\\))" desc)
(concat "\\subfigure[" (replace-regexp-in-string "\s*>.+" "" desc) "]" "{\\includegraphics" "[" (match-string 1 desc) "]" "{" file "}}")
(format "\\subfigure[%s]{\\includegraphics{%s}}" (replace-regexp-in-string "\s*>.+" "" desc) file)))
((eq backend 'html)
(if (string-match ">{\\(.+\\)}" desc)
(concat "<td><img src=\"" file "\" alt=\"" file "\"" " style=\"width:"
(match-string 1 desc)
"\""
"/><br>"
(replace-regexp-in-string "\s*>.+" "" desc)
"</td>")
(format "<td><img src=\"%s\" alt=\"%s\"/><br>%s</td>"
file file
(replace-regexp-in-string "\s*>.+" "" desc))))))
#+end_src
Example:
#+begin_src org
,#+CAPTION: Lorem impsum dolor
,#+ATTR_LaTeX: :options \centering
,#+begin_figure
@@html:<div class="org-center"><table style="margin-left:auto;margin-right:auto;"><tr>@@
[[subfig:img1.jpg][Caption of img1 >(width=.3\textwidth) >{300px}]]
[[subfig:img2.jpg][Caption of img2 >(width=.3\textwidth) >{300px}]]
@@html:</tr></table><p> </p><table style="margin-left:auto;margin-right:auto;"><tr>@@
[[subfig:img3.jpg][Caption of img3 >(width=.6\textwidth) >{600px}]]
@@html:</tr></table><br>Lorem ipsum dolor</div>@@
,#+end_figure
#+end_src
As you can see, it is not the panacea, and you have to apply some direct format...
Happy holidays
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 7%]
* Re: *strong* markup not honored at boundary of macro input during HTML export
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
@ 2020-12-23 16:05 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-23 16:05 UTC (permalink / raw)
To: m27315; +Cc: orgmode
You're welcome. Some time ago I had a similar problem with a LaTeX
command with arguments that I wanted to include in a macro. Since the
character U+200b is a kind of "ghost space", it can act as an "invisible
barrier" between the emphasis marks and the characters that precede or
follow them. An emergency cure ;-)
Regards,
Juan Manuel
m27315 <m27315@gmail.com> writes:
> Worked like a charm. Thanks, Juan!
>
> On 2020-12-23 9:22 AM, Juan Manuel Macías wrote:
>> quote (eval (concat "@@html:<span class=\"quote\">“@@" "\u200B" $1 "\u200B" "@@html:”</span>@@"))
>
^ permalink raw reply [relevance 10%]
* Re: *strong* markup not honored at boundary of macro input during HTML export
@ 2020-12-23 15:22 10% ` Juan Manuel Macías
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-23 15:22 UTC (permalink / raw)
To: m27315; +Cc: orgmode
Hello, a possible dirty solution could be defining the macro with two
Unicode zero-width spaces (u+200b):
#+MACRO: quote (eval (concat "@@html:<span class=\"quote\">“@@" "\u200B" $1 "\u200B" "@@html:”</span>@@"))
Regards,
Juan Manuel
m27315 <m27315@gmail.com> writes:
> Resending as plain-text ... If somebody could point me in the direction of
> the code that might be responsible for this, I'll try to take a look.
>
> ....
>
> If the following org file is exported as HTML, any *strong* markup for words
> at the beginning or the end of the input string are ignored. (I have
> included several slight variations to help testing.)
>
> #+TITLE: Test MACRO with *strong* Markup Input
> #+OPTIONS: date:nil timestamp:nil num:nil stat:t title:t toc:nil
>
> #+MACRO: quote @@html:<span class="quote">“@@$1@@html:”</span>@@
>
> * Test macro with non-marked text:
> Demonstrating that, {{{quote(This is a vanilla quote without markup)}}},
> Abraham Lincoln.
>
> {{{quote(This is a similar control quote without markup)}}}, George
> Washington said.
>
> * Test macro with leading *strongly* marked text:
> Wilson quipped, {{{quote(*Not all* quotes are important!)}}}.
>
> {{{quote(*But this* is a very important quote)}}}, Thomas Jefferson replied.
>
> * Test macro with trailing *strongly* marked text:
> Retorted Yoda, {{{quote(Critical if not uncertain\, all *my quotes are*)}}}.
>
> {{{quote(I am certain they are *all uncertain*)}}}, Anakin sneered.
>
> * Test macro with leading, middle, and trailing marked text:
> Darth Vader threatened, {{{quote(*All* of *my quotes* are *heeded
> carefully!*)}}}.
>
> {{{quote(*Nobody* listens to *meesa* quotes. *Why?*)}}}, Jar-Jar whined.
>
> The condensed filtered HTML output is:
>
> ...
> <h2 id="org40a1103">Test macro with non-marked text:</h2>
> <p>Demonstrating that, <span class="quote">“This is a vanilla
> quote without markup”</span>, Abraham Lincoln.</p>
> <p><span class="quote">“This is a similar control quote without
> markup”</span>, George Washington said.</p>
>
> <h2 id="org962a914">Test macro with leading <b>strongly</b> marked
> text:</h2>
> <p>Wilson quipped, <span class="quote">“*Not all* quotes are
> important!”</span>.</p>
> <p><span class="quote">“*But this* is a very important
> quote”</span>, Thomas Jefferson replied.</p>
>
> <h2 id="org47bf84f">Test macro with trailing <b>strongly</b> marked
> text:</h2>
> <p>Retorted Yoda, <span class="quote">“Critical if not uncertain,
> all *my quotes are*”</span>.</p>
> <p><span class="quote">“I am certain they are *all
> uncertain*”</span>, Anakin sneered.</p>
>
> <h2 id="org08c1694">Test macro with leading, middle, and trailing marked
> text:</h2>
> <p>Darth Vader threatened, <span class="quote">“*All* of <b>my
> quotes</b> are *heeded carefully!*”</span>.</p>
> <p><span class="quote">“*Nobody* listens to <b>meesa</b> quotes.
> *Why?*”</span>, Jar-Jar whined.</p>
> ...
>
> Notice how the *strong* marks are only transformed into <b></b> tags inside
> a string, not at the boundaries.
>
> Can anybody confirm or explain what I am doing wrong?
>
> Thanks!
>
> Trevor
>
>
^ permalink raw reply [relevance 10%]
* Re: [TIP] Export to LaTeX and HTML with a watermark
2020-12-23 2:11 8% [TIP] Export to LaTeX and HTML with a watermark Juan Manuel Macías
@ 2020-12-23 2:38 6% ` Thomas S. Dye
0 siblings, 0 replies; 144+ results
From: Thomas S. Dye @ 2020-12-23 2:38 UTC (permalink / raw)
To: emacs-orgmode
Nice!
This is the kind of thing I like to find here:
https://orgmode.org/worg/org-hacks.html
Please consider adding it to Worg!
All the best,
Tom
Juan Manuel Macías writes:
> Hi,
>
> Recently, I needed to export a document to both LaTeX and HTML
> with a
> watermark background. I came to write this little function (for
> LaTeX,
> the 'draftwatermark' package is used; for html, a bit of CSS.
> The
> optional arg `text' is the text of the watermark; by default
> what is
> printed is "DRAFT"):
>
> #+begin_src org
> ,#+begin_src emacs-lisp :exports results :results none
> (defun my-watermark (&optional text)
> (cond ((org-export-derived-backend-p
> org-export-current-backend 'latex)
> (concat "#+LaTeX_Header:\\usepackage"
> (if text
> (format "[text=%s]" (replace-regexp-in-string " " "~"
> text))
> "")
> "{draftwatermark}"))
> ((org-export-derived-backend-p org-export-current-backend
> 'html)
> (concat "@@html:<p id=\"watermark\">"
> (if text
> (format "%s" text)
> "DRAFT")
> "</p>@@"))))
>
> ,#+end_src
> #+end_src
>
> The CSS could be (source:
> https://stackoverflow.com/questions/68569/text-watermark-on-website-how-to-do-it):
>
> #+begin_src org
> ,#+html_HEAD: <style>#watermark {color: #d0d0d0; font-size:
> 200pt; -webkit-transform: rotate(-45deg); -moz-transform:
> rotate(-45deg); position: absolute; width: 100%; height: 100%;
> margin: 0; z-index: -1; left:-100px; top:-200px;}</style>
> #+end_src
>
> And then, this replacement macro:
>
> #+begin_src org
> ,#+MACRO: wmark (eval (if (org-string-nw-p $1)(my-watermark
> $1)(my-watermark)))
> #+end_src
>
> And finally, an example:
>
> #+begin_src org
> {{{wmark(Top secret!)}}}
>
> Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
> accumsan nisl.
>
> (...)
> #+end_src
>
> Regards,
>
> Juan Manuel
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 6%]
* [TIP] Export to LaTeX and HTML with a watermark
@ 2020-12-23 2:11 8% Juan Manuel Macías
2020-12-23 2:38 6% ` Thomas S. Dye
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-23 2:11 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
Hi,
Recently, I needed to export a document to both LaTeX and HTML with a
watermark background. I came to write this little function (for LaTeX,
the 'draftwatermark' package is used; for html, a bit of CSS. The
optional arg `text' is the text of the watermark; by default what is
printed is "DRAFT"):
#+begin_src org
,#+begin_src emacs-lisp :exports results :results none
(defun my-watermark (&optional text)
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
(concat "#+LaTeX_Header:\\usepackage"
(if text
(format "[text=%s]" (replace-regexp-in-string " " "~" text))
"")
"{draftwatermark}"))
((org-export-derived-backend-p org-export-current-backend 'html)
(concat "@@html:<p id=\"watermark\">"
(if text
(format "%s" text)
"DRAFT")
"</p>@@"))))
,#+end_src
#+end_src
The CSS could be (source:
https://stackoverflow.com/questions/68569/text-watermark-on-website-how-to-do-it):
#+begin_src org
,#+html_HEAD: <style>#watermark {color: #d0d0d0; font-size: 200pt; -webkit-transform: rotate(-45deg); -moz-transform: rotate(-45deg); position: absolute; width: 100%; height: 100%; margin: 0; z-index: -1; left:-100px; top:-200px;}</style>
#+end_src
And then, this replacement macro:
#+begin_src org
,#+MACRO: wmark (eval (if (org-string-nw-p $1)(my-watermark $1)(my-watermark)))
#+end_src
And finally, an example:
#+begin_src org
{{{wmark(Top secret!)}}}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
accumsan nisl.
(...)
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 8%]
* Displaying verse numbers within a verse block
@ 2020-12-20 21:37 9% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-20 21:37 UTC (permalink / raw)
To: orgmode
Hi,
One of the many, many things where I use Org Mode is my Spanish translation of Homer's
Odyssey (work in progress). To avoid getting lost inside each Book, I wrote this little
code that helps me navigate through the verses, displaying in the margin (within a verse
block) the verse numbers in sequence of 5 (not counting the empty lines), or allowing
me to jump to a certain verse number.
I've uploaded the code to GitLab in case it could be useful to anyone who also has to work
with long runs of verses (hundreds, thousands...). Of course, this is something I wrote for
my own work, and I'm not a professional programmer either, so the code can be improved for
sure ;-)
https://gitlab.com/maciaschain/org-verse-num
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* [PATCH] A proposal to add LaTeX attributes to verse blocks
@ 2020-12-17 17:23 5% Juan Manuel Macías
2021-01-03 10:25 6% ` TEC
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-17 17:23 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 4811 bytes --]
(Sorry, due to a mistake, the text of my message did not appear in my previous email)
Hi,
I would like to propose this patch to add some LaTeX attributes to the verse block,
especially to be able to apply certain features from the verse.sty package, which is an
extension (widely used in Humanities) of the standard LaTeX 'verse' environment.
These attributes would be:
- `:lines' to add verse numbers, according to any numbering sequence
- `:center' to apply the optical centering of the poem, which is a typographic convention
whereby a poem or a group of verses is centered on the page, taking the width of the
longest verse as a reference. In fact, optical centering is the correct arrangement of
verses in a document.
- `:versewidth' which expects a text string that is the longest verse of the poem,
required when applying the `:center' attribute.
As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
attribute would be used to add arbitrary code within the verse environment.
Consider this complete example with Shakespeare's first sonnet:
#+begin_src org
,#+ATTR_LaTeX: :center t :options \small :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
when exporting to LaTeX we get:
#+begin_src latex
\settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
\begin{verse}[\versewidth]
\poemlines{5}
\small
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
In an attached image I send a screenshot with the typographic result
And finally, this is the patch I would propose
#+begin_src diff
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a14b25d5..bc6b64e78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,16 @@ 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))
+ (opt (org-export-read-attribute :attr_latex verse-block :options))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if opt (format "\n%s" opt) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3513,7 +3523,9 @@ 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}"
+ vwidth-attr
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
@@ -3524,7 +3536,7 @@ contextual information."
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))))
#+end_src
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply related [relevance 5%]
* [patch] A proposal to add LaTeX attributes to verse blocks
@ 2020-12-17 17:11 5% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-17 17:11 UTC (permalink / raw)
To: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 4802 bytes --]
Hi,
I would like to propose this patch to add some LaTeX attributes to verse blocks,
especially to be able to apply certain features from the verse.sty package, which is an
extension (widely used in Humanities) of the standard LaTeX 'verse'
environment (see https://www.ctan.org/pkg/verse).
These attributes would be:
- `:lines' to add verse numbers, according to any numbering sequence
- `:center' to apply the optical centering of the poem, which is a typographic convention
whereby a poem or a group of verses is centered (as a 'block') on the page, taking the width of the
longest verse as a reference. In fact, optical centering is the correct arrangement of
verses in a document.
- `:versewidth' which expects a literal string that is the longest verse of the poem,
required when applying the `:center' attribute.
As I said, these three attributes require the LateX package verse.sty. A fourth `:options'
attribute would be used to add arbitrary code within the verse environment.
Consider this complete example with Shakespeare's first sonnet:
#+begin_src org
,#+ATTR_LaTeX: :center t :options \small :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
when exporting to LaTeX we get:
#+begin_src latex
\settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
\begin{verse}[\versewidth]
\poemlines{5}
\small
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
In an attached image I send a screenshot with the typographic result
And finally, this is the patch I would propose
#+begin_src diff
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a14b25d5..bc6b64e78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,16 @@ 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))
+ (opt (org-export-read-attribute :attr_latex verse-block :options))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if opt (format "\n%s" opt) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
+ (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3513,7 +3523,9 @@ 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}"
+ vwidth-attr
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
@@ -3524,7 +3536,7 @@ contextual information."
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))))
#+end_src
Regards,
Juan Manuel
[-- Attachment #1.2: Type: text/html, Size: 1 bytes --]
[-- Attachment #2: verse-test.png --]
[-- Type: image/png, Size: 286585 bytes --]
^ permalink raw reply related [relevance 5%]
* [Small suggestion] on exporting verse blocks to LaTeX and vertical spaces
@ 2020-12-15 17:21 8% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-15 17:21 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
Hi,
When exporting a verse block to LaTeX, each empty line between
'stanzas' results in the command =\vspace*{1em}=, which is fine.
However, I would dare to suggest that, in order to be more consistent
with the LaTeX `verse' environment (both the one that comes by
default and the one provided by the verse.sty package) the separation
between stanzas should be marked with:
- the last line of the stanza without =\\=
- + one (at least) empty line
which is the correct (or at least the most common) way to separate the
stanzas within this environment, since each stanza is still a
paragraph whose lines are cut off. Thus, we could also redefine
globally the \stanzaskip length provided by the verse.sty package
(i.e. \setlength{\stanzaskip}{1.2em plus .2em minus .5em}, etc.).
For example, with this (the number of white lines does not matter):
#+begin_src org
,#+begin_verse
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
Lorem ipsum dolor sit amet
consectetuer adipiscing elit
,#+end_verse
#+end_src
we should get:
#+begin_src latex
\begin{verse}
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
Lorem ipsum dolor sit amet\\
consectetuer adipiscing elit\\
\end{verse}
#+end_src
Perhaps replacing these lines in =org-latex-verse-block=
#+begin_src emacs-lisp
(replace-regexp-in-string
"^[ \t]*\\\\\\\\$" "\\vspace*{1em}"
#+end_src
with something like this
#+begin_src emacs-lisp
(replace-regexp-in-string
"\\(\\\\\\\\\n\\)+\\([ \t]*\\\\\\\\\\)+" "\n"
#+end_src
?
(On the other hand, I also think that vertical spaces between groups
of lines in verse blocks should always be exported to any format as
a single fixed space, regardless of how many empty lines there are).
Regards,
Juan Manuel
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [relevance 8%]
* Re: #+include and org-export-before-processing-hook
2020-12-13 17:26 10% ` Juan Manuel Macías
@ 2020-12-13 20:05 6% ` Nicolas Goaziou
0 siblings, 0 replies; 144+ results
From: Nicolas Goaziou @ 2020-12-13 20:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I have the same problem with a function that I wrote to not export
> certain footnotes, and to date I have not been able to fix it. According
> to the `org-export-before-processing-hook' docstring:
>
> " *This is run before include keywords and macros are expanded*
> and Babel code blocks executed, on a copy of the original buffer
> being exported. Visibility and narrowing are preserved. Point
> is at the beginning of the buffer.
There is also `org-export-before-parsing-hook'.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Re: #+include and org-export-before-processing-hook
@ 2020-12-13 17:26 10% ` Juan Manuel Macías
2020-12-13 20:05 6% ` Nicolas Goaziou
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-13 17:26 UTC (permalink / raw)
To: Eric S Fraga; +Cc: orgmode
Hello,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Hello,
>
> I have a particular function that I want to invoke when exporting an org
> file. This works just fine, adding this function to the
> org-export-before-processing-hook, for simple org files. However, if I
> have an org file which uses #+include: to include other org files, it
> seems like the processing doesn't happen on included files.
I have the same problem with a function that I wrote to not export
certain footnotes, and to date I have not been able to fix it. According
to the `org-export-before-processing-hook' docstring:
" *This is run before include keywords and macros are expanded*
and Babel code blocks executed, on a copy of the original buffer
being exported. Visibility and narrowing are preserved. Point
is at the beginning of the buffer.
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Accessing a DLNA server through an Org link
@ 2020-12-10 22:17 9% Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-10 22:17 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Hi,
I'm storing in an Org document a list of links to all my media files
(videos, music, and the like). This is a little trick that I came up
with to access the multimedia content of my raspberry's dlna server
(minidlna), using an Org link and the Javier López
'simple-dlna-browser' script
(https://github.com/javier-lopez/learn/blob/master/sh/tools/simple-dlna-browser).
You need to install socat:
#+begin_src emacs-lisp
(org-link-set-parameters
"dlna"
:follow (lambda (file)
(let ((command (concat "~/Scripts/./simple-dlna-browser.sh "
"\""
file
"\""
" | xargs vlc")))
(start-process-shell-command command nil command)))
:face '(:foreground "green4" :weight bold :underline t))
#+end_src
Tested on Arch Linux. As an external player I use vlc; `file' can simply be the name of
the file. For example, if we have gattaca.mp4 on our server, the link could be:
#+begin_src org
[[dlna:gattaca]]
#+end_src
Well, it works reasonably well. But I wonder if anyone knows of any
package or library to be able to do this (accessing a dlna server) in
a more emacs/org-centric way ...
Regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
[not found] ` <69288122-6dfb-4235-47bf-d38344c730b0@gmail.com>
@ 2020-12-09 15:31 6% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-09 15:31 UTC (permalink / raw)
To: Charis Michelakis; +Cc: orgmode
You're welcome ;-)
Charis Michelakis <ch.p.mxs@gmail.com> writes:
> Thank you :)
>
> On 12/9/20 5:06 PM, Juan Manuel Macías wrote:
>> Hello,
>>
>> Charis Michelakis <ch.p.mxs@gmail.com> writes:
>>
>>> There is a potential bug regarging how footnotes on headers are
>>> converted to LaTeX.
>>>
>>> Consider the following org file:
>>> ------start-of-file-----------
>>>
>>> #+AUTHOR: Me
>>> #+LATEX_HEADER: \usepackage{titlesec}
>>>
>>> * Header1[fn:1]
>>>
>>> * Footnotes
>>>
>>> [fn:1]Lorem ipsum
>> It is a LaTeX problem, as the footnote command is a 'fragile' command and should not
>> be put in a section. Try this:
>>
>> * Header1[fn:1]
>> :PROPERTIES:
>> :ALT_TITLE: Header1
>> :END:
>>
>> * Footnotes
>> [fn:1]Lorem ipsum
>>
>> in latex it is exported as
>>
>> \section[Header1]{Header1\footnote{Lorem ipsum}}
>>
>> Regards,
>>
>> Juan Manuel
>
^ permalink raw reply [relevance 6%]
* Re: Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
@ 2020-12-09 15:06 10% ` Juan Manuel Macías
[not found] ` <69288122-6dfb-4235-47bf-d38344c730b0@gmail.com>
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-09 15:06 UTC (permalink / raw)
To: Charis Michelakis; +Cc: orgmode
Hello,
Charis Michelakis <ch.p.mxs@gmail.com> writes:
> There is a potential bug regarging how footnotes on headers are
> converted to LaTeX.
>
> Consider the following org file:
> ------start-of-file-----------
>
> #+AUTHOR: Me
> #+LATEX_HEADER: \usepackage{titlesec}
>
> * Header1[fn:1]
>
> * Footnotes
>
> [fn:1]Lorem ipsum
It is a LaTeX problem, as the footnote command is a 'fragile' command and should not
be put in a section. Try this:
* Header1[fn:1]
:PROPERTIES:
:ALT_TITLE: Header1
:END:
* Footnotes
[fn:1]Lorem ipsum
in latex it is exported as
\section[Header1]{Header1\footnote{Lorem ipsum}}
Regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Footnote definition within a verse block has spurious line breaks when exported to LaTeX
2020-12-05 9:09 6% ` Nicolas Goaziou
@ 2020-12-05 13:47 10% ` Juan Manuel Macías
0 siblings, 0 replies; 144+ results
From: Juan Manuel Macías @ 2020-12-05 13:47 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> This is hopefully fixed in master branch. Let me knows if it works for
> you.
Thank you, Nicolas. I've tried it and it works perfectly. I see that
\footnotemark\footnotetext is used now, same as in tables. I
think it's a great solution.
Best,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Footnote definition within a verse block has spurious line breaks when exported to LaTeX
2020-12-01 12:08 6% Footnote definition within a verse block has spurious line breaks when exported to LaTeX Juan Manuel Macías
@ 2020-12-05 9:09 6% ` Nicolas Goaziou
2020-12-05 13:47 10% ` Juan Manuel Macías
0 siblings, 1 reply; 144+ results
From: Nicolas Goaziou @ 2020-12-05 9:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hello,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> When a verse block includes a footnote reference, the
> corresponding footnote definition is
> understood in the LaTeX export as if it were part of the verses.
> In other words, every
> line in a =\footnote{}= macro ends with the string =\\=, and the
> spaces between paragraphs are understood as spaces
> between stanzas (\vspace*{1em}). If the text of the footnote
> definition contains one or more filled
> paragraphs, then the export result is catastrophic.
>
> For example, if we have something like this:
>
> #+begin_src org
> ,#+begin_verse
> lorem
> ipsum[fn:1]
> dolor
> ,#+end_verse
>
> [fn:1] Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
> Donec hendrerit tempor
> tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt
> et, mattis eget,
> convallis nec, purus.
>
> Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
> hendrerit tempor tellus.
> Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
> mattis eget, convallis nec,
> purus.
> #+end_src
This is hopefully fixed in master branch. Let me knows if it works for
you.
Thank you for the report.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [relevance 6%]
* Footnote definition within a verse block has spurious line breaks when exported to LaTeX
@ 2020-12-01 12:08 6% Juan Manuel Macías
2020-12-05 9:09 6% ` Nicolas Goaziou
0 siblings, 1 reply; 144+ results
From: Juan Manuel Macías @ 2020-12-01 12:08 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]
Hi,
When a verse block includes a footnote reference, the
corresponding footnote definition is
understood in the LaTeX export as if it were part of the verses.
In other words, every
line in a =\footnote{}= macro ends with the string =\\=, and the
spaces between paragraphs are understood as spaces
between stanzas (\vspace*{1em}). If the text of the footnote
definition contains one or more filled
paragraphs, then the export result is catastrophic.
For example, if we have something like this:
#+begin_src org
,#+begin_verse
lorem
ipsum[fn:1]
dolor
,#+end_verse
[fn:1] Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Donec hendrerit tempor
tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt
et, mattis eget,
convallis nec, purus.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus.
Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec,
purus.
#+end_src
in LaTeX we get this:
#+begin_src latex
\begin{verse}
lorem\\
ipsum\footnote{Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec hendrerit tempor\\
tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt
et, mattis eget,\\
convallis nec, purus.\\
\vspace*{1em}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec
hendrerit tempor tellus.\\
Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec,\\
purus.}\\
dolor\\
\end{verse}
#+end_src
Since footnotes are allowed within a LaTeX =verse= environment, I
think
this behavior should be fixed.
I'm wondering if it would make sense to modify the
=org-latex-verse-block= function, in order to "save" the text
formatting
of the footnote definition, something like this (apologies in
advance
for my rudimentary Elisp: what I'm proposing is more of a
concept, or a pedestrian solution, than a actual patch ;-):
#+begin_src emacs-lisp
(defun preserve-footnote-definition-in-verse-block (cont)
(with-temp-buffer
(insert cont)
(save-excursion
(goto-char (point-max))
(while (re-search-backward "}" nil t)
(let ((from (point))
(to (save-excursion
(re-search-backward "\\\\footnote{" nil t)
(point))))
(save-restriction
(narrow-to-region from to)
(goto-char (point-min))
(while (re-search-forward "\n\n+" nil t)
(replace-match "\\\\par\s" t nil))
(goto-char (point-min))
(while (re-search-forward "\n" nil t)
(replace-match "\s" t nil))))))
(buffer-string)))
(defun org-latex-verse-block (verse-block contents info)
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
(org-latex--wrap-label
verse-block
;; In a verse environment, add a line break to each newline
;; 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}"
(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"
(preserve-footnote-definition-in-verse-block
contents) nil t) nil t) nil t))
info))
#+end_src
Best,
Juan Manuel
^ permalink raw reply [relevance 6%]
Results 1401-1544 of 1544 prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-11-28 16:59 Remembrance Agents Gerardo Moro
2020-11-28 18:26 ` Jean Louis
2020-11-29 13:07 ` Gerardo Moro
2020-11-29 13:52 ` Eric S Fraga
2020-11-29 17:29 ` Jean Louis
2020-11-29 17:47 ` Eric S Fraga
2020-11-30 11:15 ` Jean Louis
2021-01-06 6:41 ` Possibility to copy text outside EMACS and send it to orgmode document Gerardo Moro
2021-01-06 16:31 10% ` Juan Manuel Macías
2020-12-01 12:08 6% Footnote definition within a verse block has spurious line breaks when exported to LaTeX Juan Manuel Macías
2020-12-05 9:09 6% ` Nicolas Goaziou
2020-12-05 13:47 10% ` Juan Manuel Macías
2020-12-08 11:35 Bug: Footnotes on Headers and LaTeX export [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] Charis Michelakis
2020-12-09 15:06 10% ` Juan Manuel Macías
[not found] ` <69288122-6dfb-4235-47bf-d38344c730b0@gmail.com>
2020-12-09 15:31 6% ` Juan Manuel Macías
2020-12-10 22:17 9% Accessing a DLNA server through an Org link Juan Manuel Macías
2020-12-13 16:28 #+include and org-export-before-processing-hook Eric S Fraga
2020-12-13 17:26 10% ` Juan Manuel Macías
2020-12-13 20:05 6% ` Nicolas Goaziou
2020-12-15 17:21 8% [Small suggestion] on exporting verse blocks to LaTeX and vertical spaces Juan Manuel Macías
2020-12-17 17:11 5% [patch] A proposal to add LaTeX attributes to verse blocks Juan Manuel Macías
2020-12-17 17:23 5% [PATCH] " Juan Manuel Macías
2021-01-03 10:25 6% ` TEC
2021-01-03 13:07 10% ` Juan Manuel Macías
2021-01-03 13:08 5% ` TEC
2021-01-07 18:52 5% ` Juan Manuel Macías
2020-12-20 21:37 9% Displaying verse numbers within a verse block Juan Manuel Macías
2020-12-22 17:12 *strong* markup not honored at boundary of macro input during HTML export m27315
2020-12-23 14:58 ` m27315
2020-12-23 15:22 10% ` Juan Manuel Macías
[not found] ` <7e5e7cbe-31d6-2d9e-e450-9c1b54dba95e@gmail.com>
2020-12-23 16:05 10% ` Juan Manuel Macías
2020-12-23 2:11 8% [TIP] Export to LaTeX and HTML with a watermark Juan Manuel Macías
2020-12-23 2:38 6% ` Thomas S. Dye
2020-12-25 16:02 7% [tip] Export subfigures to LaTeX (and HTML) Juan Manuel Macías
2020-12-28 18:03 5% ` John Kitchin
2020-12-29 15:00 9% ` Juan Manuel Macías
2020-12-27 13:02 A way to avoid unwanted new lines when using paragraph quotes? Kashyap Chamarthy
2020-12-27 13:55 10% ` Juan Manuel Macías
2020-12-27 15:52 ` Diego Zamboni
2020-12-27 18:33 ` Kashyap Chamarthy
2020-12-27 19:17 9% ` Juan Manuel Macías
2020-12-27 21:15 6% ` Kashyap Chamarthy
2020-12-27 16:44 Bug: Tildes in URL impact visible link text [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] Chris Hunt
2020-12-27 18:12 10% ` Juan Manuel Macías
2020-12-27 20:14 6% ` tomas
2020-12-27 21:33 10% ` Juan Manuel Macías
2020-12-28 13:38 10% Org to ConTeXt exporter? Juan Manuel Macías
2020-12-28 15:04 6% ` Marcin Borkowski
2020-12-28 15:38 10% ` Juan Manuel Macías
2020-12-28 16:09 5% ` Jonathan McHugh
2020-12-28 17:54 7% ` Juan Manuel Macías
2020-12-28 19:06 5% ` Jonathan McHugh
2020-12-29 21:51 5% ` Jonathan McHugh
2020-12-28 16:23 0% ` Diego Zamboni
2020-12-28 18:03 10% ` Juan Manuel Macías
2020-12-28 19:23 6% ` Diego Zamboni
2020-12-28 20:03 5% ` Marcin Borkowski
2020-12-29 16:05 9% ` Juan Manuel Macías
2021-01-08 2:37 5% ` Jason Ross
2021-01-09 17:42 10% ` Juan Manuel Macías
2021-01-13 1:16 6% ` Jason Ross
2021-01-08 3:52 6% ` Jason Ross
2021-01-05 18:33 Inserting LaTex expressions using a filter fails Mart van de Wege
2021-01-05 21:58 10% ` Juan Manuel Macías
2021-01-06 7:50 6% ` Mart van de Wege
2021-01-06 11:51 10% ` Juan Manuel Macías
2021-01-06 12:00 6% ` Mart van de Wege
2021-01-06 12:24 10% ` Juan Manuel Macías
2021-01-06 15:17 6% ` Mart van de Wege
2021-01-06 15:58 10% ` Juan Manuel Macías
2021-01-06 16:00 6% ` Mart van de Wege
2021-01-12 22:30 9% A minor mode for inserting things while typing Juan Manuel Macías
2021-01-19 22:05 Region-based meta-notes Lawrence Bottorff
2021-01-19 22:39 10% ` Juan Manuel Macías
2021-01-22 9:20 Dealing with wide labels in description environment Loris Bennett
2021-01-22 11:20 9% ` Juan Manuel Macías
2021-01-22 12:37 6% ` Loris Bennett
2021-01-23 11:03 7% [Tip] Export a bibliography to HTML with bibLaTeX and make4ht Juan Manuel Macías
2021-01-24 11:37 4% ` Gustavo Barros
2021-01-24 13:00 ` Gustavo Barros
2021-01-24 19:20 6% ` Juan Manuel Macías
2021-01-24 22:44 4% ` Gustavo Barros
2021-01-25 17:46 9% ` Juan Manuel Macías
2021-01-25 18:30 5% ` Gustavo Barros
2021-01-29 16:03 9% org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30 5:10 6% ` Ihor Radchenko
2021-01-30 13:38 9% ` Juan Manuel Macías
2021-01-31 3:33 5% ` Ihor Radchenko
2021-01-31 10:29 9% ` Juan Manuel Macías
2021-01-31 10:52 5% ` Ihor Radchenko
2021-01-31 11:41 10% ` Juan Manuel Macías
2021-01-31 13:16 10% ` Juan Manuel Macías
2021-01-31 13:40 5% ` Ihor Radchenko
2021-01-31 14:36 10% ` Juan Manuel Macías
2021-01-31 19:37 6% [patch] to allow org-attach-git to handle individual repositories Juan Manuel Macías
2021-02-01 9:10 http links translated to html : target "_blank" Uwe Brauer
2021-02-01 11:03 9% ` Juan Manuel Macías
2021-02-01 13:56 1% ` Uwe Brauer
2021-02-01 14:46 8% ` Juan Manuel Macías
2021-02-01 15:20 0% ` Uwe Brauer
2021-02-01 21:01 10% ` Juan Manuel Macías
2021-02-04 14:07 0% ` Uwe Brauer
2021-02-01 12:51 emphasizing source code words Luca Ferrari
2021-02-01 12:55 ` TEC
2021-02-04 11:38 ` Luca Ferrari
2021-02-04 12:13 9% ` Juan Manuel Macías
2021-02-01 15:17 word counts and org-mode drawers Sharon Kimble
2021-02-01 23:29 10% ` Juan Manuel Macías
2021-02-04 13:50 1% ` Sharon Kimble
2021-02-09 10:13 local variables and export processing in hooks Eric S Fraga
2021-02-09 11:30 ` tomas
2021-02-09 12:06 ` Eric S Fraga
2021-02-10 15:43 6% ` Maxim Nikulin
2021-02-12 13:01 9% Macros and possible alternatives to the comma character (enhancement?) Juan Manuel Macías
2021-02-13 20:38 7% [Tip] Write the LaTeX preamble in a source block Juan Manuel Macías
2021-02-15 17:37 10% 'false' list item Juan Manuel Macías
2021-02-21 6:56 6% ` Kyle Meyer
2021-02-21 7:05 0% ` Tim Cross
2021-02-21 14:49 10% ` Juan Manuel Macías
2021-02-21 19:33 10% ` Juan Manuel Macías
2021-02-21 19:40 7% ` Diego Zamboni
2021-02-21 21:27 0% ` Samuel Wales
2021-02-21 22:25 10% ` Juan Manuel Macías
2021-02-21 22:31 ` Tim Cross
2021-02-22 0:21 9% ` Juan Manuel Macías
2021-02-21 22:55 6% ` Kyle Meyer
2021-02-16 16:30 9% [question] lisp code in :results header arg.? Juan Manuel Macías
2021-02-16 17:58 0% ` Berry, Charles via General discussions about Org-mode.
2021-02-16 18:25 10% ` Juan Manuel Macías
2021-02-18 16:33 6% [PATCH] Startup option to separate macros arguments with an alternative string Juan Manuel Macías
2021-02-23 18:23 10% false-list-item-mode? Juan Manuel Macías
2021-02-25 22:16 7% Add color space and icc profile information to images Juan Manuel Macías
[not found] <mailman.47.1614445226.20994.emacs-orgmode@gnu.org>
2021-02-27 18:57 ` content management in emacs Ian Garmaise
2021-02-27 19:16 ` Martin Steffen
2021-02-27 20:11 9% ` Juan Manuel Macías
2021-02-28 20:21 printing org table landscape on complete page Andrés Ramírez
2021-02-28 20:53 10% ` Juan Manuel Macías
2021-03-01 0:18 2% ` andrés ramírez
2021-03-01 12:55 9% [tip for EXWM users] An alternative method for isolate trees Juan Manuel Macías
2021-03-01 13:37 6% ` Julian M. Burgos
2021-03-01 14:10 10% ` Juan Manuel Macías
2021-03-01 15:37 5% ` Julian M. Burgos
2021-03-01 16:42 9% ` Juan Manuel Macías
2021-03-02 20:07 Org mode links: Open a PDF file at a given page and highlight a given string Rodrigo Morales
2021-03-03 2:31 9% ` Juan Manuel Macías
2021-03-03 14:51 6% ` Maxim Nikulin
2021-03-03 16:11 9% ` Juan Manuel Macías
2021-03-05 13:02 4% ` Maxim Nikulin
2021-03-04 15:38 Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)] Qqwy/Wiebe-Marten
2021-03-05 12:01 9% ` Juan Manuel Macías
2021-03-06 19:34 7% Org as a book publisher Juan Manuel Macías
2021-03-07 9:17 5% ` M. ‘quintus’ Gülker
2021-03-07 15:57 6% ` Juan Manuel Macías
2021-03-07 12:08 6% ` Diego Zamboni
2021-03-07 13:15 0% ` Vikas Rawal
2021-03-07 16:03 8% ` Juan Manuel Macías
2021-03-08 10:46 6% ` Jonathan McHugh
2021-03-07 17:46 ` Dr. Arne Babenhauserheide
2021-03-07 18:30 8% ` Juan Manuel Macías
[not found] ` <87ft16hn62.fsf@emailmessageidheader.nil>
2021-03-07 20:20 10% ` Juan Manuel Macías
2021-03-15 17:10 9% Nested macros and fontification Juan Manuel Macías
2021-03-17 20:29 Syntax Proposal: Multi-line Table Cells/Text Wrapping Atlas Cove
2021-03-17 22:07 9% ` Juan Manuel Macías
2021-03-18 13:38 ` Atlas Cove
2021-03-18 15:15 10% ` Juan Manuel Macías
2021-03-18 14:26 ` Timothy
2021-03-18 14:31 ` Atlas Cove
2021-03-18 21:58 ` Tim Cross
2021-03-18 22:41 10% ` Juan Manuel Macías
2021-03-19 8:08 5% ` tomas
2021-03-19 8:44 10% ` Juan Manuel Macías
2021-03-19 8:53 5% ` tomas
2021-03-19 9:22 9% ` Juan Manuel Macías
2021-03-19 10:14 6% ` tomas
2021-03-19 10:53 9% ` Juan Manuel Macías
2021-03-19 11:08 12% ` Juan Manuel Macías
2021-03-19 13:43 6% ` tomas
2021-03-19 15:07 9% ` Juan Manuel Macías
2021-03-20 22:49 6% ` Samuel Wales
2021-03-21 8:43 9% ` Juan Manuel Macías
2021-03-19 13:33 ` Eric S Fraga
2021-03-19 21:33 ` Tim Cross
2021-03-20 10:40 8% ` Juan Manuel Macías
2021-03-22 21:59 10% Items with emphasis marks are not sorted properly in a list Juan Manuel Macías
2021-03-23 8:36 13% ` Juan Manuel Macías
2021-03-24 1:33 "Org" source blocks and minted Michael Gauland
2021-03-24 4:18 10% ` 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).